diff options
Diffstat (limited to 'Documentation')
828 files changed, 31430 insertions, 9241 deletions
diff --git a/Documentation/ABI/obsolete/o2cb b/Documentation/ABI/obsolete/o2cb new file mode 100644 index 000000000000..fe7e45e17bc7 --- /dev/null +++ b/Documentation/ABI/obsolete/o2cb @@ -0,0 +1,11 @@ +What: /sys/o2cb +Date: Dec 2005 +KernelVersion: 2.6.16 +Contact: ocfs2-devel@oss.oracle.com +Description: Ocfs2-tools looks at 'interface-revision' for versioning + information. Each logmask/ file controls a set of debug prints + and can be written into with the strings "allow", "deny", or + "off". Reading the file returns the current state. + Was renamed to /sys/fs/u2cb/ +Users: ocfs2-tools. It's sufficient to mail proposed changes to + ocfs2-devel@oss.oracle.com. diff --git a/Documentation/ABI/obsolete/sysfs-bus-iio b/Documentation/ABI/obsolete/sysfs-bus-iio index c9531bb64816..b64394b0b374 100644 --- a/Documentation/ABI/obsolete/sysfs-bus-iio +++ b/Documentation/ABI/obsolete/sysfs-bus-iio @@ -6,6 +6,7 @@ Description: Since Kernel 5.11, multiple buffers are supported. so, it is better to use, instead: + /sys/bus/iio/devices/iio:deviceX/bufferY/length What: /sys/bus/iio/devices/iio:deviceX/buffer/enable @@ -17,6 +18,7 @@ Description: Since Kernel 5.11, multiple buffers are supported. so, it is better to use, instead: + /sys/bus/iio/devices/iio:deviceX/bufferY/enable What: /sys/bus/iio/devices/iio:deviceX/scan_elements @@ -165,6 +167,7 @@ Description: Since Kernel 5.11, multiple buffers are supported. so, it is better to use, instead: + /sys/bus/iio/devices/iio:deviceX/bufferY/watermark What: /sys/bus/iio/devices/iio:deviceX/buffer/data_available @@ -179,4 +182,5 @@ Description: Since Kernel 5.11, multiple buffers are supported. so, it is better to use, instead: + /sys/bus/iio/devices/iio:deviceX/bufferY/data_available diff --git a/Documentation/ABI/stable/o2cb b/Documentation/ABI/stable/o2cb index 5eb1545e0b8d..b62a967f01a0 100644 --- a/Documentation/ABI/stable/o2cb +++ b/Documentation/ABI/stable/o2cb @@ -1,4 +1,4 @@ -What: /sys/fs/o2cb/ (was /sys/o2cb) +What: /sys/fs/o2cb/ Date: Dec 2005 KernelVersion: 2.6.16 Contact: ocfs2-devel@oss.oracle.com diff --git a/Documentation/ABI/stable/sysfs-class-infiniband b/Documentation/ABI/stable/sysfs-class-infiniband index 9b1bdfa43354..ebf08c604336 100644 --- a/Documentation/ABI/stable/sysfs-class-infiniband +++ b/Documentation/ABI/stable/sysfs-class-infiniband @@ -232,10 +232,10 @@ Description: The RoCE type of the associated GID resides at index <gid-index>. or "RoCE v2" for RoCE v2 based GIDs. -What: /sys/class/infiniband_mad/umadN/ibdev -What: /sys/class/infiniband_mad/umadN/port -What: /sys/class/infiniband_mad/issmN/ibdev -What: /sys/class/infiniband_mad/issmN/port +What: /sys/class/infiniband_mad/umad<N>/ibdev +What: /sys/class/infiniband_mad/umad<N>/port +What: /sys/class/infiniband_mad/issm<N>/ibdev +What: /sys/class/infiniband_mad/issm<N>/port Date: Apr, 2005 KernelVersion: v2.6.12 Contact: linux-rdma@vger.kernel.org @@ -261,8 +261,8 @@ Description: userspace ABI compatibility of umad & issm devices. -What: /sys/class/infiniband_verbs/uverbsN/ibdev -What: /sys/class/infiniband_verbs/uverbsN/abi_version +What: /sys/class/infiniband_verbs/uverbs<N>/ibdev +What: /sys/class/infiniband_verbs/uverbs<N>/abi_version Date: Sept, 2005 KernelVersion: v2.6.14 Contact: linux-rdma@vger.kernel.org @@ -471,7 +471,7 @@ Description: =============== ====================================================== -What: /sys/class/infiniband/qibX/ports/N/sl2vl/[0-15] +What: /sys/class/infiniband/qibX/ports/<N>/sl2vl/[0-15] Date: May, 2010 KernelVersion: v2.6.35 Contact: linux-rdma@vger.kernel.org @@ -480,8 +480,8 @@ Description: the Service Level (SL). Listing the SL files returns the Virtual Lane (VL) as programmed by the SL. -What: /sys/class/infiniband/qibX/ports/N/CCMgtA/cc_settings_bin -What: /sys/class/infiniband/qibX/ports/N/CCMgtA/cc_table_bin +What: /sys/class/infiniband/qibX/ports/<N>/CCMgtA/cc_settings_bin +What: /sys/class/infiniband/qibX/ports/<N>/CCMgtA/cc_table_bin Date: May, 2010 KernelVersion: v2.6.35 Contact: linux-rdma@vger.kernel.org @@ -499,11 +499,11 @@ Description: delay. =============== ================================================ -What: /sys/class/infiniband/qibX/ports/N/linkstate/loopback -What: /sys/class/infiniband/qibX/ports/N/linkstate/led_override -What: /sys/class/infiniband/qibX/ports/N/linkstate/hrtbt_enable -What: /sys/class/infiniband/qibX/ports/N/linkstate/status -What: /sys/class/infiniband/qibX/ports/N/linkstate/status_str +What: /sys/class/infiniband/qibX/ports/<N>/linkstate/loopback +What: /sys/class/infiniband/qibX/ports/<N>/linkstate/led_override +What: /sys/class/infiniband/qibX/ports/<N>/linkstate/hrtbt_enable +What: /sys/class/infiniband/qibX/ports/<N>/linkstate/status +What: /sys/class/infiniband/qibX/ports/<N>/linkstate/status_str Date: May, 2010 KernelVersion: v2.6.35 Contact: linux-rdma@vger.kernel.org @@ -523,16 +523,16 @@ Description: "Fatal_Hardware_Error". =============== =============================================== -What: /sys/class/infiniband/qibX/ports/N/diag_counters/rc_resends -What: /sys/class/infiniband/qibX/ports/N/diag_counters/seq_naks -What: /sys/class/infiniband/qibX/ports/N/diag_counters/rdma_seq -What: /sys/class/infiniband/qibX/ports/N/diag_counters/rnr_naks -What: /sys/class/infiniband/qibX/ports/N/diag_counters/other_naks -What: /sys/class/infiniband/qibX/ports/N/diag_counters/rc_timeouts -What: /sys/class/infiniband/qibX/ports/N/diag_counters/look_pkts -What: /sys/class/infiniband/qibX/ports/N/diag_counters/pkt_drops -What: /sys/class/infiniband/qibX/ports/N/diag_counters/dma_wait -What: /sys/class/infiniband/qibX/ports/N/diag_counters/unaligned +What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/rc_resends +What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/seq_naks +What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/rdma_seq +What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/rnr_naks +What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/other_naks +What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/rc_timeouts +What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/look_pkts +What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/pkt_drops +What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/dma_wait +What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/unaligned Date: May, 2010 KernelVersion: v2.6.35 Contact: linux-rdma@vger.kernel.org @@ -650,9 +650,9 @@ Description: =============== ============================================= -What: /sys/class/infiniband/hfi1_X/ports/N/CCMgtA/cc_settings_bin -What: /sys/class/infiniband/hfi1_X/ports/N/CCMgtA/cc_table_bin -What: /sys/class/infiniband/hfi1_X/ports/N/CCMgtA/cc_prescan +What: /sys/class/infiniband/hfi1_X/ports/<N>/CCMgtA/cc_settings_bin +What: /sys/class/infiniband/hfi1_X/ports/<N>/CCMgtA/cc_table_bin +What: /sys/class/infiniband/hfi1_X/ports/<N>/CCMgtA/cc_prescan Date: May, 2016 KernelVersion: v4.6 Contact: linux-rdma@vger.kernel.org @@ -675,9 +675,9 @@ Description: disable. =============== ================================================ -What: /sys/class/infiniband/hfi1_X/ports/N/sc2vl/[0-31] -What: /sys/class/infiniband/hfi1_X/ports/N/sl2sc/[0-31] -What: /sys/class/infiniband/hfi1_X/ports/N/vl2mtu/[0-15] +What: /sys/class/infiniband/hfi1_X/ports/<N>/sc2vl/[0-31] +What: /sys/class/infiniband/hfi1_X/ports/<N>/sl2sc/[0-31] +What: /sys/class/infiniband/hfi1_X/ports/<N>/vl2mtu/[0-15] Date: May, 2016 KernelVersion: v4.6 Contact: linux-rdma@vger.kernel.org @@ -691,8 +691,8 @@ Description: =============== =================================================== -What: /sys/class/infiniband/hfi1_X/sdma_N/cpu_list -What: /sys/class/infiniband/hfi1_X/sdma_N/vl +What: /sys/class/infiniband/hfi1_X/sdma_<N>/cpu_list +What: /sys/class/infiniband/hfi1_X/sdma_<N>/vl Date: Sept, 2016 KernelVersion: v4.8 Contact: linux-rdma@vger.kernel.org diff --git a/Documentation/ABI/stable/sysfs-class-tpm b/Documentation/ABI/stable/sysfs-class-tpm index d897ecb9615f..411d5895bed4 100644 --- a/Documentation/ABI/stable/sysfs-class-tpm +++ b/Documentation/ABI/stable/sysfs-class-tpm @@ -195,7 +195,7 @@ Description: The "tpm_version_major" property shows the TCG spec major version 2 -What: /sys/class/tpm/tpmX/pcr-H/N +What: /sys/class/tpm/tpmX/pcr-<H>/<N> Date: March 2021 KernelVersion: 5.12 Contact: linux-integrity@vger.kernel.org diff --git a/Documentation/ABI/stable/sysfs-devices b/Documentation/ABI/stable/sysfs-devices index 42bf1eab5677..98a8ef99ac5f 100644 --- a/Documentation/ABI/stable/sysfs-devices +++ b/Documentation/ABI/stable/sysfs-devices @@ -23,3 +23,10 @@ Contact: Device Tree mailing list <devicetree@vger.kernel.org> Description: If CONFIG_OF is enabled, then this file is present. When read, it returns full name of the device node. + +What: /sys/devices/*/dev +Date: Jun 2006 +Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +Description: + Major and minor numbers of the character device corresponding + to the device (in <major>:<minor> format). diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu index 516dafea03eb..3965ce504484 100644 --- a/Documentation/ABI/stable/sysfs-devices-system-cpu +++ b/Documentation/ABI/stable/sysfs-devices-system-cpu @@ -42,6 +42,12 @@ Description: the CPU core ID of cpuX. Typically it is the hardware platform's architecture and platform dependent. Values: integer +What: /sys/devices/system/cpu/cpuX/topology/cluster_id +Description: the cluster ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. +Values: integer + What: /sys/devices/system/cpu/cpuX/topology/book_id Description: the book ID of cpuX. Typically it is the hardware platform's identifier (rather than the kernel's). The actual value is @@ -85,6 +91,15 @@ Description: human-readable list of CPUs within the same die. The format is like 0-3, 8-11, 14,17. Values: decimal list. +What: /sys/devices/system/cpu/cpuX/topology/cluster_cpus +Description: internal kernel map of CPUs within the same cluster. +Values: hexadecimal bitmask. + +What: /sys/devices/system/cpu/cpuX/topology/cluster_cpus_list +Description: human-readable list of CPUs within the same cluster. + The format is like 0-3, 8-11, 14,17. +Values: decimal list. + What: /sys/devices/system/cpu/cpuX/topology/book_siblings Description: internal kernel map of cpuX's hardware threads within the same book_id. it's only used on s390. diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io index b2553df2e786..12c3f895cd2f 100644 --- a/Documentation/ABI/stable/sysfs-driver-mlxreg-io +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -223,3 +223,247 @@ Description: These files show with which CPLD part numbers and minor system. The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/bios_active_image +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/bios_auth_fail +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/bios_upgrade_fail +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: The files represent BIOS statuses: + + bios_active_image: location of current active BIOS image: + 0: Top, 1: Bottom. + The reported value should correspond to value expected by OS + in case of BIOS safe mode is 0. This bit is related to Intel + top-swap feature of DualBios on the same flash. + + bios_auth_fail: BIOS upgrade is failed because provided BIOS + image is not signed correctly. + + bios_upgrade_fail: BIOS upgrade is failed by some other + reason not because authentication. For example due to + physical SPI flash problem. + + The files are read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc1_enable +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc2_enable +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc3_enable +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc4_enable +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc5_enable +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc6_enable +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc7_enable +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc8_enable +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: These files allow line cards enable state control. + Expected behavior: + When lc{n}_enable is written 1, related line card is released + from the reset state, when 0 - is hold in reset state. + + The files are read/write. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc1_pwr +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc2_pwr +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc3_pwr +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc4_pwr +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc5_pwr +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc6_pwr +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc7_pwr +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc8_pwr +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: These files switching line cards power on and off. + Expected behavior: + When lc{n}_pwr is written 1, related line card is powered + on, when written 0 - powered off. + + The files are read/write. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc1_rst_mask +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc2_rst_mask +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc3_rst_mask +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc4_rst_mask +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc5_rst_mask +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc6_rst_mask +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc7_rst_mask +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc8_rst_mask +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: These files clear line card reset bit enforced by ASIC, when it + sets it due to some abnormal ASIC behavior. + Expected behavior: + When lc{n}_rst_mask is written 1, related line card reset bit + is cleared, when written 0 - no effect. + + The files are write only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/os_started +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: This file, when written 1, indicates to programmable devices + that OS is taking control over it. + + The file is read/write. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pm_mgmt_en +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: This file assigns power management control ownership. + When power management control is provided by hardware, hardware + will automatically power off one or more line previously + powered line cards in case system power budget is getting + insufficient. It could be in case when some of power units lost + power good state. + When pm_mgmt_en is written 1, power management control by + software is enabled, 0 - power management control by hardware. + Note that for any setting of pm_mgmt_en attribute hardware will + not allow to power on any new line card in case system power + budget is insufficient. + Same in case software will try to power on several line cards + at once - hardware will power line cards while system has + enough power budget. + Default is 0. + + The file is read/write. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu3_on +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu4_on +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: These files switching power supply units on and off. + Expected behavior: + When psu3_on or psu4_on is written 1, related unit will be + disconnected from the power source, when written 0 - connected. + + The files are write only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/shutdown_unlock +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: This file allows to unlock ASIC after thermal shutdown event. + When system thermal shutdown is enforced by ASIC, ASIC is + getting locked and after system boot it will not be available. + Software can decide to unlock it by setting this attribute to + 1 and then perform system power cycle by setting pwr_cycle + attribute to 1 (power cycle of main power domain). + Before setting shutdown_unlock to 1 it is recommended to + validate that system reboot cause is reset_asic_thermal or + reset_thermal_spc_or_pciesw. + In case shutdown_unlock is not set 1, the only way to release + ASIC from locking - is full system power cycle through the + external power distribution unit. + Default is 1. + + The file is read/write. + +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/cpld1_pn +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/cpld1_version +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/cpld1_version_min +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: These files show with which CPLD major and minor versions + and part number has been burned CPLD device on line card. + + The files are read only. + +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga1_pn +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga1_version +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga1_version_min +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: These files show with which FPGA major and minor versions + and part number has been burned FPGA device on line card. + + The files are read only. + +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/vpd_wp +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: This file allow to overwrite line card VPD hardware write + protection mode. When attribute is set 1 - write protection is + disabled, when 0 - enabled. + Default is 0. + If the system is in locked-down mode writing this file will not + be allowed. + The purpose if this file is to allow line card VPD burning + during production flow. + + The file is read/write. + +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_aux_pwr_or_ref +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_dc_dc_pwr_fail +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_fpga_not_done +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_from_chassis +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_line_card +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_pwr_off_from_chassis +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: These files show the line reset cause, as following: power + auxiliary outage or power refresh, DC-to-DC power failure, FPGA reset + failed, line card reset failed, power off from chassis. + Value 1 in file means this is reset cause, 0 - otherwise. Only one of + the above causes could be 1 at the same time, representing only last + reset cause. + + The files are read only. + +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/cpld_upgrade_en +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga_upgrade_en +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: These files allow CPLD and FPGA burning. Value 1 in file means burning + is enabled, 0 - otherwise. + If the system is in locked-down mode writing these files will + not be allowed. + The purpose of these files to allow line card CPLD and FPGA + upgrade through the JTAG daisy-chain. + + The files are read/write. + +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/qsfp_pwr_en +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/pwr_en +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: These files allow to power on/off all QSFP ports and whole line card. + The attributes are set 1 for power on, 0 - for power off. + + The files are read/write. + +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/agb_spi_burn_en +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga_spi_burn_en +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: These files allow gearboxes and FPGA SPI flash burning. + The attributes are set 1 to enable burning, 0 - to disable. + If the system is in locked-down mode writing these files will + not be allowed. + The purpose of these files to allow line card Gearboxes and FPGA + burning during production flow. + + The file is read/write. + +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/max_power +What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/config +Date: October 2021 +KernelVersion: 5.16 +Contact: Vadim Pasternak <vadimp@nvidia.com> +Description: These files provide the maximum powered required for line card + feeding and line card configuration Id. + + The files are read only. diff --git a/Documentation/ABI/stable/sysfs-module b/Documentation/ABI/stable/sysfs-module index 6272ae5fb366..560b4a3278df 100644 --- a/Documentation/ABI/stable/sysfs-module +++ b/Documentation/ABI/stable/sysfs-module @@ -1,8 +1,7 @@ -What: /sys/module -Description: - The /sys/module tree consists of the following structure: +The /sys/module tree consists of the following structure: - /sys/module/MODULENAME +What: /sys/module/<MODULENAME> +Description: The name of the module that is in the kernel. This module name will always show up if the module is loaded as a dynamic module. If it is built directly into the kernel, it @@ -12,7 +11,8 @@ Description: Note: The conditions of creation in the built-in case are not by design and may be removed in the future. - /sys/module/MODULENAME/parameters +What: /sys/module/<MODULENAME>/parameters +Description: This directory contains individual files that are each individual parameters of the module that are able to be changed at runtime. See the individual module @@ -25,10 +25,23 @@ Description: individual driver documentation for details as to the stability of the different parameters. - /sys/module/MODULENAME/refcnt +What: /sys/module/<MODULENAME>/refcnt +Description: If the module is able to be unloaded from the kernel, this file will contain the current reference count of the module. Note: If the module is built into the kernel, or if the CONFIG_MODULE_UNLOAD kernel configuration value is not enabled, this file will not be present. + +What: /sys/module/<MODULENAME>/srcversion +Date: Jun 2005 +Description: + If the module source has MODULE_VERSION, this file will contain + the checksum of the the source code. + +What: /sys/module/<MODULENAME>/version +Date: Jun 2005 +Description: + If the module source has MODULE_VERSION, this file will contain + the version of the source code. diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac1 b/Documentation/ABI/testing/configfs-usb-gadget-uac1 index dd647d44d975..b576b3d6ea6d 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac1 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1 @@ -4,23 +4,29 @@ KernelVersion: 4.14 Description: The attributes: - ========== =================================== - c_chmask capture channel mask - c_srate capture sampling rate - c_ssize capture sample size (bytes) - c_mute_present capture mute control enable + ===================== ======================================= + c_chmask capture channel mask + c_srate capture sampling rate + c_ssize capture sample size (bytes) + c_mute_present capture mute control enable c_volume_present capture volume control enable - c_volume_min capture volume control min value (in 1/256 dB) - c_volume_max capture volume control max value (in 1/256 dB) - c_volume_res capture volume control resolution (in 1/256 dB) - p_chmask playback channel mask - p_srate playback sampling rate - p_ssize playback sample size (bytes) - p_mute_present playback mute control enable + c_volume_min capture volume control min value + (in 1/256 dB) + c_volume_max capture volume control max value + (in 1/256 dB) + c_volume_res capture volume control resolution + (in 1/256 dB) + p_chmask playback channel mask + p_srate playback sampling rate + p_ssize playback sample size (bytes) + p_mute_present playback mute control enable p_volume_present playback volume control enable - p_volume_min playback volume control min value (in 1/256 dB) - p_volume_max playback volume control max value (in 1/256 dB) - p_volume_res playback volume control resolution (in 1/256 dB) - req_number the number of pre-allocated request - for both capture and playback - ========== =================================== + p_volume_min playback volume control min value + (in 1/256 dB) + p_volume_max playback volume control max value + (in 1/256 dB) + p_volume_res playback volume control resolution + (in 1/256 dB) + req_number the number of pre-allocated request + for both capture and playback + ===================== ======================================= diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 index cfd160ff8b56..244d96650123 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -4,23 +4,30 @@ KernelVersion: 3.18 Description: The attributes: - ========= ============================ - c_chmask capture channel mask - c_srate capture sampling rate - c_ssize capture sample size (bytes) - c_sync capture synchronization type (async/adaptive) - c_mute_present capture mute control enable + ===================== ======================================= + c_chmask capture channel mask + c_srate capture sampling rate + c_ssize capture sample size (bytes) + c_sync capture synchronization type + (async/adaptive) + c_mute_present capture mute control enable c_volume_present capture volume control enable - c_volume_min capture volume control min value (in 1/256 dB) - c_volume_max capture volume control max value (in 1/256 dB) - c_volume_res capture volume control resolution (in 1/256 dB) - fb_max maximum extra bandwidth in async mode - p_chmask playback channel mask - p_srate playback sampling rate - p_ssize playback sample size (bytes) - p_mute_present playback mute control enable + c_volume_min capture volume control min value + (in 1/256 dB) + c_volume_max capture volume control max value + (in 1/256 dB) + c_volume_res capture volume control resolution + (in 1/256 dB) + fb_max maximum extra bandwidth in async mode + p_chmask playback channel mask + p_srate playback sampling rate + p_ssize playback sample size (bytes) + p_mute_present playback mute control enable p_volume_present playback volume control enable - p_volume_min playback volume control min value (in 1/256 dB) - p_volume_max playback volume control max value (in 1/256 dB) - p_volume_res playback volume control resolution (in 1/256 dB) - ========= ============================ + p_volume_min playback volume control min value + (in 1/256 dB) + p_volume_max playback volume control max value + (in 1/256 dB) + p_volume_res playback volume control resolution + (in 1/256 dB) + ===================== ======================================= diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index 284e2dfa61cd..63c46d9d538f 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -226,6 +226,12 @@ Description: Gets the state dump occurring on a CS timeout or failure. Writing an integer X discards X state dumps, so that the next read would return X+1-st newest state dump. +What: /sys/kernel/debug/habanalabs/hl<n>/timeout_locked +Date: Sep 2021 +KernelVersion: 5.16 +Contact: obitton@habana.ai +Description: Sets the command submission timeout value in seconds. + What: /sys/kernel/debug/habanalabs/hl<n>/stop_on_err Date: Mar 2020 KernelVersion: 5.6 diff --git a/Documentation/ABI/testing/evm b/Documentation/ABI/testing/evm index 553fd8a33e56..44750a933db4 100644 --- a/Documentation/ABI/testing/evm +++ b/Documentation/ABI/testing/evm @@ -1,4 +1,5 @@ -What: security/evm +What: /sys/kernel/security/evm +What: /sys/kernel/security/*/evm Date: March 2011 Contact: Mimi Zohar <zohar@us.ibm.com> Description: @@ -93,7 +94,7 @@ Description: core/ima-setup) have support for loading keys at boot time. -What: security/integrity/evm/evm_xattrs +What: /sys/kernel/security/*/evm/evm_xattrs Date: April 2018 Contact: Matthew Garrett <mjg59@google.com> Description: diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy index 5c2798534950..839fab811b18 100644 --- a/Documentation/ABI/testing/ima_policy +++ b/Documentation/ABI/testing/ima_policy @@ -1,4 +1,4 @@ -What: security/ima/policy +What: /sys/kernel/security/*/ima/policy Date: May 2008 Contact: Mimi Zohar <zohar@us.ibm.com> Description: @@ -22,8 +22,9 @@ Description: action: measure | dont_measure | appraise | dont_appraise | audit | hash | dont_hash condition:= base | lsm [option] - base: [[func=] [mask=] [fsmagic=] [fsuuid=] [uid=] - [euid=] [fowner=] [fsname=]] + base: [[func=] [mask=] [fsmagic=] [fsuuid=] [fsname=] + [uid=] [euid=] [gid=] [egid=] + [fowner=] [fgroup=]] lsm: [[subj_user=] [subj_role=] [subj_type=] [obj_user=] [obj_role=] [obj_type=]] option: [[appraise_type=]] [template=] [permit_directio] @@ -40,7 +41,10 @@ Description: fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6) uid:= decimal value euid:= decimal value + gid:= decimal value + egid:= decimal value fowner:= decimal value + fgroup:= decimal value lsm: are LSM specific option: appraise_type:= [imasig] [imasig|modsig] diff --git a/Documentation/ABI/testing/pstore b/Documentation/ABI/testing/pstore index 5b02540781a2..d3cff4a7ee10 100644 --- a/Documentation/ABI/testing/pstore +++ b/Documentation/ABI/testing/pstore @@ -1,4 +1,5 @@ -What: /sys/fs/pstore/... (or /dev/pstore/...) +What: /sys/fs/pstore/... +What: /dev/pstore/... Date: March 2011 KernelVersion: 2.6.39 Contact: tony.luck@intel.com diff --git a/Documentation/ABI/testing/sysfs-ata b/Documentation/ABI/testing/sysfs-ata index 9ab0ef1dd1c7..2f726c914752 100644 --- a/Documentation/ABI/testing/sysfs-ata +++ b/Documentation/ABI/testing/sysfs-ata @@ -1,4 +1,4 @@ -What: /sys/class/ata_... +What: /sys/class/ata_* Description: Provide a place in sysfs for storing the ATA topology of the system. This allows retrieving various information about ATA diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block index a0ed87386639..b16b0c45a272 100644 --- a/Documentation/ABI/testing/sysfs-block +++ b/Documentation/ABI/testing/sysfs-block @@ -28,6 +28,22 @@ Description: For more details refer Documentation/admin-guide/iostats.rst +What: /sys/block/<disk>/inflight +Date: October 2009 +Contact: Jens Axboe <axboe@kernel.dk>, Nikanth Karthikesan <knikanth@suse.de> +Description: + Reports the number of I/O requests currently in progress + (pending / in flight) in a device driver. This can be less + than the number of requests queued in the block device queue. + The report contains 2 fields: one for read requests + and one for write requests. + The value type is unsigned int. + Cf. Documentation/block/stat.rst which contains a single value for + requests in flight. + This is related to nr_requests in Documentation/block/queue-sysfs.rst + and for SCSI device also its queue_depth. + + What: /sys/block/<disk>/diskseq Date: February 2021 Contact: Matteo Croce <mcroce@microsoft.com> diff --git a/Documentation/ABI/testing/sysfs-bus-counter b/Documentation/ABI/testing/sysfs-bus-counter index 20fe5afd4f9e..06c2b3e27e0b 100644 --- a/Documentation/ABI/testing/sysfs-bus-counter +++ b/Documentation/ABI/testing/sysfs-bus-counter @@ -203,6 +203,27 @@ Description: both edges: Any state transition. +What: /sys/bus/counter/devices/counterX/countY/ceiling_component_id +What: /sys/bus/counter/devices/counterX/countY/floor_component_id +What: /sys/bus/counter/devices/counterX/countY/count_mode_component_id +What: /sys/bus/counter/devices/counterX/countY/direction_component_id +What: /sys/bus/counter/devices/counterX/countY/enable_component_id +What: /sys/bus/counter/devices/counterX/countY/error_noise_component_id +What: /sys/bus/counter/devices/counterX/countY/prescaler_component_id +What: /sys/bus/counter/devices/counterX/countY/preset_component_id +What: /sys/bus/counter/devices/counterX/countY/preset_enable_component_id +What: /sys/bus/counter/devices/counterX/countY/signalZ_action_component_id +What: /sys/bus/counter/devices/counterX/signalY/cable_fault_component_id +What: /sys/bus/counter/devices/counterX/signalY/cable_fault_enable_component_id +What: /sys/bus/counter/devices/counterX/signalY/filter_clock_prescaler_component_id +What: /sys/bus/counter/devices/counterX/signalY/index_polarity_component_id +What: /sys/bus/counter/devices/counterX/signalY/synchronous_mode_component_id +KernelVersion: 5.16 +Contact: linux-iio@vger.kernel.org +Description: + Read-only attribute that indicates the component ID of the + respective extension or Synapse. + What: /sys/bus/counter/devices/counterX/countY/spike_filter_ns KernelVersion: 5.14 Contact: linux-iio@vger.kernel.org @@ -212,6 +233,14 @@ Description: shorter or equal to configured value are ignored. Value 0 means filter is disabled. +What: /sys/bus/counter/devices/counterX/events_queue_size +KernelVersion: 5.16 +Contact: linux-iio@vger.kernel.org +Description: + Size of the Counter events queue in number of struct + counter_event data structures. The number of elements will be + rounded-up to a power of 2. + What: /sys/bus/counter/devices/counterX/name KernelVersion: 5.2 Contact: linux-iio@vger.kernel.org @@ -286,7 +315,14 @@ What: /sys/bus/counter/devices/counterX/signalY/signal KernelVersion: 5.2 Contact: linux-iio@vger.kernel.org Description: - Signal data of Signal Y represented as a string. + Signal level state of Signal Y. The following signal level + states are available: + + low: + Low level state. + + high: + High level state. What: /sys/bus/counter/devices/counterX/signalY/synchronous_mode KernelVersion: 5.2 diff --git a/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo b/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo new file mode 100644 index 000000000000..531fe9d6b40a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo @@ -0,0 +1,10 @@ +What: /sys/bus/fsi/devices/XX.XX.00:06/sbefifoX/timeout +KernelVersion: 5.15 +Contact: eajames@linux.ibm.com +Description: + Indicates whether or not this SBE device has experienced a + timeout; i.e. the SBE did not respond within the time allotted + by the driver. A value of 1 indicates that a timeout has + ocurred and no transfers have completed since the timeout. A + value of 0 indicates that no timeout has ocurred, or if one + has, more recent transfers have completed successful. diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 6ad47a67521c..c551301b33f1 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -429,6 +429,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_angl_scale What: /sys/bus/iio/devices/iio:deviceX/in_intensity_x_scale What: /sys/bus/iio/devices/iio:deviceX/in_intensity_y_scale What: /sys/bus/iio/devices/iio:deviceX/in_intensity_z_scale +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_scale KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -1957,3 +1958,44 @@ Description: Specify the percent for light sensor relative to the channel absolute value that a data field should change before an event is generated. Units are a percentage of the prior reading. + +What: /sys/bus/iio/devices/iio:deviceX/calibration_auto_enable +Date: June 2020 +KernelVersion: 5.8 +Contact: linux-iio@vger.kernel.org +Description: + Some sensors have the ability to apply auto calibration at + runtime. For example, it may be necessary to compensate for + contaminant build-up in a measurement chamber or optical + element deterioration that would otherwise lead to sensor drift. + + Writing 1 or 0 to this attribute will respectively activate or + deactivate this auto calibration function. + + Upon reading, the current status is returned. + +What: /sys/bus/iio/devices/iio:deviceX/calibration_forced_value +Date: June 2020 +KernelVersion: 5.8 +Contact: linux-iio@vger.kernel.org +Description: + Some sensors have the ability to apply a manual calibration using + a known measurement value, perhaps obtained from an external + reference device. + + Writing a value to this function will force such a calibration + change. For the scd30 the value should be from the range + [400 1 2000]. + + Note for the scd30 that a valid value may only be obtained once + it is has been written. Until then any read back of this value + should be ignored. As for the scd4x an error will be returned + immediately if the manual calibration has failed. + +What: /sys/bus/iio/devices/iio:deviceX/calibration_forced_value_available +KernelVersion: 5.15 +Contact: linux-iio@vger.kernel.org +Description: + Available range for the forced calibration value, expressed as: + + - a range specified as "[min step max]" diff --git a/Documentation/ABI/testing/sysfs-bus-iio-chemical-sunrise-co2 b/Documentation/ABI/testing/sysfs-bus-iio-chemical-sunrise-co2 new file mode 100644 index 000000000000..ee7aeb11709b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-chemical-sunrise-co2 @@ -0,0 +1,38 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_calibration_factory +Date: August 2021 +KernelVersion: 5.16 +Contact: Jacopo Mondi <jacopo@jmondi.org> +Description: + Writing '1' triggers a 'Factory' calibration cycle. + +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_calibration_background +Date: August 2021 +KernelVersion: 5.16 +Contact: Jacopo Mondi <jacopo@jmondi.org> +Description: + Writing '1' triggers a 'Background' calibration cycle. + +What: /sys/bus/iio/devices/iio:deviceX/error_status_available +Date: August 2021 +KernelVersion: 5.16 +Contact: Jacopo Mondi <jacopo@jmondi.org> +Description: + Reading returns the list of possible chip error status. + Available options are: + - 'error_fatal': Analog front-end initialization error + - 'error_i2c': Read/write to non-existing register + - 'error_algorithm': Corrupted parameters + - 'error_calibration': Calibration has failed + - 'error_self_diagnostic': Internal interface failure + - 'error_out_of_range': Measured concentration out of scale + - 'error_memory': Error during memory operations + - 'error_no_measurement': Cleared at first measurement + - 'error_low_voltage': Sensor regulated voltage too low + - 'error_measurement_timeout': Unable to complete measurement + +What: /sys/bus/iio/devices/iio:deviceX/error_status +Date: August 2021 +KernelVersion: 5.16 +Contact: Jacopo Mondi <jacopo@jmondi.org> +Description: + Reading returns the current chip error status. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-scd30 b/Documentation/ABI/testing/sysfs-bus-iio-scd30 deleted file mode 100644 index b9712f390bec..000000000000 --- a/Documentation/ABI/testing/sysfs-bus-iio-scd30 +++ /dev/null @@ -1,34 +0,0 @@ -What: /sys/bus/iio/devices/iio:deviceX/calibration_auto_enable -Date: June 2020 -KernelVersion: 5.8 -Contact: linux-iio@vger.kernel.org -Description: - Contaminants build-up in the measurement chamber or optical - elements deterioration leads to sensor drift. - - One can compensate for sensor drift by using automatic self - calibration procedure (asc). - - Writing 1 or 0 to this attribute will respectively activate or - deactivate asc. - - Upon reading current asc status is returned. - -What: /sys/bus/iio/devices/iio:deviceX/calibration_forced_value -Date: June 2020 -KernelVersion: 5.8 -Contact: linux-iio@vger.kernel.org -Description: - Contaminants build-up in the measurement chamber or optical - elements deterioration leads to sensor drift. - - One can compensate for sensor drift by using forced - recalibration (frc). This is useful in case there's known - co2 reference available nearby the sensor. - - Picking value from the range [400 1 2000] and writing it to the - sensor will set frc. - - Upon reading current frc value is returned. Note that after - power cycling default value (i.e 400) is returned even though - internally sensor had recalibrated itself. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31865 b/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31865 new file mode 100644 index 000000000000..4b072da92218 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31865 @@ -0,0 +1,20 @@ +What: /sys/bus/iio/devices/iio:deviceX/fault_ovuv +KernelVersion: 5.11 +Contact: linux-iio@vger.kernel.org +Description: + Overvoltage or Undervoltage Input fault. The internal circuitry + is protected from excessive voltages applied to the thermocouple + cables at FORCE+, FORCE2, RTDIN+ & RTDIN-. This circuitry turn + off when the input voltage is negative or greater than VDD. + + Reading returns '1' if input voltage is negative or greater + than VDD, otherwise '0'. + +What: /sys/bus/iio/devices/iio:deviceX/in_filter_notch_center_frequency +KernelVersion: 5.11 +Contact: linux-iio@vger.kernel.org +Description: + Notch frequency in Hz for a noise rejection filter. Used i.e for + line noise rejection. + + Valid notch filter values are 50 Hz and 60 Hz. diff --git a/Documentation/ABI/testing/sysfs-bus-mdio b/Documentation/ABI/testing/sysfs-bus-mdio index da86efc7781b..38be04dfc05e 100644 --- a/Documentation/ABI/testing/sysfs-bus-mdio +++ b/Documentation/ABI/testing/sysfs-bus-mdio @@ -1,4 +1,5 @@ What: /sys/bus/mdio_bus/devices/.../statistics/ +What: /sys/class/mdio_bus/.../statistics/ Date: January 2020 KernelVersion: 5.6 Contact: netdev@vger.kernel.org @@ -7,6 +8,7 @@ Description: MDIO bus address statistics. What: /sys/bus/mdio_bus/devices/.../statistics/transfers +What: /sys/class/mdio_bus/.../transfers Date: January 2020 KernelVersion: 5.6 Contact: netdev@vger.kernel.org @@ -14,6 +16,7 @@ Description: Total number of transfers for this MDIO bus. What: /sys/bus/mdio_bus/devices/.../statistics/errors +What: /sys/class/mdio_bus/.../statistics/errors Date: January 2020 KernelVersion: 5.6 Contact: netdev@vger.kernel.org @@ -21,6 +24,7 @@ Description: Total number of transfer errors for this MDIO bus. What: /sys/bus/mdio_bus/devices/.../statistics/writes +What: /sys/class/mdio_bus/.../statistics/writes Date: January 2020 KernelVersion: 5.6 Contact: netdev@vger.kernel.org @@ -28,6 +32,7 @@ Description: Total number of write transactions for this MDIO bus. What: /sys/bus/mdio_bus/devices/.../statistics/reads +What: /sys/class/mdio_bus/.../statistics/reads Date: January 2020 KernelVersion: 5.6 Contact: netdev@vger.kernel.org @@ -35,6 +40,7 @@ Description: Total number of read transactions for this MDIO bus. What: /sys/bus/mdio_bus/devices/.../statistics/transfers_<addr> +What: /sys/class/mdio_bus/.../statistics/transfers_<addr> Date: January 2020 KernelVersion: 5.6 Contact: netdev@vger.kernel.org @@ -42,6 +48,7 @@ Description: Total number of transfers for this MDIO bus address. What: /sys/bus/mdio_bus/devices/.../statistics/errors_<addr> +What: /sys/class/mdio_bus/.../statistics/errors_<addr> Date: January 2020 KernelVersion: 5.6 Contact: netdev@vger.kernel.org @@ -49,6 +56,7 @@ Description: Total number of transfer errors for this MDIO bus address. What: /sys/bus/mdio_bus/devices/.../statistics/writes_<addr> +What: /sys/class/mdio_bus/.../statistics/writes_<addr> Date: January 2020 KernelVersion: 5.6 Contact: netdev@vger.kernel.org @@ -56,6 +64,7 @@ Description: Total number of write transactions for this MDIO bus address. What: /sys/bus/mdio_bus/devices/.../statistics/reads_<addr> +What: /sys/class/mdio_bus/.../statistics/reads_<addr> Date: January 2020 KernelVersion: 5.6 Contact: netdev@vger.kernel.org diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index d4ae03296861..6fc2c2efe8ab 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -1,4 +1,5 @@ What: /sys/bus/pci/drivers/.../bind +What: /sys/devices/pciX/.../bind Date: December 2003 Contact: linux-pci@vger.kernel.org Description: @@ -14,6 +15,7 @@ Description: (Note: kernels before 2.6.28 may require echo -n). What: /sys/bus/pci/drivers/.../unbind +What: /sys/devices/pciX/.../unbind Date: December 2003 Contact: linux-pci@vger.kernel.org Description: @@ -29,6 +31,7 @@ Description: (Note: kernels before 2.6.28 may require echo -n). What: /sys/bus/pci/drivers/.../new_id +What: /sys/devices/pciX/.../new_id Date: December 2003 Contact: linux-pci@vger.kernel.org Description: @@ -47,6 +50,7 @@ Description: # echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id What: /sys/bus/pci/drivers/.../remove_id +What: /sys/devices/pciX/.../remove_id Date: February 2009 Contact: Chris Wright <chrisw@sous-sol.org> Description: @@ -96,6 +100,17 @@ Description: This attribute indicates the mode that the irq vector named by the file is in (msi vs. msix) +What: /sys/bus/pci/devices/.../irq +Date: August 2021 +Contact: Linux PCI developers <linux-pci@vger.kernel.org> +Description: + If a driver has enabled MSI (not MSI-X), "irq" contains the + IRQ of the first MSI vector. Otherwise "irq" contains the + IRQ of the legacy INTx interrupt. + + "irq" being set to 0 indicates that the device isn't + capable of generating legacy INTx interrupts. + What: /sys/bus/pci/devices/.../remove Date: January 2009 Contact: Linux PCI developers <linux-pci@vger.kernel.org> @@ -160,7 +175,7 @@ Description: If the underlying VPD has a writable section then the corresponding section of this file will be writable. -What: /sys/bus/pci/devices/.../virtfnN +What: /sys/bus/pci/devices/.../virtfn<N> Date: March 2009 Contact: Yu Zhao <yu.zhao@intel.com> Description: @@ -187,6 +202,24 @@ Description: The symbolic link points to the PCI device sysfs entry of the Physical Function this device associates with. +What: /sys/bus/pci/devices/.../modalias +Date: May 2005 +Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +Description: + This attribute indicates the PCI ID of the device object. + + That is in the format: + pci:vXXXXXXXXdXXXXXXXXsvXXXXXXXXsdXXXXXXXXbcXXscXXiXX, + where: + + - vXXXXXXXX contains the vendor ID; + - dXXXXXXXX contains the device ID; + - svXXXXXXXX contains the sub-vendor ID; + - sdXXXXXXXX contains the subsystem device ID; + - bcXX contains the device class; + - scXX contains the device subclass; + - iXX contains the device class programming interface. + What: /sys/bus/pci/slots/.../module Date: June 2009 Contact: linux-pci@vger.kernel.org diff --git a/Documentation/ABI/testing/sysfs-bus-platform b/Documentation/ABI/testing/sysfs-bus-platform index ff30728595ef..c4dfe7355c2d 100644 --- a/Documentation/ABI/testing/sysfs-bus-platform +++ b/Documentation/ABI/testing/sysfs-bus-platform @@ -42,3 +42,15 @@ Date: August 2021 Contact: Barry Song <song.bao.hua@hisilicon.com> Description: This attribute will show "msi" if <N> is a valid msi irq + +What: /sys/bus/platform/devices/.../modalias +Description: + Same as MODALIAS in the uevent at device creation. + + A platform device that it is exposed via devicetree uses: + + - of:N`of node name`T`type` + + Other platform devices use, instead: + + - platform:`driver name` diff --git a/Documentation/ABI/testing/sysfs-bus-platform-devices-occ-hwmon b/Documentation/ABI/testing/sysfs-bus-platform-devices-occ-hwmon new file mode 100644 index 000000000000..b24d7ab0278f --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-platform-devices-occ-hwmon @@ -0,0 +1,13 @@ +What: /sys/bus/platform/devices/occ-hwmon.X/ffdc +KernelVersion: 5.15 +Contact: eajames@linux.ibm.com +Description: + Contains the First Failure Data Capture from the SBEFIFO + hardware, if there is any from a previous transfer. Otherwise, + the file is empty. The data is cleared when it's been + completely read by a user. As the name suggests, only the data + from the first error is saved, until it's cleared upon read. The OCC hwmon driver, running on + a Baseboard Management Controller (BMC), communicates with + POWER9 and up processors over the Self-Boot Engine (SBE) FIFO. + In many error conditions, the SBEFIFO will return error data + indicating the type of error and system state, etc. diff --git a/Documentation/ABI/testing/sysfs-bus-rapidio b/Documentation/ABI/testing/sysfs-bus-rapidio index 634ea207a50a..f8b6728dac10 100644 --- a/Documentation/ABI/testing/sysfs-bus-rapidio +++ b/Documentation/ABI/testing/sysfs-bus-rapidio @@ -1,4 +1,4 @@ -What: /sys/bus/rapidio/devices/nn:d:iiii +What: /sys/bus/rapidio/devices/<nn>:<d>:<iiii> Description: For each RapidIO device, the RapidIO subsystem creates files in an individual subdirectory with the following name format of @@ -29,7 +29,7 @@ Description: Attributes Common for All RapidIO Devices ----------------------------------------- -What: /sys/bus/rapidio/devices/nn:d:iiii/did +What: /sys/bus/rapidio/devices/<nn>:<d>:<iiii>/did Date: Nov, 2005 KernelVersion: v2.6.15 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -37,7 +37,7 @@ Contact: Matt Porter <mporter@kernel.crashing.org>, Description: (RO) returns the device identifier -What: /sys/bus/rapidio/devices/nn:d:iiii/vid +What: /sys/bus/rapidio/devices/<nn>:<d>:<iiii>/vid Date: Nov, 2005 KernelVersion: v2.6.15 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -45,7 +45,7 @@ Contact: Matt Porter <mporter@kernel.crashing.org>, Description: (RO) returns the device vendor identifier -What: /sys/bus/rapidio/devices/nn:d:iiii/device_rev +What: /sys/bus/rapidio/devices/<nn>:<d>:<iiii>/device_rev Date: Nov, 2005 KernelVersion: v2.6.15 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -53,7 +53,7 @@ Contact: Matt Porter <mporter@kernel.crashing.org>, Description: (RO) returns the device revision level -What: /sys/bus/rapidio/devices/nn:d:iiii/asm_did +What: /sys/bus/rapidio/devices/<nn>:<d>:<iiii>/asm_did Date: Nov, 2005 KernelVersion: v2.6.15 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -61,7 +61,7 @@ Contact: Matt Porter <mporter@kernel.crashing.org>, Description: (RO) returns identifier for the assembly containing the device -What: /sys/bus/rapidio/devices/nn:d:iiii/asm_rev +What: /sys/bus/rapidio/devices/<nn>:<d>:<iiii>/asm_rev Date: Nov, 2005 KernelVersion: v2.6.15 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -70,7 +70,7 @@ Description: (RO) returns revision level of the assembly containing the device -What: /sys/bus/rapidio/devices/nn:d:iiii/asm_vid +What: /sys/bus/rapidio/devices/<nn>:<d>:<iiii>/asm_vid Date: Nov, 2005 KernelVersion: v2.6.15 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -79,7 +79,7 @@ Description: (RO) returns vendor identifier of the assembly containing the device -What: /sys/bus/rapidio/devices/nn:d:iiii/destid +What: /sys/bus/rapidio/devices/<nn>:<d>:<iiii>/destid Date: Mar, 2011 KernelVersion: v2.6.3 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -88,7 +88,7 @@ Description: (RO) returns device destination ID assigned by the enumeration routine -What: /sys/bus/rapidio/devices/nn:d:iiii/lprev +What: /sys/bus/rapidio/devices/<nn>:<d>:<iiii>/lprev Date: Mar, 2011 KernelVersion: v2.6.39 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -97,7 +97,7 @@ Description: (RO) returns name of previous device (switch) on the path to the device that that owns this attribute -What: /sys/bus/rapidio/devices/nn:d:iiii/modalias +What: /sys/bus/rapidio/devices/<nn>:<d>:<iiii>/modalias Date: Jul, 2013 KernelVersion: v3.11 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -105,7 +105,7 @@ Contact: Matt Porter <mporter@kernel.crashing.org>, Description: (RO) returns the device modalias -What: /sys/bus/rapidio/devices/nn:d:iiii/config +What: /sys/bus/rapidio/devices/<nn>:<d>:<iiii>/config Date: Nov, 2005 KernelVersion: v2.6.15 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -128,7 +128,7 @@ device-specific sysfs attributes by specifying a callback function that may be set by the switch initialization routine during enumeration or discovery process. -What: /sys/bus/rapidio/devices/nn:s:iiii/routes +What: /sys/bus/rapidio/devices/<nn>:<s>:<iiii>/routes Date: Nov, 2005 KernelVersion: v2.6.15 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -138,7 +138,7 @@ Description: This attribute reports only valid routing table entries, one line for each entry. -What: /sys/bus/rapidio/devices/nn:s:iiii/destid +What: /sys/bus/rapidio/devices/<nn>:<s>:<iiii>/destid Date: Mar, 2011 KernelVersion: v2.6.3 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -147,7 +147,7 @@ Description: (RO) device destination ID of the associated device that defines a route to the switch -What: /sys/bus/rapidio/devices/nn:s:iiii/hopcount +What: /sys/bus/rapidio/devices/<nn>:<s>:<iiii>/hopcount Date: Mar, 2011 KernelVersion: v2.6.39 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -155,7 +155,7 @@ Contact: Matt Porter <mporter@kernel.crashing.org>, Description: (RO) number of hops on the path to the switch -What: /sys/bus/rapidio/devices/nn:s:iiii/lnext +What: /sys/bus/rapidio/devices/<nn>:<s>:<iiii>/lnext Date: Mar, 2011 KernelVersion: v2.6.39 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -172,7 +172,7 @@ Device-specific Switch Attributes IDT_GEN2- -What: /sys/bus/rapidio/devices/nn:s:iiii/errlog +What: /sys/bus/rapidio/devices/<nn>:<s>:<iiii>/errlog Date: Oct, 2010 KernelVersion: v2.6.37 Contact: Matt Porter <mporter@kernel.crashing.org>, diff --git a/Documentation/ABI/testing/sysfs-bus-soundwire-master b/Documentation/ABI/testing/sysfs-bus-soundwire-master index 46ef038d8722..d2342911ffbb 100644 --- a/Documentation/ABI/testing/sysfs-bus-soundwire-master +++ b/Documentation/ABI/testing/sysfs-bus-soundwire-master @@ -1,13 +1,13 @@ -What: /sys/bus/soundwire/devices/sdw-master-N/revision - /sys/bus/soundwire/devices/sdw-master-N/clk_stop_modes - /sys/bus/soundwire/devices/sdw-master-N/clk_freq - /sys/bus/soundwire/devices/sdw-master-N/clk_gears - /sys/bus/soundwire/devices/sdw-master-N/default_col - /sys/bus/soundwire/devices/sdw-master-N/default_frame_rate - /sys/bus/soundwire/devices/sdw-master-N/default_row - /sys/bus/soundwire/devices/sdw-master-N/dynamic_shape - /sys/bus/soundwire/devices/sdw-master-N/err_threshold - /sys/bus/soundwire/devices/sdw-master-N/max_clk_freq +What: /sys/bus/soundwire/devices/sdw-master-<N>/revision + /sys/bus/soundwire/devices/sdw-master-<N>/clk_stop_modes + /sys/bus/soundwire/devices/sdw-master-<N>/clk_freq + /sys/bus/soundwire/devices/sdw-master-<N>/clk_gears + /sys/bus/soundwire/devices/sdw-master-<N>/default_col + /sys/bus/soundwire/devices/sdw-master-<N>/default_frame_rate + /sys/bus/soundwire/devices/sdw-master-<N>/default_row + /sys/bus/soundwire/devices/sdw-master-<N>/dynamic_shape + /sys/bus/soundwire/devices/sdw-master-<N>/err_threshold + /sys/bus/soundwire/devices/sdw-master-<N>/max_clk_freq Date: April 2020 diff --git a/Documentation/ABI/testing/sysfs-bus-soundwire-slave b/Documentation/ABI/testing/sysfs-bus-soundwire-slave index d324aa0b678f..fbf55834dfee 100644 --- a/Documentation/ABI/testing/sysfs-bus-soundwire-slave +++ b/Documentation/ABI/testing/sysfs-bus-soundwire-slave @@ -64,37 +64,37 @@ Description: SoundWire Slave Data Port-0 DisCo properties. Data port 0 are used by the bus to configure the Data Port 0. -What: /sys/bus/soundwire/devices/sdw:.../dpN_src/max_word - /sys/bus/soundwire/devices/sdw:.../dpN_src/min_word - /sys/bus/soundwire/devices/sdw:.../dpN_src/words - /sys/bus/soundwire/devices/sdw:.../dpN_src/type - /sys/bus/soundwire/devices/sdw:.../dpN_src/max_grouping - /sys/bus/soundwire/devices/sdw:.../dpN_src/simple_ch_prep_sm - /sys/bus/soundwire/devices/sdw:.../dpN_src/ch_prep_timeout - /sys/bus/soundwire/devices/sdw:.../dpN_src/imp_def_interrupts - /sys/bus/soundwire/devices/sdw:.../dpN_src/min_ch - /sys/bus/soundwire/devices/sdw:.../dpN_src/max_ch - /sys/bus/soundwire/devices/sdw:.../dpN_src/channels - /sys/bus/soundwire/devices/sdw:.../dpN_src/ch_combinations - /sys/bus/soundwire/devices/sdw:.../dpN_src/max_async_buffer - /sys/bus/soundwire/devices/sdw:.../dpN_src/block_pack_mode - /sys/bus/soundwire/devices/sdw:.../dpN_src/port_encoding - - /sys/bus/soundwire/devices/sdw:.../dpN_sink/max_word - /sys/bus/soundwire/devices/sdw:.../dpN_sink/min_word - /sys/bus/soundwire/devices/sdw:.../dpN_sink/words - /sys/bus/soundwire/devices/sdw:.../dpN_sink/type - /sys/bus/soundwire/devices/sdw:.../dpN_sink/max_grouping - /sys/bus/soundwire/devices/sdw:.../dpN_sink/simple_ch_prep_sm - /sys/bus/soundwire/devices/sdw:.../dpN_sink/ch_prep_timeout - /sys/bus/soundwire/devices/sdw:.../dpN_sink/imp_def_interrupts - /sys/bus/soundwire/devices/sdw:.../dpN_sink/min_ch - /sys/bus/soundwire/devices/sdw:.../dpN_sink/max_ch - /sys/bus/soundwire/devices/sdw:.../dpN_sink/channels - /sys/bus/soundwire/devices/sdw:.../dpN_sink/ch_combinations - /sys/bus/soundwire/devices/sdw:.../dpN_sink/max_async_buffer - /sys/bus/soundwire/devices/sdw:.../dpN_sink/block_pack_mode - /sys/bus/soundwire/devices/sdw:.../dpN_sink/port_encoding +What: /sys/bus/soundwire/devices/sdw:.../dp<N>_src/max_word + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/min_word + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/words + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/type + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/max_grouping + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/simple_ch_prep_sm + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/ch_prep_timeout + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/imp_def_interrupts + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/min_ch + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/max_ch + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/channels + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/ch_combinations + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/max_async_buffer + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/block_pack_mode + /sys/bus/soundwire/devices/sdw:.../dp<N>_src/port_encoding + + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/max_word + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/min_word + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/words + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/type + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/max_grouping + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/simple_ch_prep_sm + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/ch_prep_timeout + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/imp_def_interrupts + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/min_ch + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/max_ch + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/channels + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/ch_combinations + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/max_async_buffer + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/block_pack_mode + /sys/bus/soundwire/devices/sdw:.../dp<N>_sink/port_encoding Date: May 2020 diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index 73eb23bc1f34..2ebe5708b4bc 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -1,4 +1,4 @@ -What: /sys/bus/usb/devices/INTERFACE/authorized +What: /sys/bus/usb/devices/<INTERFACE>/authorized Date: August 2015 Description: This allows to authorize (1) or deauthorize (0) @@ -166,14 +166,14 @@ Description: The file will be present for all speeds of USB devices, and will always read "no" for USB 1.1 and USB 2.0 devices. -What: /sys/bus/usb/devices/.../(hub interface)/portX +What: /sys/bus/usb/devices/.../<hub_interface>/port<X> Date: August 2012 Contact: Lan Tianyu <tianyu.lan@intel.com> Description: - The /sys/bus/usb/devices/.../(hub interface)/portX + The /sys/bus/usb/devices/.../<hub_interface>/port<X> is usb port device's sysfs directory. -What: /sys/bus/usb/devices/.../(hub interface)/portX/connect_type +What: /sys/bus/usb/devices/.../<hub_interface>/port<X>/connect_type Date: January 2013 Contact: Lan Tianyu <tianyu.lan@intel.com> Description: @@ -182,7 +182,7 @@ Description: The file will read "hotplug", "hardwired" and "not used" if the information is available, and "unknown" otherwise. -What: /sys/bus/usb/devices/.../(hub interface)/portX/location +What: /sys/bus/usb/devices/.../<hub_interface>/port<X>/location Date: October 2018 Contact: Bjørn Mork <bjorn@mork.no> Description: @@ -192,7 +192,7 @@ Description: raw location value as a hex integer. -What: /sys/bus/usb/devices/.../(hub interface)/portX/quirks +What: /sys/bus/usb/devices/.../<hub_interface>/port<X>/quirks Date: May 2018 Contact: Nicolas Boichat <drinkcat@chromium.org> Description: @@ -216,7 +216,7 @@ Description: used to help make enumeration work better on some high speed devices. -What: /sys/bus/usb/devices/.../(hub interface)/portX/over_current_count +What: /sys/bus/usb/devices/.../<hub_interface>/port<X>/over_current_count Date: February 2018 Contact: Richard Leitner <richard.leitner@skidata.com> Description: @@ -230,10 +230,10 @@ Description: Any time this value changes the corresponding hub device will send a udev event with the following attributes:: - OVER_CURRENT_PORT=/sys/bus/usb/devices/.../(hub interface)/portX + OVER_CURRENT_PORT=/sys/bus/usb/devices/.../<hub_interface>/port<X> OVER_CURRENT_COUNT=[current value of this sysfs attribute] -What: /sys/bus/usb/devices/.../(hub interface)/portX/usb3_lpm_permit +What: /sys/bus/usb/devices/.../<hub_interface>/port<X>/usb3_lpm_permit Date: November 2015 Contact: Lu Baolu <baolu.lu@linux.intel.com> Description: @@ -288,3 +288,277 @@ Description: USB 3.2 adds Dual-lane support, 2 rx and 2 tx -lanes over Type-C. Inter-Chip SSIC devices support asymmetric lanes up to 4 lanes per direction. Devices before USB 3.2 are single lane (tx_lanes = 1) + +What: /sys/bus/usb/devices/usbX/bAlternateSetting +Description: + The current interface alternate setting number, in decimal. + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bcdDevice +Description: + The device's release number, in hexadecimal. + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bConfigurationValue +Description: + While a USB device typically have just one configuration + setting, some devices support multiple configurations. + + This value shows the current configuration, in decimal. + + Changing its value will change the device's configuration + to another setting. + + The number of configurations supported by a device is at: + + /sys/bus/usb/devices/usbX/bNumConfigurations + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bDeviceClass +Description: + Class code of the device, in hexadecimal. + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bDeviceProtocol +Description: + Protocol code of the device, in hexadecimal. + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bDeviceSubClass +Description: + Subclass code of the device, in hexadecimal. + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bInterfaceClass +Description: + Class code of the interface, in hexadecimal. + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bInterfaceNumber +Description: + Interface number, in hexadecimal. + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bInterfaceProtocol +Description: + Protocol code of the interface, in hexadecimal. + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bInterfaceSubClass +Description: + Subclass code of the interface, in hexadecimal. + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bmAttributes +Description: + Attributes of the current configuration, in hexadecimal. + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bMaxPacketSize0 +Description: + Maximum endpoint 0 packet size, in decimal. + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bMaxPower +Description: + Maximum power consumption of the active configuration of + the device, in miliamperes. + +What: /sys/bus/usb/devices/usbX/bNumConfigurations +Description: + Number of the possible configurations of the device, in + decimal. The current configuration is controlled via: + + /sys/bus/usb/devices/usbX/bConfigurationValue + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bNumEndpoints +Description: + Number of endpoints used on this interface, in hexadecimal. + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/bNumInterfaces +Description: + Number of interfaces on this device, in decimal. + +What: /sys/bus/usb/devices/usbX/busnum +Description: + Number of the bus. + +What: /sys/bus/usb/devices/usbX/configuration +Description: + Contents of the string descriptor associated with the + current configuration. It may include the firmware version + of a device and/or its serial number. + +What: /sys/bus/usb/devices/usbX/descriptors +Description: + Contains the interface descriptors, in binary. + +What: /sys/bus/usb/devices/usbX/idProduct +Description: + Product ID, in hexadecimal. + +What: /sys/bus/usb/devices/usbX/idVendor +Description: + Vendor ID, in hexadecimal. + +What: /sys/bus/usb/devices/usbX/devspec +Description: + Displays the Device Tree Open Firmware node of the interface. + +What: /sys/bus/usb/devices/usbX/avoid_reset_quirk +Description: + Most devices have this set to zero. + + If the value is 1, enable a USB quirk that prevents this + device to use reset. + + (read/write) + +What: /sys/bus/usb/devices/usbX/devnum +Description: + USB interface device number, in decimal. + +What: /sys/bus/usb/devices/usbX/devpath +Description: + String containing the USB interface device path. + +What: /sys/bus/usb/devices/usbX/manufacturer +Description: + Vendor specific string containing the name of the + manufacturer of the device. + +What: /sys/bus/usb/devices/usbX/maxchild +Description: + Number of ports of an USB hub + +What: /sys/bus/usb/devices/usbX/persist +Description: + Keeps the device even if it gets disconnected. + +What: /sys/bus/usb/devices/usbX/product +Description: + Vendor specific string containing the name of the + device's product. + +What: /sys/bus/usb/devices/usbX/speed +Description: + Shows the device's max speed, according to the USB version, + in Mbps. + Can be: + + ======= ==================== + Unknown speed unknown + 1.5 Low speed + 15 Full speed + 480 High Speed + 5000 Super Speed + 10000 Super Speed+ + 20000 Super Speed+ Gen 2x2 + ======= ==================== + +What: /sys/bus/usb/devices/usbX/supports_autosuspend +Description: + Returns 1 if the device doesn't support autosuspend. + Otherwise, returns 0. + +What: /sys/bus/usb/devices/usbX/urbnum +Description: + Number of URBs submitted for the whole device. + +What: /sys/bus/usb/devices/usbX/version +Description: + String containing the USB device version, as encoded + at the BCD descriptor. + +What: /sys/bus/usb/devices/usbX/power/autosuspend +Description: + Time in milliseconds for the device to autosuspend. If the + value is negative, then autosuspend is prevented. + + (read/write) + +What: /sys/bus/usb/devices/usbX/power/active_duration +Description: + The total time the device has not been suspended. + +What: /sys/bus/usb/devices/usbX/power/connected_duration +Description: + The total time (in msec) that the device has been connected. + +What: /sys/bus/usb/devices/usbX/power/level +Description: + +What: /sys/bus/usb/devices/usbX/ep_<N>/bEndpointAddress +Description: + The address of the endpoint described by this descriptor, + in hexadecimal. The endpoint direction on this bitmapped field + is also shown at: + + /sys/bus/usb/devices/usbX/ep_<N>/direction + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/ep_<N>/bInterval +Description: + The interval of the endpoint as described on its descriptor, + in hexadecimal. The actual interval depends on the version + of the USB. Also shown in time units at + /sys/bus/usb/devices/usbX/ep_<N>/interval. + +What: /sys/bus/usb/devices/usbX/ep_<N>/bLength +Description: + Number of bytes of the endpoint descriptor, in hexadecimal. + +What: /sys/bus/usb/devices/usbX/ep_<N>/bmAttributes +Description: + Attributes which apply to the endpoint as described on its + descriptor, in hexadecimal. The endpoint type on this + bitmapped field is also shown at: + + /sys/bus/usb/devices/usbX/ep_<N>/type + + See USB specs for its meaning. + +What: /sys/bus/usb/devices/usbX/ep_<N>/direction +Description: + Direction of the endpoint. Can be: + + - both (on control endpoints) + - in + - out + +What: /sys/bus/usb/devices/usbX/ep_<N>/interval +Description: + Interval for polling endpoint for data transfers, in + milisseconds or microseconds. + +What: /sys/bus/usb/devices/usbX/ep_<N>/type +Description: + Descriptor type. Can be: + + - Control + - Isoc + - Bulk + - Interrupt + - unknown + +What: /sys/bus/usb/devices/usbX/ep_<N>/wMaxPacketSize +Description: + Maximum packet size this endpoint is capable of + sending or receiving, in hexadecimal. diff --git a/Documentation/ABI/testing/sysfs-class-bdi b/Documentation/ABI/testing/sysfs-class-bdi index 5402bd74ba43..6d2a2fc189dd 100644 --- a/Documentation/ABI/testing/sysfs-class-bdi +++ b/Documentation/ABI/testing/sysfs-class-bdi @@ -23,14 +23,17 @@ default The default backing dev, used for non-block device backed filesystems which do not provide their own BDI. -Files under /sys/class/bdi/<bdi>/ - -read_ahead_kb (read-write) - +What: /sys/class/bdi/<bdi>/read_ahead_kb +Date: January 2008 +Contact: Peter Zijlstra <a.p.zijlstra@chello.nl> +Description: Size of the read-ahead window in kilobytes -min_ratio (read-write) - + (read-write) +What: /sys/class/bdi/<bdi>/min_ratio +Date: January 2008 +Contact: Peter Zijlstra <a.p.zijlstra@chello.nl> +Description: Under normal circumstances each device is given a part of the total write-back cache that relates to its current average writeout speed in relation to the other devices. @@ -39,8 +42,12 @@ min_ratio (read-write) percentage of the write-back cache to a particular device. For example, this is useful for providing a minimum QoS. -max_ratio (read-write) + (read-write) +What: /sys/class/bdi/<bdi>/max_ratio +Date: January 2008 +Contact: Peter Zijlstra <a.p.zijlstra@chello.nl> +Description: Allows limiting a particular device to use not more than the given percentage of the write-back cache. This is useful in situations where we want to avoid one device taking all or @@ -48,7 +55,12 @@ max_ratio (read-write) mount that is prone to get stuck, or a FUSE mount which cannot be trusted to play fair. -stable_pages_required (read-only) - + (read-write) +What: /sys/class/bdi/<bdi>/stable_pages_required +Date: January 2008 +Contact: Peter Zijlstra <a.p.zijlstra@chello.nl> +Description: If set, the backing device requires that all pages comprising a write request must not be changed until writeout is complete. + + (read-only) diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl index 818f55970efb..3c77677e0ca7 100644 --- a/Documentation/ABI/testing/sysfs-class-cxl +++ b/Documentation/ABI/testing/sysfs-class-cxl @@ -166,10 +166,11 @@ Description: read only Decimal value of the Per Process MMIO space length. Users: https://github.com/ibm-capi/libcxl -What: /sys/class/cxl/<afu>m/pp_mmio_off (not in a guest) +What: /sys/class/cxl/<afu>m/pp_mmio_off Date: September 2014 Contact: linuxppc-dev@lists.ozlabs.org Description: read only + (not in a guest) Decimal value of the Per Process MMIO space offset. Users: https://github.com/ibm-capi/libcxl @@ -190,28 +191,31 @@ Description: read only Identifies the revision level of the PSL. Users: https://github.com/ibm-capi/libcxl -What: /sys/class/cxl/<card>/base_image (not in a guest) +What: /sys/class/cxl/<card>/base_image Date: September 2014 Contact: linuxppc-dev@lists.ozlabs.org Description: read only + (not in a guest) Identifies the revision level of the base image for devices that support loadable PSLs. For FPGAs this field identifies the image contained in the on-adapter flash which is loaded during the initial program load. Users: https://github.com/ibm-capi/libcxl -What: /sys/class/cxl/<card>/image_loaded (not in a guest) +What: /sys/class/cxl/<card>/image_loaded Date: September 2014 Contact: linuxppc-dev@lists.ozlabs.org Description: read only + (not in a guest) Will return "user" or "factory" depending on the image loaded onto the card. Users: https://github.com/ibm-capi/libcxl -What: /sys/class/cxl/<card>/load_image_on_perst (not in a guest) +What: /sys/class/cxl/<card>/load_image_on_perst Date: December 2014 Contact: linuxppc-dev@lists.ozlabs.org Description: read/write + (not in a guest) Valid entries are "none", "user", and "factory". "none" means PERST will not cause image to be loaded to the card. A power cycle is required to load the image. @@ -235,10 +239,11 @@ Description: write only contexts on the card AFUs. Users: https://github.com/ibm-capi/libcxl -What: /sys/class/cxl/<card>/perst_reloads_same_image (not in a guest) +What: /sys/class/cxl/<card>/perst_reloads_same_image Date: July 2015 Contact: linuxppc-dev@lists.ozlabs.org Description: read/write + (not in a guest) Trust that when an image is reloaded via PERST, it will not have changed. diff --git a/Documentation/ABI/testing/sysfs-class-devfreq-event b/Documentation/ABI/testing/sysfs-class-devfreq-event index ceaf0f686d4a..dbe48495e55a 100644 --- a/Documentation/ABI/testing/sysfs-class-devfreq-event +++ b/Documentation/ABI/testing/sysfs-class-devfreq-event @@ -1,25 +1,25 @@ -What: /sys/class/devfreq-event/event(x)/ +What: /sys/class/devfreq-event/event<x>/ Date: January 2017 Contact: Chanwoo Choi <cw00.choi@samsung.com> Description: Provide a place in sysfs for the devfreq-event objects. This allows accessing various devfreq-event specific variables. - The name of devfreq-event object denoted as 'event(x)' which + The name of devfreq-event object denoted as 'event<x>' which includes the unique number of 'x' for each devfreq-event object. -What: /sys/class/devfreq-event/event(x)/name +What: /sys/class/devfreq-event/event<x>/name Date: January 2017 Contact: Chanwoo Choi <cw00.choi@samsung.com> Description: - The /sys/class/devfreq-event/event(x)/name attribute contains + The /sys/class/devfreq-event/event<x>/name attribute contains the name of the devfreq-event object. This attribute is read-only. -What: /sys/class/devfreq-event/event(x)/enable_count +What: /sys/class/devfreq-event/event<x>/enable_count Date: January 2017 Contact: Chanwoo Choi <cw00.choi@samsung.com> Description: - The /sys/class/devfreq-event/event(x)/enable_count attribute + The /sys/class/devfreq-event/event<x>/enable_count attribute contains the reference count to enable the devfreq-event object. If the device is enabled, the value of attribute is greater than zero. diff --git a/Documentation/ABI/testing/sysfs-class-extcon b/Documentation/ABI/testing/sysfs-class-extcon index fde0fecd5de9..f8e705375b24 100644 --- a/Documentation/ABI/testing/sysfs-class-extcon +++ b/Documentation/ABI/testing/sysfs-class-extcon @@ -65,19 +65,19 @@ Description: interface associated with each cable cannot update multiple cable states of an extcon device simultaneously. -What: /sys/class/extcon/.../cable.x/name +What: /sys/class/extcon/.../cable.X/name Date: February 2012 Contact: MyungJoo Ham <myungjoo.ham@samsung.com> Description: - The /sys/class/extcon/.../cable.x/name shows the name of cable - "x" (integer between 0 and 31) of an extcon device. + The /sys/class/extcon/.../cable.X/name shows the name of cable + "X" (integer between 0 and 31) of an extcon device. -What: /sys/class/extcon/.../cable.x/state +What: /sys/class/extcon/.../cable.X/state Date: February 2012 Contact: MyungJoo Ham <myungjoo.ham@samsung.com> Description: - The /sys/class/extcon/.../cable.x/state shows and stores the - state of cable "x" (integer between 0 and 31) of an extcon + The /sys/class/extcon/.../cable.X/state shows and stores the + state of cable "X" (integer between 0 and 31) of an extcon device. The state value is either 0 (detached) or 1 (attached). diff --git a/Documentation/ABI/testing/sysfs-class-fc b/Documentation/ABI/testing/sysfs-class-fc new file mode 100644 index 000000000000..3057a6d3b8cf --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-fc @@ -0,0 +1,27 @@ +What: /sys/class/fc/fc_udev_device/appid_store +Date: Aug 2021 +Contact: Muneendra Kumar <muneendra.kumar@broadconm.com> +Description: + This interface allows an admin to set an FC application + identifier in the blkcg associated with a cgroup id. The + identifier is typically a UUID that is associated with + an application or logical entity such as a virtual + machine or container group. The application or logical + entity utilizes a block device via the cgroup id. + FC adapter drivers may query the identifier and tag FC + traffic based on the identifier. FC host and FC fabric + entities can utilize the application id and FC traffic + tag to identify traffic sources. + + The interface expects a string "<cgroupid>:<appid>" where: + <cgroupid> is inode of the cgroup in hexadecimal + <appid> is user provided string upto 128 characters + in length. + + If an appid_store is done for a cgroup id that already + has an appid set, the new value will override the + previous value. + + If an admin wants to remove an FC application identifier + from a cgroup, an appid_store should be done with the + following string: "<cgroupid>:" diff --git a/Documentation/ABI/testing/sysfs-class-gnss b/Documentation/ABI/testing/sysfs-class-gnss index c8553d972edd..9650f3a7fc03 100644 --- a/Documentation/ABI/testing/sysfs-class-gnss +++ b/Documentation/ABI/testing/sysfs-class-gnss @@ -1,4 +1,4 @@ -What: /sys/class/gnss/gnssN/type +What: /sys/class/gnss/gnss<N>/type Date: May 2018 KernelVersion: 4.18 Contact: Johan Hovold <johan@kernel.org> diff --git a/Documentation/ABI/testing/sysfs-class-hwmon b/Documentation/ABI/testing/sysfs-class-hwmon new file mode 100644 index 000000000000..1f20687def44 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-hwmon @@ -0,0 +1,932 @@ +What: /sys/class/hwmon/hwmonX/name +Description: + The chip name. + This should be a short, lowercase string, not containing + whitespace, dashes, or the wildcard character '*'. + This attribute represents the chip name. It is the only + mandatory attribute. + I2C devices get this attribute created automatically. + + RO + +What: /sys/class/hwmon/hwmonX/update_interval +Description: + The interval at which the chip will update readings. + Unit: millisecond + + RW + + Some devices have a variable update rate or interval. + This attribute can be used to change it to the desired value. + +What: /sys/class/hwmon/hwmonX/inY_min +Description: + Voltage min value. + + Unit: millivolt + + RW + +What: /sys/class/hwmon/hwmonX/inY_lcrit +Description: + Voltage critical min value. + + Unit: millivolt + + RW + + If voltage drops to or below this limit, the system may + take drastic action such as power down or reset. At the very + least, it should report a fault. + +What: /sys/class/hwmon/hwmonX/inY_max +Description: + Voltage max value. + + Unit: millivolt + + RW + +What: /sys/class/hwmon/hwmonX/inY_crit +Description: + Voltage critical max value. + + Unit: millivolt + + RW + + If voltage reaches or exceeds this limit, the system may + take drastic action such as power down or reset. At the very + least, it should report a fault. + +What: /sys/class/hwmon/hwmonX/inY_input +Description: + Voltage input value. + + Unit: millivolt + + RO + + Voltage measured on the chip pin. + + Actual voltage depends on the scaling resistors on the + motherboard, as recommended in the chip datasheet. + + This varies by chip and by motherboard. + Because of this variation, values are generally NOT scaled + by the chip driver, and must be done by the application. + However, some drivers (notably lm87 and via686a) + do scale, because of internal resistors built into a chip. + These drivers will output the actual voltage. Rule of + thumb: drivers should report the voltage values at the + "pins" of the chip. + +What: /sys/class/hwmon/hwmonX/inY_average +Description: + Average voltage + + Unit: millivolt + + RO + +What: /sys/class/hwmon/hwmonX/inY_lowest +Description: + Historical minimum voltage + + Unit: millivolt + + RO + +What: /sys/class/hwmon/hwmonX/inY_highest +Description: + Historical maximum voltage + + Unit: millivolt + + RO + +What: /sys/class/hwmon/hwmonX/inY_reset_history +Description: + Reset inX_lowest and inX_highest + + WO + +What: /sys/class/hwmon/hwmonX/in_reset_history +Description: + Reset inX_lowest and inX_highest for all sensors + + WO + +What: /sys/class/hwmon/hwmonX/inY_label +Description: + Suggested voltage channel label. + + Text string + + Should only be created if the driver has hints about what + this voltage channel is being used for, and user-space + doesn't. In all other cases, the label is provided by + user-space. + + RO + +What: /sys/class/hwmon/hwmonX/inY_enable +Description: + Enable or disable the sensors. + + When disabled the sensor read will return -ENODATA. + + - 1: Enable + - 0: Disable + + RW + +What: /sys/class/hwmon/hwmonX/cpuY_vid +Description: + CPU core reference voltage. + + Unit: millivolt + + RO + + Not always correct. + +What: /sys/class/hwmon/hwmonX/vrm +Description: + Voltage Regulator Module version number. + + RW (but changing it should no more be necessary) + + Originally the VRM standard version multiplied by 10, but now + an arbitrary number, as not all standards have a version + number. + + Affects the way the driver calculates the CPU core reference + voltage from the vid pins. + +What: /sys/class/hwmon/hwmonX/inY_rated_min +Description: + Minimum rated voltage. + + Unit: millivolt + + RO + +What: /sys/class/hwmon/hwmonX/inY_rated_max +Description: + Maximum rated voltage. + + Unit: millivolt + + RO + +What: /sys/class/hwmon/hwmonX/fanY_min +Description: + Fan minimum value + + Unit: revolution/min (RPM) + + RW + +What: /sys/class/hwmon/hwmonX/fanY_max +Description: + Fan maximum value + + Unit: revolution/min (RPM) + + Only rarely supported by the hardware. + RW + +What: /sys/class/hwmon/hwmonX/fanY_input +Description: + Fan input value. + + Unit: revolution/min (RPM) + + RO + +What: /sys/class/hwmon/hwmonX/fanY_div +Description: + Fan divisor. + + Integer value in powers of two (1, 2, 4, 8, 16, 32, 64, 128). + + RW + + Some chips only support values 1, 2, 4 and 8. + Note that this is actually an internal clock divisor, which + affects the measurable speed range, not the read value. + +What: /sys/class/hwmon/hwmonX/fanY_pulses +Description: + Number of tachometer pulses per fan revolution. + + Integer value, typically between 1 and 4. + + RW + + This value is a characteristic of the fan connected to the + device's input, so it has to be set in accordance with the fan + model. + + Should only be created if the chip has a register to configure + the number of pulses. In the absence of such a register (and + thus attribute) the value assumed by all devices is 2 pulses + per fan revolution. + +What: /sys/class/hwmon/hwmonX/fanY_target +Description: + Desired fan speed + + Unit: revolution/min (RPM) + + RW + + Only makes sense if the chip supports closed-loop fan speed + control based on the measured fan speed. + +What: /sys/class/hwmon/hwmonX/fanY_label +Description: + Suggested fan channel label. + + Text string + + Should only be created if the driver has hints about what + this fan channel is being used for, and user-space doesn't. + In all other cases, the label is provided by user-space. + + RO + +What: /sys/class/hwmon/hwmonX/fanY_enable +Description: + Enable or disable the sensors. + + When disabled the sensor read will return -ENODATA. + + - 1: Enable + - 0: Disable + + RW + +What: /sys/class/hwmon/hwmonX/pwmY +Description: + Pulse width modulation fan control. + + Integer value in the range 0 to 255 + + RW + + 255 is max or 100%. + +What: /sys/class/hwmon/hwmonX/pwmY_enable +Description: + Fan speed control method: + + - 0: no fan speed control (i.e. fan at full speed) + - 1: manual fan speed control enabled (using `pwmY`) + - 2+: automatic fan speed control enabled + + Check individual chip documentation files for automatic mode + details. + + RW + +What: /sys/class/hwmon/hwmonX/pwmY_mode +Description: + - 0: DC mode (direct current) + - 1: PWM mode (pulse-width modulation) + + RW + +What: /sys/class/hwmon/hwmonX/pwmY_freq +Description: + Base PWM frequency in Hz. + + Only possibly available when pwmN_mode is PWM, but not always + present even then. + + RW + +What: /sys/class/hwmon/hwmonX/pwmY_auto_channels_temp +Description: + Select which temperature channels affect this PWM output in + auto mode. + + Bitfield, 1 is temp1, 2 is temp2, 4 is temp3 etc... + Which values are possible depend on the chip used. + + RW + +What: /sys/class/hwmon/hwmonX/pwmY_auto_pointZ_pwm +What: /sys/class/hwmon/hwmonX/pwmY_auto_pointZ_temp +What: /sys/class/hwmon/hwmonX/pwmY_auto_pointZ_temp_hyst +Description: + Define the PWM vs temperature curve. + + Number of trip points is chip-dependent. Use this for chips + which associate trip points to PWM output channels. + + RW + +What: /sys/class/hwmon/hwmonX/tempY_auto_pointZ_pwm +What: /sys/class/hwmon/hwmonX/tempY_auto_pointZ_temp +What: /sys/class/hwmon/hwmonX/tempY_auto_pointZ_temp_hyst +Description: + Define the PWM vs temperature curve. + + Number of trip points is chip-dependent. Use this for chips + which associate trip points to temperature channels. + + RW + +What: /sys/class/hwmon/hwmonX/tempY_type +Description: + Sensor type selection. + + Integers 1 to 6 + + RW + + - 1: CPU embedded diode + - 2: 3904 transistor + - 3: thermal diode + - 4: thermistor + - 5: AMD AMDSI + - 6: Intel PECI + + Not all types are supported by all chips + +What: /sys/class/hwmon/hwmonX/tempY_max +Description: + Temperature max value. + + Unit: millidegree Celsius (or millivolt, see below) + + RW + +What: /sys/class/hwmon/hwmonX/tempY_min +Description: + Temperature min value. + + Unit: millidegree Celsius + + RW + +What: /sys/class/hwmon/hwmonX/tempY_max_hyst +Description: + Temperature hysteresis value for max limit. + + Unit: millidegree Celsius + + Must be reported as an absolute temperature, NOT a delta + from the max value. + + RW + +What: /sys/class/hwmon/hwmonX/tempY_min_hyst +Description: + Temperature hysteresis value for min limit. + Unit: millidegree Celsius + + Must be reported as an absolute temperature, NOT a delta + from the min value. + + RW + +What: /sys/class/hwmon/hwmonX/tempY_input +Description: + Temperature input value. + + Unit: millidegree Celsius + + RO + +What: /sys/class/hwmon/hwmonX/tempY_crit +Description: + Temperature critical max value, typically greater than + corresponding temp_max values. + + Unit: millidegree Celsius + + RW + +What: /sys/class/hwmon/hwmonX/tempY_crit_alarm +Description: + Critical high temperature alarm flag. + + - 0: OK + - 1: temperature has reached tempY_crit + + RW + + Contrary to regular alarm flags which clear themselves + automatically when read, this one sticks until cleared by + the user. This is done by writing 0 to the file. Writing + other values is unsupported. + +What: /sys/class/hwmon/hwmonX/tempY_crit_hyst +Description: + Temperature hysteresis value for critical limit. + + Unit: millidegree Celsius + + Must be reported as an absolute temperature, NOT a delta + from the critical value. + + RW + +What: /sys/class/hwmon/hwmonX/tempY_emergency +Description: + Temperature emergency max value, for chips supporting more than + two upper temperature limits. Must be equal or greater than + corresponding temp_crit values. + + Unit: millidegree Celsius + + RW + +What: /sys/class/hwmon/hwmonX/tempY_emergency_hyst +Description: + Temperature hysteresis value for emergency limit. + + Unit: millidegree Celsius + + Must be reported as an absolute temperature, NOT a delta + from the emergency value. + + RW + +What: /sys/class/hwmon/hwmonX/tempY_lcrit +Description: + Temperature critical min value, typically lower than + corresponding temp_min values. + + Unit: millidegree Celsius + + RW + +What: /sys/class/hwmon/hwmonX/tempY_lcrit_hyst +Description: + Temperature hysteresis value for critical min limit. + + Unit: millidegree Celsius + + Must be reported as an absolute temperature, NOT a delta + from the critical min value. + + RW + +What: /sys/class/hwmon/hwmonX/tempY_offset +Description: + Temperature offset which is added to the temperature reading + by the chip. + + Unit: millidegree Celsius + + Read/Write value. + +What: /sys/class/hwmon/hwmonX/tempY_label +Description: + Suggested temperature channel label. + + Text string + + Should only be created if the driver has hints about what + this temperature channel is being used for, and user-space + doesn't. In all other cases, the label is provided by + user-space. + + RO + +What: /sys/class/hwmon/hwmonX/tempY_lowest +Description: + Historical minimum temperature + + Unit: millidegree Celsius + + RO + +What: /sys/class/hwmon/hwmonX/tempY_highest +Description: + Historical maximum temperature + + Unit: millidegree Celsius + + RO + +What: /sys/class/hwmon/hwmonX/tempY_reset_history +Description: + Reset temp_lowest and temp_highest + + WO + +What: /sys/class/hwmon/hwmonX/temp_reset_history +Description: + Reset temp_lowest and temp_highest for all sensors + + WO + +What: /sys/class/hwmon/hwmonX/tempY_enable +Description: + Enable or disable the sensors. + + When disabled the sensor read will return -ENODATA. + + - 1: Enable + - 0: Disable + + RW + +What: /sys/class/hwmon/hwmonX/tempY_rated_min +Description: + Minimum rated temperature. + + Unit: millidegree Celsius + + RO + +What: /sys/class/hwmon/hwmonX/tempY_rated_max +Description: + Maximum rated temperature. + + Unit: millidegree Celsius + + RO + +What: /sys/class/hwmon/hwmonX/currY_max +Description: + Current max value + + Unit: milliampere + + RW + +What: /sys/class/hwmon/hwmonX/currY_min +Description: + Current min value. + + Unit: milliampere + + RW + +What: /sys/class/hwmon/hwmonX/currY_lcrit +Description: + Current critical low value + + Unit: milliampere + + RW + +What: /sys/class/hwmon/hwmonX/currY_crit +Description: + Current critical high value. + + Unit: milliampere + + RW + +What: /sys/class/hwmon/hwmonX/currY_input +Description: + Current input value + + Unit: milliampere + + RO + +What: /sys/class/hwmon/hwmonX/currY_average +Description: + Average current use + + Unit: milliampere + + RO + +What: /sys/class/hwmon/hwmonX/currY_lowest +Description: + Historical minimum current + + Unit: milliampere + + RO + +What: /sys/class/hwmon/hwmonX/currY_highest +Description: + Historical maximum current + Unit: milliampere + RO + +What: /sys/class/hwmon/hwmonX/currY_reset_history +Description: + Reset currX_lowest and currX_highest + + WO + +What: /sys/class/hwmon/hwmonX/curr_reset_history +Description: + Reset currX_lowest and currX_highest for all sensors + + WO + +What: /sys/class/hwmon/hwmonX/currY_enable +Description: + Enable or disable the sensors. + + When disabled the sensor read will return -ENODATA. + + - 1: Enable + - 0: Disable + + RW + +What: /sys/class/hwmon/hwmonX/currY_rated_min +Description: + Minimum rated current. + + Unit: milliampere + + RO + +What: /sys/class/hwmon/hwmonX/currY_rated_max +Description: + Maximum rated current. + + Unit: milliampere + + RO + +What: /sys/class/hwmon/hwmonX/powerY_average +Description: + Average power use + + Unit: microWatt + + RO + +What: /sys/class/hwmon/hwmonX/powerY_average_interval +Description: + Power use averaging interval. A poll + notification is sent to this file if the + hardware changes the averaging interval. + + Unit: milliseconds + + RW + +What: /sys/class/hwmon/hwmonX/powerY_average_interval_max +Description: + Maximum power use averaging interval + + Unit: milliseconds + + RO + +What: /sys/class/hwmon/hwmonX/powerY_average_interval_min +Description: + Minimum power use averaging interval + + Unit: milliseconds + + RO + +What: /sys/class/hwmon/hwmonX/powerY_average_highest +Description: + Historical average maximum power use + + Unit: microWatt + + RO + +What: /sys/class/hwmon/hwmonX/powerY_average_lowest +Description: + Historical average minimum power use + + Unit: microWatt + + RO + +What: /sys/class/hwmon/hwmonX/powerY_average_max +Description: + A poll notification is sent to + `powerY_average` when power use + rises above this value. + + Unit: microWatt + + RW + +What: /sys/class/hwmon/hwmonX/powerY_average_min +Description: + A poll notification is sent to + `powerY_average` when power use + sinks below this value. + + Unit: microWatt + + RW + +What: /sys/class/hwmon/hwmonX/powerY_input +Description: + Instantaneous power use + + Unit: microWatt + + RO + +What: /sys/class/hwmon/hwmonX/powerY_input_highest +Description: + Historical maximum power use + + Unit: microWatt + + RO + +What: /sys/class/hwmon/hwmonX/powerY_input_lowest +Description: + Historical minimum power use + + Unit: microWatt + + RO + +What: /sys/class/hwmon/hwmonX/powerY_reset_history +Description: + Reset input_highest, input_lowest, + average_highest and average_lowest. + + WO + +What: /sys/class/hwmon/hwmonX/powerY_accuracy +Description: + Accuracy of the power meter. + + Unit: Percent + + RO + +What: /sys/class/hwmon/hwmonX/powerY_cap +Description: + If power use rises above this limit, the + system should take action to reduce power use. + A poll notification is sent to this file if the + cap is changed by the hardware. The `*_cap` + files only appear if the cap is known to be + enforced by hardware. + + Unit: microWatt + + RW + +What: /sys/class/hwmon/hwmonX/powerY_cap_hyst +Description: + Margin of hysteresis built around capping and + notification. + + Unit: microWatt + + RW + +What: /sys/class/hwmon/hwmonX/powerY_cap_max +Description: + Maximum cap that can be set. + + Unit: microWatt + + RO + +What: /sys/class/hwmon/hwmonX/powerY_cap_min +Description: + Minimum cap that can be set. + + Unit: microWatt + + RO + +What: /sys/class/hwmon/hwmonX/powerY_max +Description: + Maximum power. + + Unit: microWatt + + RW + +What: /sys/class/hwmon/hwmonX/powerY_crit +Description: + Critical maximum power. + + If power rises to or above this limit, the + system is expected take drastic action to reduce + power consumption, such as a system shutdown or + a forced powerdown of some devices. + + Unit: microWatt + + RW + +What: /sys/class/hwmon/hwmonX/powerY_enable +Description: + Enable or disable the sensors. + + When disabled the sensor read will return + -ENODATA. + + - 1: Enable + - 0: Disable + + RW + +What: /sys/class/hwmon/hwmonX/powerY_rated_min +Description: + Minimum rated power. + + Unit: microWatt + + RO + +What: /sys/class/hwmon/hwmonX/powerY_rated_max +Description: + Maximum rated power. + + Unit: microWatt + + RO + +What: /sys/class/hwmon/hwmonX/energyY_input +Description: + Cumulative energy use + + Unit: microJoule + + RO + +What: /sys/class/hwmon/hwmonX/energyY_enable +Description: + Enable or disable the sensors. + + When disabled the sensor read will return + -ENODATA. + + - 1: Enable + - 0: Disable + + RW + +What: /sys/class/hwmon/hwmonX/humidityY_input +Description: + Humidity + + Unit: milli-percent (per cent mille, pcm) + + RO + + +What: /sys/class/hwmon/hwmonX/humidityY_enable +Description: + Enable or disable the sensors + + When disabled the sensor read will return + -ENODATA. + + - 1: Enable + - 0: Disable + + RW + +What: /sys/class/hwmon/hwmonX/humidityY_rated_min +Description: + Minimum rated humidity. + + Unit: milli-percent (per cent mille, pcm) + + RO + +What: /sys/class/hwmon/hwmonX/humidityY_rated_max +Description: + Maximum rated humidity. + + Unit: milli-percent (per cent mille, pcm) + + RO + + +What: /sys/class/hwmon/hwmonX/intrusionY_alarm +Description: + Chassis intrusion detection + + - 0: OK + - 1: intrusion detected + + RW + + Contrary to regular alarm flags which clear themselves + automatically when read, this one sticks until cleared by + the user. This is done by writing 0 to the file. Writing + other values is unsupported. + +What: /sys/class/hwmon/hwmonX/intrusionY_beep +Description: + Chassis intrusion beep + + - 0: disable + - 1: enable + + RW diff --git a/Documentation/ABI/testing/sysfs-class-mei b/Documentation/ABI/testing/sysfs-class-mei index 5c52372b43cb..1db36ddf8e58 100644 --- a/Documentation/ABI/testing/sysfs-class-mei +++ b/Documentation/ABI/testing/sysfs-class-mei @@ -6,7 +6,7 @@ Description: The mei/ class sub-directory belongs to mei device class -What: /sys/class/mei/meiN/ +What: /sys/class/mei/mei<N>/ Date: May 2014 KernelVersion: 3.17 Contact: Tomas Winkler <tomas.winkler@intel.com> @@ -14,7 +14,7 @@ Description: The /sys/class/mei/meiN directory is created for each probed mei device -What: /sys/class/mei/meiN/fw_status +What: /sys/class/mei/mei<N>/fw_status Date: Nov 2014 KernelVersion: 3.19 Contact: Tomas Winkler <tomas.winkler@intel.com> @@ -29,7 +29,7 @@ Description: Display fw status registers content Also number of registers varies between 1 and 6 depending on generation. -What: /sys/class/mei/meiN/hbm_ver +What: /sys/class/mei/mei<N>/hbm_ver Date: Aug 2016 KernelVersion: 4.9 Contact: Tomas Winkler <tomas.winkler@intel.com> @@ -38,7 +38,7 @@ Description: Display the negotiated HBM protocol version. The HBM protocol version negotiated between the driver and the device. -What: /sys/class/mei/meiN/hbm_ver_drv +What: /sys/class/mei/mei<N>/hbm_ver_drv Date: Aug 2016 KernelVersion: 4.9 Contact: Tomas Winkler <tomas.winkler@intel.com> @@ -46,7 +46,7 @@ Description: Display the driver HBM protocol version. The HBM protocol version supported by the driver. -What: /sys/class/mei/meiN/tx_queue_limit +What: /sys/class/mei/mei<N>/tx_queue_limit Date: Jan 2018 KernelVersion: 4.16 Contact: Tomas Winkler <tomas.winkler@intel.com> @@ -55,7 +55,7 @@ Description: Configure tx queue limit Set maximal number of pending writes per opened session. -What: /sys/class/mei/meiN/fw_ver +What: /sys/class/mei/mei<N>/fw_ver Date: May 2018 KernelVersion: 4.18 Contact: Tomas Winkler <tomas.winkler@intel.com> @@ -66,7 +66,7 @@ Description: Display the ME firmware version. There can be up to three such blocks for different FW components. -What: /sys/class/mei/meiN/dev_state +What: /sys/class/mei/mei<N>/dev_state Date: Mar 2019 KernelVersion: 5.1 Contact: Tomas Winkler <tomas.winkler@intel.com> @@ -81,7 +81,7 @@ Description: Display the ME device state. POWER_DOWN POWER_UP -What: /sys/class/mei/meiN/trc +What: /sys/class/mei/mei<N>/trc Date: Nov 2019 KernelVersion: 5.5 Contact: Tomas Winkler <tomas.winkler@intel.com> @@ -91,7 +91,7 @@ Description: Display trc status register content status information into trc status register for BIOS and OS to monitor fw health. -What: /sys/class/mei/meiN/kind +What: /sys/class/mei/mei<N>/kind Date: Jul 2020 KernelVersion: 5.8 Contact: Tomas Winkler <tomas.winkler@intel.com> diff --git a/Documentation/ABI/testing/sysfs-class-mic b/Documentation/ABI/testing/sysfs-class-mic index bd0e780c3760..5e5f36d10055 100644 --- a/Documentation/ABI/testing/sysfs-class-mic +++ b/Documentation/ABI/testing/sysfs-class-mic @@ -8,7 +8,7 @@ Description: PCIe form factor add-in Coprocessor card based on the Intel Many Integrated Core (MIC) architecture that runs a Linux OS. -What: /sys/class/mic/mic(x) +What: /sys/class/mic/mic<X> Date: October 2013 KernelVersion: 3.13 Contact: Sudeep Dutt <sudeep.dutt@intel.com> @@ -17,7 +17,7 @@ Description: represent MIC devices (0,1,..etc). Each directory has information specific to that MIC device. -What: /sys/class/mic/mic(x)/family +What: /sys/class/mic/mic<X>/family Date: October 2013 KernelVersion: 3.13 Contact: Sudeep Dutt <sudeep.dutt@intel.com> @@ -25,7 +25,7 @@ Description: Provides information about the Coprocessor family for an Intel MIC device. For example - "x100" -What: /sys/class/mic/mic(x)/stepping +What: /sys/class/mic/mic<X>/stepping Date: October 2013 KernelVersion: 3.13 Contact: Sudeep Dutt <sudeep.dutt@intel.com> @@ -33,7 +33,7 @@ Description: Provides information about the silicon stepping for an Intel MIC device. For example - "A0" or "B0" -What: /sys/class/mic/mic(x)/state +What: /sys/class/mic/mic<X>/state Date: October 2013 KernelVersion: 3.13 Contact: Sudeep Dutt <sudeep.dutt@intel.com> @@ -69,7 +69,7 @@ Description: "shutdown" Initiates card OS shutdown. ========== =================================================== -What: /sys/class/mic/mic(x)/shutdown_status +What: /sys/class/mic/mic<X>/shutdown_status Date: October 2013 KernelVersion: 3.13 Contact: Sudeep Dutt <sudeep.dutt@intel.com> @@ -88,7 +88,7 @@ Description: "restart" Shutdown because of a restart command. ========== =================================================== -What: /sys/class/mic/mic(x)/cmdline +What: /sys/class/mic/mic<X>/cmdline Date: October 2013 KernelVersion: 3.13 Contact: Sudeep Dutt <sudeep.dutt@intel.com> @@ -104,7 +104,7 @@ Description: or modify existing ones and then write the whole kernel command line back to this entry. -What: /sys/class/mic/mic(x)/firmware +What: /sys/class/mic/mic<X>/firmware Date: October 2013 KernelVersion: 3.13 Contact: Sudeep Dutt <sudeep.dutt@intel.com> @@ -114,7 +114,7 @@ Description: card can be found. The entry can be written to change the firmware image location under /lib/firmware/. -What: /sys/class/mic/mic(x)/ramdisk +What: /sys/class/mic/mic<X>/ramdisk Date: October 2013 KernelVersion: 3.13 Contact: Sudeep Dutt <sudeep.dutt@intel.com> @@ -124,7 +124,7 @@ Description: OS boot can be found. The entry can be written to change the ramdisk image location under /lib/firmware/. -What: /sys/class/mic/mic(x)/bootmode +What: /sys/class/mic/mic<X>/bootmode Date: October 2013 KernelVersion: 3.13 Contact: Sudeep Dutt <sudeep.dutt@intel.com> @@ -135,7 +135,7 @@ Description: a) linux - Boot a Linux image. b) flash - Boot an image for flash updates. -What: /sys/class/mic/mic(x)/log_buf_addr +What: /sys/class/mic/mic<X>/log_buf_addr Date: October 2013 KernelVersion: 3.13 Contact: Sudeep Dutt <sudeep.dutt@intel.com> @@ -149,7 +149,7 @@ Description: log buffer address to be written can be found in the System.map file of the card OS. -What: /sys/class/mic/mic(x)/log_buf_len +What: /sys/class/mic/mic<X>/log_buf_len Date: October 2013 KernelVersion: 3.13 Contact: Sudeep Dutt <sudeep.dutt@intel.com> @@ -163,7 +163,7 @@ Description: buffer length address to be written can be found in the System.map file of the card OS. -What: /sys/class/mic/mic(x)/heartbeat_enable +What: /sys/class/mic/mic<X>/heartbeat_enable Date: March 2015 KernelVersion: 4.4 Contact: Ashutosh Dixit <ashutosh.dixit@intel.com> diff --git a/Documentation/ABI/testing/sysfs-class-mux b/Documentation/ABI/testing/sysfs-class-mux index 8715f9c7bd4f..c58b7b6e1aa6 100644 --- a/Documentation/ABI/testing/sysfs-class-mux +++ b/Documentation/ABI/testing/sysfs-class-mux @@ -7,7 +7,7 @@ Description: Framework and provides a sysfs interface for using MUX controllers. -What: /sys/class/mux/muxchipN/ +What: /sys/class/mux/muxchip<N>/ Date: April 2017 KernelVersion: 4.13 Contact: Peter Rosin <peda@axentia.se> diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power index ca830c6cd809..f7904efc4cfa 100644 --- a/Documentation/ABI/testing/sysfs-class-power +++ b/Documentation/ABI/testing/sysfs-class-power @@ -480,6 +480,19 @@ Description: Valid values: Represented in microvolts +What: /sys/class/power_supply/<supply_name>/cycle_count +Date: January 2010 +Contact: linux-pm@vger.kernel.org +Description: + Reports the number of full charge + discharge cycles the + battery has undergone. + + Access: Read + + Valid values: + Integer > 0: representing full cycles + Integer = 0: cycle_count info is not available + **USB Properties** What: /sys/class/power_supply/<supply_name>/input_current_limit diff --git a/Documentation/ABI/testing/sysfs-class-pwm b/Documentation/ABI/testing/sysfs-class-pwm index c20e61354561..3d65285bcd5f 100644 --- a/Documentation/ABI/testing/sysfs-class-pwm +++ b/Documentation/ABI/testing/sysfs-class-pwm @@ -7,7 +7,7 @@ Description: Framework and provides a sysfs interface for using PWM channels. -What: /sys/class/pwm/pwmchipN/ +What: /sys/class/pwm/pwmchip<N>/ Date: May 2013 KernelVersion: 3.11 Contact: H Hartley Sweeten <hsweeten@visionengravers.com> @@ -16,14 +16,14 @@ Description: probed PWM controller/chip where N is the base of the PWM chip. -What: /sys/class/pwm/pwmchipN/npwm +What: /sys/class/pwm/pwmchip<N>/npwm Date: May 2013 KernelVersion: 3.11 Contact: H Hartley Sweeten <hsweeten@visionengravers.com> Description: The number of PWM channels supported by the PWM chip. -What: /sys/class/pwm/pwmchipN/export +What: /sys/class/pwm/pwmchip<N>/export Date: May 2013 KernelVersion: 3.11 Contact: H Hartley Sweeten <hsweeten@visionengravers.com> @@ -31,14 +31,14 @@ Description: Exports a PWM channel from the PWM chip for sysfs control. Value is between 0 and /sys/class/pwm/pwmchipN/npwm - 1. -What: /sys/class/pwm/pwmchipN/unexport +What: /sys/class/pwm/pwmchip<N>/unexport Date: May 2013 KernelVersion: 3.11 Contact: H Hartley Sweeten <hsweeten@visionengravers.com> Description: Unexports a PWM channel. -What: /sys/class/pwm/pwmchipN/pwmX +What: /sys/class/pwm/pwmchip<N>/pwmX Date: May 2013 KernelVersion: 3.11 Contact: H Hartley Sweeten <hsweeten@visionengravers.com> @@ -47,21 +47,21 @@ Description: each exported PWM channel where X is the exported PWM channel number. -What: /sys/class/pwm/pwmchipN/pwmX/period +What: /sys/class/pwm/pwmchip<N>/pwmX/period Date: May 2013 KernelVersion: 3.11 Contact: H Hartley Sweeten <hsweeten@visionengravers.com> Description: Sets the PWM signal period in nanoseconds. -What: /sys/class/pwm/pwmchipN/pwmX/duty_cycle +What: /sys/class/pwm/pwmchip<N>/pwmX/duty_cycle Date: May 2013 KernelVersion: 3.11 Contact: H Hartley Sweeten <hsweeten@visionengravers.com> Description: Sets the PWM signal duty cycle in nanoseconds. -What: /sys/class/pwm/pwmchipN/pwmX/polarity +What: /sys/class/pwm/pwmchip<N>/pwmX/polarity Date: May 2013 KernelVersion: 3.11 Contact: H Hartley Sweeten <hsweeten@visionengravers.com> @@ -69,7 +69,7 @@ Description: Sets the output polarity of the PWM signal to "normal" or "inversed". -What: /sys/class/pwm/pwmchipN/pwmX/enable +What: /sys/class/pwm/pwmchip<N>/pwmX/enable Date: May 2013 KernelVersion: 3.11 Contact: H Hartley Sweeten <hsweeten@visionengravers.com> @@ -78,7 +78,7 @@ Description: 0 is disabled 1 is enabled -What: /sys/class/pwm/pwmchipN/pwmX/capture +What: /sys/class/pwm/pwmchip<N>/pwmX/capture Date: June 2016 KernelVersion: 4.8 Contact: Lee Jones <lee.jones@linaro.org> diff --git a/Documentation/ABI/testing/sysfs-class-rapidio b/Documentation/ABI/testing/sysfs-class-rapidio index 19aefb21b639..81e09145525a 100644 --- a/Documentation/ABI/testing/sysfs-class-rapidio +++ b/Documentation/ABI/testing/sysfs-class-rapidio @@ -10,7 +10,7 @@ Description: NOTE: An mport ID is not a RapidIO destination ID assigned to a given local mport device. -What: /sys/class/rapidio_port/rapidioN/sys_size +What: /sys/class/rapidio_port/rapidio<N>/sys_size Date: Apr, 2014 KernelVersion: v3.15 Contact: Matt Porter <mporter@kernel.crashing.org>, @@ -22,7 +22,7 @@ Description: 1 = large (16-bit destination ID, max. 65536 devices). -What: /sys/class/rapidio_port/rapidioN/port_destid +What: /sys/class/rapidio_port/rapidio<N>/port_destid Date: Apr, 2014 KernelVersion: v3.15 Contact: Matt Porter <mporter@kernel.crashing.org>, diff --git a/Documentation/ABI/testing/sysfs-class-rc b/Documentation/ABI/testing/sysfs-class-rc index 9c8ff7910858..84e46d70d82b 100644 --- a/Documentation/ABI/testing/sysfs-class-rc +++ b/Documentation/ABI/testing/sysfs-class-rc @@ -7,7 +7,7 @@ Description: core and provides a sysfs interface for configuring infrared remote controller receivers. -What: /sys/class/rc/rcN/ +What: /sys/class/rc/rc<N>/ Date: Apr 2010 KernelVersion: 2.6.35 Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> @@ -15,7 +15,7 @@ Description: A /sys/class/rc/rcN directory is created for each remote control receiver device where N is the number of the receiver. -What: /sys/class/rc/rcN/protocols +What: /sys/class/rc/rc<N>/protocols Date: Jun 2010 KernelVersion: 2.6.36 Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> @@ -40,7 +40,7 @@ Description: Write fails with EINVAL if an invalid protocol combination or unknown protocol name is used. -What: /sys/class/rc/rcN/filter +What: /sys/class/rc/rc<N>/filter Date: Jan 2014 KernelVersion: 3.15 Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> @@ -55,7 +55,7 @@ Description: This value may be reset to 0 if the current protocol is altered. -What: /sys/class/rc/rcN/filter_mask +What: /sys/class/rc/rc<N>/filter_mask Date: Jan 2014 KernelVersion: 3.15 Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> @@ -72,7 +72,7 @@ Description: This value may be reset to 0 if the current protocol is altered. -What: /sys/class/rc/rcN/wakeup_protocols +What: /sys/class/rc/rc<N>/wakeup_protocols Date: Feb 2017 KernelVersion: 4.11 Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> @@ -98,7 +98,7 @@ Description: unknown protocol name is used, or if wakeup is not supported by the hardware. -What: /sys/class/rc/rcN/wakeup_filter +What: /sys/class/rc/rc<N>/wakeup_filter Date: Jan 2014 KernelVersion: 3.15 Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> @@ -117,7 +117,7 @@ Description: This value may be reset to 0 if the wakeup protocol is altered. -What: /sys/class/rc/rcN/wakeup_filter_mask +What: /sys/class/rc/rc<N>/wakeup_filter_mask Date: Jan 2014 KernelVersion: 3.15 Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> diff --git a/Documentation/ABI/testing/sysfs-class-rc-nuvoton b/Documentation/ABI/testing/sysfs-class-rc-nuvoton index d3abe45f8690..f7bad8ecd08f 100644 --- a/Documentation/ABI/testing/sysfs-class-rc-nuvoton +++ b/Documentation/ABI/testing/sysfs-class-rc-nuvoton @@ -1,4 +1,4 @@ -What: /sys/class/rc/rcN/wakeup_data +What: /sys/class/rc/rc<N>/wakeup_data Date: Mar 2016 KernelVersion: 4.6 Contact: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> diff --git a/Documentation/ABI/testing/sysfs-class-thermal b/Documentation/ABI/testing/sysfs-class-thermal new file mode 100644 index 000000000000..2c52bb1f864c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-thermal @@ -0,0 +1,259 @@ +What: /sys/class/thermal/thermal_zoneX/type +Description: + Strings which represent the thermal zone type. + This is given by thermal zone driver as part of registration. + E.g: "acpitz" indicates it's an ACPI thermal device. + In order to keep it consistent with hwmon sys attribute; this + shouldbe a short, lowercase string, not containing spaces nor + dashes. + + RO, Required + +What: /sys/class/thermal/thermal_zoneX/temp +Description: + Current temperature as reported by thermal zone (sensor). + + Unit: millidegree Celsius + + RO, Required + +What: /sys/class/thermal/thermal_zoneX/mode +Description: + One of the predefined values in [enabled, disabled]. + This file gives information about the algorithm that is + currently managing the thermal zone. It can be either default + kernel based algorithm or user space application. + + enabled + enable Kernel Thermal management. + disabled + Preventing kernel thermal zone driver actions upon + trip points so that user application can take full + charge of the thermal management. + + RW, Optional + +What: /sys/class/thermal/thermal_zoneX/policy +Description: + One of the various thermal governors used for a particular zone. + + RW, Required + +What: /sys/class/thermal/thermal_zoneX/available_policies +Description: + Available thermal governors which can be used for a + particular zone. + + RO, Required + +What: /sys/class/thermal/thermal_zoneX/trip_point_Y_temp +Description: + The temperature above which trip point will be fired. + + Unit: millidegree Celsius + + RO, Optional + +What: /sys/class/thermal/thermal_zoneX/trip_point_Y_type +Description: + Strings which indicate the type of the trip point. + + E.g. it can be one of critical, hot, passive, `active[0-*]` + for ACPI thermal zone. + + RO, Optional + +What: /sys/class/thermal/thermal_zoneX/trip_point_Y_hyst +Description: + The hysteresis value for a trip point, represented as an + integer. + + Unit: Celsius + + RW, Optional + +What: /sys/class/thermal/thermal_zoneX/cdevY +Description: + Sysfs link to the thermal cooling device node where the sys I/F + for cooling device throttling control represents. + + RO, Optional + +What: /sys/class/thermal/thermal_zoneX/cdevY_trip_point +Description: + The trip point in this thermal zone which `cdev[0-*]` is + associated with; -1 means the cooling device is not + associated with any trip point. + + RO, Optional + +What: /sys/class/thermal/thermal_zoneX/cdevY_weight +Description: + The influence of `cdev[0-*]` in this thermal zone. This value + is relative to the rest of cooling devices in the thermal + zone. For example, if a cooling device has a weight double + than that of other, it's twice as effective in cooling the + thermal zone. + + RW, Optional + +What: /sys/class/thermal/thermal_zoneX/emul_temp +Description: + Interface to set the emulated temperature method in thermal zone + (sensor). After setting this temperature, the thermal zone may + pass this temperature to platform emulation function if + registered or cache it locally. This is useful in debugging + different temperature threshold and its associated cooling + action. This is write only node and writing 0 on this node + should disable emulation. + + Unit: millidegree Celsius + + WO, Optional + + WARNING: + Be careful while enabling this option on production systems, + because userland can easily disable the thermal policy by simply + flooding this sysfs node with low temperature values. + + +What: /sys/class/thermal/thermal_zoneX/k_d +Description: + The derivative term of the power allocator governor's PID + controller. For more information see + Documentation/driver-api/thermal/power_allocator.rst + + RW, Optional + +What: /sys/class/thermal/thermal_zoneX/k_i +Description: + The integral term of the power allocator governor's PID + controller. This term allows the PID controller to compensate + for long term drift. For more information see + Documentation/driver-api/thermal/power_allocator.rst + + RW, Optional + +What: /sys/class/thermal/thermal_zoneX/k_po +Description: + The proportional term of the power allocator governor's PID + controller during temperature overshoot. Temperature overshoot + is when the current temperature is above the "desired + temperature" trip point. For more information see + Documentation/driver-api/thermal/power_allocator.rst + + RW, Optional + +What: /sys/class/thermal/thermal_zoneX/k_pu +Description: + The proportional term of the power allocator governor's PID + controller during temperature undershoot. Temperature undershoot + is when the current temperature is below the "desired + temperature" trip point. For more information see + Documentation/driver-api/thermal/power_allocator.rst + + RW, Optional + +What: /sys/class/thermal/thermal_zoneX/integral_cutoff +Description: + Temperature offset from the desired temperature trip point + above which the integral term of the power allocator + governor's PID controller starts accumulating errors. For + example, if integral_cutoff is 0, then the integral term only + accumulates error when temperature is above the desired + temperature trip point. For more information see + Documentation/driver-api/thermal/power_allocator.rst + + Unit: millidegree Celsius + + RW, Optional + +What: /sys/class/thermal/thermal_zoneX/slope +Description: + The slope constant used in a linear extrapolation model + to determine a hotspot temperature based off the sensor's + raw readings. It is up to the device driver to determine + the usage of these values. + + RW, Optional + +What: /sys/class/thermal/thermal_zoneX/offset +Description: + The offset constant used in a linear extrapolation model + to determine a hotspot temperature based off the sensor's + raw readings. It is up to the device driver to determine + the usage of these values. + + RW, Optional + +What: /sys/class/thermal/thermal_zoneX/sustainable_power +Description: + An estimate of the sustained power that can be dissipated by + the thermal zone. Used by the power allocator governor. For + more information see + Documentation/driver-api/thermal/power_allocator.rst + + Unit: milliwatts + + RW, Optional + +What: /sys/class/thermal/cooling_deviceX/type +Description: + String which represents the type of device, e.g: + + - for generic ACPI: should be "Fan", "Processor" or "LCD" + - for memory controller device on intel_menlow platform: + should be "Memory controller". + + RO, Required + +What: /sys/class/thermal/cooling_deviceX/max_state +Description: + The maximum permissible cooling state of this cooling device. + + RO, Required + +What: /sys/class/thermal/cooling_deviceX/cur_state +Description: + The current cooling state of this cooling device. + The value can any integer numbers between 0 and max_state: + + - cur_state == 0 means no cooling + - cur_state == max_state means the maximum cooling. + + RW, Required + +What: /sys/class/thermal/cooling_deviceX/stats/reset +Description: + Writing any value resets the cooling device's statistics. + + WO, Required + +What: /sys/class/thermal/cooling_deviceX/stats/time_in_state_ms: +Description: + The amount of time spent by the cooling device in various + cooling states. The output will have "<state> <time>" pair + in each line, which will mean this cooling device spent <time> + msec of time at <state>. + + Output will have one line for each of the supported states. + + RO, Required + +What: /sys/class/thermal/cooling_deviceX/stats/total_trans +Description: + A single positive value showing the total number of times + the state of a cooling device is changed. + + RO, Required + +What: /sys/class/thermal/cooling_deviceX/stats/trans_table +Description: + This gives fine grained information about all the cooling state + transitions. The cat output here is a two dimensional matrix, + where an entry <i,j> (row i, column j) represents the number + of transitions from State_i to State_j. If the transition + table is bigger than PAGE_SIZE, reading this will return + an -EFBIG error. + + RO, Required diff --git a/Documentation/ABI/testing/sysfs-class-typec b/Documentation/ABI/testing/sysfs-class-typec index 40122d915ae1..75088ecad202 100644 --- a/Documentation/ABI/testing/sysfs-class-typec +++ b/Documentation/ABI/testing/sysfs-class-typec @@ -200,7 +200,7 @@ Description: USB Power Delivery Specification defines a set of product types amc Alternate Mode Controller ====================== ========================== -What: /sys/class/typec/<port>-partner>/identity/ +What: /sys/class/typec/<port>-partner/identity/ Date: April 2017 Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> Description: diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc b/Documentation/ABI/testing/sysfs-class-uwb_rc index 6c5dcad21e19..a7ea169dc4eb 100644 --- a/Documentation/ABI/testing/sysfs-class-uwb_rc +++ b/Documentation/ABI/testing/sysfs-class-uwb_rc @@ -18,14 +18,14 @@ Description: and it will be removed. The default is 3 superframes (~197 ms) as required by the specification. -What: /sys/class/uwb_rc/uwbN/ +What: /sys/class/uwb_rc/uwb<N>/ Date: July 2008 KernelVersion: 2.6.27 Contact: linux-usb@vger.kernel.org Description: An individual UWB radio controller. -What: /sys/class/uwb_rc/uwbN/beacon +What: /sys/class/uwb_rc/uwb<N>/beacon Date: July 2008 KernelVersion: 2.6.27 Contact: linux-usb@vger.kernel.org @@ -43,7 +43,7 @@ Description: Reading returns the currently active channel, or -1 if the radio controller is not beaconing. -What: /sys/class/uwb_rc/uwbN/ASIE +What: /sys/class/uwb_rc/uwb<N>/ASIE Date: August 2014 KernelVersion: 3.18 Contact: linux-usb@vger.kernel.org @@ -56,7 +56,7 @@ Description: Reading returns the current ASIE. Writing replaces the current ASIE with the one written. -What: /sys/class/uwb_rc/uwbN/scan +What: /sys/class/uwb_rc/uwb<N>/scan Date: July 2008 KernelVersion: 2.6.27 Contact: linux-usb@vger.kernel.org @@ -75,7 +75,7 @@ Description: 4 scan (with start time of <bpst offset>) == ======================================= -What: /sys/class/uwb_rc/uwbN/mac_address +What: /sys/class/uwb_rc/uwb<N>/mac_address Date: July 2008 KernelVersion: 2.6.27 Contact: linux-usb@vger.kernel.org @@ -85,7 +85,7 @@ Description: controller's EUI-48 but only do so while the device is not beaconing or scanning. -What: /sys/class/uwb_rc/uwbN/wusbhc +What: /sys/class/uwb_rc/uwb<N>/wusbhc Date: July 2008 KernelVersion: 2.6.27 Contact: linux-usb@vger.kernel.org @@ -93,7 +93,7 @@ Description: A symlink to the device (if any) of the WUSB Host Controller PAL using this radio controller. -What: /sys/class/uwb_rc/uwbN/<EUI-48>/ +What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/ Date: July 2008 KernelVersion: 2.6.27 Contact: linux-usb@vger.kernel.org @@ -102,7 +102,7 @@ Description: as part of a scan or is a member of the radio controllers beacon group. -What: /sys/class/uwb_rc/uwbN/<EUI-48>/BPST +What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/BPST Date: July 2008 KernelVersion: 2.6.27 Contact: linux-usb@vger.kernel.org @@ -111,7 +111,7 @@ Description: interval superframe timer) of the last beacon from this device was received. -What: /sys/class/uwb_rc/uwbN/<EUI-48>/DevAddr +What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/DevAddr Date: July 2008 KernelVersion: 2.6.27 Contact: linux-usb@vger.kernel.org @@ -119,7 +119,7 @@ Description: The current DevAddr of this device in colon separated hex octets. -What: /sys/class/uwb_rc/uwbN/<EUI-48>/EUI_48 +What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/EUI_48 Date: July 2008 KernelVersion: 2.6.27 Contact: linux-usb@vger.kernel.org @@ -128,7 +128,7 @@ Description: The EUI-48 of this device in colon separated hex octets. -What: /sys/class/uwb_rc/uwbN/<EUI-48>/IEs +What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/IEs Date: July 2008 KernelVersion: 2.6.27 Contact: linux-usb@vger.kernel.org @@ -136,7 +136,7 @@ Description: The latest IEs included in this device's beacon, in space separated hex octets with one IE per line. -What: /sys/class/uwb_rc/uwbN/<EUI-48>/LQE +What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/LQE Date: July 2008 KernelVersion: 2.6.27 Contact: linux-usb@vger.kernel.org @@ -146,7 +146,7 @@ Description: This gives an estimate on a suitable PHY rate. Refer to [ECMA-368] section 13.3 for more details. -What: /sys/class/uwb_rc/uwbN/<EUI-48>/RSSI +What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/RSSI Date: July 2008 KernelVersion: 2.6.27 Contact: linux-usb@vger.kernel.org diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc index 5977e2875325..55eb55cac92e 100644 --- a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc +++ b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc @@ -1,4 +1,4 @@ -What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_chid +What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_chid Date: July 2008 KernelVersion: 2.6.27 Contact: David Vrabel <david.vrabel@csr.com> @@ -9,7 +9,7 @@ Description: Set an all zero CHID to stop the host controller. -What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_trust_timeout +What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_trust_timeout Date: July 2008 KernelVersion: 2.6.27 Contact: David Vrabel <david.vrabel@csr.com> @@ -24,7 +24,7 @@ Description: lifetime of PTKs and GTKs) it should not be changed from the default. -What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_phy_rate +What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_phy_rate Date: August 2009 KernelVersion: 2.6.32 Contact: David Vrabel <david.vrabel@csr.com> @@ -37,7 +37,7 @@ Description: Refer to [ECMA-368] section 10.3.1.1 for the value to use. -What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_dnts +What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_dnts Date: June 2013 KernelVersion: 3.11 Contact: Thomas Pugliese <thomas.pugliese@gmail.com> @@ -47,7 +47,7 @@ Description: often the devices will have the opportunity to send notifications to the host. -What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_retry_count +What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_retry_count Date: June 2013 KernelVersion: 3.11 Contact: Thomas Pugliese <thomas.pugliese@gmail.com> diff --git a/Documentation/ABI/testing/sysfs-devices-platform-dock b/Documentation/ABI/testing/sysfs-devices-platform-dock index 1d8c18f905c7..411c174de830 100644 --- a/Documentation/ABI/testing/sysfs-devices-platform-dock +++ b/Documentation/ABI/testing/sysfs-devices-platform-dock @@ -1,4 +1,4 @@ -What: /sys/devices/platform/dock.N/docked +What: /sys/devices/platform/dock.<N>/docked Date: Dec, 2006 KernelVersion: 2.6.19 Contact: linux-acpi@vger.kernel.org @@ -6,7 +6,7 @@ Description: (RO) Value 1 or 0 indicates whether the software believes the laptop is docked in a docking station. -What: /sys/devices/platform/dock.N/undock +What: /sys/devices/platform/dock.<N>/undock Date: Dec, 2006 KernelVersion: 2.6.19 Contact: linux-acpi@vger.kernel.org @@ -14,14 +14,14 @@ Description: (WO) Writing to this file causes the software to initiate an undock request to the firmware. -What: /sys/devices/platform/dock.N/uid +What: /sys/devices/platform/dock.<N>/uid Date: Feb, 2007 KernelVersion: v2.6.21 Contact: linux-acpi@vger.kernel.org Description: (RO) Displays the docking station the laptop is docked to. -What: /sys/devices/platform/dock.N/flags +What: /sys/devices/platform/dock.<N>/flags Date: May, 2007 KernelVersion: v2.6.21 Contact: linux-acpi@vger.kernel.org @@ -30,7 +30,7 @@ Description: request has been made by the user (from the immediate_undock option). -What: /sys/devices/platform/dock.N/type +What: /sys/devices/platform/dock.<N>/type Date: Aug, 2008 KernelVersion: v2.6.27 Contact: linux-acpi@vger.kernel.org diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 1763e64dd152..1b2a2d41ff80 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -269,3 +269,39 @@ Description: the current runtime PM status of the device, which may be "suspended", "suspending", "resuming", "active", "error" (fatal error), or "unsupported" (runtime PM is disabled). + +What: /sys/devices/.../power/runtime_active_time +Date: Jul 2010 +Contact: Arjan van de Ven <arjan@linux.intel.com> +Description: + Reports the total time that the device has been active. + Used for runtime PM statistics. + +What: /sys/devices/.../power/runtime_suspended_time +Date: Jul 2010 +Contact: Arjan van de Ven <arjan@linux.intel.com> +Description: + Reports total time that the device has been suspended. + Used for runtime PM statistics. + +What: /sys/devices/.../power/runtime_usage +Date: Apr 2010 +Contact: Dominik Brodowski <linux@dominikbrodowski.net> +Description: + Reports the runtime PM usage count of a device. + +What: /sys/devices/.../power/runtime_enabled +Date: Apr 2010 +Contact: Dominik Brodowski <linux@dominikbrodowski.net> +Description: + Is runtime PM enabled for this device? + States are "enabled", "disabled", "forbidden" or a + combination of the latter two. + +What: /sys/devices/.../power/runtime_active_kids +Date: Apr 2010 +Contact: Dominik Brodowski <linux@dominikbrodowski.net> +Description: + Reports the runtime PM children usage count of a device, or + 0 if the the children will be ignored. + diff --git a/Documentation/ABI/testing/sysfs-devices-removable b/Documentation/ABI/testing/sysfs-devices-removable index bda6c320c8d3..754ecb4587ca 100644 --- a/Documentation/ABI/testing/sysfs-devices-removable +++ b/Documentation/ABI/testing/sysfs-devices-removable @@ -7,10 +7,12 @@ Description: bus / platform-specific way. This attribute is only present for devices that can support determining such information: - "removable": device can be removed from the platform by the user - "fixed": device is fixed to the platform / cannot be removed + =========== =================================================== + "removable" device can be removed from the platform by the user + "fixed" device is fixed to the platform / cannot be removed by the user. - "unknown": The information is unavailable / cannot be deduced. + "unknown" The information is unavailable / cannot be deduced. + =========== =================================================== Currently this is only supported by USB (which infers the information from a combination of hub descriptor bits and diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index b46ef147616a..69c65da16dff 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -7,7 +7,7 @@ Description: Individual CPU attributes are contained in subdirectories named by the kernel's logical CPU number, e.g.: - /sys/devices/system/cpu/cpu#/ + /sys/devices/system/cpu/cpuX/ What: /sys/devices/system/cpu/kernel_max /sys/devices/system/cpu/offline @@ -53,7 +53,7 @@ Description: Dynamic addition and removal of CPU's. This is not hotplug the system. Information written to the file to remove CPU's is architecture specific. -What: /sys/devices/system/cpu/cpu#/node +What: /sys/devices/system/cpu/cpuX/node Date: October 2009 Contact: Linux memory management mailing list <linux-mm@kvack.org> Description: Discover NUMA node a CPU belongs to @@ -67,41 +67,41 @@ Description: Discover NUMA node a CPU belongs to /sys/devices/system/cpu/cpu42/node2 -> ../../node/node2 -What: /sys/devices/system/cpu/cpu#/topology/core_id - /sys/devices/system/cpu/cpu#/topology/core_siblings - /sys/devices/system/cpu/cpu#/topology/core_siblings_list - /sys/devices/system/cpu/cpu#/topology/physical_package_id - /sys/devices/system/cpu/cpu#/topology/thread_siblings - /sys/devices/system/cpu/cpu#/topology/thread_siblings_list +What: /sys/devices/system/cpu/cpuX/topology/core_id + /sys/devices/system/cpu/cpuX/topology/core_siblings + /sys/devices/system/cpu/cpuX/topology/core_siblings_list + /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 Date: December 2008 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> Description: CPU topology files that describe a logical CPU's relationship to other cores and threads in the same physical package. - One cpu# directory is created per logical CPU in the system, + One cpuX directory is created per logical CPU in the system, e.g. /sys/devices/system/cpu/cpu42/. Briefly, the files above are: - core_id: the CPU core ID of cpu#. Typically it is the + core_id: the CPU core ID of cpuX. Typically it is the hardware platform's identifier (rather than the kernel's). The actual value is architecture and platform dependent. - core_siblings: internal kernel map of cpu#'s hardware threads + core_siblings: internal kernel map of cpuX's hardware threads within the same physical_package_id. core_siblings_list: human-readable list of the logical CPU - numbers within the same physical_package_id as cpu#. + numbers within the same physical_package_id as cpuX. - physical_package_id: physical package id of cpu#. Typically + physical_package_id: physical package id of cpuX. Typically corresponds to a physical socket number, but the actual value is architecture and platform dependent. - thread_siblings: internal kernel map of cpu#'s hardware - threads within the same core as cpu# + thread_siblings: internal kernel map of cpuX's hardware + threads within the same core as cpuX - thread_siblings_list: human-readable list of cpu#'s hardware - threads within the same core as cpu# + thread_siblings_list: human-readable list of cpuX's hardware + threads within the same core as cpuX See Documentation/admin-guide/cputopology.rst for more information. @@ -135,7 +135,7 @@ Description: Discover cpuidle policy and mechanism Documentation/driver-api/pm/cpuidle.rst for more information. -What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/name +What: /sys/devices/system/cpu/cpuX/cpuidle/state<N>/name /sys/devices/system/cpu/cpuX/cpuidle/stateN/latency /sys/devices/system/cpu/cpuX/cpuidle/stateN/power /sys/devices/system/cpu/cpuX/cpuidle/stateN/time @@ -174,7 +174,7 @@ Description: (a count). ======== ==== ================================================= -What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/desc +What: /sys/devices/system/cpu/cpuX/cpuidle/state<N>/desc Date: February 2008 KernelVersion: v2.6.25 Contact: Linux power management list <linux-pm@vger.kernel.org> @@ -182,7 +182,7 @@ Description: (RO) A small description about the idle state (string). -What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/disable +What: /sys/devices/system/cpu/cpuX/cpuidle/state<N>/disable Date: March 2012 KernelVersion: v3.10 Contact: Linux power management list <linux-pm@vger.kernel.org> @@ -195,14 +195,14 @@ Description: does not reflect it. Likewise, if one enables a deep state but a lighter state still is disabled, then this has no effect. -What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/default_status +What: /sys/devices/system/cpu/cpuX/cpuidle/state<N>/default_status Date: December 2019 KernelVersion: v5.6 Contact: Linux power management list <linux-pm@vger.kernel.org> Description: (RO) The default status of this state, "enabled" or "disabled". -What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/residency +What: /sys/devices/system/cpu/cpuX/cpuidle/state<N>/residency Date: March 2014 KernelVersion: v3.15 Contact: Linux power management list <linux-pm@vger.kernel.org> @@ -211,7 +211,7 @@ Description: time (in microseconds) this cpu should spend in this idle state to make the transition worth the effort. -What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/s2idle/ +What: /sys/devices/system/cpu/cpuX/cpuidle/state<N>/s2idle/ Date: March 2018 KernelVersion: v4.17 Contact: Linux power management list <linux-pm@vger.kernel.org> @@ -221,7 +221,7 @@ Description: This attribute group is only present for states that can be used in suspend-to-idle with suspended timekeeping. -What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/s2idle/time +What: /sys/devices/system/cpu/cpuX/cpuidle/state<N>/s2idle/time Date: March 2018 KernelVersion: v4.17 Contact: Linux power management list <linux-pm@vger.kernel.org> @@ -229,7 +229,7 @@ Description: Total time spent by the CPU in suspend-to-idle (with scheduler tick suspended) after requesting this state. -What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/s2idle/usage +What: /sys/devices/system/cpu/cpuX/cpuidle/state<N>/s2idle/usage Date: March 2018 KernelVersion: v4.17 Contact: Linux power management list <linux-pm@vger.kernel.org> @@ -237,7 +237,7 @@ Description: Total number of times this state has been requested by the CPU while entering suspend-to-idle. -What: /sys/devices/system/cpu/cpu#/cpufreq/* +What: /sys/devices/system/cpu/cpuX/cpufreq/* Date: pre-git history Contact: linux-pm@vger.kernel.org Description: Discover and change clock speed of CPUs @@ -252,7 +252,7 @@ Description: Discover and change clock speed of CPUs See files in Documentation/cpu-freq/ for more information. -What: /sys/devices/system/cpu/cpu#/cpufreq/freqdomain_cpus +What: /sys/devices/system/cpu/cpuX/cpufreq/freqdomain_cpus Date: June 2013 Contact: linux-pm@vger.kernel.org Description: Discover CPUs in the same CPU frequency coordination domain @@ -301,16 +301,16 @@ Description: Processor frequency boosting control Documentation/admin-guide/pm/cpufreq.rst -What: /sys/devices/system/cpu/cpu#/crash_notes - /sys/devices/system/cpu/cpu#/crash_notes_size +What: /sys/devices/system/cpu/cpuX/crash_notes + /sys/devices/system/cpu/cpuX/crash_notes_size Date: April 2013 Contact: kexec@lists.infradead.org Description: address and size of the percpu note. crash_notes: the physical address of the memory that holds the - note of cpu#. + note of cpuX. - crash_notes_size: size of the note of cpu#. + crash_notes_size: size of the note of cpuX. What: /sys/devices/system/cpu/intel_pstate/max_perf_pct @@ -503,12 +503,12 @@ Description: Identifies the subset of CPUs in the system that can execute If absent, then all or none of the CPUs can execute AArch32 applications and execve() will behave accordingly. -What: /sys/devices/system/cpu/cpu#/cpu_capacity +What: /sys/devices/system/cpu/cpuX/cpu_capacity Date: December 2016 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> Description: information about CPUs heterogeneity. - cpu_capacity: capacity of cpu#. + cpu_capacity: capacity of cpuX. What: /sys/devices/system/cpu/vulnerabilities /sys/devices/system/cpu/vulnerabilities/meltdown @@ -560,7 +560,7 @@ Description: Control Symmetric Multi Threading (SMT) If control status is "forceoff" or "notsupported" writes are rejected. -What: /sys/devices/system/cpu/cpu#/power/energy_perf_bias +What: /sys/devices/system/cpu/cpuX/power/energy_perf_bias Date: March 2019 Contact: linux-pm@vger.kernel.org Description: Intel Energy and Performance Bias Hint (EPB) diff --git a/Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing b/Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing new file mode 100644 index 000000000000..b363827da437 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing @@ -0,0 +1,27 @@ +What: /sys/bus/platform/drivers/aspeed-uart-routing/*/uart* +Date: September 2021 +Contact: Oskar Senft <osk@google.com> + Chia-Wei Wang <chiawei_wang@aspeedtech.com> +Description: Selects the RX source of the UARTx device. + + When read, each file shows the list of available options with currently + selected option marked by brackets "[]". The list of available options + depends on the selected file. + + e.g. + cat /sys/bus/platform/drivers/aspeed-uart-routing/*.uart_routing/uart1 + [io1] io2 io3 io4 uart2 uart3 uart4 io6 + + In this case, UART1 gets its input from IO1 (physical serial port 1). + +Users: OpenBMC. Proposed changes should be mailed to + openbmc@lists.ozlabs.org + +What: /sys/bus/platform/drivers/aspeed-uart-routing/*/io* +Date: September 2021 +Contact: Oskar Senft <osk@google.com> + Chia-Wei Wang <chiawei_wang@aspeedtech.com> +Description: Selects the RX source of IOx serial port. The current selection + will be marked by brackets "[]". +Users: OpenBMC. Proposed changes should be mailed to + openbmc@lists.ozlabs.org diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index ec3a7149ced5..a44ef8bfbadf 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -13,6 +13,7 @@ Description: Interface specification for more details. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/device_type +What: /sys/bus/platform/devices/*.ufs/device_descriptor/device_type Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the device type. This is one of the UFS @@ -22,6 +23,7 @@ Description: This file shows the device type. This is one of the UFS The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/device_class +What: /sys/bus/platform/devices/*.ufs/device_descriptor/device_class Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the device class. This is one of the UFS @@ -31,6 +33,7 @@ Description: This file shows the device class. This is one of the UFS The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/device_sub_class +What: /sys/bus/platform/devices/*.ufs/device_descriptor/device_sub_class Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the UFS storage subclass. This is one of @@ -40,6 +43,7 @@ Description: This file shows the UFS storage subclass. This is one of The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/protocol +What: /sys/bus/platform/devices/*.ufs/device_descriptor/protocol Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the protocol supported by an UFS device. @@ -50,6 +54,7 @@ Description: This file shows the protocol supported by an UFS device. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/number_of_luns +What: /sys/bus/platform/devices/*.ufs/device_descriptor/number_of_luns Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows number of logical units. This is one of @@ -59,6 +64,7 @@ Description: This file shows number of logical units. This is one of The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/number_of_wluns +What: /sys/bus/platform/devices/*.ufs/device_descriptor/number_of_wluns Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows number of well known logical units. @@ -69,6 +75,7 @@ Description: This file shows number of well known logical units. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/boot_enable +What: /sys/bus/platform/devices/*.ufs/device_descriptor/boot_enable Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows value that indicates whether the device is @@ -79,6 +86,7 @@ Description: This file shows value that indicates whether the device is The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/descriptor_access_enable +What: /sys/bus/platform/devices/*.ufs/device_descriptor/descriptor_access_enable Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows value that indicates whether the device @@ -90,6 +98,7 @@ Description: This file shows value that indicates whether the device The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/initial_power_mode +What: /sys/bus/platform/devices/*.ufs/device_descriptor/initial_power_mode Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows value that defines the power mode after @@ -100,6 +109,7 @@ Description: This file shows value that defines the power mode after The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/high_priority_lun +What: /sys/bus/platform/devices/*.ufs/device_descriptor/high_priority_lun Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the high priority lun. This is one of @@ -109,6 +119,7 @@ Description: This file shows the high priority lun. This is one of The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/secure_removal_type +What: /sys/bus/platform/devices/*.ufs/device_descriptor/secure_removal_type Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the secure removal type. This is one of @@ -118,6 +129,7 @@ Description: This file shows the secure removal type. This is one of The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/support_security_lun +What: /sys/bus/platform/devices/*.ufs/device_descriptor/support_security_lun Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows whether the security lun is supported. @@ -128,6 +140,7 @@ Description: This file shows whether the security lun is supported. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/bkops_termination_latency +What: /sys/bus/platform/devices/*.ufs/device_descriptor/bkops_termination_latency Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the background operations termination @@ -138,6 +151,7 @@ Description: This file shows the background operations termination The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/initial_active_icc_level +What: /sys/bus/platform/devices/*.ufs/device_descriptor/initial_active_icc_level Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the initial active ICC level. This is one @@ -147,6 +161,7 @@ Description: This file shows the initial active ICC level. This is one The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/specification_version +What: /sys/bus/platform/devices/*.ufs/device_descriptor/specification_version Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the specification version. This is one @@ -156,6 +171,7 @@ Description: This file shows the specification version. This is one The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/manufacturing_date +What: /sys/bus/platform/devices/*.ufs/device_descriptor/manufacturing_date Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the manufacturing date in BCD format. @@ -166,6 +182,7 @@ Description: This file shows the manufacturing date in BCD format. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/manufacturer_id +What: /sys/bus/platform/devices/*.ufs/device_descriptor/manufacturer_id Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the manufacturer ID. This is one of the @@ -175,6 +192,7 @@ Description: This file shows the manufacturer ID. This is one of the The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/rtt_capability +What: /sys/bus/platform/devices/*.ufs/device_descriptor/rtt_capability Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the maximum number of outstanding RTTs @@ -185,6 +203,7 @@ Description: This file shows the maximum number of outstanding RTTs The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/rtc_update +What: /sys/bus/platform/devices/*.ufs/device_descriptor/rtc_update Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the frequency and method of the realtime @@ -195,6 +214,7 @@ Description: This file shows the frequency and method of the realtime The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/ufs_features +What: /sys/bus/platform/devices/*.ufs/device_descriptor/ufs_features Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows which features are supported by the device. @@ -205,6 +225,7 @@ Description: This file shows which features are supported by the device. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/ffu_timeout +What: /sys/bus/platform/devices/*.ufs/device_descriptor/ffu_timeout Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the FFU timeout. This is one of the @@ -214,6 +235,7 @@ Description: This file shows the FFU timeout. This is one of the The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/queue_depth +What: /sys/bus/platform/devices/*.ufs/device_descriptor/queue_depth Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the device queue depth. This is one of the @@ -223,6 +245,7 @@ Description: This file shows the device queue depth. This is one of the The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/device_version +What: /sys/bus/platform/devices/*.ufs/device_descriptor/device_version Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the device version. This is one of the @@ -232,6 +255,7 @@ Description: This file shows the device version. This is one of the The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/number_of_secure_wpa +What: /sys/bus/platform/devices/*.ufs/device_descriptor/number_of_secure_wpa Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows number of secure write protect areas @@ -242,6 +266,7 @@ Description: This file shows number of secure write protect areas The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/psa_max_data_size +What: /sys/bus/platform/devices/*.ufs/device_descriptor/psa_max_data_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the maximum amount of data that may be @@ -253,6 +278,7 @@ Description: This file shows the maximum amount of data that may be The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/psa_state_timeout +What: /sys/bus/platform/devices/*.ufs/device_descriptor/psa_state_timeout Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the command maximum timeout for a change @@ -264,6 +290,7 @@ Description: This file shows the command maximum timeout for a change What: /sys/bus/platform/drivers/ufshcd/*/interconnect_descriptor/unipro_version +What: /sys/bus/platform/devices/*.ufs/interconnect_descriptor/unipro_version Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the MIPI UniPro version number in BCD format. @@ -274,6 +301,7 @@ Description: This file shows the MIPI UniPro version number in BCD format. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/interconnect_descriptor/mphy_version +What: /sys/bus/platform/devices/*.ufs/interconnect_descriptor/mphy_version Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the MIPI M-PHY version number in BCD format. @@ -285,6 +313,7 @@ Description: This file shows the MIPI M-PHY version number in BCD format. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/raw_device_capacity +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/raw_device_capacity Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the total memory quantity available to @@ -296,6 +325,7 @@ Description: This file shows the total memory quantity available to The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/max_number_of_luns +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/max_number_of_luns Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the maximum number of logical units @@ -306,6 +336,7 @@ Description: This file shows the maximum number of logical units The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/segment_size +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/segment_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the segment size. This is one of the UFS @@ -315,6 +346,7 @@ Description: This file shows the segment size. This is one of the UFS The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/allocation_unit_size +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/allocation_unit_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the allocation unit size. This is one of @@ -324,6 +356,7 @@ Description: This file shows the allocation unit size. This is one of The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/min_addressable_block_size +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/min_addressable_block_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the minimum addressable block size. This @@ -334,6 +367,7 @@ Description: This file shows the minimum addressable block size. This The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/optimal_read_block_size +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/optimal_read_block_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the optimal read block size. This is one @@ -344,6 +378,7 @@ Description: This file shows the optimal read block size. This is one The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/optimal_write_block_size +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/optimal_write_block_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the optimal write block size. This is one @@ -354,6 +389,7 @@ Description: This file shows the optimal write block size. This is one The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/max_in_buffer_size +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/max_in_buffer_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the maximum data-in buffer size. This @@ -364,6 +400,7 @@ Description: This file shows the maximum data-in buffer size. This The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/max_out_buffer_size +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/max_out_buffer_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the maximum data-out buffer size. This @@ -374,6 +411,7 @@ Description: This file shows the maximum data-out buffer size. This The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/rpmb_rw_size +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/rpmb_rw_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the maximum number of RPMB frames allowed @@ -384,6 +422,7 @@ Description: This file shows the maximum number of RPMB frames allowed The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/dyn_capacity_resource_policy +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/dyn_capacity_resource_policy Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the dynamic capacity resource policy. This @@ -394,6 +433,7 @@ Description: This file shows the dynamic capacity resource policy. This The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/data_ordering +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/data_ordering Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows support for out-of-order data transfer. @@ -404,6 +444,7 @@ Description: This file shows support for out-of-order data transfer. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/max_number_of_contexts +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/max_number_of_contexts Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows maximum available number of contexts which @@ -414,6 +455,7 @@ Description: This file shows maximum available number of contexts which The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/sys_data_tag_unit_size +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/sys_data_tag_unit_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows system data tag unit size. This is one of @@ -423,6 +465,7 @@ Description: This file shows system data tag unit size. This is one of The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/sys_data_tag_resource_size +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/sys_data_tag_resource_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows maximum storage area size allocated by @@ -434,6 +477,7 @@ Description: This file shows maximum storage area size allocated by The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/secure_removal_types +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/secure_removal_types Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows supported secure removal types. This is @@ -444,6 +488,7 @@ Description: This file shows supported secure removal types. This is The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/memory_types +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/memory_types Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows supported memory types. This is one of @@ -454,6 +499,7 @@ Description: This file shows supported memory types. This is one of The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/*_memory_max_alloc_units +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/*_memory_max_alloc_units Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the maximum number of allocation units for @@ -465,6 +511,7 @@ Description: This file shows the maximum number of allocation units for The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/*_memory_capacity_adjustment_factor +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/*_memory_capacity_adjustment_factor Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the memory capacity adjustment factor for @@ -477,6 +524,7 @@ Description: This file shows the memory capacity adjustment factor for What: /sys/bus/platform/drivers/ufshcd/*/health_descriptor/eol_info +What: /sys/bus/platform/devices/*.ufs/health_descriptor/eol_info Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows preend of life information. This is one @@ -487,6 +535,7 @@ Description: This file shows preend of life information. This is one The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/health_descriptor/life_time_estimation_a +What: /sys/bus/platform/devices/*.ufs/health_descriptor/life_time_estimation_a Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows indication of the device life time @@ -497,6 +546,7 @@ Description: This file shows indication of the device life time The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/health_descriptor/life_time_estimation_b +What: /sys/bus/platform/devices/*.ufs/health_descriptor/life_time_estimation_b Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows indication of the device life time @@ -508,6 +558,7 @@ Description: This file shows indication of the device life time What: /sys/bus/platform/drivers/ufshcd/*/power_descriptor/active_icc_levels_vcc* +What: /sys/bus/platform/devices/*.ufs/power_descriptor/active_icc_levels_vcc* Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows maximum VCC, VCCQ and VCCQ2 value for @@ -519,6 +570,7 @@ Description: This file shows maximum VCC, VCCQ and VCCQ2 value for What: /sys/bus/platform/drivers/ufshcd/*/string_descriptors/manufacturer_name +What: /sys/bus/platform/devices/*.ufs/string_descriptors/manufacturer_name Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file contains a device manufacturer name string. @@ -528,6 +580,7 @@ Description: This file contains a device manufacturer name string. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/string_descriptors/product_name +What: /sys/bus/platform/devices/*.ufs/string_descriptors/product_name Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file contains a product name string. The full information @@ -536,6 +589,7 @@ Description: This file contains a product name string. The full information The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/string_descriptors/oem_id +What: /sys/bus/platform/devices/*.ufs/string_descriptors/oem_id Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file contains a OEM ID string. The full information @@ -544,6 +598,7 @@ Description: This file contains a OEM ID string. The full information The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/string_descriptors/serial_number +What: /sys/bus/platform/devices/*.ufs/string_descriptors/serial_number Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file contains a device serial number string. The full @@ -553,6 +608,7 @@ Description: This file contains a device serial number string. The full The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/string_descriptors/product_revision +What: /sys/bus/platform/devices/*.ufs/string_descriptors/product_revision Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file contains a product revision string. The full @@ -684,6 +740,7 @@ Description: This file shows the granularity of the LUN. This is one of What: /sys/bus/platform/drivers/ufshcd/*/flags/device_init +What: /sys/bus/platform/devices/*.ufs/flags/device_init Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the device init status. The full information @@ -692,6 +749,7 @@ Description: This file shows the device init status. The full information The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/flags/permanent_wpe +What: /sys/bus/platform/devices/*.ufs/flags/permanent_wpe Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows whether permanent write protection is enabled. @@ -701,6 +759,7 @@ Description: This file shows whether permanent write protection is enabled. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/flags/power_on_wpe +What: /sys/bus/platform/devices/*.ufs/flags/power_on_wpe Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows whether write protection is enabled on all @@ -711,6 +770,7 @@ Description: This file shows whether write protection is enabled on all The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/flags/bkops_enable +What: /sys/bus/platform/devices/*.ufs/flags/bkops_enable Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows whether the device background operations are @@ -720,6 +780,7 @@ Description: This file shows whether the device background operations are The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/flags/life_span_mode_enable +What: /sys/bus/platform/devices/*.ufs/flags/life_span_mode_enable Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows whether the device life span mode is enabled. @@ -729,6 +790,7 @@ Description: This file shows whether the device life span mode is enabled. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/flags/phy_resource_removal +What: /sys/bus/platform/devices/*.ufs/flags/phy_resource_removal Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows whether physical resource removal is enable. @@ -738,6 +800,7 @@ Description: This file shows whether physical resource removal is enable. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/flags/busy_rtc +What: /sys/bus/platform/devices/*.ufs/flags/busy_rtc Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows whether the device is executing internal @@ -747,6 +810,7 @@ Description: This file shows whether the device is executing internal The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/flags/disable_fw_update +What: /sys/bus/platform/devices/*.ufs/flags/disable_fw_update Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows whether the device FW update is permanently @@ -757,6 +821,7 @@ Description: This file shows whether the device FW update is permanently What: /sys/bus/platform/drivers/ufshcd/*/attributes/boot_lun_enabled +What: /sys/bus/platform/devices/*.ufs/attributes/boot_lun_enabled Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file provides the boot lun enabled UFS device attribute. @@ -766,6 +831,7 @@ Description: This file provides the boot lun enabled UFS device attribute. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/current_power_mode +What: /sys/bus/platform/devices/*.ufs/attributes/current_power_mode Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file provides the current power mode UFS device attribute. @@ -775,6 +841,7 @@ Description: This file provides the current power mode UFS device attribute. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/active_icc_level +What: /sys/bus/platform/devices/*.ufs/attributes/active_icc_level Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file provides the active icc level UFS device attribute. @@ -784,6 +851,7 @@ Description: This file provides the active icc level UFS device attribute. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/ooo_data_enabled +What: /sys/bus/platform/devices/*.ufs/attributes/ooo_data_enabled Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file provides the out of order data transfer enabled UFS @@ -793,6 +861,7 @@ Description: This file provides the out of order data transfer enabled UFS The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/bkops_status +What: /sys/bus/platform/devices/*.ufs/attributes/bkops_status Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file provides the background operations status UFS device @@ -802,6 +871,7 @@ Description: This file provides the background operations status UFS device The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/purge_status +What: /sys/bus/platform/devices/*.ufs/attributes/purge_status Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file provides the purge operation status UFS device @@ -811,6 +881,7 @@ Description: This file provides the purge operation status UFS device The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_data_in_size +What: /sys/bus/platform/devices/*.ufs/attributes/max_data_in_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the maximum data size in a DATA IN @@ -820,6 +891,7 @@ Description: This file shows the maximum data size in a DATA IN The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_data_out_size +What: /sys/bus/platform/devices/*.ufs/attributes/max_data_out_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the maximum number of bytes that can be @@ -829,6 +901,7 @@ Description: This file shows the maximum number of bytes that can be The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/reference_clock_frequency +What: /sys/bus/platform/devices/*.ufs/attributes/reference_clock_frequency Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file provides the reference clock frequency UFS device @@ -838,6 +911,7 @@ Description: This file provides the reference clock frequency UFS device The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/configuration_descriptor_lock +What: /sys/bus/platform/devices/*.ufs/attributes/configuration_descriptor_lock Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows whether the configuration descriptor is locked. @@ -845,6 +919,7 @@ Description: This file shows whether the configuration descriptor is locked. UFS specifications 2.1. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_number_of_rtt +What: /sys/bus/platform/devices/*.ufs/attributes/max_number_of_rtt Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file provides the maximum current number of @@ -855,6 +930,7 @@ Description: This file provides the maximum current number of The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/exception_event_control +What: /sys/bus/platform/devices/*.ufs/attributes/exception_event_control Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file provides the exception event control UFS device @@ -864,6 +940,7 @@ Description: This file provides the exception event control UFS device The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/exception_event_status +What: /sys/bus/platform/devices/*.ufs/attributes/exception_event_status Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file provides the exception event status UFS device @@ -873,6 +950,7 @@ Description: This file provides the exception event status UFS device The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/ffu_status +What: /sys/bus/platform/devices/*.ufs/attributes/ffu_status Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file provides the ffu status UFS device attribute. @@ -882,6 +960,7 @@ Description: This file provides the ffu status UFS device attribute. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/psa_state +What: /sys/bus/platform/devices/*.ufs/attributes/psa_state Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file show the PSA feature status. The full information @@ -890,6 +969,7 @@ Description: This file show the PSA feature status. The full information The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/psa_data_size +What: /sys/bus/platform/devices/*.ufs/attributes/psa_data_size Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Description: This file shows the amount of data that the host plans to @@ -903,7 +983,7 @@ Description: This file shows the amount of data that the host plans to What: /sys/class/scsi_device/*/device/dyn_cap_needed Date: February 2018 Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> -Description: This file shows the The amount of physical memory needed +Description: This file shows the amount of physical memory needed to be removed from the physical memory resources pool of the particular logical unit. The full information about the attribute could be found at UFS specifications 2.1. @@ -912,6 +992,7 @@ Description: This file shows the The amount of physical memory needed What: /sys/bus/platform/drivers/ufshcd/*/rpm_lvl +What: /sys/bus/platform/devices/*.ufs/rpm_lvl Date: September 2014 Contact: Subhash Jadavani <subhashj@codeaurora.org> Description: This entry could be used to set or show the UFS device @@ -938,6 +1019,7 @@ Description: This entry could be used to set or show the UFS device == ==================================================== What: /sys/bus/platform/drivers/ufshcd/*/rpm_target_dev_state +What: /sys/bus/platform/devices/*.ufs/rpm_target_dev_state Date: February 2018 Contact: Subhash Jadavani <subhashj@codeaurora.org> Description: This entry shows the target power mode of an UFS device @@ -946,6 +1028,7 @@ Description: This entry shows the target power mode of an UFS device The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/rpm_target_link_state +What: /sys/bus/platform/devices/*.ufs/rpm_target_link_state Date: February 2018 Contact: Subhash Jadavani <subhashj@codeaurora.org> Description: This entry shows the target state of an UFS UIC link @@ -954,6 +1037,7 @@ Description: This entry shows the target state of an UFS UIC link The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/spm_lvl +What: /sys/bus/platform/devices/*.ufs/spm_lvl Date: September 2014 Contact: Subhash Jadavani <subhashj@codeaurora.org> Description: This entry could be used to set or show the UFS device @@ -980,6 +1064,7 @@ Description: This entry could be used to set or show the UFS device == ==================================================== What: /sys/bus/platform/drivers/ufshcd/*/spm_target_dev_state +What: /sys/bus/platform/devices/*.ufs/spm_target_dev_state Date: February 2018 Contact: Subhash Jadavani <subhashj@codeaurora.org> Description: This entry shows the target power mode of an UFS device @@ -988,6 +1073,7 @@ Description: This entry shows the target power mode of an UFS device The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/spm_target_link_state +What: /sys/bus/platform/devices/*.ufs/spm_target_link_state Date: February 2018 Contact: Subhash Jadavani <subhashj@codeaurora.org> Description: This entry shows the target state of an UFS UIC link @@ -996,6 +1082,7 @@ Description: This entry shows the target state of an UFS UIC link The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_enable +What: /sys/bus/platform/devices/*.ufs/monitor/monitor_enable Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows the status of performance monitor enablement @@ -1003,6 +1090,7 @@ Description: This file shows the status of performance monitor enablement is stopped, the performance data collected is also cleared. What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_chunk_size +What: /sys/bus/platform/devices/*.ufs/monitor/monitor_chunk_size Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file tells the monitor to focus on requests transferring @@ -1010,6 +1098,7 @@ Description: This file tells the monitor to focus on requests transferring It can only be changed when monitor is disabled. What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_sectors +What: /sys/bus/platform/devices/*.ufs/monitor/read_total_sectors Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows how many sectors (in 512 Bytes) have been @@ -1018,6 +1107,7 @@ Description: This file shows how many sectors (in 512 Bytes) have been The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_busy +What: /sys/bus/platform/devices/*.ufs/monitor/read_total_busy Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows how long (in micro seconds) has been spent @@ -1026,6 +1116,7 @@ Description: This file shows how long (in micro seconds) has been spent The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_nr_requests +What: /sys/bus/platform/devices/*.ufs/monitor/read_nr_requests Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows how many read requests have been sent after @@ -1034,6 +1125,7 @@ Description: This file shows how many read requests have been sent after The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_max +What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_max Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows the maximum latency (in micro seconds) of @@ -1042,6 +1134,7 @@ Description: This file shows the maximum latency (in micro seconds) of The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_min +What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_min Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows the minimum latency (in micro seconds) of @@ -1050,6 +1143,7 @@ Description: This file shows the minimum latency (in micro seconds) of The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_avg +What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_avg Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows the average latency (in micro seconds) of @@ -1058,6 +1152,7 @@ Description: This file shows the average latency (in micro seconds) of The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_sum +What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_sum Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows the total latency (in micro seconds) of @@ -1066,6 +1161,7 @@ Description: This file shows the total latency (in micro seconds) of The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_sectors +What: /sys/bus/platform/devices/*.ufs/monitor/write_total_sectors Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows how many sectors (in 512 Bytes) have been sent @@ -1074,6 +1170,7 @@ Description: This file shows how many sectors (in 512 Bytes) have been sent The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_busy +What: /sys/bus/platform/devices/*.ufs/monitor/write_total_busy Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows how long (in micro seconds) has been spent @@ -1082,6 +1179,7 @@ Description: This file shows how long (in micro seconds) has been spent The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_nr_requests +What: /sys/bus/platform/devices/*.ufs/monitor/write_nr_requests Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows how many write requests have been sent after @@ -1090,6 +1188,7 @@ Description: This file shows how many write requests have been sent after The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_max +What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_max Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows the maximum latency (in micro seconds) of write @@ -1098,6 +1197,7 @@ Description: This file shows the maximum latency (in micro seconds) of write The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_min +What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_min Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows the minimum latency (in micro seconds) of write @@ -1106,6 +1206,7 @@ Description: This file shows the minimum latency (in micro seconds) of write The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_avg +What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_avg Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows the average latency (in micro seconds) of write @@ -1114,6 +1215,7 @@ Description: This file shows the average latency (in micro seconds) of write The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_sum +What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_sum Date: January 2021 Contact: Can Guo <cang@codeaurora.org> Description: This file shows the total latency (in micro seconds) of write @@ -1122,6 +1224,7 @@ Description: This file shows the total latency (in micro seconds) of write The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_presv_us_en +What: /sys/bus/platform/devices/*.ufs/device_descriptor/wb_presv_us_en Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: This entry shows if preserve user-space was configured @@ -1129,6 +1232,7 @@ Description: This entry shows if preserve user-space was configured The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_shared_alloc_units +What: /sys/bus/platform/devices/*.ufs/device_descriptor/wb_shared_alloc_units Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: This entry shows the shared allocated units of WB buffer @@ -1136,6 +1240,7 @@ Description: This entry shows the shared allocated units of WB buffer The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_type +What: /sys/bus/platform/devices/*.ufs/device_descriptor/wb_type Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: This entry shows the configured WB type. @@ -1144,6 +1249,7 @@ Description: This entry shows the configured WB type. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_buff_cap_adj +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_buff_cap_adj Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: This entry shows the total user-space decrease in shared @@ -1154,6 +1260,7 @@ Description: This entry shows the total user-space decrease in shared The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_alloc_units +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_max_alloc_units Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: This entry shows the Maximum total WriteBooster Buffer size @@ -1162,6 +1269,7 @@ Description: This entry shows the Maximum total WriteBooster Buffer size The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_wb_luns +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_max_wb_luns Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: This entry shows the maximum number of luns that can support @@ -1170,6 +1278,7 @@ Description: This entry shows the maximum number of luns that can support The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_red_type +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_sup_red_type Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: The supportability of user space reduction mode @@ -1184,6 +1293,7 @@ Description: The supportability of user space reduction mode The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_wb_type +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_sup_wb_type Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: The supportability of WriteBooster Buffer type. @@ -1198,6 +1308,7 @@ Description: The supportability of WriteBooster Buffer type. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_enable +What: /sys/bus/platform/devices/*.ufs/flags/wb_enable Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: This entry shows the status of WriteBooster. @@ -1210,6 +1321,7 @@ Description: This entry shows the status of WriteBooster. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_en +What: /sys/bus/platform/devices/*.ufs/flags/wb_flush_en Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: This entry shows if flush is enabled. @@ -1222,6 +1334,7 @@ Description: This entry shows if flush is enabled. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_during_h8 +What: /sys/bus/platform/devices/*.ufs/flags/wb_flush_during_h8 Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: Flush WriteBooster Buffer during hibernate state. @@ -1236,6 +1349,7 @@ Description: Flush WriteBooster Buffer during hibernate state. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_avail_buf +What: /sys/bus/platform/devices/*.ufs/attributes/wb_avail_buf Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: This entry shows the amount of unused WriteBooster buffer @@ -1244,6 +1358,7 @@ Description: This entry shows the amount of unused WriteBooster buffer The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_cur_buf +What: /sys/bus/platform/devices/*.ufs/attributes/wb_cur_buf Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: This entry shows the amount of unused current buffer. @@ -1251,6 +1366,7 @@ Description: This entry shows the amount of unused current buffer. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_flush_status +What: /sys/bus/platform/devices/*.ufs/attributes/wb_flush_status Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: This entry shows the flush operation status. @@ -1267,6 +1383,7 @@ Description: This entry shows the flush operation status. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_life_time_est +What: /sys/bus/platform/devices/*.ufs/attributes/wb_life_time_est Date: June 2020 Contact: Asutosh Das <asutoshd@codeaurora.org> Description: This entry shows an indication of the WriteBooster Buffer @@ -1289,6 +1406,7 @@ Description: This entry shows the configured size of WriteBooster buffer. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/wb_on +What: /sys/bus/platform/devices/*.ufs/wb_on Date: January 2021 Contact: Bean Huo <beanhuo@micron.com> Description: This node is used to set or display whether UFS WriteBooster is @@ -1300,6 +1418,7 @@ Description: This node is used to set or display whether UFS WriteBooster is disable/enable WriteBooster through this sysfs node. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version +What: /sys/bus/platform/devices/*.ufs/device_descriptor/hpb_version Date: June 2021 Contact: Daejun Park <daejun7.park@samsung.com> Description: This entry shows the HPB specification version. @@ -1310,6 +1429,7 @@ Description: This entry shows the HPB specification version. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_control +What: /sys/bus/platform/devices/*.ufs/device_descriptor/hpb_control Date: June 2021 Contact: Daejun Park <daejun7.park@samsung.com> Description: This entry shows an indication of the HPB control mode. @@ -1319,6 +1439,7 @@ Description: This entry shows an indication of the HPB control mode. The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_region_size +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_region_size Date: June 2021 Contact: Daejun Park <daejun7.park@samsung.com> Description: This entry shows the bHPBRegionSize which can be calculated @@ -1328,6 +1449,7 @@ Description: This entry shows the bHPBRegionSize which can be calculated The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_number_lu +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_number_lu Date: June 2021 Contact: Daejun Park <daejun7.park@samsung.com> Description: This entry shows the maximum number of HPB LU supported by @@ -1338,6 +1460,7 @@ Description: This entry shows the maximum number of HPB LU supported by The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_subregion_size +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_subregion_size Date: June 2021 Contact: Daejun Park <daejun7.park@samsung.com> Description: This entry shows the bHPBSubRegionSize, which can be @@ -1349,6 +1472,7 @@ Description: This entry shows the bHPBSubRegionSize, which can be The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_max_active_regions +What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_max_active_regions Date: June 2021 Contact: Daejun Park <daejun7.park@samsung.com> Description: This entry shows the maximum number of active HPB regions that @@ -1434,6 +1558,7 @@ Description: This entry shows the requeue timeout threshold for write buffer this entry. What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_data_size_hpb_single_cmd +What: /sys/bus/platform/devices/*.ufs/attributes/max_data_size_hpb_single_cmd Date: June 2021 Contact: Daejun Park <daejun7.park@samsung.com> Description: This entry shows the maximum HPB data size for using a single HPB @@ -1450,6 +1575,7 @@ Description: This entry shows the maximum HPB data size for using a single HPB The file is read only. What: /sys/bus/platform/drivers/ufshcd/*/flags/hpb_enable +What: /sys/bus/platform/devices/*.ufs/flags/hpb_enable Date: June 2021 Contact: Daejun Park <daejun7.park@samsung.com> Description: This entry shows the status of HPB. diff --git a/Documentation/ABI/testing/sysfs-driver-xen-blkback b/Documentation/ABI/testing/sysfs-driver-xen-blkback index ac2947b98950..a74dfe52dd76 100644 --- a/Documentation/ABI/testing/sysfs-driver-xen-blkback +++ b/Documentation/ABI/testing/sysfs-driver-xen-blkback @@ -29,7 +29,7 @@ Description: What: /sys/module/xen_blkback/parameters/buffer_squeeze_duration_ms Date: December 2019 KernelVersion: 5.6 -Contact: SeongJae Park <sjpark@amazon.de> +Contact: SeongJae Park <sj@kernel.org> Description: When memory pressure is reported to blkback this option controls the duration in milliseconds that blkback will not @@ -39,7 +39,7 @@ Description: What: /sys/module/xen_blkback/parameters/feature_persistent Date: September 2020 KernelVersion: 5.10 -Contact: SeongJae Park <sjpark@amazon.de> +Contact: SeongJae Park <sj@kernel.org> Description: Whether to enable the persistent grants feature or not. Note that this option only takes effect on newly created backends. diff --git a/Documentation/ABI/testing/sysfs-driver-xen-blkfront b/Documentation/ABI/testing/sysfs-driver-xen-blkfront index 28008905615f..61fd173fabfe 100644 --- a/Documentation/ABI/testing/sysfs-driver-xen-blkfront +++ b/Documentation/ABI/testing/sysfs-driver-xen-blkfront @@ -12,7 +12,7 @@ Description: What: /sys/module/xen_blkfront/parameters/feature_persistent Date: September 2020 KernelVersion: 5.10 -Contact: SeongJae Park <sjpark@amazon.de> +Contact: SeongJae Park <sj@kernel.org> Description: Whether to enable the persistent grants feature or not. Note that this option only takes effect on newly created frontends. diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-esrt b/Documentation/ABI/testing/sysfs-firmware-efi-esrt index 31b57676d4ad..4c2d440487dd 100644 --- a/Documentation/ABI/testing/sysfs-firmware-efi-esrt +++ b/Documentation/ABI/testing/sysfs-firmware-efi-esrt @@ -24,14 +24,14 @@ Date: February 2015 Contact: Peter Jones <pjones@redhat.com> Description: The version of the ESRT structure provided by the firmware. -What: /sys/firmware/efi/esrt/entries/entry$N/ +What: /sys/firmware/efi/esrt/entries/entry<N>/ Date: February 2015 Contact: Peter Jones <pjones@redhat.com> Description: Each ESRT entry is identified by a GUID, and each gets a subdirectory under entries/ . example: /sys/firmware/efi/esrt/entries/entry0/ -What: /sys/firmware/efi/esrt/entries/entry$N/fw_type +What: /sys/firmware/efi/esrt/entries/entry<N>/fw_type Date: February 2015 Contact: Peter Jones <pjones@redhat.com> Description: What kind of firmware entry this is: @@ -43,33 +43,33 @@ Description: What kind of firmware entry this is: 3 UEFI Driver == =============== -What: /sys/firmware/efi/esrt/entries/entry$N/fw_class +What: /sys/firmware/efi/esrt/entries/entry<N>/fw_class Date: February 2015 Contact: Peter Jones <pjones@redhat.com> Description: This is the entry's guid, and will match the directory name. -What: /sys/firmware/efi/esrt/entries/entry$N/fw_version +What: /sys/firmware/efi/esrt/entries/entry<N>/fw_version Date: February 2015 Contact: Peter Jones <pjones@redhat.com> Description: The version of the firmware currently installed. This is a 32-bit unsigned integer. -What: /sys/firmware/efi/esrt/entries/entry$N/lowest_supported_fw_version +What: /sys/firmware/efi/esrt/entries/entry<N>/lowest_supported_fw_version Date: February 2015 Contact: Peter Jones <pjones@redhat.com> Description: The lowest version of the firmware that can be installed. -What: /sys/firmware/efi/esrt/entries/entry$N/capsule_flags +What: /sys/firmware/efi/esrt/entries/entry<N>/capsule_flags Date: February 2015 Contact: Peter Jones <pjones@redhat.com> Description: Flags that must be passed to UpdateCapsule() -What: /sys/firmware/efi/esrt/entries/entry$N/last_attempt_version +What: /sys/firmware/efi/esrt/entries/entry<N>/last_attempt_version Date: February 2015 Contact: Peter Jones <pjones@redhat.com> Description: The last firmware version for which an update was attempted. -What: /sys/firmware/efi/esrt/entries/entry$N/last_attempt_status +What: /sys/firmware/efi/esrt/entries/entry<N>/last_attempt_status Date: February 2015 Contact: Peter Jones <pjones@redhat.com> Description: The result of the last firmware update attempt for the diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index f627e705e663..b268e3e18b4a 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -512,3 +512,19 @@ Date: July 2021 Contact: "Daeho Jeong" <daehojeong@google.com> Description: You can control the multiplier value of bdi device readahead window size between 2 (default) and 256 for POSIX_FADV_SEQUENTIAL advise option. + +What: /sys/fs/f2fs/<disk>/max_fragment_chunk +Date: August 2021 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: With "mode=fragment:block" mount options, we can scatter block allocation. + f2fs will allocate 1..<max_fragment_chunk> blocks in a chunk and make a hole + in the length of 1..<max_fragment_hole> by turns. This value can be set + between 1..512 and the default value is 4. + +What: /sys/fs/f2fs/<disk>/max_fragment_hole +Date: August 2021 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: With "mode=fragment:block" mount options, we can scatter block allocation. + f2fs will allocate 1..<max_fragment_chunk> blocks in a chunk and make a hole + in the length of 1..<max_fragment_hole> by turns. This value can be set + between 1..512 and the default value is 4. diff --git a/Documentation/ABI/testing/sysfs-kernel-slab b/Documentation/ABI/testing/sysfs-kernel-slab index c9f12baf8baa..c440f4946e12 100644 --- a/Documentation/ABI/testing/sysfs-kernel-slab +++ b/Documentation/ABI/testing/sysfs-kernel-slab @@ -10,7 +10,7 @@ Description: any cache it aliases, if any). Users: kernel memory tuning tools -What: /sys/kernel/slab/cache/aliases +What: /sys/kernel/slab/<cache>/aliases Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -19,7 +19,7 @@ Description: The aliases file is read-only and specifies how many caches have merged into this cache. -What: /sys/kernel/slab/cache/align +What: /sys/kernel/slab/<cache>/align Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -28,7 +28,7 @@ Description: The align file is read-only and specifies the cache's object alignment in bytes. -What: /sys/kernel/slab/cache/alloc_calls +What: /sys/kernel/slab/<cache>/alloc_calls Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -39,7 +39,7 @@ Description: The alloc_calls file only contains information if debugging is enabled for that cache (see Documentation/vm/slub.rst). -What: /sys/kernel/slab/cache/alloc_fastpath +What: /sys/kernel/slab/<cache>/alloc_fastpath Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -50,7 +50,7 @@ Description: current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/alloc_from_partial +What: /sys/kernel/slab/<cache>/alloc_from_partial Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -62,7 +62,7 @@ Description: count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/alloc_refill +What: /sys/kernel/slab/<cache>/alloc_refill Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -73,7 +73,7 @@ Description: remote cpu frees. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/alloc_slab +What: /sys/kernel/slab/<cache>/alloc_slab Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -84,7 +84,7 @@ Description: clear the current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/alloc_slowpath +What: /sys/kernel/slab/<cache>/alloc_slowpath Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -96,7 +96,7 @@ Description: clear the current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/cache_dma +What: /sys/kernel/slab/<cache>/cache_dma Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -106,7 +106,7 @@ Description: are from ZONE_DMA. Available when CONFIG_ZONE_DMA is enabled. -What: /sys/kernel/slab/cache/cpu_slabs +What: /sys/kernel/slab/<cache>/cpu_slabs Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -115,7 +115,7 @@ Description: The cpu_slabs file is read-only and displays how many cpu slabs are active and their NUMA locality. -What: /sys/kernel/slab/cache/cpuslab_flush +What: /sys/kernel/slab/<cache>/cpuslab_flush Date: April 2009 KernelVersion: 2.6.31 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -128,7 +128,7 @@ Description: current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/ctor +What: /sys/kernel/slab/<cache>/ctor Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -138,7 +138,7 @@ Description: constructor function, which is invoked for each object when a new slab is allocated. -What: /sys/kernel/slab/cache/deactivate_empty +What: /sys/kernel/slab/<cache>/deactivate_empty Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -148,7 +148,7 @@ Description: was deactivated. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/deactivate_full +What: /sys/kernel/slab/<cache>/deactivate_full Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -158,7 +158,7 @@ Description: was deactivated. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/deactivate_remote_frees +What: /sys/kernel/slab/<cache>/deactivate_remote_frees Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -169,7 +169,7 @@ Description: remotely. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/deactivate_to_head +What: /sys/kernel/slab/<cache>/deactivate_to_head Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -180,7 +180,7 @@ Description: list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/deactivate_to_tail +What: /sys/kernel/slab/<cache>/deactivate_to_tail Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -191,7 +191,7 @@ Description: list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/destroy_by_rcu +What: /sys/kernel/slab/<cache>/destroy_by_rcu Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -200,7 +200,7 @@ Description: The destroy_by_rcu file is read-only and specifies whether slabs (not objects) are freed by rcu. -What: /sys/kernel/slab/cache/free_add_partial +What: /sys/kernel/slab/<cache>/free_add_partial Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -211,7 +211,7 @@ Description: partial list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/free_calls +What: /sys/kernel/slab/<cache>/free_calls Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -221,7 +221,7 @@ Description: object frees if slab debugging is enabled (see Documentation/vm/slub.rst). -What: /sys/kernel/slab/cache/free_fastpath +What: /sys/kernel/slab/<cache>/free_fastpath Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -232,7 +232,7 @@ Description: It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/free_frozen +What: /sys/kernel/slab/<cache>/free_frozen Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -243,7 +243,7 @@ Description: clear the current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/free_remove_partial +What: /sys/kernel/slab/<cache>/free_remove_partial Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -255,7 +255,7 @@ Description: count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/free_slab +What: /sys/kernel/slab/<cache>/free_slab Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -266,7 +266,7 @@ Description: the current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/free_slowpath +What: /sys/kernel/slab/<cache>/free_slowpath Date: February 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -277,7 +277,7 @@ Description: be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/hwcache_align +What: /sys/kernel/slab/<cache>/hwcache_align Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -286,7 +286,7 @@ Description: The hwcache_align file is read-only and specifies whether objects are aligned on cachelines. -What: /sys/kernel/slab/cache/min_partial +What: /sys/kernel/slab/<cache>/min_partial Date: February 2009 KernelVersion: 2.6.30 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -297,7 +297,7 @@ Description: allocating new slabs. Such slabs may be reclaimed by utilizing the shrink file. -What: /sys/kernel/slab/cache/object_size +What: /sys/kernel/slab/<cache>/object_size Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -306,7 +306,7 @@ Description: The object_size file is read-only and specifies the cache's object size. -What: /sys/kernel/slab/cache/objects +What: /sys/kernel/slab/<cache>/objects Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -315,7 +315,7 @@ Description: The objects file is read-only and displays how many objects are active and from which nodes they are from. -What: /sys/kernel/slab/cache/objects_partial +What: /sys/kernel/slab/<cache>/objects_partial Date: April 2008 KernelVersion: 2.6.26 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -325,7 +325,7 @@ Description: objects are on partial slabs and from which nodes they are from. -What: /sys/kernel/slab/cache/objs_per_slab +What: /sys/kernel/slab/<cache>/objs_per_slab Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -333,9 +333,9 @@ Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Description: The file objs_per_slab is read-only and specifies how many objects may be allocated from a single slab of the order - specified in /sys/kernel/slab/cache/order. + specified in /sys/kernel/slab/<cache>/order. -What: /sys/kernel/slab/cache/order +What: /sys/kernel/slab/<cache>/order Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -352,7 +352,7 @@ Description: order is used and this sysfs entry can not be used to change the order at run time. -What: /sys/kernel/slab/cache/order_fallback +What: /sys/kernel/slab/<cache>/order_fallback Date: April 2008 KernelVersion: 2.6.26 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -365,7 +365,7 @@ Description: Available when CONFIG_SLUB_STATS is enabled. -What: /sys/kernel/slab/cache/partial +What: /sys/kernel/slab/<cache>/partial Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -374,7 +374,7 @@ Description: The partial file is read-only and displays how long many partial slabs there are and how long each node's list is. -What: /sys/kernel/slab/cache/poison +What: /sys/kernel/slab/<cache>/poison Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -383,7 +383,7 @@ Description: The poison file specifies whether objects should be poisoned when a new slab is allocated. -What: /sys/kernel/slab/cache/reclaim_account +What: /sys/kernel/slab/<cache>/reclaim_account Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -392,7 +392,7 @@ Description: The reclaim_account file specifies whether the cache's objects are reclaimable (and grouped by their mobility). -What: /sys/kernel/slab/cache/red_zone +What: /sys/kernel/slab/<cache>/red_zone Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -401,7 +401,7 @@ Description: The red_zone file specifies whether the cache's objects are red zoned. -What: /sys/kernel/slab/cache/remote_node_defrag_ratio +What: /sys/kernel/slab/<cache>/remote_node_defrag_ratio Date: January 2008 KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -415,7 +415,7 @@ Description: Available when CONFIG_NUMA is enabled. -What: /sys/kernel/slab/cache/sanity_checks +What: /sys/kernel/slab/<cache>/sanity_checks Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -426,7 +426,7 @@ Description: checks. Caches that enable sanity_checks cannot be merged with caches that do not. -What: /sys/kernel/slab/cache/shrink +What: /sys/kernel/slab/<cache>/shrink Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -442,7 +442,7 @@ Description: adversely impact other running applications. So it should be used with care. -What: /sys/kernel/slab/cache/slab_size +What: /sys/kernel/slab/<cache>/slab_size Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -451,7 +451,7 @@ Description: The slab_size file is read-only and specifies the object size with metadata (debugging information and alignment) in bytes. -What: /sys/kernel/slab/cache/slabs +What: /sys/kernel/slab/<cache>/slabs Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -461,7 +461,7 @@ Description: there are (both cpu and partial) and from which nodes they are from. -What: /sys/kernel/slab/cache/store_user +What: /sys/kernel/slab/<cache>/store_user Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -470,7 +470,7 @@ Description: The store_user file specifies whether the location of allocation or free should be tracked for a cache. -What: /sys/kernel/slab/cache/total_objects +What: /sys/kernel/slab/<cache>/total_objects Date: April 2008 KernelVersion: 2.6.26 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -479,7 +479,7 @@ Description: The total_objects file is read-only and displays how many total objects a cache has and from which nodes they are from. -What: /sys/kernel/slab/cache/trace +What: /sys/kernel/slab/<cache>/trace Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -488,7 +488,7 @@ Description: The trace file specifies whether object allocations and frees should be traced. -What: /sys/kernel/slab/cache/validate +What: /sys/kernel/slab/<cache>/validate Date: May 2007 KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, @@ -496,3 +496,24 @@ Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Description: Writing to the validate file causes SLUB to traverse all of its cache's objects and check the validity of metadata. + +What: /sys/kernel/slab/<cache>/usersize +Date: Jun 2017 +Contact: David Windsor <dave@nullcore.net> +Description: + The usersize file is read-only and contains the usercopy + region size. + +What: /sys/kernel/slab/<cache>/slabs_cpu_partial +Date: Aug 2011 +Contact: Christoph Lameter <cl@linux.com> +Description: + This read-only file shows the number of partialli allocated + frozen slabs. + +What: /sys/kernel/slab/<cache>/cpu_partial +Date: Aug 2011 +Contact: Christoph Lameter <cl@linux.com> +Description: + This read-only file shows the number of per cpu partial + pages to keep around. diff --git a/Documentation/ABI/testing/sysfs-mce b/Documentation/ABI/testing/sysfs-mce new file mode 100644 index 000000000000..c8cd989034b4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-mce @@ -0,0 +1,129 @@ +What: /sys/devices/system/machinecheck/machinecheckX/ +Contact: Andi Kleen <ak@linux.intel.com> +Date: Feb, 2007 +Description: + (X = CPU number) + + Machine checks report internal hardware error conditions + detected by the CPU. Uncorrected errors typically cause a + machine check (often with panic), corrected ones cause a + machine check log entry. + + For more details about the x86 machine check architecture + see the Intel and AMD architecture manuals from their + developer websites. + + For more details about the architecture + see http://one.firstfloor.org/~andi/mce.pdf + + Each CPU has its own directory. + +What: /sys/devices/system/machinecheck/machinecheckX/bank<Y> +Contact: Andi Kleen <ak@linux.intel.com> +Date: Feb, 2007 +Description: + (Y bank number) + + 64bit Hex bitmask enabling/disabling specific subevents for + bank Y. + + When a bit in the bitmask is zero then the respective + subevent will not be reported. + + By default all events are enabled. + + Note that BIOS maintain another mask to disable specific events + per bank. This is not visible here + +What: /sys/devices/system/machinecheck/machinecheckX/check_interval +Contact: Andi Kleen <ak@linux.intel.com> +Date: Feb, 2007 +Description: + The entries appear for each CPU, but they are truly shared + between all CPUs. + + How often to poll for corrected machine check errors, in + seconds (Note output is hexadecimal). Default 5 minutes. + When the poller finds MCEs it triggers an exponential speedup + (poll more often) on the polling interval. When the poller + stops finding MCEs, it triggers an exponential backoff + (poll less often) on the polling interval. The check_interval + variable is both the initial and maximum polling interval. + 0 means no polling for corrected machine check errors + (but some corrected errors might be still reported + in other ways) + +What: /sys/devices/system/machinecheck/machinecheckX/tolerant +Contact: Andi Kleen <ak@linux.intel.com> +Date: Feb, 2007 +Description: + The entries appear for each CPU, but they are truly shared + between all CPUs. + + Tolerance level. When a machine check exception occurs for a + non corrected machine check the kernel can take different + actions. + + Since machine check exceptions can happen any time it is + sometimes risky for the kernel to kill a process because it + defies normal kernel locking rules. The tolerance level + configures how hard the kernel tries to recover even at some + risk of deadlock. Higher tolerant values trade potentially + better uptime with the risk of a crash or even corruption + (for tolerant >= 3). + + == =========================================================== + 0 always panic on uncorrected errors, log corrected errors + 1 panic or SIGBUS on uncorrected errors, log corrected errors + 2 SIGBUS or log uncorrected errors, log corrected errors + 3 never panic or SIGBUS, log all errors (for testing only) + == =========================================================== + + Default: 1 + + Note this only makes a difference if the CPU allows recovery + from a machine check exception. Current x86 CPUs generally + do not. + +What: /sys/devices/system/machinecheck/machinecheckX/trigger +Contact: Andi Kleen <ak@linux.intel.com> +Date: Feb, 2007 +Description: + The entries appear for each CPU, but they are truly shared + between all CPUs. + + Program to run when a machine check event is detected. + This is an alternative to running mcelog regularly from cron + and allows to detect events faster. + +What: /sys/devices/system/machinecheck/machinecheckX/monarch_timeout +Contact: Andi Kleen <ak@linux.intel.com> +Date: Feb, 2007 +Description: + How long to wait for the other CPUs to machine check too on a + exception. 0 to disable waiting for other CPUs. + + Unit: us + +What: /sys/devices/system/machinecheck/machinecheckX/ignore_ce +Contact: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> +Date: Jun 2009 +Description: + Disables polling and CMCI for corrected errors. + All corrected events are not cleared and kept in bank MSRs. + +What: /sys/devices/system/machinecheck/machinecheckX/dont_log_ce +Contact: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> +Date: Jun 2009 +Description: + Disables logging for corrected errors. + All reported corrected errors will be cleared silently. + + This option will be useful if you never care about corrected + errors. + +What: /sys/devices/system/machinecheck/machinecheckX/cmci_disabled +Contact: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> +Date: Jun 2009 +Description: + Disables the CMCI feature. diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module index 88bddf192ceb..08886367d047 100644 --- a/Documentation/ABI/testing/sysfs-module +++ b/Documentation/ABI/testing/sysfs-module @@ -41,6 +41,13 @@ KernelVersion: 3.3 Contact: Kay Sievers <kay.sievers@vrfy.org> Description: Module size in bytes. +What: /sys/module/*/initstate +Date: Nov 2006 +KernelVersion: 2.6.19 +Contact: Kay Sievers <kay.sievers@vrfy.org> +Description: Show the initialization state(live, coming, going) of + the module. + What: /sys/module/*/taint Date: Jan 2012 KernelVersion: 3.3 diff --git a/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi index 7f9e18705861..1f1f274a6979 100644 --- a/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi +++ b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi @@ -1,55 +1,71 @@ What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type Date: Apr 2021 KernelVersion: 5.13 -Contact: "perry.yuan@dell.com>" +Contact: "<perry.yuan@dell.com>" Description: Display which dell hardware level privacy devices are supported “Dell Privacy” is a set of HW, FW, and SW features to enhance Dell’s commitment to platform privacy for MIC, Camera, and ePrivacy screens. The supported hardware privacy devices are: -Attributes: - Microphone Mute: + + Attributes: + Microphone Mute: Identifies the local microphone can be muted by hardware, no applications is available to capture system mic sound - Camera Shutter: + Camera Shutter: Identifies camera shutter controlled by hardware, which is a micromechanical shutter assembly that is built onto the camera module to block capturing images from outside the laptop - supported: + Values: + + supported: The privacy device is supported by this system - unsupported: + unsupported: The privacy device is not supported on this system - For example to check which privacy devices are supported: + For example to check which privacy devices are supported:: - # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type - [Microphone Mute] [supported] - [Camera Shutter] [supported] - [ePrivacy Screen] [unsupported] + # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type + [Microphone Mute] [supported] + [Camera Shutter] [supported] + [ePrivacy Screen] [unsupported] What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state Date: Apr 2021 KernelVersion: 5.13 -Contact: "perry.yuan@dell.com>" +Contact: "<perry.yuan@dell.com>" Description: Allow user space to check current dell privacy device state. Describes the Device State class exposed by BIOS which can be consumed by various applications interested in knowing the Privacy feature capabilities -Attributes: - muted: - Identifies the privacy device is turned off and cannot send stream to OS applications - unmuted: - Identifies the privacy device is turned on ,audio or camera driver can get - stream from mic and camera module to OS applications + Attributes: + Microphone: + Identifies the local microphone can be muted by hardware, no applications + is available to capture system mic sound + + Camera Shutter: + Identifies camera shutter controlled by hardware, which is a micromechanical + shutter assembly that is built onto the camera module to block capturing images + from outside the laptop + + Values: + muted: + Identifies the privacy device is turned off + and cannot send stream to OS applications + + unmuted: + Identifies the privacy device is turned on, + audio or camera driver can get stream from mic + and camera module to OS applications - For example to check all supported current privacy device states: + For example to check all supported current privacy device states:: - # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state - [Microphone] [unmuted] - [Camera Shutter] [unmuted] + # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state + [Microphone] [unmuted] + [Camera Shutter] [unmuted] diff --git a/Documentation/ABI/testing/sysfs-platform-dptf b/Documentation/ABI/testing/sysfs-platform-dptf index 53c6b1000320..620fd20434a5 100644 --- a/Documentation/ABI/testing/sysfs-platform-dptf +++ b/Documentation/ABI/testing/sysfs-platform-dptf @@ -133,7 +133,10 @@ Contact: linux-acpi@vger.kernel.org Description: (RO) Presents SSC (spread spectrum clock) information for EMI (Electro magnetic interference) control. This is a bit mask. + + ======= ========================================== Bits Description + ======= ========================================== [7:0] Sets clock spectrum spread percentage: 0x00=0.2% , 0x3F=10% 1 LSB = 0.1% increase in spread (for @@ -151,3 +154,4 @@ Description: [10] 0: No white noise. 1: Add white noise to spread waveform [11] When 1, future writes are ignored. + ======= ========================================== diff --git a/Documentation/ABI/testing/sysfs-platform-intel-pmc b/Documentation/ABI/testing/sysfs-platform-intel-pmc index ef199af75ab0..f31d59b21f9b 100644 --- a/Documentation/ABI/testing/sysfs-platform-intel-pmc +++ b/Documentation/ABI/testing/sysfs-platform-intel-pmc @@ -11,8 +11,10 @@ Description: to take effect. Display global reset setting bits for PMC. + * bit 31 - global reset is locked * bit 20 - global reset is set + Writing bit 20 value to the etr3 will induce a platform "global reset" upon consequent platform reset, in case the register is not locked. diff --git a/Documentation/ABI/testing/sysfs-platform-sst-atom b/Documentation/ABI/testing/sysfs-platform-sst-atom index d5f6e21f0e42..0154b0fba759 100644 --- a/Documentation/ABI/testing/sysfs-platform-sst-atom +++ b/Documentation/ABI/testing/sysfs-platform-sst-atom @@ -1,4 +1,4 @@ -What: /sys/devices/platform/8086%x:00/firmware_version +What: /sys/devices/platform/8086<x>:00/firmware_version Date: November 2016 KernelVersion: 4.10 Contact: "Sebastien Guiriec" <sebastien.guiriec@intel.com> diff --git a/Documentation/ABI/testing/sysfs-ptp b/Documentation/ABI/testing/sysfs-ptp index d378f57c1b73..9c317ac7c47a 100644 --- a/Documentation/ABI/testing/sysfs-ptp +++ b/Documentation/ABI/testing/sysfs-ptp @@ -6,7 +6,7 @@ Description: providing a standardized interface to the ancillary features of PTP hardware clocks. -What: /sys/class/ptp/ptpN/ +What: /sys/class/ptp/ptp<N>/ Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> Description: @@ -14,7 +14,7 @@ Description: hardware clock registered into the PTP class driver subsystem. -What: /sys/class/ptp/ptpN/clock_name +What: /sys/class/ptp/ptp<N>/clock_name Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> Description: @@ -25,7 +25,7 @@ Description: MAC based ones. The string does not necessarily have to be any kind of unique id. -What: /sys/class/ptp/ptpN/max_adjustment +What: /sys/class/ptp/ptp<N>/max_adjustment Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> Description: @@ -33,42 +33,42 @@ Description: frequency adjustment value (a positive integer) in parts per billion. -What: /sys/class/ptp/ptpN/max_vclocks +What: /sys/class/ptp/ptp<N>/max_vclocks Date: May 2021 Contact: Yangbo Lu <yangbo.lu@nxp.com> Description: This file contains the maximum number of ptp vclocks. Write integer to re-configure it. -What: /sys/class/ptp/ptpN/n_alarms +What: /sys/class/ptp/ptp<N>/n_alarms Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> Description: This file contains the number of periodic or one shot alarms offer by the PTP hardware clock. -What: /sys/class/ptp/ptpN/n_external_timestamps +What: /sys/class/ptp/ptp<N>/n_external_timestamps Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> Description: This file contains the number of external timestamp channels offered by the PTP hardware clock. -What: /sys/class/ptp/ptpN/n_periodic_outputs +What: /sys/class/ptp/ptp<N>/n_periodic_outputs Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> Description: This file contains the number of programmable periodic output channels offered by the PTP hardware clock. -What: /sys/class/ptp/ptpN/n_pins +What: /sys/class/ptp/ptp<N>/n_pins Date: March 2014 Contact: Richard Cochran <richardcochran@gmail.com> Description: This file contains the number of programmable pins offered by the PTP hardware clock. -What: /sys/class/ptp/ptpN/n_vclocks +What: /sys/class/ptp/ptp<N>/n_vclocks Date: May 2021 Contact: Yangbo Lu <yangbo.lu@nxp.com> Description: @@ -81,7 +81,7 @@ Description: switches the physical clock back to normal, adjustable operation. -What: /sys/class/ptp/ptpN/pins +What: /sys/class/ptp/ptp<N>/pins Date: March 2014 Contact: Richard Cochran <richardcochran@gmail.com> Description: @@ -94,7 +94,7 @@ Description: assignment may be changed by two writing numbers into the file. -What: /sys/class/ptp/ptpN/pps_available +What: /sys/class/ptp/ptp<N>/pps_available Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> Description: @@ -103,7 +103,7 @@ Description: "1" means that the PPS is supported, while "0" means not supported. -What: /sys/class/ptp/ptpN/extts_enable +What: /sys/class/ptp/ptp<N>/extts_enable Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> Description: @@ -113,7 +113,7 @@ Description: To disable external timestamps, write the channel index followed by a "0" into the file. -What: /sys/class/ptp/ptpN/fifo +What: /sys/class/ptp/ptp<N>/fifo Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> Description: @@ -121,7 +121,7 @@ Description: the form of three integers: channel index, seconds, and nanoseconds. -What: /sys/class/ptp/ptpN/period +What: /sys/class/ptp/ptp<N>/period Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> Description: @@ -132,7 +132,7 @@ Description: period nanoseconds. To disable a periodic output, set all the seconds and nanoseconds values to zero. -What: /sys/class/ptp/ptpN/pps_enable +What: /sys/class/ptp/ptp<N>/pps_enable Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> Description: diff --git a/Documentation/ABI/testing/sysfs-timecard b/Documentation/ABI/testing/sysfs-timecard new file mode 100644 index 000000000000..97f6773794a5 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-timecard @@ -0,0 +1,174 @@ +What: /sys/class/timecard/ +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: This directory contains files and directories + providing a standardized interface to the ancillary + features of the OpenCompute timecard. + +What: /sys/class/timecard/ocpN/ +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: This directory contains the attributes of the Nth timecard + registered. + +What: /sys/class/timecard/ocpN/available_clock_sources +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) The list of available time sources that the PHC + uses for clock adjustments. + + ==== ================================================= + NONE no adjustments + PPS adjustments come from the PPS1 selector (default) + TOD adjustments from the GNSS/TOD module + IRIG adjustments from external IRIG-B signal + DCF adjustments from external DCF signal + ==== ================================================= + +What: /sys/class/timecard/ocpN/available_sma_inputs +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Set of available destinations (sinks) for a SMA + input signal. + + ===== ================================================ + 10Mhz signal is used as the 10Mhz reference clock + PPS1 signal is sent to the PPS1 selector + PPS2 signal is sent to the PPS2 selector + TS1 signal is sent to timestamper 1 + TS2 signal is sent to timestamper 2 + IRIG signal is sent to the IRIG-B module + DCF signal is sent to the DCF module + ===== ================================================ + +What: /sys/class/timecard/ocpN/available_sma_outputs +Date: May 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Set of available sources for a SMA output signal. + + ===== ================================================ + 10Mhz output is from the 10Mhz reference clock + PHC output PPS is from the PHC clock + MAC output PPS is from the Miniature Atomic Clock + GNSS output PPS is from the GNSS module + GNSS2 output PPS is from the second GNSS module + IRIG output is from the PHC, in IRIG-B format + DCF output is from the PHC, in DCF format + ===== ================================================ + +What: /sys/class/timecard/ocpN/clock_source +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RW) Contains the current synchronization source used by + the PHC. May be changed by writing one of the listed + values from the available_clock_sources attribute set. + +What: /sys/class/timecard/ocpN/gnss_sync +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Indicates whether a valid GNSS signal is received, + or when the signal was lost. + +What: /sys/class/timecard/ocpN/i2c +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: This optional attribute links to the associated i2c device. + +What: /sys/class/timecard/ocpN/irig_b_mode +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RW) An integer from 0-7 indicating the timecode format + of the IRIG-B output signal: B00<n> + +What: /sys/class/timecard/ocpN/pps +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: This optional attribute links to the associated PPS device. + +What: /sys/class/timecard/ocpN/ptp +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: This attribute links to the associated PTP device. + +What: /sys/class/timecard/ocpN/serialnum +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Provides the serial number of the timecard. + +What: /sys/class/timecard/ocpN/sma1 +What: /sys/class/timecard/ocpN/sma2 +What: /sys/class/timecard/ocpN/sma3 +What: /sys/class/timecard/ocpN/sma4 +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RW) These attributes specify the direction of the signal + on the associated SMA connectors, and also the signal sink + or source. + + The display format of the attribute is a space separated + list of signals, prefixed by the input/output direction. + + The signal direction may be changed (if supported) by + prefixing the signal list with either "in:" or "out:". + If neither prefix is present, then the direction is unchanged. + + The output signal may be changed by writing one of the listed + values from the available_sma_outputs attribute set. + + The input destinations may be changed by writing multiple + values from the available_sma_inputs attribute set, + separated by spaces. If there are duplicated input + destinations between connectors, the lowest numbered SMA + connector is given priority. + + Note that not all input combinations may make sense. + + The 10Mhz reference clock input is currently only valid + on SMA1 and may not be combined with other destination sinks. + +What: /sys/class/timecard/ocpN/ts_window_adjust +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RW) When retrieving the PHC with the PTP SYS_OFFSET_EXTENDED + ioctl, a system timestamp is made before and after the PHC + time is retrieved. The midpoint between the two system + timestamps is usually taken to be the SYS time associated + with the PHC time. This estimate may be wrong, as it depends + on PCI latencies, and when the PHC time was latched + + The attribute value reduces the end timestamp by the given + number of nanoseconds, so the computed midpoint matches the + retrieved PHC time. + + The initial value is set based on measured PCI latency and + the estimated point where the FPGA latches the PHC time. This + value may be changed by writing an unsigned integer. + +What: /sys/class/timecard/ocpN/ttyGNSS +What: /sys/class/timecard/ocpN/ttyGNSS2 +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: These optional attributes link to the TTY serial ports + associated with the GNSS devices. + +What: /sys/class/timecard/ocpN/ttyMAC +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: This optional attribute links to the TTY serial port + associated with the Miniature Atomic Clock. + +What: /sys/class/timecard/ocpN/ttyNMEA +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: This optional attribute links to the TTY serial port + which outputs the PHC time in NMEA ZDA format. + +What: /sys/class/timecard/ocpN/utc_tai_offset +Date: September 2021 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RW) The DCF and IRIG output signals are in UTC, while the + TimeCard operates on TAI. This attribute allows setting the + offset in seconds, which is added to the TAI timebase for + these formats. + + The offset may be changed by writing an unsigned integer. diff --git a/Documentation/ABI/testing/sysfs-tty b/Documentation/ABI/testing/sysfs-tty index e157130a6792..820e412d38a8 100644 --- a/Documentation/ABI/testing/sysfs-tty +++ b/Documentation/ABI/testing/sysfs-tty @@ -9,7 +9,7 @@ Description: The file supports poll() to detect virtual console switches. -What: /sys/class/tty/tty0/active +What: /sys/class/tty/tty<x>/active Date: Nov 2010 Contact: Kay Sievers <kay.sievers@vrfy.org> Description: @@ -18,7 +18,7 @@ Description: The file supports poll() to detect virtual console switches. -What: /sys/class/tty/ttyS0/uartclk +What: /sys/class/tty/ttyS<x>/uartclk Date: Sep 2012 Contact: Tomas Hlavacek <tmshlvck@gmail.com> Description: @@ -29,7 +29,7 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. -What: /sys/class/tty/ttyS0/type +What: /sys/class/tty/ttyS<x>/type Date: October 2012 Contact: Alan Cox <alan@linux.intel.com> Description: @@ -38,7 +38,7 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. -What: /sys/class/tty/ttyS0/line +What: /sys/class/tty/ttyS<x>/line Date: October 2012 Contact: Alan Cox <alan@linux.intel.com> Description: @@ -47,7 +47,7 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. -What: /sys/class/tty/ttyS0/port +What: /sys/class/tty/ttyS<x>/port Date: October 2012 Contact: Alan Cox <alan@linux.intel.com> Description: @@ -56,7 +56,7 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. -What: /sys/class/tty/ttyS0/irq +What: /sys/class/tty/ttyS<x>/irq Date: October 2012 Contact: Alan Cox <alan@linux.intel.com> Description: @@ -65,7 +65,7 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. -What: /sys/class/tty/ttyS0/flags +What: /sys/class/tty/ttyS<x>/flags Date: October 2012 Contact: Alan Cox <alan@linux.intel.com> Description: @@ -74,7 +74,7 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. -What: /sys/class/tty/ttyS0/xmit_fifo_size +What: /sys/class/tty/ttyS<x>/xmit_fifo_size Date: October 2012 Contact: Alan Cox <alan@linux.intel.com> Description: @@ -83,7 +83,7 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. -What: /sys/class/tty/ttyS0/close_delay +What: /sys/class/tty/ttyS<x>/close_delay Date: October 2012 Contact: Alan Cox <alan@linux.intel.com> Description: @@ -92,7 +92,7 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. -What: /sys/class/tty/ttyS0/closing_wait +What: /sys/class/tty/ttyS<x>/closing_wait Date: October 2012 Contact: Alan Cox <alan@linux.intel.com> Description: @@ -101,7 +101,7 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. -What: /sys/class/tty/ttyS0/custom_divisor +What: /sys/class/tty/ttyS<x>/custom_divisor Date: October 2012 Contact: Alan Cox <alan@linux.intel.com> Description: @@ -110,7 +110,7 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. -What: /sys/class/tty/ttyS0/io_type +What: /sys/class/tty/ttyS<x>/io_type Date: October 2012 Contact: Alan Cox <alan@linux.intel.com> Description: @@ -120,7 +120,7 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. -What: /sys/class/tty/ttyS0/iomem_base +What: /sys/class/tty/ttyS<x>/iomem_base Date: October 2012 Contact: Alan Cox <alan@linux.intel.com> Description: @@ -129,7 +129,7 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. -What: /sys/class/tty/ttyS0/iomem_reg_shift +What: /sys/class/tty/ttyS<x>/iomem_reg_shift Date: October 2012 Contact: Alan Cox <alan@linux.intel.com> Description: @@ -139,7 +139,7 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. -What: /sys/class/tty/ttyS0/rx_trig_bytes +What: /sys/class/tty/ttyS<x>/rx_trig_bytes Date: May 2014 Contact: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> Description: @@ -155,7 +155,7 @@ Description: 16550A, which has 1/4/8/14 bytes trigger, the RX trigger is automatically changed to 4 bytes. -What: /sys/class/tty/ttyS0/console +What: /sys/class/tty/ttyS<x>/console Date: February 2020 Contact: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Description: diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst index eeb351296df1..7fdf151a8680 100644 --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst @@ -202,49 +202,44 @@ newly arrived RCU callbacks against future grace periods: 1 static void rcu_prepare_for_idle(void) 2 { 3 bool needwake; - 4 struct rcu_data *rdp; - 5 struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks); - 6 struct rcu_node *rnp; - 7 struct rcu_state *rsp; - 8 int tne; - 9 - 10 if (IS_ENABLED(CONFIG_RCU_NOCB_CPU_ALL) || - 11 rcu_is_nocb_cpu(smp_processor_id())) - 12 return; + 4 struct rcu_data *rdp = this_cpu_ptr(&rcu_data); + 5 struct rcu_node *rnp; + 6 int tne; + 7 + 8 lockdep_assert_irqs_disabled(); + 9 if (rcu_rdp_is_offloaded(rdp)) + 10 return; + 11 + 12 /* Handle nohz enablement switches conservatively. */ 13 tne = READ_ONCE(tick_nohz_active); - 14 if (tne != rdtp->tick_nohz_enabled_snap) { - 15 if (rcu_cpu_has_callbacks(NULL)) - 16 invoke_rcu_core(); - 17 rdtp->tick_nohz_enabled_snap = tne; + 14 if (tne != rdp->tick_nohz_enabled_snap) { + 15 if (!rcu_segcblist_empty(&rdp->cblist)) + 16 invoke_rcu_core(); /* force nohz to see update. */ + 17 rdp->tick_nohz_enabled_snap = tne; 18 return; - 19 } + 19 } 20 if (!tne) 21 return; - 22 if (rdtp->all_lazy && - 23 rdtp->nonlazy_posted != rdtp->nonlazy_posted_snap) { - 24 rdtp->all_lazy = false; - 25 rdtp->nonlazy_posted_snap = rdtp->nonlazy_posted; - 26 invoke_rcu_core(); - 27 return; - 28 } - 29 if (rdtp->last_accelerate == jiffies) - 30 return; - 31 rdtp->last_accelerate = jiffies; - 32 for_each_rcu_flavor(rsp) { - 33 rdp = this_cpu_ptr(rsp->rda); - 34 if (rcu_segcblist_pend_cbs(&rdp->cblist)) - 35 continue; - 36 rnp = rdp->mynode; - 37 raw_spin_lock_rcu_node(rnp); - 38 needwake = rcu_accelerate_cbs(rsp, rnp, rdp); - 39 raw_spin_unlock_rcu_node(rnp); - 40 if (needwake) - 41 rcu_gp_kthread_wake(rsp); - 42 } - 43 } + 22 + 23 /* + 24 * If we have not yet accelerated this jiffy, accelerate all + 25 * callbacks on this CPU. + 26 */ + 27 if (rdp->last_accelerate == jiffies) + 28 return; + 29 rdp->last_accelerate = jiffies; + 30 if (rcu_segcblist_pend_cbs(&rdp->cblist)) { + 31 rnp = rdp->mynode; + 32 raw_spin_lock_rcu_node(rnp); /* irqs already disabled. */ + 33 needwake = rcu_accelerate_cbs(rnp, rdp); + 34 raw_spin_unlock_rcu_node(rnp); /* irqs remain disabled. */ + 35 if (needwake) + 36 rcu_gp_kthread_wake(); + 37 } + 38 } But the only part of ``rcu_prepare_for_idle()`` that really matters for -this discussion are lines 37–39. We will therefore abbreviate this +this discussion are lines 32–34. We will therefore abbreviate this function as follows: .. kernel-figure:: rcu_node-lock.svg diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst index 5036df24ae61..28f8ad16db25 100644 --- a/Documentation/RCU/stallwarn.rst +++ b/Documentation/RCU/stallwarn.rst @@ -96,6 +96,16 @@ warnings: the ``rcu_.*timer wakeup didn't happen for`` console-log message, which will include additional debugging information. +- A low-level kernel issue that either fails to invoke one of the + variants of rcu_user_enter(), rcu_user_exit(), rcu_idle_enter(), + rcu_idle_exit(), rcu_irq_enter(), or rcu_irq_exit() on the one + hand, or that invokes one of them too many times on the other. + Historically, the most frequent issue has been an omission + of either irq_enter() or irq_exit(), which in turn invoke + rcu_irq_enter() or rcu_irq_exit(), respectively. Building your + kernel with CONFIG_RCU_EQS_DEBUG=y can help track down these types + of issues, which sometimes arise in architecture-specific code. + - A bug in the RCU implementation. - A hardware failure. This is quite unlikely, but has occurred diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst index 700329d25f57..3e11926a4df9 100644 --- a/Documentation/admin-guide/blockdev/zram.rst +++ b/Documentation/admin-guide/blockdev/zram.rst @@ -328,6 +328,14 @@ as idle:: From now on, any pages on zram are idle pages. The idle mark will be removed until someone requests access of the block. IOW, unless there is access request, those pages are still idle pages. +Additionally, when CONFIG_ZRAM_MEMORY_TRACKING is enabled pages can be +marked as idle based on how long (in seconds) it's been since they were +last accessed:: + + echo 86400 > /sys/block/zramX/idle + +In this example all pages which haven't been accessed in more than 86400 +seconds (one day) will be marked idle. Admin can request writeback of those idle pages at right timing via:: diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index 41191b5fb69d..faac50149a22 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst @@ -87,10 +87,8 @@ Brief summary of control files. memory.oom_control set/show oom controls. memory.numa_stat show the number of memory usage per numa node - memory.kmem.limit_in_bytes set/show hard limit for kernel memory - This knob is deprecated and shouldn't be - used. It is planned that this be removed in - the foreseeable future. + memory.kmem.limit_in_bytes This knob is deprecated and writing to + it will return -ENOTSUPP. memory.kmem.usage_in_bytes show current kernel memory allocation memory.kmem.failcnt show the number of kernel memory usage hits limits @@ -518,11 +516,6 @@ will be charged as a new owner of it. charged file caches. Some out-of-use page caches may keep charged until memory pressure happens. If you want to avoid that, force_empty will be useful. - Also, note that when memory.kmem.limit_in_bytes is set the charges due to - kernel pages will still be seen. This is not considered a failure and the - write will still return success. In this case, it is expected that - memory.kmem.usage_in_bytes == memory.usage_in_bytes. - 5.2 stat file ------------- diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index babbe04c8d37..2aeb7ae8b393 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1016,6 +1016,8 @@ All time durations are in microseconds. - nr_periods - nr_throttled - throttled_usec + - nr_bursts + - burst_usec cpu.weight A read-write single value file which exists on non-root @@ -1047,6 +1049,12 @@ All time durations are in microseconds. $PERIOD duration. "max" for $MAX indicates no limit. If only one number is written, $MAX is updated. + cpu.max.burst + A read-write single value file which exists on non-root + cgroups. The default is "0". + + The burst in the range [0, $MAX]. + cpu.pressure A read-write nested-keyed file. @@ -1226,7 +1234,7 @@ PAGE_SIZE multiple when read back. Note that all fields in this file are hierarchical and the file modified event can be generated due to an event down the - hierarchy. For for the local events at the cgroup level see + hierarchy. For the local events at the cgroup level see memory.events.local. low @@ -2170,19 +2178,19 @@ existing device files. Cgroup v2 device controller has no interface files and is implemented on top of cgroup BPF. To control access to device files, a user may -create bpf programs of the BPF_CGROUP_DEVICE type and attach them -to cgroups. On an attempt to access a device file, corresponding -BPF programs will be executed, and depending on the return value -the attempt will succeed or fail with -EPERM. +create bpf programs of type BPF_PROG_TYPE_CGROUP_DEVICE and attach +them to cgroups with BPF_CGROUP_DEVICE flag. On an attempt to access a +device file, corresponding BPF programs will be executed, and depending +on the return value the attempt will succeed or fail with -EPERM. -A BPF_CGROUP_DEVICE program takes a pointer to the bpf_cgroup_dev_ctx -structure, which describes the device access attempt: access type -(mknod/read/write) and device (type, major and minor numbers). -If the program returns 0, the attempt fails with -EPERM, otherwise -it succeeds. +A BPF_PROG_TYPE_CGROUP_DEVICE program takes a pointer to the +bpf_cgroup_dev_ctx structure, which describes the device access attempt: +access type (mknod/read/write) and device (type, major and minor numbers). +If the program returns 0, the attempt fails with -EPERM, otherwise it +succeeds. -An example of BPF_CGROUP_DEVICE program may be found in the kernel -source tree in the tools/testing/selftests/bpf/progs/dev_cgroup.c file. +An example of BPF_PROG_TYPE_CGROUP_DEVICE program may be found in +tools/testing/selftests/bpf/progs/dev_cgroup.c in the kernel source tree. RDMA @@ -2310,6 +2318,16 @@ Miscellaneous controller provides 3 interface files. If two misc resources (res_ Limits can be set higher than the capacity value in the misc.capacity file. + misc.events + A read-only flat-keyed file which exists on non-root cgroups. The + following entries are defined. Unless specified otherwise, a value + change in this file generates a file modified event. All fields in + this file are hierarchical. + + max + The number of times the cgroup's resource usage was + about to go over the max boundary. + Migration and Ownership ~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/admin-guide/cputopology.rst b/Documentation/admin-guide/cputopology.rst index b085dbac60a5..6b62e182baf4 100644 --- a/Documentation/admin-guide/cputopology.rst +++ b/Documentation/admin-guide/cputopology.rst @@ -19,11 +19,13 @@ these macros in include/asm-XXX/topology.h:: #define topology_physical_package_id(cpu) #define topology_die_id(cpu) + #define topology_cluster_id(cpu) #define topology_core_id(cpu) #define topology_book_id(cpu) #define topology_drawer_id(cpu) #define topology_sibling_cpumask(cpu) #define topology_core_cpumask(cpu) + #define topology_cluster_cpumask(cpu) #define topology_die_cpumask(cpu) #define topology_book_cpumask(cpu) #define topology_drawer_cpumask(cpu) @@ -39,10 +41,12 @@ not defined by include/asm-XXX/topology.h: 1) topology_physical_package_id: -1 2) topology_die_id: -1 -3) topology_core_id: 0 -4) topology_sibling_cpumask: just the given CPU -5) topology_core_cpumask: just the given CPU -6) topology_die_cpumask: just the given CPU +3) topology_cluster_id: -1 +4) topology_core_id: 0 +5) topology_sibling_cpumask: just the given CPU +6) topology_core_cpumask: just the given CPU +7) topology_cluster_cpumask: just the given CPU +8) topology_die_cpumask: just the given CPU For architectures that don't support books (CONFIG_SCHED_BOOK) there are no default definitions for topology_book_id() and topology_book_cpumask(). diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index b119b8277b3e..a89cfa083155 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -249,8 +249,7 @@ Debug messages during Boot Process To activate debug messages for core code and built-in modules during the boot process, even before userspace and debugfs exists, use -``dyndbg="QUERY"``, ``module.dyndbg="QUERY"``, or ``ddebug_query="QUERY"`` -(``ddebug_query`` is obsoleted by ``dyndbg``, and deprecated). QUERY follows +``dyndbg="QUERY"`` or ``module.dyndbg="QUERY"``. QUERY follows the syntax described above, but must not exceed 1023 characters. Your bootloader may impose lower limits. @@ -270,8 +269,7 @@ this boot parameter for debugging purposes. If ``foo`` module is not built-in, ``foo.dyndbg`` will still be processed at boot time, without effect, but will be reprocessed when module is -loaded later. ``ddebug_query=`` and bare ``dyndbg=`` are only processed at -boot. +loaded later. Bare ``dyndbg=`` is only processed at boot. Debug Messages at Module Initialization Time @@ -358,8 +356,11 @@ Examples // boot-args example, with newlines and comments for readability Kernel command line: ... // see whats going on in dyndbg=value processing - dynamic_debug.verbose=1 - // enable pr_debugs in 2 builtins, #cmt is stripped - dyndbg="module params +p #cmt ; module sys +p" + dynamic_debug.verbose=3 + // enable pr_debugs in the btrfs module (can be builtin or loadable) + btrfs.dyndbg="+p" + // enable pr_debugs in all files under init/ + // and the function parse_one, #cmt is stripped + dyndbg="file init/* +p #cmt ; func parse_one +p" // enable pr_debugs in 2 functions in a module loaded later pc87360.dyndbg="func pc87360_init_device +p; func pc87360_find +p" diff --git a/Documentation/admin-guide/filesystem-monitoring.rst b/Documentation/admin-guide/filesystem-monitoring.rst new file mode 100644 index 000000000000..ab8dba76283c --- /dev/null +++ b/Documentation/admin-guide/filesystem-monitoring.rst @@ -0,0 +1,78 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================================== +File system Monitoring with fanotify +==================================== + +File system Error Reporting +=========================== + +Fanotify supports the FAN_FS_ERROR event type for file system-wide error +reporting. It is meant to be used by file system health monitoring +daemons, which listen for these events and take actions (notify +sysadmin, start recovery) when a file system problem is detected. + +By design, a FAN_FS_ERROR notification exposes sufficient information +for a monitoring tool to know a problem in the file system has happened. +It doesn't necessarily provide a user space application with semantics +to verify an IO operation was successfully executed. That is out of +scope for this feature. Instead, it is only meant as a framework for +early file system problem detection and reporting recovery tools. + +When a file system operation fails, it is common for dozens of kernel +errors to cascade after the initial failure, hiding the original failure +log, which is usually the most useful debug data to troubleshoot the +problem. For this reason, FAN_FS_ERROR tries to report only the first +error that occurred for a file system since the last notification, and +it simply counts additional errors. This ensures that the most +important pieces of information are never lost. + +FAN_FS_ERROR requires the fanotify group to be setup with the +FAN_REPORT_FID flag. + +At the time of this writing, the only file system that emits FAN_FS_ERROR +notifications is Ext4. + +A FAN_FS_ERROR Notification has the following format:: + + :: + + [ Notification Metadata (Mandatory) ] + [ Generic Error Record (Mandatory) ] + [ FID record (Mandatory) ] + +The order of records is not guaranteed, and new records might be added +in the future. Therefore, applications must not rely on the order and +must be prepared to skip over unknown records. Please refer to +``samples/fanotify/fs-monitor.c`` for an example parser. + +Generic error record +-------------------- + +The generic error record provides enough information for a file system +agnostic tool to learn about a problem in the file system, without +providing any additional details about the problem. This record is +identified by ``struct fanotify_event_info_header.info_type`` being set +to FAN_EVENT_INFO_TYPE_ERROR. + + :: + + struct fanotify_event_info_error { + struct fanotify_event_info_header hdr; + __s32 error; + __u32 error_count; + }; + +The `error` field identifies the type of error using errno values. +`error_count` tracks the number of errors that occurred and were +suppressed to preserve the original error information, since the last +notification. + +FID record +---------- + +The FID record can be used to uniquely identify the inode that triggered +the error through the combination of fsid and file handle. A file system +specific application can use that information to attempt a recovery +procedure. Errors that are not related to an inode are reported with an +empty file handle of type FILEID_INVALID. diff --git a/Documentation/admin-guide/hw-vuln/core-scheduling.rst b/Documentation/admin-guide/hw-vuln/core-scheduling.rst index 0febe458597c..cf1eeefdfc32 100644 --- a/Documentation/admin-guide/hw-vuln/core-scheduling.rst +++ b/Documentation/admin-guide/hw-vuln/core-scheduling.rst @@ -61,8 +61,9 @@ arg3: ``pid`` of the task for which the operation applies. arg4: - ``pid_type`` for which the operation applies. It is of type ``enum pid_type``. - For example, if arg4 is ``PIDTYPE_TGID``, then the operation of this command + ``pid_type`` for which the operation applies. It is one of + ``PR_SCHED_CORE_SCOPE_``-prefixed macro constants. For example, if arg4 + is ``PR_SCHED_CORE_SCOPE_THREAD_GROUP``, then the operation of this command will be performed for all tasks in the task group of ``pid``. arg5: diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index e05e581af5cf..ab7d402c1677 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -490,9 +490,8 @@ Spectre variant 2 Restricting indirect branch speculation on a user program will also prevent the program from launching a variant 2 attack - on x86. All sand-boxed SECCOMP programs have indirect branch - speculation restricted by default. Administrators can change - that behavior via the kernel command line and sysfs control files. + on x86. Administrators can change that behavior via the kernel + command line and sysfs control files. See :ref:`spectre_mitigation_control_command_line`. Programs that disable their indirect branch speculation will have @@ -594,61 +593,14 @@ kernel command line. Not specifying this option is equivalent to spectre_v2=auto. -For user space mitigation: - - spectre_v2_user= - - [X86] Control mitigation of Spectre variant 2 - (indirect branch speculation) vulnerability between - user space tasks - - on - Unconditionally enable mitigations. Is - enforced by spectre_v2=on - - off - Unconditionally disable mitigations. Is - enforced by spectre_v2=off - - prctl - Indirect branch speculation is enabled, - but mitigation can be enabled via prctl - per thread. The mitigation control state - is inherited on fork. - - prctl,ibpb - Like "prctl" above, but only STIBP is - controlled per thread. IBPB is issued - always when switching between different user - space processes. - - seccomp - Same as "prctl" above, but all seccomp - threads will enable the mitigation unless - they explicitly opt out. - - seccomp,ibpb - Like "seccomp" above, but only STIBP is - controlled per thread. IBPB is issued - always when switching between different - user space processes. - - auto - Kernel selects the mitigation depending on - the available CPU features and vulnerability. - - Default mitigation: - If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl" - - Not specifying this option is equivalent to - spectre_v2_user=auto. - In general the kernel by default selects reasonable mitigations for the current CPU. To disable Spectre variant 2 mitigations, boot with spectre_v2=off. Spectre variant 1 mitigations cannot be disabled. +For spectre_v2_user see :doc:`/admin-guide/kernel-parameters`. + Mitigation selection guide -------------------------- @@ -674,9 +626,8 @@ Mitigation selection guide off by disabling their indirect branch speculation when they are run (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`). This prevents untrusted programs from polluting the branch target - buffer. All programs running in SECCOMP sandboxes have indirect - branch speculation restricted by default. This behavior can be - changed via the kernel command line and sysfs control files. See + buffer. This behavior can be changed via the kernel command line + and sysfs control files. See :ref:`spectre_mitigation_control_command_line`. 3. High security mode diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index dc00afcabb95..1bedab498104 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -82,6 +82,7 @@ configure specific aspects of kernel behavior to your liking. edid efi-stub ext4 + filesystem-monitoring nfs/index gpio/index highuid diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 91ba391f9b32..9725c546a0d4 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -841,11 +841,6 @@ Format: <port#>,<type> See also Documentation/input/devices/joystick-parport.rst - ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot - time. See - Documentation/admin-guide/dynamic-debug-howto.rst for - details. Deprecated, see dyndbg. - debug [KNL] Enable kernel debugging (events log level). debug_boot_weak_hash @@ -1266,7 +1261,7 @@ The VGA and EFI output is eventually overwritten by the real console. - The xen output can only be used by Xen PV guests. + The xen option can only be used in Xen domains. The sclp output can only be used on s390. @@ -1587,8 +1582,10 @@ registers. Default set by CONFIG_HPET_MMAP_DEFAULT. hugetlb_cma= [HW,CMA] The size of a CMA area used for allocation - of gigantic hugepages. - Format: nn[KMGTPE] + of gigantic hugepages. Or using node format, the size + of a CMA area per node can be specified. + Format: nn[KMGTPE] or (node format) + <node>:nn[KMGTPE][,<node>:nn[KMGTPE]] Reserve a CMA area of given size and allocate gigantic hugepages using the CMA allocator. If enabled, the @@ -1599,9 +1596,11 @@ the number of pages of hugepagesz to be allocated. If this is the first HugeTLB parameter on the command line, it specifies the number of pages to allocate for - the default huge page size. See also - Documentation/admin-guide/mm/hugetlbpage.rst. - Format: <integer> + the default huge page size. If using node format, the + number of pages to allocate per-node can be specified. + See also Documentation/admin-guide/mm/hugetlbpage.rst. + Format: <integer> or (node format) + <node>:<integer>[,<node>:<integer>] hugepagesz= [HW] The size of the HugeTLB pages. This is used in @@ -2353,7 +2352,14 @@ [KVM] Controls how many 4KiB pages are periodically zapped back to huge pages. 0 disables the recovery, otherwise if the value is N KVM will zap 1/Nth of the 4KiB pages every - minute. The default is 60. + period (see below). The default is 60. + + kvm.nx_huge_pages_recovery_period_ms= + [KVM] Controls the time period at which KVM zaps 4KiB pages + back to huge pages. If the value is a non-zero N, KVM will + zap a portion (see ratio above) of the pages every N msecs. + If the value is 0 (the default), KVM will pick a period based + on the ratio, such that a page is zapped after 1 hour on average. kvm-amd.nested= [KVM,AMD] Allow nested virtualization in KVM/SVM. Default is 1 (enabled) @@ -2365,6 +2371,8 @@ kvm-arm.mode= [KVM,ARM] Select one of KVM/arm64's modes of operation. + none: Forcefully disable KVM. + nvhe: Standard nVHE-based mode, without support for protected guests. @@ -2372,7 +2380,9 @@ state is kept private from the host. Not valid if the kernel is running in EL2. - Defaults to VHE/nVHE based on hardware support. + Defaults to VHE/nVHE based on hardware support. Setting + mode to "protected" will disable kexec and hibernation + for the host. kvm-arm.vgic_v3_group0_trap= [KVM,ARM] Trap guest accesses to GICv3 group-0 @@ -3243,6 +3253,19 @@ driver. A non-zero value sets the minimum interval in seconds between layoutstats transmissions. + nfsd.inter_copy_offload_enable = + [NFSv4.2] When set to 1, the server will support + server-to-server copies for which this server is + the destination of the copy. + + nfsd.nfsd4_ssc_umount_timeout = + [NFSv4.2] When used as the destination of a + server-to-server copy, knfsd temporarily mounts + the source server. It caches the mount in case + it will be needed again, and discards it if not + used for the number of milliseconds specified by + this parameter. + nfsd.nfs4_disable_idmapping= [NFSv4] When set to the default of '1', the NFSv4 server will return only numeric uids and gids to @@ -3250,6 +3273,7 @@ and gids from such clients. This is intended to ease migration from NFSv2/v3. + nmi_backtrace.backtrace_idle [KNL] Dump stacks even of idle CPUs in response to an NMI stack-backtrace request. @@ -4982,6 +5006,18 @@ an IOTLB flush. Default is lazy flushing before reuse, which is faster. + s390_iommu_aperture= [KNL,S390] + Specifies the size of the per device DMA address space + accessible through the DMA and IOMMU APIs as a decimal + factor of the size of main memory. + The default is 1 meaning that one can concurrently use + as many DMA addresses as physical memory is installed, + if supported by hardware, and thus map all of memory + once. With a value of 2 one can map all of memory twice + and so on. As a special case a factor of 0 imposes no + restrictions other than those given by hardware at the + cost of significant additional memory use for tables. + sa1100ir [NET] See drivers/net/irda/sa1100_ir.c. @@ -5303,8 +5339,7 @@ auto - Kernel selects the mitigation depending on the available CPU features and vulnerability. - Default mitigation: - If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl" + Default mitigation: "prctl" Not specifying this option is equivalent to spectre_v2_user=auto. @@ -5348,7 +5383,7 @@ will disable SSB unless they explicitly opt out. Default mitigations: - X86: If CONFIG_SECCOMP=y "seccomp", otherwise "prctl" + X86: "prctl" On powerpc the options are: @@ -5497,6 +5532,15 @@ stifb= [HW] Format: bpp:<bpp1>[:<bpp2>[:<bpp3>...]] + strict_sas_size= + [X86] + Format: <bool> + Enable or disable strict sigaltstack size checks + against the required signal frame size which + depends on the supported FPU features. This can + be used to filter out binaries which have + not yet been made aware of AT_MINSIGSTKSZ. + sunrpc.min_resvport= sunrpc.max_resvport= [NFS,SUNRPC] @@ -6349,6 +6393,13 @@ improve timer resolution at the expense of processing more timer interrupts. + xen.balloon_boot_timeout= [XEN] + The time (in seconds) to wait before giving up to boot + in case initial ballooning fails to free enough memory. + Applies only when running as HVM or PVH guest and + started with less memory configured than allowed at + max. Default is 180. + xen.event_eoi_delay= [XEN] How long to delay EOI handling in case of event storms (jiffies). Default is 10. diff --git a/Documentation/admin-guide/laptops/thinkpad-acpi.rst b/Documentation/admin-guide/laptops/thinkpad-acpi.rst index 6721a80a2d4f..475eb0e81e4a 100644 --- a/Documentation/admin-guide/laptops/thinkpad-acpi.rst +++ b/Documentation/admin-guide/laptops/thinkpad-acpi.rst @@ -1520,15 +1520,15 @@ This sysfs attribute controls the keyboard "face" that will be shown on the Lenovo X1 Carbon 2nd gen (2014)'s adaptive keyboard. The value can be read and set. -- 1 = Home mode -- 2 = Web-browser mode -- 3 = Web-conference mode -- 4 = Function mode -- 5 = Layflat mode +- 0 = Home mode +- 1 = Web-browser mode +- 2 = Web-conference mode +- 3 = Function mode +- 4 = Layflat mode For more details about which buttons will appear depending on the mode, please review the laptop's user guide: -http://www.lenovo.com/shop/americas/content/user_guides/x1carbon_2_ug_en.pdf +https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/x1carbon_2_ug_en.pdf Battery charge control ---------------------- diff --git a/Documentation/admin-guide/media/i2c-cardlist.rst b/Documentation/admin-guide/media/i2c-cardlist.rst index e60d459d18a9..db17f39b56cf 100644 --- a/Documentation/admin-guide/media/i2c-cardlist.rst +++ b/Documentation/admin-guide/media/i2c-cardlist.rst @@ -58,15 +58,20 @@ Camera sensor devices ============ ========================================================== Driver Name ============ ========================================================== +ccs MIPI CCS compliant camera sensors (also SMIA++ and SMIA) et8ek8 ET8EK8 camera sensor hi556 Hynix Hi-556 sensor +hi846 Hynix Hi-846 sensor +imx208 Sony IMX208 sensor imx214 Sony IMX214 sensor imx219 Sony IMX219 sensor imx258 Sony IMX258 sensor imx274 Sony IMX274 sensor imx290 Sony IMX290 sensor imx319 Sony IMX319 sensor +imx334 Sony IMX334 sensor imx355 Sony IMX355 sensor +imx412 Sony IMX412 sensor m5mols Fujitsu M-5MOLS 8MP sensor mt9m001 mt9m001 mt9m032 MT9M032 camera sensor @@ -79,6 +84,7 @@ mt9v032 Micron MT9V032 sensor mt9v111 Aptina MT9V111 sensor noon010pc30 Siliconfile NOON010PC30 sensor ov13858 OmniVision OV13858 sensor +ov13b10 OmniVision OV13B10 sensor ov2640 OmniVision OV2640 sensor ov2659 OmniVision OV2659 sensor ov2680 OmniVision OV2680 sensor @@ -104,7 +110,6 @@ s5k4ecgx Samsung S5K4ECGX sensor s5k5baf Samsung S5K5BAF sensor s5k6a3 Samsung S5K6A3 sensor s5k6aa Samsung S5K6AAFX sensor -smiapp SMIA++/SMIA sensor sr030pc30 Siliconfile SR030PC30 sensor vs6624 ST VS6624 sensor ============ ========================================================== @@ -138,6 +143,7 @@ Driver Name ad5820 AD5820 lens voice coil ak7375 AK7375 lens voice coil dw9714 DW9714 lens voice coil +dw9768 DW9768 lens voice coil dw9807-vcm DW9807 lens voice coil ============ ========================================================== diff --git a/Documentation/admin-guide/media/imx7.rst b/Documentation/admin-guide/media/imx7.rst index 1e442c97da47..4785ae8ac978 100644 --- a/Documentation/admin-guide/media/imx7.rst +++ b/Documentation/admin-guide/media/imx7.rst @@ -155,6 +155,66 @@ the resolutions supported by the sensor. [fmt:SBGGR10_1X10/800x600@1/30 field:none colorspace:srgb] -> "imx7-mipi-csis.0":0 [ENABLED] +i.MX6ULL-EVK with OV5640 +------------------------ + +On this platform a parallel OV5640 sensor is connected to the CSI port. +The following example configures a video capture pipeline with an output +of 640x480 and UYVY8_2X8 format: + +.. code-block:: none + + # Setup links + media-ctl -l "'ov5640 1-003c':0 -> 'csi':0[1]" + media-ctl -l "'csi':1 -> 'csi capture':0[1]" + + # Configure pads for pipeline + media-ctl -v -V "'ov5640 1-003c':0 [fmt:UYVY8_2X8/640x480 field:none]" + +After this streaming can start: + +.. code-block:: none + + gst-launch-1.0 -v v4l2src device=/dev/video1 ! video/x-raw,format=UYVY,width=640,height=480 ! v4l2convert ! fbdevsink + +.. code-block:: none + + # media-ctl -p + Media controller API version 5.14.0 + + Media device information + ------------------------ + driver imx7-csi + model imx-media + serial + bus info + hw revision 0x0 + driver version 5.14.0 + + Device topology + - entity 1: csi (2 pads, 2 links) + type V4L2 subdev subtype Unknown flags 0 + device node name /dev/v4l-subdev0 + pad0: Sink + [fmt:UYVY8_2X8/640x480 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] + <- "ov5640 1-003c":0 [ENABLED,IMMUTABLE] + pad1: Source + [fmt:UYVY8_2X8/640x480 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] + -> "csi capture":0 [ENABLED,IMMUTABLE] + + - entity 4: csi capture (1 pad, 1 link) + type Node subtype V4L flags 0 + device node name /dev/video1 + pad0: Sink + <- "csi":1 [ENABLED,IMMUTABLE] + + - entity 10: ov5640 1-003c (1 pad, 1 link) + type V4L2 subdev subtype Sensor flags 0 + device node name /dev/v4l-subdev1 + pad0: Source + [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] + -> "csi":0 [ENABLED,IMMUTABLE] + References ---------- diff --git a/Documentation/admin-guide/media/ipu3.rst b/Documentation/admin-guide/media/ipu3.rst index 52c1c04173da..83b3cd03b35c 100644 --- a/Documentation/admin-guide/media/ipu3.rst +++ b/Documentation/admin-guide/media/ipu3.rst @@ -51,10 +51,11 @@ to userspace as a V4L2 sub-device node and has two pads: .. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}| .. flat-table:: + :header-rows: 1 - * - pad - - direction - - purpose + * - Pad + - Direction + - Purpose * - 0 - sink @@ -148,10 +149,11 @@ Each pipe has two sink pads and three source pads for the following purpose: .. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}| .. flat-table:: + :header-rows: 1 - * - pad - - direction - - purpose + * - Pad + - Direction + - Purpose * - 0 - sink diff --git a/Documentation/admin-guide/media/ivtv.rst b/Documentation/admin-guide/media/ivtv.rst index 7b8775d20214..101f16d0263e 100644 --- a/Documentation/admin-guide/media/ivtv.rst +++ b/Documentation/admin-guide/media/ivtv.rst @@ -159,7 +159,7 @@ whatever). Otherwise the device numbers can get confusing. The ivtv Read-only The raw YUV video output from the current video input. The YUV format - is non-standard (V4L2_PIX_FMT_HM12). + is a 16x16 linear tiled NV12 format (V4L2_PIX_FMT_NV12_16L16) Note that the YUV and PCM streams are not synchronized, so they are of limited use. diff --git a/Documentation/admin-guide/media/vimc.rst b/Documentation/admin-guide/media/vimc.rst index 211cc8972410..180507d455f2 100644 --- a/Documentation/admin-guide/media/vimc.rst +++ b/Documentation/admin-guide/media/vimc.rst @@ -61,9 +61,10 @@ vimc-debayer: * 1 Pad source vimc-scaler: - Scale up the image by a factor of 3. E.g.: a 640x480 image becomes a - 1920x1440 image. (this value can be configured, see at - `Module options`_). + Re-size the image to meet the source pad resolution. E.g.: if the sync + pad is configured to 360x480 and the source to 1280x720, the image will + be stretched to fit the source resolution. Works for any resolution + within the vimc limitations (even shrinking the image if necessary). Exposes: * 1 Pad sink @@ -75,16 +76,3 @@ vimc-capture: * 1 Pad sink * 1 Pad source - - -Module options --------------- - -Vimc has a module parameter to configure the driver. - -* ``sca_mult=<unsigned int>`` - - Image size multiplier factor to be used to multiply both width and - height, so the image size will be ``sca_mult^2`` bigger than the - original one. Currently, only supports scaling up (the default value - is 3). diff --git a/Documentation/admin-guide/mm/damon/index.rst b/Documentation/admin-guide/mm/damon/index.rst index 8c5dde3a5754..61aff88347f3 100644 --- a/Documentation/admin-guide/mm/damon/index.rst +++ b/Documentation/admin-guide/mm/damon/index.rst @@ -13,3 +13,4 @@ optimize those. start usage + reclaim diff --git a/Documentation/admin-guide/mm/damon/reclaim.rst b/Documentation/admin-guide/mm/damon/reclaim.rst new file mode 100644 index 000000000000..fb9def3a7355 --- /dev/null +++ b/Documentation/admin-guide/mm/damon/reclaim.rst @@ -0,0 +1,235 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================= +DAMON-based Reclamation +======================= + +DAMON-based Reclamation (DAMON_RECLAIM) is a static kernel module that aimed to +be used for proactive and lightweight reclamation under light memory pressure. +It doesn't aim to replace the LRU-list based page_granularity reclamation, but +to be selectively used for different level of memory pressure and requirements. + +Where Proactive Reclamation is Required? +======================================== + +On general memory over-committed systems, proactively reclaiming cold pages +helps saving memory and reducing latency spikes that incurred by the direct +reclaim of the process or CPU consumption of kswapd, while incurring only +minimal performance degradation [1]_ [2]_ . + +Free Pages Reporting [3]_ based memory over-commit virtualization systems are +good example of the cases. In such systems, the guest VMs reports their free +memory to host, and the host reallocates the reported memory to other guests. +As a result, the memory of the systems are fully utilized. However, the +guests could be not so memory-frugal, mainly because some kernel subsystems and +user-space applications are designed to use as much memory as available. Then, +guests could report only small amount of memory as free to host, results in +memory utilization drop of the systems. Running the proactive reclamation in +guests could mitigate this problem. + +How It Works? +============= + +DAMON_RECLAIM finds memory regions that didn't accessed for specific time +duration and page out. To avoid it consuming too much CPU for the paging out +operation, a speed limit can be configured. Under the speed limit, it pages +out memory regions that didn't accessed longer time first. System +administrators can also configure under what situation this scheme should +automatically activated and deactivated with three memory pressure watermarks. + +Interface: Module Parameters +============================ + +To use this feature, you should first ensure your system is running on a kernel +that is built with ``CONFIG_DAMON_RECLAIM=y``. + +To let sysadmins enable or disable it and tune for the given system, +DAMON_RECLAIM utilizes module parameters. That is, you can put +``damon_reclaim.<parameter>=<value>`` on the kernel boot command line or write +proper values to ``/sys/modules/damon_reclaim/parameters/<parameter>`` files. + +Note that the parameter values except ``enabled`` are applied only when +DAMON_RECLAIM starts. Therefore, if you want to apply new parameter values in +runtime and DAMON_RECLAIM is already enabled, you should disable and re-enable +it via ``enabled`` parameter file. Writing of the new values to proper +parameter values should be done before the re-enablement. + +Below are the description of each parameter. + +enabled +------- + +Enable or disable DAMON_RECLAIM. + +You can enable DAMON_RCLAIM by setting the value of this parameter as ``Y``. +Setting it as ``N`` disables DAMON_RECLAIM. Note that DAMON_RECLAIM could do +no real monitoring and reclamation due to the watermarks-based activation +condition. Refer to below descriptions for the watermarks parameter for this. + +min_age +------- + +Time threshold for cold memory regions identification in microseconds. + +If a memory region is not accessed for this or longer time, DAMON_RECLAIM +identifies the region as cold, and reclaims it. + +120 seconds by default. + +quota_ms +-------- + +Limit of time for the reclamation in milliseconds. + +DAMON_RECLAIM tries to use only up to this time within a time window +(quota_reset_interval_ms) for trying reclamation of cold pages. This can be +used for limiting CPU consumption of DAMON_RECLAIM. If the value is zero, the +limit is disabled. + +10 ms by default. + +quota_sz +-------- + +Limit of size of memory for the reclamation in bytes. + +DAMON_RECLAIM charges amount of memory which it tried to reclaim within a time +window (quota_reset_interval_ms) and makes no more than this limit is tried. +This can be used for limiting consumption of CPU and IO. If this value is +zero, the limit is disabled. + +128 MiB by default. + +quota_reset_interval_ms +----------------------- + +The time/size quota charge reset interval in milliseconds. + +The charget reset interval for the quota of time (quota_ms) and size +(quota_sz). That is, DAMON_RECLAIM does not try reclamation for more than +quota_ms milliseconds or quota_sz bytes within quota_reset_interval_ms +milliseconds. + +1 second by default. + +wmarks_interval +--------------- + +Minimal time to wait before checking the watermarks, when DAMON_RECLAIM is +enabled but inactive due to its watermarks rule. + +wmarks_high +----------- + +Free memory rate (per thousand) for the high watermark. + +If free memory of the system in bytes per thousand bytes is higher than this, +DAMON_RECLAIM becomes inactive, so it does nothing but only periodically checks +the watermarks. + +wmarks_mid +---------- + +Free memory rate (per thousand) for the middle watermark. + +If free memory of the system in bytes per thousand bytes is between this and +the low watermark, DAMON_RECLAIM becomes active, so starts the monitoring and +the reclaiming. + +wmarks_low +---------- + +Free memory rate (per thousand) for the low watermark. + +If free memory of the system in bytes per thousand bytes is lower than this, +DAMON_RECLAIM becomes inactive, so it does nothing but periodically checks the +watermarks. In the case, the system falls back to the LRU-list based page +granularity reclamation logic. + +sample_interval +--------------- + +Sampling interval for the monitoring in microseconds. + +The sampling interval of DAMON for the cold memory monitoring. Please refer to +the DAMON documentation (:doc:`usage`) for more detail. + +aggr_interval +------------- + +Aggregation interval for the monitoring in microseconds. + +The aggregation interval of DAMON for the cold memory monitoring. Please +refer to the DAMON documentation (:doc:`usage`) for more detail. + +min_nr_regions +-------------- + +Minimum number of monitoring regions. + +The minimal number of monitoring regions of DAMON for the cold memory +monitoring. This can be used to set lower-bound of the monitoring quality. +But, setting this too high could result in increased monitoring overhead. +Please refer to the DAMON documentation (:doc:`usage`) for more detail. + +max_nr_regions +-------------- + +Maximum number of monitoring regions. + +The maximum number of monitoring regions of DAMON for the cold memory +monitoring. This can be used to set upper-bound of the monitoring overhead. +However, setting this too low could result in bad monitoring quality. Please +refer to the DAMON documentation (:doc:`usage`) for more detail. + +monitor_region_start +-------------------- + +Start of target memory region in physical address. + +The start physical address of memory region that DAMON_RECLAIM will do work +against. That is, DAMON_RECLAIM will find cold memory regions in this region +and reclaims. By default, biggest System RAM is used as the region. + +monitor_region_end +------------------ + +End of target memory region in physical address. + +The end physical address of memory region that DAMON_RECLAIM will do work +against. That is, DAMON_RECLAIM will find cold memory regions in this region +and reclaims. By default, biggest System RAM is used as the region. + +kdamond_pid +----------- + +PID of the DAMON thread. + +If DAMON_RECLAIM is enabled, this becomes the PID of the worker thread. Else, +-1. + +Example +======= + +Below runtime example commands make DAMON_RECLAIM to find memory regions that +not accessed for 30 seconds or more and pages out. The reclamation is limited +to be done only up to 1 GiB per second to avoid DAMON_RECLAIM consuming too +much CPU time for the paging out operation. It also asks DAMON_RECLAIM to do +nothing if the system's free memory rate is more than 50%, but start the real +works if it becomes lower than 40%. If DAMON_RECLAIM doesn't make progress and +therefore the free memory rate becomes lower than 20%, it asks DAMON_RECLAIM to +do nothing again, so that we can fall back to the LRU-list based page +granularity reclamation. :: + + # cd /sys/modules/damon_reclaim/parameters + # echo 30000000 > min_age + # echo $((1 * 1024 * 1024 * 1024)) > quota_sz + # echo 1000 > quota_reset_interval_ms + # echo 500 > wmarks_high + # echo 400 > wmarks_mid + # echo 200 > wmarks_low + # echo Y > enabled + +.. [1] https://research.google/pubs/pub48551/ +.. [2] https://lwn.net/Articles/787611/ +.. [3] https://www.kernel.org/doc/html/latest/vm/free_page_reporting.html diff --git a/Documentation/admin-guide/mm/damon/start.rst b/Documentation/admin-guide/mm/damon/start.rst index d5eb89a8fc38..4d5ca2c46288 100644 --- a/Documentation/admin-guide/mm/damon/start.rst +++ b/Documentation/admin-guide/mm/damon/start.rst @@ -6,39 +6,9 @@ Getting Started This document briefly describes how you can use DAMON by demonstrating its default user space tool. Please note that this document describes only a part -of its features for brevity. Please refer to :doc:`usage` for more details. - - -TL; DR -====== - -Follow the commands below to monitor and visualize the memory access pattern of -your workload. :: - - # # build the kernel with CONFIG_DAMON_*=y, install it, and reboot - # mount -t debugfs none /sys/kernel/debug/ - # git clone https://github.com/awslabs/damo - # ./damo/damo record $(pidof <your workload>) - # ./damo/damo report heat --plot_ascii - -The final command draws the access heatmap of ``<your workload>``. The heatmap -shows which memory region (x-axis) is accessed when (y-axis) and how frequently -(number; the higher the more accesses have been observed). :: - - 111111111111111111111111111111111111111111111111111111110000 - 111121111111111111111111111111211111111111111111111111110000 - 000000000000000000000000000000000000000000000000001555552000 - 000000000000000000000000000000000000000000000222223555552000 - 000000000000000000000000000000000000000011111677775000000000 - 000000000000000000000000000000000000000488888000000000000000 - 000000000000000000000000000000000177888400000000000000000000 - 000000000000000000000000000046666522222100000000000000000000 - 000000000000000000000014444344444300000000000000000000000000 - 000000000000000002222245555510000000000000000000000000000000 - # access_frequency: 0 1 2 3 4 5 6 7 8 9 - # x-axis: space (140286319947776-140286426374096: 101.496 MiB) - # y-axis: time (605442256436361-605479951866441: 37.695430s) - # resolution: 60x10 (1.692 MiB and 3.770s for each character) +of its features for brevity. Please refer to the usage `doc +<https://github.com/awslabs/damo/blob/next/USAGE.md>`_ of the tool for more +details. Prerequisites @@ -91,24 +61,74 @@ pattern in the ``damon.data`` file. Visualizing Recorded Patterns ============================= -The following three commands visualize the recorded access patterns and save -the results as separate image files. :: - - $ damo report heats --heatmap access_pattern_heatmap.png - $ damo report wss --range 0 101 1 --plot wss_dist.png - $ damo report wss --range 0 101 1 --sortby time --plot wss_chron_change.png - -- ``access_pattern_heatmap.png`` will visualize the data access pattern in a - heatmap, showing which memory region (y-axis) got accessed when (x-axis) - and how frequently (color). -- ``wss_dist.png`` will show the distribution of the working set size. -- ``wss_chron_change.png`` will show how the working set size has - chronologically changed. - -You can view the visualizations of this example workload at [1]_. -Visualizations of other realistic workloads are available at [2]_ [3]_ [4]_. - -.. [1] https://damonitor.github.io/doc/html/v17/admin-guide/mm/damon/start.html#visualizing-recorded-patterns -.. [2] https://damonitor.github.io/test/result/visual/latest/rec.heatmap.1.png.html -.. [3] https://damonitor.github.io/test/result/visual/latest/rec.wss_sz.png.html -.. [4] https://damonitor.github.io/test/result/visual/latest/rec.wss_time.png.html +You can visualize the pattern in a heatmap, showing which memory region +(x-axis) got accessed when (y-axis) and how frequently (number).:: + + $ sudo damo report heats --heatmap stdout + 22222222222222222222222222222222222222211111111111111111111111111111111111111100 + 44444444444444444444444444444444444444434444444444444444444444444444444444443200 + 44444444444444444444444444444444444444433444444444444444444444444444444444444200 + 33333333333333333333333333333333333333344555555555555555555555555555555555555200 + 33333333333333333333333333333333333344444444444444444444444444444444444444444200 + 22222222222222222222222222222222222223355555555555555555555555555555555555555200 + 00000000000000000000000000000000000000288888888888888888888888888888888888888400 + 00000000000000000000000000000000000000288888888888888888888888888888888888888400 + 33333333333333333333333333333333333333355555555555555555555555555555555555555200 + 88888888888888888888888888888888888888600000000000000000000000000000000000000000 + 88888888888888888888888888888888888888600000000000000000000000000000000000000000 + 33333333333333333333333333333333333333444444444444444444444444444444444444443200 + 00000000000000000000000000000000000000288888888888888888888888888888888888888400 + [...] + # access_frequency: 0 1 2 3 4 5 6 7 8 9 + # x-axis: space (139728247021568-139728453431248: 196.848 MiB) + # y-axis: time (15256597248362-15326899978162: 1 m 10.303 s) + # resolution: 80x40 (2.461 MiB and 1.758 s for each character) + +You can also visualize the distribution of the working set size, sorted by the +size.:: + + $ sudo damo report wss --range 0 101 10 + # <percentile> <wss> + # target_id 18446632103789443072 + # avr: 107.708 MiB + 0 0 B | | + 10 95.328 MiB |**************************** | + 20 95.332 MiB |**************************** | + 30 95.340 MiB |**************************** | + 40 95.387 MiB |**************************** | + 50 95.387 MiB |**************************** | + 60 95.398 MiB |**************************** | + 70 95.398 MiB |**************************** | + 80 95.504 MiB |**************************** | + 90 190.703 MiB |********************************************************* | + 100 196.875 MiB |***********************************************************| + +Using ``--sortby`` option with the above command, you can show how the working +set size has chronologically changed.:: + + $ sudo damo report wss --range 0 101 10 --sortby time + # <percentile> <wss> + # target_id 18446632103789443072 + # avr: 107.708 MiB + 0 3.051 MiB | | + 10 190.703 MiB |***********************************************************| + 20 95.336 MiB |***************************** | + 30 95.328 MiB |***************************** | + 40 95.387 MiB |***************************** | + 50 95.332 MiB |***************************** | + 60 95.320 MiB |***************************** | + 70 95.398 MiB |***************************** | + 80 95.398 MiB |***************************** | + 90 95.340 MiB |***************************** | + 100 95.398 MiB |***************************** | + + +Data Access Pattern Aware Memory Management +=========================================== + +Below three commands make every memory region of size >=4K that doesn't +accessed for >=60 seconds in your workload to be swapped out. :: + + $ echo "#min-size max-size min-acc max-acc min-age max-age action" > test_scheme + $ echo "4K max 0 0 60s max pageout" >> test_scheme + $ damo schemes -c test_scheme <pid of your workload> diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index a72cda374aba..ed96bbf0daff 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -10,15 +10,16 @@ DAMON provides below three interfaces for different users. This is for privileged people such as system administrators who want a just-working human-friendly interface. Using this, users can use the DAMON’s major features in a human-friendly way. It may not be highly tuned for - special cases, though. It supports only virtual address spaces monitoring. + special cases, though. It supports both virtual and physical address spaces + monitoring. - *debugfs interface.* This is for privileged user space programmers who want more optimized use of DAMON. Using this, users can use DAMON’s major features by reading from and writing to special debugfs files. Therefore, you can write and use your personalized DAMON debugfs wrapper programs that reads/writes the debugfs files instead of you. The DAMON user space tool is also a reference - implementation of such programs. It supports only virtual address spaces - monitoring. + implementation of such programs. It supports both virtual and physical + address spaces monitoring. - *Kernel Space Programming Interface.* This is for kernel space programmers. Using this, users can utilize every feature of DAMON most flexibly and efficiently by writing kernel space @@ -34,8 +35,9 @@ the reason, this document describes only the debugfs interface debugfs Interface ================= -DAMON exports three files, ``attrs``, ``target_ids``, and ``monitor_on`` under -its debugfs directory, ``<debugfs>/damon/``. +DAMON exports five files, ``attrs``, ``target_ids``, ``init_regions``, +``schemes`` and ``monitor_on`` under its debugfs directory, +``<debugfs>/damon/``. Attributes @@ -71,9 +73,106 @@ check it again:: # cat target_ids 42 4242 +Users can also monitor the physical memory address space of the system by +writing a special keyword, "``paddr\n``" to the file. Because physical address +space monitoring doesn't support multiple targets, reading the file will show a +fake value, ``42``, as below:: + + # cd <debugfs>/damon + # echo paddr > target_ids + # cat target_ids + 42 + Note that setting the target ids doesn't start the monitoring. +Initial Monitoring Target Regions +--------------------------------- + +In case of the virtual address space monitoring, DAMON automatically sets and +updates the monitoring target regions so that entire memory mappings of target +processes can be covered. However, users can want to limit the monitoring +region to specific address ranges, such as the heap, the stack, or specific +file-mapped area. Or, some users can know the initial access pattern of their +workloads and therefore want to set optimal initial regions for the 'adaptive +regions adjustment'. + +In contrast, DAMON do not automatically sets and updates the monitoring target +regions in case of physical memory monitoring. Therefore, users should set the +monitoring target regions by themselves. + +In such cases, users can explicitly set the initial monitoring target regions +as they want, by writing proper values to the ``init_regions`` file. Each line +of the input should represent one region in below form.:: + + <target id> <start address> <end address> + +The ``target id`` should already in ``target_ids`` file, and the regions should +be passed in address order. For example, below commands will set a couple of +address ranges, ``1-100`` and ``100-200`` as the initial monitoring target +region of process 42, and another couple of address ranges, ``20-40`` and +``50-100`` as that of process 4242.:: + + # cd <debugfs>/damon + # echo "42 1 100 + 42 100 200 + 4242 20 40 + 4242 50 100" > init_regions + +Note that this sets the initial monitoring target regions only. In case of +virtual memory monitoring, DAMON will automatically updates the boundary of the +regions after one ``regions update interval``. Therefore, users should set the +``regions update interval`` large enough in this case, if they don't want the +update. + + +Schemes +------- + +For usual DAMON-based data access aware memory management optimizations, users +would simply want the system to apply a memory management action to a memory +region of a specific size having a specific access frequency for a specific +time. DAMON receives such formalized operation schemes from the user and +applies those to the target processes. It also counts the total number and +size of regions that each scheme is applied. This statistics can be used for +online analysis or tuning of the schemes. + +Users can get and set the schemes by reading from and writing to ``schemes`` +debugfs file. Reading the file also shows the statistics of each scheme. To +the file, each of the schemes should be represented in each line in below form: + + min-size max-size min-acc max-acc min-age max-age action + +Note that the ranges are closed interval. Bytes for the size of regions +(``min-size`` and ``max-size``), number of monitored accesses per aggregate +interval for access frequency (``min-acc`` and ``max-acc``), number of +aggregate intervals for the age of regions (``min-age`` and ``max-age``), and a +predefined integer for memory management actions should be used. The supported +numbers and their meanings are as below. + + - 0: Call ``madvise()`` for the region with ``MADV_WILLNEED`` + - 1: Call ``madvise()`` for the region with ``MADV_COLD`` + - 2: Call ``madvise()`` for the region with ``MADV_PAGEOUT`` + - 3: Call ``madvise()`` for the region with ``MADV_HUGEPAGE`` + - 4: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE`` + - 5: Do nothing but count the statistics + +You can disable schemes by simply writing an empty string to the file. For +example, below commands applies a scheme saying "If a memory region of size in +[4KiB, 8KiB] is showing accesses per aggregate interval in [0, 5] for aggregate +interval in [10, 20], page out the region", check the entered scheme again, and +finally remove the scheme. :: + + # cd <debugfs>/damon + # echo "4096 8192 0 5 10 20 2" > schemes + # cat schemes + 4096 8192 0 5 10 20 2 0 0 + # echo > schemes + +The last two integers in the 4th line of above example is the total number and +the total size of the regions that the scheme is applied. + + Turning On/Off -------------- diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst index 8abaeb144e44..0166f9de3428 100644 --- a/Documentation/admin-guide/mm/hugetlbpage.rst +++ b/Documentation/admin-guide/mm/hugetlbpage.rst @@ -128,7 +128,9 @@ hugepages implicitly specifies the number of huge pages of default size to allocate. If the number of huge pages of default size is implicitly specified, it can not be overwritten by a hugepagesz,hugepages - parameter pair for the default size. + parameter pair for the default size. This parameter also has a + node format. The node format specifies the number of huge pages + to allocate on specific nodes. For example, on an architecture with 2M default huge page size:: @@ -138,6 +140,14 @@ hugepages indicating that the hugepages=512 parameter is ignored. If a hugepages parameter is preceded by an invalid hugepagesz parameter, it will be ignored. + + Node format example:: + + hugepagesz=2M hugepages=0:1,1:2 + + It will allocate 1 2M hugepage on node0 and 2 2M hugepages on node1. + If the node number is invalid, the parameter will be ignored. + default_hugepagesz Specify the default huge page size. This parameter can only be specified once on the command line. default_hugepagesz can @@ -234,8 +244,12 @@ will exist, of the form:: hugepages-${size}kB -Inside each of these directories, the same set of files will exist:: +Inside each of these directories, the set of files contained in ``/proc`` +will exist. In addition, two additional interfaces for demoting huge +pages may exist:: + demote + demote_size nr_hugepages nr_hugepages_mempolicy nr_overcommit_hugepages @@ -243,7 +257,29 @@ Inside each of these directories, the same set of files will exist:: resv_hugepages surplus_hugepages -which function as described above for the default huge page-sized case. +The demote interfaces provide the ability to split a huge page into +smaller huge pages. For example, the x86 architecture supports both +1GB and 2MB huge pages sizes. A 1GB huge page can be split into 512 +2MB huge pages. Demote interfaces are not available for the smallest +huge page size. The demote interfaces are: + +demote_size + is the size of demoted pages. When a page is demoted a corresponding + number of huge pages of demote_size will be created. By default, + demote_size is set to the next smaller huge page size. If there are + multiple smaller huge page sizes, demote_size can be set to any of + these smaller sizes. Only huge page sizes less than the current huge + pages size are allowed. + +demote + is used to demote a number of huge pages. A user with root privileges + can write to this file. It may not be possible to demote the + requested number of huge pages. To determine how many pages were + actually demoted, compare the value of nr_hugepages before and after + writing to the demote interface. demote is a write only interface. + +The interfaces which are the same as in ``/proc`` (all except demote and +demote_size) function as described above for the default huge page-sized case. .. _mem_policy_and_hp_alloc: diff --git a/Documentation/admin-guide/mm/index.rst b/Documentation/admin-guide/mm/index.rst index cbd19d5e625f..c21b5823f126 100644 --- a/Documentation/admin-guide/mm/index.rst +++ b/Documentation/admin-guide/mm/index.rst @@ -37,5 +37,7 @@ the Linux memory management. numaperf pagemap soft-dirty + swap_numa transhuge userfaultfd + zswap diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst index 03dfbc925252..0f56ecd8ac05 100644 --- a/Documentation/admin-guide/mm/memory-hotplug.rst +++ b/Documentation/admin-guide/mm/memory-hotplug.rst @@ -165,9 +165,8 @@ Or alternatively:: % echo 1 > /sys/devices/system/memory/memoryXXX/online -The kernel will select the target zone automatically, usually defaulting to -``ZONE_NORMAL`` unless ``movablecore=1`` has been specified on the kernel -command line or if the memory block would intersect the ZONE_MOVABLE already. +The kernel will select the target zone automatically, depending on the +configured ``online_policy``. One can explicitly request to associate an offline memory block with ZONE_MOVABLE by:: @@ -198,6 +197,9 @@ Auto-onlining can be enabled by writing ``online``, ``online_kernel`` or % echo online > /sys/devices/system/memory/auto_online_blocks +Similarly to manual onlining, with ``online`` the kernel will select the +target zone automatically, depending on the configured ``online_policy``. + Modifying the auto-online behavior will only affect all subsequently added memory blocks only. @@ -393,11 +395,16 @@ command line parameters are relevant: ======================== ======================================================= ``memhp_default_state`` configure auto-onlining by essentially setting ``/sys/devices/system/memory/auto_online_blocks``. -``movablecore`` configure automatic zone selection of the kernel. When - set, the kernel will default to ZONE_MOVABLE, unless - other zones can be kept contiguous. +``movable_node`` configure automatic zone selection in the kernel when + using the ``contig-zones`` online policy. When + set, the kernel will default to ZONE_MOVABLE when + onlining a memory block, unless other zones can be kept + contiguous. ======================== ======================================================= +See Documentation/admin-guide/kernel-parameters.txt for a more generic +description of these command line parameters. + Module Parameters ------------------ @@ -410,24 +417,118 @@ them with ``memory_hotplug.`` such as:: and they can be observed (and some even modified at runtime) via:: - /sys/modules/memory_hotplug/parameters/ + /sys/module/memory_hotplug/parameters/ The following module parameters are currently defined: -======================== ======================================================= -``memmap_on_memory`` read-write: Allocate memory for the memmap from the - added memory block itself. Even if enabled, actual - support depends on various other system properties and - should only be regarded as a hint whether the behavior - would be desired. - - While allocating the memmap from the memory block - itself makes memory hotplug less likely to fail and - keeps the memmap on the same NUMA node in any case, it - can fragment physical memory in a way that huge pages - in bigger granularity cannot be formed on hotplugged - memory. -======================== ======================================================= +================================ =============================================== +``memmap_on_memory`` read-write: Allocate memory for the memmap from + the added memory block itself. Even if enabled, + actual support depends on various other system + properties and should only be regarded as a + hint whether the behavior would be desired. + + While allocating the memmap from the memory + block itself makes memory hotplug less likely + to fail and keeps the memmap on the same NUMA + node in any case, it can fragment physical + memory in a way that huge pages in bigger + granularity cannot be formed on hotplugged + memory. +``online_policy`` read-write: Set the basic policy used for + automatic zone selection when onlining memory + blocks without specifying a target zone. + ``contig-zones`` has been the kernel default + before this parameter was added. After an + online policy was configured and memory was + online, the policy should not be changed + anymore. + + When set to ``contig-zones``, the kernel will + try keeping zones contiguous. If a memory block + intersects multiple zones or no zone, the + behavior depends on the ``movable_node`` kernel + command line parameter: default to ZONE_MOVABLE + if set, default to the applicable kernel zone + (usually ZONE_NORMAL) if not set. + + When set to ``auto-movable``, the kernel will + try onlining memory blocks to ZONE_MOVABLE if + possible according to the configuration and + memory device details. With this policy, one + can avoid zone imbalances when eventually + hotplugging a lot of memory later and still + wanting to be able to hotunplug as much as + possible reliably, very desirable in + virtualized environments. This policy ignores + the ``movable_node`` kernel command line + parameter and isn't really applicable in + environments that require it (e.g., bare metal + with hotunpluggable nodes) where hotplugged + memory might be exposed via the + firmware-provided memory map early during boot + to the system instead of getting detected, + added and onlined later during boot (such as + done by virtio-mem or by some hypervisors + implementing emulated DIMMs). As one example, a + hotplugged DIMM will be onlined either + completely to ZONE_MOVABLE or completely to + ZONE_NORMAL, not a mixture. + As another example, as many memory blocks + belonging to a virtio-mem device will be + onlined to ZONE_MOVABLE as possible, + special-casing units of memory blocks that can + only get hotunplugged together. *This policy + does not protect from setups that are + problematic with ZONE_MOVABLE and does not + change the zone of memory blocks dynamically + after they were onlined.* +``auto_movable_ratio`` read-write: Set the maximum MOVABLE:KERNEL + memory ratio in % for the ``auto-movable`` + online policy. Whether the ratio applies only + for the system across all NUMA nodes or also + per NUMA nodes depends on the + ``auto_movable_numa_aware`` configuration. + + All accounting is based on present memory pages + in the zones combined with accounting per + memory device. Memory dedicated to the CMA + allocator is accounted as MOVABLE, although + residing on one of the kernel zones. The + possible ratio depends on the actual workload. + The kernel default is "301" %, for example, + allowing for hotplugging 24 GiB to a 8 GiB VM + and automatically onlining all hotplugged + memory to ZONE_MOVABLE in many setups. The + additional 1% deals with some pages being not + present, for example, because of some firmware + allocations. + + Note that ZONE_NORMAL memory provided by one + memory device does not allow for more + ZONE_MOVABLE memory for a different memory + device. As one example, onlining memory of a + hotplugged DIMM to ZONE_NORMAL will not allow + for another hotplugged DIMM to get onlined to + ZONE_MOVABLE automatically. In contrast, memory + hotplugged by a virtio-mem device that got + onlined to ZONE_NORMAL will allow for more + ZONE_MOVABLE memory within *the same* + virtio-mem device. +``auto_movable_numa_aware`` read-write: Configure whether the + ``auto_movable_ratio`` in the ``auto-movable`` + online policy also applies per NUMA + node in addition to the whole system across all + NUMA nodes. The kernel default is "Y". + + Disabling NUMA awareness can be helpful when + dealing with NUMA nodes that should be + completely hotunpluggable, onlining the memory + completely to ZONE_MOVABLE automatically if + possible. + + Parameter availability depends on CONFIG_NUMA. +================================ =============================================== ZONE_MOVABLE ============ diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst index fb578fbbb76c..bfc28704856c 100644 --- a/Documentation/admin-guide/mm/pagemap.rst +++ b/Documentation/admin-guide/mm/pagemap.rst @@ -90,13 +90,14 @@ Short descriptions to the page flags ==================================== 0 - LOCKED - page is being locked for exclusive access, e.g. by undergoing read/write IO + The page is being locked for exclusive access, e.g. by undergoing read/write + IO. 7 - SLAB - page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator + The page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator. When compound page is used, SLUB/SLQB will only set this flag on the head page; SLOB will not flag it at all. 10 - BUDDY - a free memory block managed by the buddy system allocator + A free memory block managed by the buddy system allocator. The buddy system organizes free memory in blocks of various orders. An order N block has 2^N physically contiguous pages, with the BUDDY flag set for and _only_ for the first page. @@ -112,65 +113,65 @@ Short descriptions to the page flags 16 - COMPOUND_TAIL A compound page tail (see description above). 17 - HUGE - this is an integral part of a HugeTLB page + This is an integral part of a HugeTLB page. 19 - HWPOISON - hardware detected memory corruption on this page: don't touch the data! + Hardware detected memory corruption on this page: don't touch the data! 20 - NOPAGE - no page frame exists at the requested address + No page frame exists at the requested address. 21 - KSM - identical memory pages dynamically shared between one or more processes + Identical memory pages dynamically shared between one or more processes. 22 - THP - contiguous pages which construct transparent hugepages + Contiguous pages which construct transparent hugepages. 23 - OFFLINE - page is logically offline + The page is logically offline. 24 - ZERO_PAGE - zero page for pfn_zero or huge_zero page + Zero page for pfn_zero or huge_zero page. 25 - IDLE - page has not been accessed since it was marked idle (see + The page has not been accessed since it was marked idle (see :ref:`Documentation/admin-guide/mm/idle_page_tracking.rst <idle_page_tracking>`). Note that this flag may be stale in case the page was accessed via a PTE. To make sure the flag is up-to-date one has to read ``/sys/kernel/mm/page_idle/bitmap`` first. 26 - PGTABLE - page is in use as a page table + The page is in use as a page table. IO related page flags --------------------- 1 - ERROR - IO error occurred + IO error occurred. 3 - UPTODATE - page has up-to-date data + The page has up-to-date data. ie. for file backed page: (in-memory data revision >= on-disk one) 4 - DIRTY - page has been written to, hence contains new data + The page has been written to, hence contains new data. i.e. for file backed page: (in-memory data revision > on-disk one) 8 - WRITEBACK - page is being synced to disk + The page is being synced to disk. LRU related page flags ---------------------- 5 - LRU - page is in one of the LRU lists + The page is in one of the LRU lists. 6 - ACTIVE - page is in the active LRU list + The page is in the active LRU list. 18 - UNEVICTABLE - page is in the unevictable (non-)LRU list It is somehow pinned and + The page is in the unevictable (non-)LRU list It is somehow pinned and not a candidate for LRU page reclaims, e.g. ramfs pages, - shmctl(SHM_LOCK) and mlock() memory segments + shmctl(SHM_LOCK) and mlock() memory segments. 2 - REFERENCED - page has been referenced since last LRU list enqueue/requeue + The page has been referenced since last LRU list enqueue/requeue. 9 - RECLAIM - page will be reclaimed soon after its pageout IO completed + The page will be reclaimed soon after its pageout IO completed. 11 - MMAP - a memory mapped page + A memory mapped page. 12 - ANON - a memory mapped page that is not part of a file + A memory mapped page that is not part of a file. 13 - SWAPCACHE - page is mapped to swap space, i.e. has an associated swap entry + The page is mapped to swap space, i.e. has an associated swap entry. 14 - SWAPBACKED - page is backed by swap/RAM + The page is backed by swap/RAM. The page-types tool in the tools/vm directory can be used to query the above flags. @@ -196,6 +197,28 @@ you can go through every map in the process, find the PFNs, look those up in kpagecount, and tally up the number of pages that are only referenced once. +Exceptions for Shared Memory +============================ + +Page table entries for shared pages are cleared when the pages are zapped or +swapped out. This makes swapped out pages indistinguishable from never-allocated +ones. + +In kernel space, the swap location can still be retrieved from the page cache. +However, values stored only on the normal PTE get lost irretrievably when the +page is swapped out (i.e. SOFT_DIRTY). + +In user space, whether the page is present, swapped or none can be deduced with +the help of lseek and/or mincore system calls. + +lseek() can differentiate between accessed pages (present or swapped out) and +holes (none/non-allocated) by specifying the SEEK_DATA flag on the file where +the pages are backed. For anonymous shared pages, the file can be found in +``/proc/pid/map_files/``. + +mincore() can differentiate between pages in memory (present, including swap +cache) and out of memory (swapped out or none/non-allocated). + Other notes =========== diff --git a/Documentation/vm/swap_numa.rst b/Documentation/admin-guide/mm/swap_numa.rst index e0466f2db8fa..e0466f2db8fa 100644 --- a/Documentation/vm/swap_numa.rst +++ b/Documentation/admin-guide/mm/swap_numa.rst diff --git a/Documentation/vm/zswap.rst b/Documentation/admin-guide/mm/zswap.rst index 8edb8d578caf..8edb8d578caf 100644 --- a/Documentation/vm/zswap.rst +++ b/Documentation/admin-guide/mm/zswap.rst diff --git a/Documentation/admin-guide/ramoops.rst b/Documentation/admin-guide/ramoops.rst index 8f107d8c9261..e9f85142182d 100644 --- a/Documentation/admin-guide/ramoops.rst +++ b/Documentation/admin-guide/ramoops.rst @@ -69,7 +69,7 @@ Setting the ramoops parameters can be done in several different manners: mem=128M ramoops.mem_address=0x8000000 ramoops.ecc=1 B. Use Device Tree bindings, as described in - ``Documentation/devicetree/bindings/reserved-memory/ramoops.txt``. + ``Documentation/devicetree/bindings/reserved-memory/ramoops.yaml``. For example:: reserved-memory { diff --git a/Documentation/admin-guide/spkguide.txt b/Documentation/admin-guide/spkguide.txt index 977ab3f5a0a8..1265c1eab31c 100644 --- a/Documentation/admin-guide/spkguide.txt +++ b/Documentation/admin-guide/spkguide.txt @@ -543,7 +543,7 @@ As mentioned earlier, Speakup can either be completely compiled into the kernel, with the exception of the help module, or it can be compiled as a series of modules. When compiled as modules, Speakup will only be able to speak some of the bootup messages if your system administrator -has configured the system to load the modules at boo time. The modules +has configured the system to load the modules at boot time. The modules can be loaded after the file systems have been checked and mounted, or from an initrd. There is a third possibility. Speakup can be compiled with some components built into the kernel, and others as modules. As diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 426162009ce9..0e486f41185e 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -1099,7 +1099,7 @@ task_delayacct =============== Enables/disables task delay accounting (see -:doc:`accounting/delay-accounting.rst`). Enabling this feature incurs +Documentation/accounting/delay-accounting.rst. Enabling this feature incurs a small amount of overhead in the scheduler but is useful for debugging and performance tuning. It is required by some tools such as iotop. diff --git a/Documentation/arm/index.rst b/Documentation/arm/index.rst index d4f34ae9e6f4..2bda5461a80b 100644 --- a/Documentation/arm/index.rst +++ b/Documentation/arm/index.rst @@ -55,6 +55,7 @@ SoC-specific documents stm32/stm32h750-overview stm32/stm32f769-overview stm32/stm32f429-overview + stm32/stm32mp13-overview stm32/stm32mp157-overview sunxi diff --git a/Documentation/arm/marvell.rst b/Documentation/arm/marvell.rst index 56bb592dbd0c..9485a5a2e2e9 100644 --- a/Documentation/arm/marvell.rst +++ b/Documentation/arm/marvell.rst @@ -21,6 +21,7 @@ Orion family - Datasheet: https://web.archive.org/web/20210124231420/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-datasheet.pdf - Programmer's User Guide: https://web.archive.org/web/20210124231536/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-opensource-manual.pdf - User Manual: https://web.archive.org/web/20210124231631/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-usermanual.pdf + - Functional Errata: https://web.archive.org/web/20210704165540/https://www.digriz.org.uk/ts78xx/88F5182_Functional_Errata.pdf - 88F5281 - Datasheet: https://web.archive.org/web/20131028144728/http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf @@ -103,6 +104,8 @@ Discovery family Not supported by the Linux kernel. + Homepage: + https://web.archive.org/web/20110924171043/http://www.marvell.com/embedded-processors/discovery-innovation/ Core: Feroceon 88fr571-vd ARMv5 compatible @@ -119,6 +122,7 @@ EBU Armada family - 88F6707 - 88F6W11 + - Product infos: https://web.archive.org/web/20141002083258/http://www.marvell.com/embedded-processors/armada-370/ - Product Brief: https://web.archive.org/web/20121115063038/http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf - Hardware Spec: https://web.archive.org/web/20140617183747/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf - Functional Spec: https://web.archive.org/web/20140617183701/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf @@ -126,9 +130,29 @@ EBU Armada family Core: Sheeva ARMv7 compatible PJ4B + Armada XP Flavors: + - MV78230 + - MV78260 + - MV78460 + + NOTE: + not to be confused with the non-SMP 78xx0 SoCs + + - Product infos: https://web.archive.org/web/20150101215721/http://www.marvell.com/embedded-processors/armada-xp/ + - Product Brief: https://web.archive.org/web/20121021173528/http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf + - Functional Spec: https://web.archive.org/web/20180829171131/http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf + - Hardware Specs: + - https://web.archive.org/web/20141127013651/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF + - https://web.archive.org/web/20141222000224/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF + - https://web.archive.org/web/20141222000230/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF + + Core: + Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP + Armada 375 Flavors: - 88F6720 + - Product infos: https://web.archive.org/web/20140108032402/http://www.marvell.com/embedded-processors/armada-375/ - Product Brief: https://web.archive.org/web/20131216023516/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf Core: @@ -161,29 +185,6 @@ EBU Armada family Core: ARM Cortex-A9 - Armada XP Flavors: - - MV78230 - - MV78260 - - MV78460 - - NOTE: - not to be confused with the non-SMP 78xx0 SoCs - - Product Brief: - https://web.archive.org/web/20121021173528/http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf - - Functional Spec: - https://web.archive.org/web/20180829171131/http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf - - - Hardware Specs: - - - https://web.archive.org/web/20141127013651/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF - - https://web.archive.org/web/20141222000224/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF - - https://web.archive.org/web/20141222000230/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF - - Core: - Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP - Linux kernel mach directory: arch/arm/mach-mvebu Linux kernel plat directory: @@ -212,6 +213,7 @@ EBU Armada family ARMv8 arch/arm64/boot/dts/marvell/armada-37* Armada 7K Flavors: + - 88F6040 (AP806 Quad 600 MHz + one CP110) - 88F7020 (AP806 Dual + one CP110) - 88F7040 (AP806 Quad + one CP110) @@ -243,6 +245,23 @@ EBU Armada family ARMv8 Device tree files: arch/arm64/boot/dts/marvell/armada-80* + Octeon TX2 CN913x Flavors: + - CN9130 (AP807 Quad + one internal CP115) + - CN9131 (AP807 Quad + one internal CP115 + one external CP115 / 88F8215) + - CN9132 (AP807 Quad + one internal CP115 + two external CP115 / 88F8215) + + Core: + ARM Cortex A72 + + Homepage: + https://web.archive.org/web/20200803150818/https://www.marvell.com/products/infrastructure-processors/multi-core-processors/octeon-tx2/octeon-tx2-cn9130.html + + Product Brief: + https://web.archive.org/web/20200803150818/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-infrastructure-processors-octeon-tx2-cn913x-product-brief-2020-02.pdf + + Device tree files: + arch/arm64/boot/dts/marvell/cn913* + Avanta family ------------- @@ -417,7 +436,7 @@ Berlin family (Multimedia Solutions) - Flavors: - 88DE3010, Armada 1000 (no Linux support) - Core: Marvell PJ1 (ARMv5TE), Dual-core - - Product Brief: http://www.marvell.com.cn/digital-entertainment/assets/armada_1000_pb.pdf + - Product Brief: https://web.archive.org/web/20131103162620/http://www.marvell.com/digital-entertainment/assets/armada_1000_pb.pdf - 88DE3005, Armada 1500 Mini - Design name: BG2CD - Core: ARM Cortex-A9, PL310 L2CC diff --git a/Documentation/arm/microchip.rst b/Documentation/arm/microchip.rst index 9c013299fd3b..e721d855f2c9 100644 --- a/Documentation/arm/microchip.rst +++ b/Documentation/arm/microchip.rst @@ -137,6 +137,26 @@ the Microchip website: http://www.microchip.com. http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001476B.pdf + * ARM Cortex-A7 based SoCs + - sama7g5 family + + - sama7g51 + - sama7g52 + - sama7g53 + - sama7g54 (device superset) + + * Datasheet + + Coming soon + + - lan966 family + - lan9662 + - lan9668 + + * Datasheet + + Coming soon + * ARM Cortex-M7 MCUs - sams70 family diff --git a/Documentation/arm/stm32/stm32mp13-overview.rst b/Documentation/arm/stm32/stm32mp13-overview.rst new file mode 100644 index 000000000000..3bb9492dad49 --- /dev/null +++ b/Documentation/arm/stm32/stm32mp13-overview.rst @@ -0,0 +1,37 @@ +=================== +STM32MP13 Overview +=================== + +Introduction +------------ + +The STM32MP131/STM32MP133/STM32MP135 are Cortex-A MPU aimed at various applications. +They feature: + +- One Cortex-A7 application core +- Standard memories interface support +- Standard connectivity, widely inherited from the STM32 MCU family +- Comprehensive security support + +More details: + +- Cortex-A7 core running up to @900MHz +- FMC controller to connect SDRAM, NOR and NAND memories +- QSPI +- SD/MMC/SDIO support +- 2*Ethernet controller +- CAN +- ADC/DAC +- USB EHCI/OHCI controllers +- USB OTG +- I2C, SPI, CAN busses support +- Several general purpose timers +- Serial Audio interface +- LCD controller +- DCMIPP +- SPDIFRX +- DFSDM + +:Authors: + +- Alexandre Torgue <alexandre.torgue@foss.st.com> diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index 3f9d86557c5e..52d060caf8bb 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -340,6 +340,16 @@ Before jumping into the kernel, the following conditions must be met: - SMCR_EL2.LEN must be initialised to the same value for all CPUs the kernel will execute on. + For CPUs with the Scalable Matrix Extension FA64 feature (FEAT_SME_FA64) + + - If EL3 is present: + + - SMCR_EL3.FA64 (bit 31) must be initialised to 0b1. + + - If the kernel is entered at EL1 and EL2 is present: + + - SMCR_EL2.FA64 (bit 31) must be initialised to 0b1. + The requirements described above for CPU mode, caches, MMUs, architected timers, coherency and system registers apply to all CPUs. All CPUs must enter the kernel in the same exception level. Where the values documented diff --git a/Documentation/arm64/cpu-feature-registers.rst b/Documentation/arm64/cpu-feature-registers.rst index 328e0c454fbd..9f9b8fd06089 100644 --- a/Documentation/arm64/cpu-feature-registers.rst +++ b/Documentation/arm64/cpu-feature-registers.rst @@ -235,7 +235,15 @@ infrastructure: | DPB | [3-0] | y | +------------------------------+---------+---------+ - 6) ID_AA64MMFR2_EL1 - Memory model feature register 2 + 6) ID_AA64MMFR0_EL1 - Memory model feature register 0 + + +------------------------------+---------+---------+ + | Name | bits | visible | + +------------------------------+---------+---------+ + | ECV | [63-60] | y | + +------------------------------+---------+---------+ + + 7) ID_AA64MMFR2_EL1 - Memory model feature register 2 +------------------------------+---------+---------+ | Name | bits | visible | @@ -243,7 +251,7 @@ infrastructure: | AT | [35-32] | y | +------------------------------+---------+---------+ - 7) ID_AA64ZFR0_EL1 - SVE feature ID register 0 + 8) ID_AA64ZFR0_EL1 - SVE feature ID register 0 +------------------------------+---------+---------+ | Name | bits | visible | diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst index ec1a5a63c1d0..af106af8e1c0 100644 --- a/Documentation/arm64/elf_hwcaps.rst +++ b/Documentation/arm64/elf_hwcaps.rst @@ -247,6 +247,10 @@ HWCAP2_MTE Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described by Documentation/arm64/memory-tagging-extension.rst. +HWCAP2_ECV + + Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001. + 4. Unused AT_HWCAP bits ----------------------- diff --git a/Documentation/arm64/pointer-authentication.rst b/Documentation/arm64/pointer-authentication.rst index f127666ea3a8..e5dad2e40aa8 100644 --- a/Documentation/arm64/pointer-authentication.rst +++ b/Documentation/arm64/pointer-authentication.rst @@ -53,11 +53,10 @@ The number of bits that the PAC occupies in a pointer is 55 minus the virtual address size configured by the kernel. For example, with a virtual address size of 48, the PAC is 7 bits wide. -Recent versions of GCC can compile code with APIAKey-based return -address protection when passed the -msign-return-address option. This -uses instructions in the HINT space (unless -march=armv8.3-a or higher -is also passed), and such code can run on systems without the pointer -authentication extension. +When ARM64_PTR_AUTH_KERNEL is selected, the kernel will be compiled +with HINT space pointer authentication instructions protecting +function returns. Kernels built with this option will work on hardware +with or without pointer authentication support. In addition to exec(), keys can also be reinitialized to random values using the PR_PAC_RESET_KEYS prctl. A bitmask of PR_PAC_APIAKEY, diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index d410a47ffa57..5342e895fb60 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst @@ -92,12 +92,24 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1349291 | N/A | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Neoverse-N2 | #2253138 | ARM64_ERRATUM_2253138 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | MMU-500 | #841119,826419 | N/A | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ diff --git a/Documentation/asm-annotations.rst b/Documentation/asm-annotations.rst index 76424e0431f4..f4bf0f6395fb 100644 --- a/Documentation/asm-annotations.rst +++ b/Documentation/asm-annotations.rst @@ -64,7 +64,7 @@ macros, it was decided that brand new macros should be introduced instead:: of importing all the crappy, historic, essentially randomly chosen debug symbol macro names from the binutils and older kernels? -.. _discussion: https://lkml.kernel.org/r/20170217104757.28588-1-jslaby@suse.cz +.. _discussion: https://lore.kernel.org/r/20170217104757.28588-1-jslaby@suse.cz Macros Description ------------------ diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 7f9b40d6b416..4d151fbe2058 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -1,5 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 +.. _inline_encryption: + ================= Inline Encryption ================= @@ -7,230 +9,269 @@ Inline Encryption Background ========== -Inline encryption hardware sits logically between memory and the disk, and can -en/decrypt data as it goes in/out of the disk. Inline encryption hardware has a -fixed number of "keyslots" - slots into which encryption contexts (i.e. the -encryption key, encryption algorithm, data unit size) can be programmed by the -kernel at any time. Each request sent to the disk can be tagged with the index -of a keyslot (and also a data unit number to act as an encryption tweak), and -the inline encryption hardware will en/decrypt the data in the request with the -encryption context programmed into that keyslot. This is very different from -full disk encryption solutions like self encrypting drives/TCG OPAL/ATA -Security standards, since with inline encryption, any block on disk could be -encrypted with any encryption context the kernel chooses. - +Inline encryption hardware sits logically between memory and disk, and can +en/decrypt data as it goes in/out of the disk. For each I/O request, software +can control exactly how the inline encryption hardware will en/decrypt the data +in terms of key, algorithm, data unit size (the granularity of en/decryption), +and data unit number (a value that determines the initialization vector(s)). + +Some inline encryption hardware accepts all encryption parameters including raw +keys directly in low-level I/O requests. However, most inline encryption +hardware instead has a fixed number of "keyslots" and requires that the key, +algorithm, and data unit size first be programmed into a keyslot. Each +low-level I/O request then just contains a keyslot index and data unit number. + +Note that inline encryption hardware is very different from traditional crypto +accelerators, which are supported through the kernel crypto API. Traditional +crypto accelerators operate on memory regions, whereas inline encryption +hardware operates on I/O requests. Thus, inline encryption hardware needs to be +managed by the block layer, not the kernel crypto API. + +Inline encryption hardware is also very different from "self-encrypting drives", +such as those based on the TCG Opal or ATA Security standards. Self-encrypting +drives don't provide fine-grained control of encryption and provide no way to +verify the correctness of the resulting ciphertext. Inline encryption hardware +provides fine-grained control of encryption, including the choice of key and +initialization vector for each sector, and can be tested for correctness. Objective ========= -We want to support inline encryption (IE) in the kernel. -To allow for testing, we also want a crypto API fallback when actual -IE hardware is absent. We also want IE to work with layered devices -like dm and loopback (i.e. we want to be able to use the IE hardware -of the underlying devices if present, or else fall back to crypto API -en/decryption). - +We want to support inline encryption in the kernel. To make testing easier, we +also want support for falling back to the kernel crypto API when actual inline +encryption hardware is absent. We also want inline encryption to work with +layered devices like device-mapper and loopback (i.e. we want to be able to use +the inline encryption hardware of the underlying devices if present, or else +fall back to crypto API en/decryption). Constraints and notes ===================== -- IE hardware has a limited number of "keyslots" that can be programmed - with an encryption context (key, algorithm, data unit size, etc.) at any time. - One can specify a keyslot in a data request made to the device, and the - device will en/decrypt the data using the encryption context programmed into - that specified keyslot. When possible, we want to make multiple requests with - the same encryption context share the same keyslot. - -- We need a way for upper layers like filesystems to specify an encryption - context to use for en/decrypting a struct bio, and a device driver (like UFS) - needs to be able to use that encryption context when it processes the bio. - -- We need a way for device drivers to expose their inline encryption - capabilities in a unified way to the upper layers. - - -Design -====== - -We add a struct bio_crypt_ctx to struct bio that can -represent an encryption context, because we need to be able to pass this -encryption context from the upper layers (like the fs layer) to the -device driver to act upon. - -While IE hardware works on the notion of keyslots, the FS layer has no -knowledge of keyslots - it simply wants to specify an encryption context to -use while en/decrypting a bio. - -We introduce a keyslot manager (KSM) that handles the translation from -encryption contexts specified by the FS to keyslots on the IE hardware. -This KSM also serves as the way IE hardware can expose its capabilities to -upper layers. The generic mode of operation is: each device driver that wants -to support IE will construct a KSM and set it up in its struct request_queue. -Upper layers that want to use IE on this device can then use this KSM in -the device's struct request_queue to translate an encryption context into -a keyslot. The presence of the KSM in the request queue shall be used to mean -that the device supports IE. - -The KSM uses refcounts to track which keyslots are idle (either they have no -encryption context programmed, or there are no in-flight struct bios -referencing that keyslot). When a new encryption context needs a keyslot, it -tries to find a keyslot that has already been programmed with the same -encryption context, and if there is no such keyslot, it evicts the least -recently used idle keyslot and programs the new encryption context into that -one. If no idle keyslots are available, then the caller will sleep until there -is at least one. - - -blk-mq changes, other block layer changes and blk-crypto-fallback -================================================================= - -We add a pointer to a ``bi_crypt_context`` and ``keyslot`` to -struct request. These will be referred to as the ``crypto fields`` -for the request. This ``keyslot`` is the keyslot into which the -``bi_crypt_context`` has been programmed in the KSM of the ``request_queue`` -that this request is being sent to. - -We introduce ``block/blk-crypto-fallback.c``, which allows upper layers to remain -blissfully unaware of whether or not real inline encryption hardware is present -underneath. When a bio is submitted with a target ``request_queue`` that doesn't -support the encryption context specified with the bio, the block layer will -en/decrypt the bio with the blk-crypto-fallback. - -If the bio is a ``WRITE`` bio, a bounce bio is allocated, and the data in the bio -is encrypted stored in the bounce bio - blk-mq will then proceed to process the -bounce bio as if it were not encrypted at all (except when blk-integrity is -concerned). ``blk-crypto-fallback`` sets the bounce bio's ``bi_end_io`` to an -internal function that cleans up the bounce bio and ends the original bio. - -If the bio is a ``READ`` bio, the bio's ``bi_end_io`` (and also ``bi_private``) -is saved and overwritten by ``blk-crypto-fallback`` to -``bio_crypto_fallback_decrypt_bio``. The bio's ``bi_crypt_context`` is also -overwritten with ``NULL``, so that to the rest of the stack, the bio looks -as if it was a regular bio that never had an encryption context specified. -``bio_crypto_fallback_decrypt_bio`` will decrypt the bio, restore the original -``bi_end_io`` (and also ``bi_private``) and end the bio again. - -Regardless of whether real inline encryption hardware is used or the +- We need a way for upper layers (e.g. filesystems) to specify an encryption + context to use for en/decrypting a bio, and device drivers (e.g. UFSHCD) need + to be able to use that encryption context when they process the request. + Encryption contexts also introduce constraints on bio merging; the block layer + needs to be aware of these constraints. + +- Different inline encryption hardware has different supported algorithms, + supported data unit sizes, maximum data unit numbers, etc. We call these + properties the "crypto capabilities". We need a way for device drivers to + advertise crypto capabilities to upper layers in a generic way. + +- Inline encryption hardware usually (but not always) requires that keys be + programmed into keyslots before being used. Since programming keyslots may be + slow and there may not be very many keyslots, we shouldn't just program the + key for every I/O request, but rather keep track of which keys are in the + keyslots and reuse an already-programmed keyslot when possible. + +- Upper layers typically define a specific end-of-life for crypto keys, e.g. + when an encrypted directory is locked or when a crypto mapping is torn down. + At these times, keys are wiped from memory. We must provide a way for upper + layers to also evict keys from any keyslots they are present in. + +- When possible, device-mapper devices must be able to pass through the inline + encryption support of their underlying devices. However, it doesn't make + sense for device-mapper devices to have keyslots themselves. + +Basic design +============ + +We introduce ``struct blk_crypto_key`` to represent an inline encryption key and +how it will be used. This includes the actual bytes of the key; the size of the +key; the algorithm and data unit size the key will be used with; and the number +of bytes needed to represent the maximum data unit number the key will be used +with. + +We introduce ``struct bio_crypt_ctx`` to represent an encryption context. It +contains a data unit number and a pointer to a blk_crypto_key. We add pointers +to a bio_crypt_ctx to ``struct bio`` and ``struct request``; this allows users +of the block layer (e.g. filesystems) to provide an encryption context when +creating a bio and have it be passed down the stack for processing by the block +layer and device drivers. Note that the encryption context doesn't explicitly +say whether to encrypt or decrypt, as that is implicit from the direction of the +bio; WRITE means encrypt, and READ means decrypt. + +We also introduce ``struct blk_crypto_profile`` to contain all generic inline +encryption-related state for a particular inline encryption device. The +blk_crypto_profile serves as the way that drivers for inline encryption hardware +advertise their crypto capabilities and provide certain functions (e.g., +functions to program and evict keys) to upper layers. Each device driver that +wants to support inline encryption will construct a blk_crypto_profile, then +associate it with the disk's request_queue. + +The blk_crypto_profile also manages the hardware's keyslots, when applicable. +This happens in the block layer, so that users of the block layer can just +specify encryption contexts and don't need to know about keyslots at all, nor do +device drivers need to care about most details of keyslot management. + +Specifically, for each keyslot, the block layer (via the blk_crypto_profile) +keeps track of which blk_crypto_key that keyslot contains (if any), and how many +in-flight I/O requests are using it. When the block layer creates a +``struct request`` for a bio that has an encryption context, it grabs a keyslot +that already contains the key if possible. Otherwise it waits for an idle +keyslot (a keyslot that isn't in-use by any I/O), then programs the key into the +least-recently-used idle keyslot using the function the device driver provided. +In both cases, the resulting keyslot is stored in the ``crypt_keyslot`` field of +the request, where it is then accessible to device drivers and is released after +the request completes. + +``struct request`` also contains a pointer to the original bio_crypt_ctx. +Requests can be built from multiple bios, and the block layer must take the +encryption context into account when trying to merge bios and requests. For two +bios/requests to be merged, they must have compatible encryption contexts: both +unencrypted, or both encrypted with the same key and contiguous data unit +numbers. Only the encryption context for the first bio in a request is +retained, since the remaining bios have been verified to be merge-compatible +with the first bio. + +To make it possible for inline encryption to work with request_queue based +layered devices, when a request is cloned, its encryption context is cloned as +well. When the cloned request is submitted, it is then processed as usual; this +includes getting a keyslot from the clone's target device if needed. + +blk-crypto-fallback +=================== + +It is desirable for the inline encryption support of upper layers (e.g. +filesystems) to be testable without real inline encryption hardware, and +likewise for the block layer's keyslot management logic. It is also desirable +to allow upper layers to just always use inline encryption rather than have to +implement encryption in multiple ways. + +Therefore, we also introduce *blk-crypto-fallback*, which is an implementation +of inline encryption using the kernel crypto API. blk-crypto-fallback is built +into the block layer, so it works on any block device without any special setup. +Essentially, when a bio with an encryption context is submitted to a +request_queue that doesn't support that encryption context, the block layer will +handle en/decryption of the bio using blk-crypto-fallback. + +For encryption, the data cannot be encrypted in-place, as callers usually rely +on it being unmodified. Instead, blk-crypto-fallback allocates bounce pages, +fills a new bio with those bounce pages, encrypts the data into those bounce +pages, and submits that "bounce" bio. When the bounce bio completes, +blk-crypto-fallback completes the original bio. If the original bio is too +large, multiple bounce bios may be required; see the code for details. + +For decryption, blk-crypto-fallback "wraps" the bio's completion callback +(``bi_complete``) and private data (``bi_private``) with its own, unsets the +bio's encryption context, then submits the bio. If the read completes +successfully, blk-crypto-fallback restores the bio's original completion +callback and private data, then decrypts the bio's data in-place using the +kernel crypto API. Decryption happens from a workqueue, as it may sleep. +Afterwards, blk-crypto-fallback completes the bio. + +In both cases, the bios that blk-crypto-fallback submits no longer have an +encryption context. Therefore, lower layers only see standard unencrypted I/O. + +blk-crypto-fallback also defines its own blk_crypto_profile and has its own +"keyslots"; its keyslots contain ``struct crypto_skcipher`` objects. The reason +for this is twofold. First, it allows the keyslot management logic to be tested +without actual inline encryption hardware. Second, similar to actual inline +encryption hardware, the crypto API doesn't accept keys directly in requests but +rather requires that keys be set ahead of time, and setting keys can be +expensive; moreover, allocating a crypto_skcipher can't happen on the I/O path +at all due to the locks it takes. Therefore, the concept of keyslots still +makes sense for blk-crypto-fallback. + +Note that regardless of whether real inline encryption hardware or blk-crypto-fallback is used, the ciphertext written to disk (and hence the -on-disk format of data) will be the same (assuming the hardware's implementation -of the algorithm being used adheres to spec and functions correctly). - -If a ``request queue``'s inline encryption hardware claimed to support the -encryption context specified with a bio, then it will not be handled by the -``blk-crypto-fallback``. We will eventually reach a point in blk-mq when a -struct request needs to be allocated for that bio. At that point, -blk-mq tries to program the encryption context into the ``request_queue``'s -keyslot_manager, and obtain a keyslot, which it stores in its newly added -``keyslot`` field. This keyslot is released when the request is completed. - -When the first bio is added to a request, ``blk_crypto_rq_bio_prep`` is called, -which sets the request's ``crypt_ctx`` to a copy of the bio's -``bi_crypt_context``. bio_crypt_do_front_merge is called whenever a subsequent -bio is merged to the front of the request, which updates the ``crypt_ctx`` of -the request so that it matches the newly merged bio's ``bi_crypt_context``. In particular, the request keeps a copy of the ``bi_crypt_context`` of the first -bio in its bio-list (blk-mq needs to be careful to maintain this invariant -during bio and request merges). - -To make it possible for inline encryption to work with request queue based -layered devices, when a request is cloned, its ``crypto fields`` are cloned as -well. When the cloned request is submitted, blk-mq programs the -``bi_crypt_context`` of the request into the clone's request_queue's keyslot -manager, and stores the returned keyslot in the clone's ``keyslot``. +on-disk format of data) will be the same (assuming that both the inline +encryption hardware's implementation and the kernel crypto API's implementation +of the algorithm being used adhere to spec and function correctly). +blk-crypto-fallback is optional and is controlled by the +``CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK`` kernel configuration option. API presented to users of the block layer ========================================= -``struct blk_crypto_key`` represents a crypto key (the raw key, size of the -key, the crypto algorithm to use, the data unit size to use, and the number of -bytes required to represent data unit numbers that will be specified with the -``bi_crypt_context``). - -``blk_crypto_init_key`` allows upper layers to initialize such a -``blk_crypto_key``. - -``bio_crypt_set_ctx`` should be called on any bio that a user of -the block layer wants en/decrypted via inline encryption (or the -blk-crypto-fallback, if hardware support isn't available for the desired -crypto configuration). This function takes the ``blk_crypto_key`` and the -data unit number (DUN) to use when en/decrypting the bio. - -``blk_crypto_config_supported`` allows upper layers to query whether or not the -an encryption context passed to request queue can be handled by blk-crypto -(either by real inline encryption hardware, or by the blk-crypto-fallback). -This is useful e.g. when blk-crypto-fallback is disabled, and the upper layer -wants to use an algorithm that may not supported by hardware - this function -lets the upper layer know ahead of time that the algorithm isn't supported, -and the upper layer can fallback to something else if appropriate. - -``blk_crypto_start_using_key`` - Upper layers must call this function on -``blk_crypto_key`` and a ``request_queue`` before using the key with any bio -headed for that ``request_queue``. This function ensures that either the -hardware supports the key's crypto settings, or the crypto API fallback has -transforms for the needed mode allocated and ready to go. Note that this -function may allocate an ``skcipher``, and must not be called from the data -path, since allocating ``skciphers`` from the data path can deadlock. - -``blk_crypto_evict_key`` *must* be called by upper layers before a -``blk_crypto_key`` is freed. Further, it *must* only be called only once -there are no more in-flight requests that use that ``blk_crypto_key``. -``blk_crypto_evict_key`` will ensure that a key is removed from any keyslots in -inline encryption hardware that the key might have been programmed into (or the blk-crypto-fallback). +``blk_crypto_config_supported()`` allows users to check ahead of time whether +inline encryption with particular crypto settings will work on a particular +request_queue -- either via hardware or via blk-crypto-fallback. This function +takes in a ``struct blk_crypto_config`` which is like blk_crypto_key, but omits +the actual bytes of the key and instead just contains the algorithm, data unit +size, etc. This function can be useful if blk-crypto-fallback is disabled. + +``blk_crypto_init_key()`` allows users to initialize a blk_crypto_key. + +Users must call ``blk_crypto_start_using_key()`` before actually starting to use +a blk_crypto_key on a request_queue (even if ``blk_crypto_config_supported()`` +was called earlier). This is needed to initialize blk-crypto-fallback if it +will be needed. This must not be called from the data path, as this may have to +allocate resources, which may deadlock in that case. + +Next, to attach an encryption context to a bio, users should call +``bio_crypt_set_ctx()``. This function allocates a bio_crypt_ctx and attaches +it to a bio, given the blk_crypto_key and the data unit number that will be used +for en/decryption. Users don't need to worry about freeing the bio_crypt_ctx +later, as that happens automatically when the bio is freed or reset. + +Finally, when done using inline encryption with a blk_crypto_key on a +request_queue, users must call ``blk_crypto_evict_key()``. This ensures that +the key is evicted from all keyslots it may be programmed into and unlinked from +any kernel data structures it may be linked into. + +In summary, for users of the block layer, the lifecycle of a blk_crypto_key is +as follows: + +1. ``blk_crypto_config_supported()`` (optional) +2. ``blk_crypto_init_key()`` +3. ``blk_crypto_start_using_key()`` +4. ``bio_crypt_set_ctx()`` (potentially many times) +5. ``blk_crypto_evict_key()`` (after all I/O has completed) +6. Zeroize the blk_crypto_key (this has no dedicated function) + +If a blk_crypto_key is being used on multiple request_queues, then +``blk_crypto_config_supported()`` (if used), ``blk_crypto_start_using_key()``, +and ``blk_crypto_evict_key()`` must be called on each request_queue. API presented to device drivers =============================== -A :c:type:``struct blk_keyslot_manager`` should be set up by device drivers in -the ``request_queue`` of the device. The device driver needs to call -``blk_ksm_init`` (or its resource-managed variant ``devm_blk_ksm_init``) on the -``blk_keyslot_manager``, while specifying the number of keyslots supported by -the hardware. - -The device driver also needs to tell the KSM how to actually manipulate the -IE hardware in the device to do things like programming the crypto key into -the IE hardware into a particular keyslot. All this is achieved through the -struct blk_ksm_ll_ops field in the KSM that the device driver -must fill up after initing the ``blk_keyslot_manager``. - -The KSM also handles runtime power management for the device when applicable -(e.g. when it wants to program a crypto key into the IE hardware, the device -must be runtime powered on) - so the device driver must also set the ``dev`` -field in the ksm to point to the `struct device` for the KSM to use for runtime -power management. - -``blk_ksm_reprogram_all_keys`` can be called by device drivers if the device -needs each and every of its keyslots to be reprogrammed with the key it -"should have" at the point in time when the function is called. This is useful -e.g. if a device loses all its keys on runtime power down/up. - -If the driver used ``blk_ksm_init`` instead of ``devm_blk_ksm_init``, then -``blk_ksm_destroy`` should be called to free up all resources used by a -``blk_keyslot_manager`` once it is no longer needed. +A device driver that wants to support inline encryption must set up a +blk_crypto_profile in the request_queue of its device. To do this, it first +must call ``blk_crypto_profile_init()`` (or its resource-managed variant +``devm_blk_crypto_profile_init()``), providing the number of keyslots. + +Next, it must advertise its crypto capabilities by setting fields in the +blk_crypto_profile, e.g. ``modes_supported`` and ``max_dun_bytes_supported``. + +It then must set function pointers in the ``ll_ops`` field of the +blk_crypto_profile to tell upper layers how to control the inline encryption +hardware, e.g. how to program and evict keyslots. Most drivers will need to +implement ``keyslot_program`` and ``keyslot_evict``. For details, see the +comments for ``struct blk_crypto_ll_ops``. + +Once the driver registers a blk_crypto_profile with a request_queue, I/O +requests the driver receives via that queue may have an encryption context. All +encryption contexts will be compatible with the crypto capabilities declared in +the blk_crypto_profile, so drivers don't need to worry about handling +unsupported requests. Also, if a nonzero number of keyslots was declared in the +blk_crypto_profile, then all I/O requests that have an encryption context will +also have a keyslot which was already programmed with the appropriate key. + +If the driver implements runtime suspend and its blk_crypto_ll_ops don't work +while the device is runtime-suspended, then the driver must also set the ``dev`` +field of the blk_crypto_profile to point to the ``struct device`` that will be +resumed before any of the low-level operations are called. + +If there are situations where the inline encryption hardware loses the contents +of its keyslots, e.g. device resets, the driver must handle reprogramming the +keyslots. To do this, the driver may call ``blk_crypto_reprogram_all_keys()``. + +Finally, if the driver used ``blk_crypto_profile_init()`` instead of +``devm_blk_crypto_profile_init()``, then it is responsible for calling +``blk_crypto_profile_destroy()`` when the crypto profile is no longer needed. Layered Devices =============== -Request queue based layered devices like dm-rq that wish to support IE need to -create their own keyslot manager for their request queue, and expose whatever -functionality they choose. When a layered device wants to pass a clone of that -request to another ``request_queue``, blk-crypto will initialize and prepare the -clone as necessary - see ``blk_crypto_insert_cloned_request`` in -``blk-crypto.c``. - - -Future Optimizations for layered devices -======================================== - -Creating a keyslot manager for a layered device uses up memory for each -keyslot, and in general, a layered device merely passes the request on to a -"child" device, so the keyslots in the layered device itself are completely -unused, and don't need any refcounting or keyslot programming. We can instead -define a new type of KSM; the "passthrough KSM", that layered devices can use -to advertise an unlimited number of keyslots, and support for any encryption -algorithms they choose, while not actually using any memory for each keyslot. -Another use case for the "passthrough KSM" is for IE devices that do not have a -limited number of keyslots. - +Request queue based layered devices like dm-rq that wish to support inline +encryption need to create their own blk_crypto_profile for their request_queue, +and expose whatever functionality they choose. When a layered device wants to +pass a clone of that request to another request_queue, blk-crypto will +initialize and prepare the clone as necessary; see +``blk_crypto_insert_cloned_request()``. Interaction between inline encryption and blk integrity ======================================================= @@ -257,7 +298,7 @@ Because there isn't any real hardware yet, it seems prudent to assume that hardware implementations might not implement both features together correctly, and disallow the combination for now. Whenever a device supports integrity, the kernel will pretend that the device does not support hardware inline encryption -(by essentially setting the keyslot manager in the request_queue of the device -to NULL). When the crypto API fallback is enabled, this means that all bios with -and encryption context will use the fallback, and IO will complete as usual. -When the fallback is disabled, a bio with an encryption context will be failed. +(by setting the blk_crypto_profile in the request_queue of the device to NULL). +When the crypto API fallback is enabled, this means that all bios with and +encryption context will use the fallback, and IO will complete as usual. When +the fallback is disabled, a bio with an encryption context will be failed. diff --git a/Documentation/block/queue-sysfs.rst b/Documentation/block/queue-sysfs.rst index 4dc7f0d499a8..3f569d532485 100644 --- a/Documentation/block/queue-sysfs.rst +++ b/Documentation/block/queue-sysfs.rst @@ -4,7 +4,7 @@ Queue sysfs files This text file will detail the queue files that are located in the sysfs tree for each block device. Note that stacked devices typically do not export -any settings, since their queue merely functions are a remapping target. +any settings, since their queue merely functions as a remapping target. These files are the ones found in the /sys/block/xxx/queue/ directory. Files denoted with a RO postfix are readonly and the RW postfix means @@ -40,10 +40,11 @@ discard_max_hw_bytes (RO) ------------------------- Devices that support discard functionality may have internal limits on the number of bytes that can be trimmed or unmapped in a single operation. -The discard_max_bytes parameter is set by the device driver to the maximum -number of bytes that can be discarded in a single operation. Discard -requests issued to the device must not exceed this limit. A discard_max_bytes -value of 0 means that the device does not support discard functionality. +The `discard_max_hw_bytes` parameter is set by the device driver to the +maximum number of bytes that can be discarded in a single operation. +Discard requests issued to the device must not exceed this limit. +A `discard_max_hw_bytes` value of 0 means that the device does not support +discard functionality. discard_max_bytes (RW) ---------------------- @@ -286,4 +287,35 @@ sequential zones of zoned block devices (devices with a zoned attributed that reports "host-managed" or "host-aware"). This value is always 0 for regular block devices. +independent_access_ranges (RO) +------------------------------ + +The presence of this sub-directory of the /sys/block/xxx/queue/ directory +indicates that the device is capable of executing requests targeting +different sector ranges in parallel. For instance, single LUN multi-actuator +hard-disks will have an independent_access_ranges directory if the device +correctly advertizes the sector ranges of its actuators. + +The independent_access_ranges directory contains one directory per access +range, with each range described using the sector (RO) attribute file to +indicate the first sector of the range and the nr_sectors (RO) attribute file +to indicate the total number of sectors in the range starting from the first +sector of the range. For example, a dual-actuator hard-disk will have the +following independent_access_ranges entries.:: + + $ tree /sys/block/<device>/queue/independent_access_ranges/ + /sys/block/<device>/queue/independent_access_ranges/ + |-- 0 + | |-- nr_sectors + | `-- sector + `-- 1 + |-- nr_sectors + `-- sector + +The sector and nr_sectors attributes use 512B sector unit, regardless of +the actual block size of the device. Independent access ranges do not +overlap and include all sectors within the device capacity. The access +ranges are numbered in increasing order of the range start sector, +that is, the sector attribute of range 0 always has the value 0. + Jens Axboe <jens.axboe@oracle.com>, February 2009 diff --git a/Documentation/bpf/bpf_licensing.rst b/Documentation/bpf/bpf_licensing.rst new file mode 100644 index 000000000000..b19c433f41d2 --- /dev/null +++ b/Documentation/bpf/bpf_licensing.rst @@ -0,0 +1,92 @@ +============= +BPF licensing +============= + +Background +========== + +* Classic BPF was BSD licensed + +"BPF" was originally introduced as BSD Packet Filter in +http://www.tcpdump.org/papers/bpf-usenix93.pdf. The corresponding instruction +set and its implementation came from BSD with BSD license. That original +instruction set is now known as "classic BPF". + +However an instruction set is a specification for machine-language interaction, +similar to a programming language. It is not a code. Therefore, the +application of a BSD license may be misleading in a certain context, as the +instruction set may enjoy no copyright protection. + +* eBPF (extended BPF) instruction set continues to be BSD + +In 2014, the classic BPF instruction set was significantly extended. We +typically refer to this instruction set as eBPF to disambiguate it from cBPF. +The eBPF instruction set is still BSD licensed. + +Implementations of eBPF +======================= + +Using the eBPF instruction set requires implementing code in both kernel space +and user space. + +In Linux Kernel +--------------- + +The reference implementations of the eBPF interpreter and various just-in-time +compilers are part of Linux and are GPLv2 licensed. The implementation of +eBPF helper functions is also GPLv2 licensed. Interpreters, JITs, helpers, +and verifiers are called eBPF runtime. + +In User Space +------------- + +There are also implementations of eBPF runtime (interpreter, JITs, helper +functions) under +Apache2 (https://github.com/iovisor/ubpf), +MIT (https://github.com/qmonnet/rbpf), and +BSD (https://github.com/DPDK/dpdk/blob/main/lib/librte_bpf). + +In HW +----- + +The HW can choose to execute eBPF instruction natively and provide eBPF runtime +in HW or via the use of implementing firmware with a proprietary license. + +In other operating systems +-------------------------- + +Other kernels or user space implementations of eBPF instruction set and runtime +can have proprietary licenses. + +Using BPF programs in the Linux kernel +====================================== + +Linux Kernel (while being GPLv2) allows linking of proprietary kernel modules +under these rules: +Documentation/process/license-rules.rst + +When a kernel module is loaded, the linux kernel checks which functions it +intends to use. If any function is marked as "GPL only," the corresponding +module or program has to have GPL compatible license. + +Loading BPF program into the Linux kernel is similar to loading a kernel +module. BPF is loaded at run time and not statically linked to the Linux +kernel. BPF program loading follows the same license checking rules as kernel +modules. BPF programs can be proprietary if they don't use "GPL only" BPF +helper functions. + +Further, some BPF program types - Linux Security Modules (LSM) and TCP +Congestion Control (struct_ops), as of Aug 2021 - are required to be GPL +compatible even if they don't use "GPL only" helper functions directly. The +registration step of LSM and TCP congestion control modules of the Linux +kernel is done through EXPORT_SYMBOL_GPL kernel functions. In that sense LSM +and struct_ops BPF programs are implicitly calling "GPL only" functions. +The same restriction applies to BPF programs that call kernel functions +directly via unstable interface also known as "kfunc". + +Packaging BPF programs with user space applications +==================================================== + +Generally, proprietary-licensed applications and GPL licensed BPF programs +written for the Linux kernel in the same package can co-exist because they are +separate executable processes. This applies to both cBPF and eBPF programs. diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst index 846354cd2d69..9ad4218a751f 100644 --- a/Documentation/bpf/btf.rst +++ b/Documentation/bpf/btf.rst @@ -85,6 +85,7 @@ sequentially and type id is assigned to each recognized type starting from id #define BTF_KIND_VAR 14 /* Variable */ #define BTF_KIND_DATASEC 15 /* Section */ #define BTF_KIND_FLOAT 16 /* Floating point */ + #define BTF_KIND_DECL_TAG 17 /* Decl Tag */ Note that the type section encodes debug info, not just pure types. ``BTF_KIND_FUNC`` is not a type, and it represents a defined subprogram. @@ -106,7 +107,7 @@ Each type contains the following common data:: * "size" tells the size of the type it is describing. * * "type" is used by PTR, TYPEDEF, VOLATILE, CONST, RESTRICT, - * FUNC and FUNC_PROTO. + * FUNC, FUNC_PROTO and DECL_TAG. * "type" is a type_id referring to another type. */ union { @@ -465,6 +466,32 @@ map definition. No additional type data follow ``btf_type``. +2.2.17 BTF_KIND_DECL_TAG +~~~~~~~~~~~~~~~~~~~~~~~~ + +``struct btf_type`` encoding requirement: + * ``name_off``: offset to a non-empty string + * ``info.kind_flag``: 0 + * ``info.kind``: BTF_KIND_DECL_TAG + * ``info.vlen``: 0 + * ``type``: ``struct``, ``union``, ``func``, ``var`` or ``typedef`` + +``btf_type`` is followed by ``struct btf_decl_tag``.:: + + struct btf_decl_tag { + __u32 component_idx; + }; + +The ``name_off`` encodes btf_decl_tag attribute string. +The ``type`` should be ``struct``, ``union``, ``func``, ``var`` or ``typedef``. +For ``var`` or ``typedef`` type, ``btf_decl_tag.component_idx`` must be ``-1``. +For the other three types, if the btf_decl_tag attribute is +applied to the ``struct``, ``union`` or ``func`` itself, +``btf_decl_tag.component_idx`` must be ``-1``. Otherwise, +the attribute is applied to a ``struct``/``union`` member or +a ``func`` argument, and ``btf_decl_tag.component_idx`` should be a +valid index (starting from 0) pointing to a member or an argument. + 3. BTF Kernel API ***************** diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index 1ceb5d704a97..610450f59e05 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -15,7 +15,7 @@ that goes into great technical depth about the BPF Architecture. libbpf ====== -Documentation/bpf/libbpf/libbpf.rst is a userspace library for loading and interacting with bpf programs. +Documentation/bpf/libbpf/index.rst is a userspace library for loading and interacting with bpf programs. BPF Type Format (BTF) ===================== @@ -82,6 +82,15 @@ Testing and debugging BPF s390 +Licensing +========= + +.. toctree:: + :maxdepth: 1 + + bpf_licensing + + Other ===== diff --git a/Documentation/bpf/libbpf/libbpf_naming_convention.rst b/Documentation/bpf/libbpf/libbpf_naming_convention.rst index 9c68d5014ff1..f86360f734a8 100644 --- a/Documentation/bpf/libbpf/libbpf_naming_convention.rst +++ b/Documentation/bpf/libbpf/libbpf_naming_convention.rst @@ -150,6 +150,46 @@ mirror of the mainline's version of libbpf for a stand-alone build. However, all changes to libbpf's code base must be upstreamed through the mainline kernel tree. + +API documentation convention +============================ + +The libbpf API is documented via comments above definitions in +header files. These comments can be rendered by doxygen and sphinx +for well organized html output. This section describes the +convention in which these comments should be formated. + +Here is an example from btf.h: + +.. code-block:: c + + /** + * @brief **btf__new()** creates a new instance of a BTF object from the raw + * bytes of an ELF's BTF section + * @param data raw bytes + * @param size number of bytes passed in `data` + * @return new BTF object instance which has to be eventually freed with + * **btf__free()** + * + * On error, error-code-encoded-as-pointer is returned, not a NULL. To extract + * error code from such a pointer `libbpf_get_error()` should be used. If + * `libbpf_set_strict_mode(LIBBPF_STRICT_CLEAN_PTRS)` is enabled, NULL is + * returned on error instead. In both cases thread-local `errno` variable is + * always set to error code as well. + */ + +The comment must start with a block comment of the form '/\*\*'. + +The documentation always starts with a @brief directive. This line is a short +description about this API. It starts with the name of the API, denoted in bold +like so: **api_name**. Please include an open and close parenthesis if this is a +function. Follow with the short description of the API. A longer form description +can be added below the last directive, at the bottom of the comment. + +Parameters are denoted with the @param directive, there should be one for each +parameter. If this is a function with a non-void return, use the @return directive +to document it. + License ------------------- diff --git a/Documentation/cdrom/cdrom-standard.rst b/Documentation/cdrom/cdrom-standard.rst index 5845960ca382..52ea7b6b2fe8 100644 --- a/Documentation/cdrom/cdrom-standard.rst +++ b/Documentation/cdrom/cdrom-standard.rst @@ -907,6 +907,17 @@ commands can be identified by the underscores in their names. specifies the slot for which the information is given. The special value *CDSL_CURRENT* requests that information about the currently selected slot be returned. +`CDROM_TIMED_MEDIA_CHANGE` + Checks whether the disc has been changed since a user supplied time + and returns the time of the last disc change. + + *arg* is a pointer to a *cdrom_timed_media_change_info* struct. + *arg->last_media_change* may be set by calling code to signal + the timestamp of the last known media change (by the caller). + Upon successful return, this ioctl call will set + *arg->last_media_change* to the latest media change timestamp (in ms) + known by the kernel/driver and set *arg->has_changed* to 1 if + that timestamp is more recent than the timestamp set by the caller. `CDROM_DRIVE_STATUS` Returns the status of the drive by a call to *drive_status()*. Return values are defined in cdrom_drive_status_. diff --git a/Documentation/conf.py b/Documentation/conf.py index 948a97d6387d..17f7cee56987 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -353,6 +353,9 @@ latex_elements = { \\setsansfont{DejaVu Sans} \\setromanfont{DejaVu Serif} \\setmonofont{DejaVu Sans Mono} + % Adjust \\headheight for fancyhdr + \\addtolength{\\headheight}{1.6pt} + \\addtolength{\\topmargin}{-1.6pt} ''', } diff --git a/Documentation/core-api/cachetlb.rst b/Documentation/core-api/cachetlb.rst index 8aed9103e48a..5c0552e78c58 100644 --- a/Documentation/core-api/cachetlb.rst +++ b/Documentation/core-api/cachetlb.rst @@ -326,6 +326,12 @@ maps this page at its virtual address. dirty. Again, see sparc64 for examples of how to deal with this. + ``void flush_dcache_folio(struct folio *folio)`` + This function is called under the same circumstances as + flush_dcache_page(). It allows the architecture to + optimise for flushing the entire folio of pages instead + of flushing one page at a time. + ``void copy_to_user_page(struct vm_area_struct *vma, struct page *page, unsigned long user_vaddr, void *dst, void *src, int len)`` ``void copy_from_user_page(struct vm_area_struct *vma, struct page *page, diff --git a/Documentation/core-api/irq/irq-domain.rst b/Documentation/core-api/irq/irq-domain.rst index 9c0e8758037a..d30b4d0a9769 100644 --- a/Documentation/core-api/irq/irq-domain.rst +++ b/Documentation/core-api/irq/irq-domain.rst @@ -67,9 +67,6 @@ variety of methods: deprecated - generic_handle_domain_irq() handles an interrupt described by a domain and a hwirq number -- handle_domain_irq() does the same thing for root interrupt - controllers and deals with the set_irq_reg()/irq_enter() sequences - that most architecture requires Note that irq domain lookups must happen in contexts that are compatible with a RCU read-side critical section. diff --git a/Documentation/core-api/memory-hotplug.rst b/Documentation/core-api/memory-hotplug.rst index de7467e48067..682259ee633a 100644 --- a/Documentation/core-api/memory-hotplug.rst +++ b/Documentation/core-api/memory-hotplug.rst @@ -57,7 +57,6 @@ The third argument (arg) passes a pointer of struct memory_notify:: unsigned long start_pfn; unsigned long nr_pages; int status_change_nid_normal; - int status_change_nid_high; int status_change_nid; } @@ -65,8 +64,6 @@ The third argument (arg) passes a pointer of struct memory_notify:: - nr_pages is # of pages of online/offline memory. - status_change_nid_normal is set node id when N_NORMAL_MEMORY of nodemask is (will be) set/clear, if this is -1, then nodemask status is not changed. -- status_change_nid_high is set node id when N_HIGH_MEMORY of nodemask - is (will be) set/clear, if this is -1, then nodemask status is not changed. - status_change_nid is set node id when N_MEMORY of nodemask is (will be) set/clear. It means a new(memoryless) node gets new memory by online and a node loses all memory. If this is -1, then nodemask status is not changed. diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-api.rst index a42f9baddfbf..395835f9289f 100644 --- a/Documentation/core-api/mm-api.rst +++ b/Documentation/core-api/mm-api.rst @@ -95,6 +95,11 @@ More Memory Management Functions .. kernel-doc:: mm/mempolicy.c .. kernel-doc:: include/linux/mm_types.h :internal: +.. kernel-doc:: include/linux/mm_inline.h +.. kernel-doc:: include/linux/page-flags.h .. kernel-doc:: include/linux/mm.h :internal: +.. kernel-doc:: include/linux/page_ref.h .. kernel-doc:: include/linux/mmzone.h +.. kernel-doc:: mm/util.c + :functions: folio_mapping diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index e08bbe9b0cbf..5e89497ba314 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -580,7 +580,7 @@ Flags bitfields such as page flags, gfp_flags :: - %pGp referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff + %pGp 0x17ffffc0002036(referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff) %pGg GFP_USER|GFP_DMA32|GFP_NOWARN %pGv read|exec|mayread|maywrite|mayexec|denywrite diff --git a/Documentation/core-api/workqueue.rst b/Documentation/core-api/workqueue.rst index 541d31de8926..3b22ed137662 100644 --- a/Documentation/core-api/workqueue.rst +++ b/Documentation/core-api/workqueue.rst @@ -216,10 +216,6 @@ resources, scheduled and executed. This flag is meaningless for unbound wq. -Note that the flag ``WQ_NON_REENTRANT`` no longer exists as all -workqueues are now non-reentrant - any work item is guaranteed to be -executed by at most one worker system-wide at any given time. - ``max_active`` -------------- @@ -391,6 +387,23 @@ the stack trace of the offending worker thread. :: The work item's function should be trivially visible in the stack trace. +Non-reentrance Conditions +========================= + +Workqueue guarantees that a work item cannot be re-entrant if the following +conditions hold after a work item gets queued: + + 1. The work function hasn't been changed. + 2. No one queues the work item to another workqueue. + 3. The work item hasn't been reinitiated. + +In other words, if the above conditions hold, the work item is guaranteed to be +executed by at most one worker system-wide at any given time. + +Note that requeuing the work item (to the same queue) in the self function +doesn't break these conditions, so it's safe to do. Otherwise, caution is +required when breaking the conditions inside a work function. + Kernel Inline Documentations Reference ====================================== diff --git a/Documentation/cpu-freq/core.rst b/Documentation/cpu-freq/core.rst index 33cb90bd1d8f..4ceef8e7217c 100644 --- a/Documentation/cpu-freq/core.rst +++ b/Documentation/cpu-freq/core.rst @@ -73,12 +73,12 @@ CPUFREQ_POSTCHANGE. The third argument is a struct cpufreq_freqs with the following values: -===== =========================== -cpu number of the affected CPU +====== ====================================== +policy a pointer to the struct cpufreq_policy old old frequency new new frequency flags flags of the cpufreq driver -===== =========================== +====== ====================================== 3. CPUFreq Table Generation with Operating Performance Point (OPP) ================================================================== diff --git a/Documentation/crypto/crypto_engine.rst b/Documentation/crypto/crypto_engine.rst index 25cf9836c336..d562ea17d994 100644 --- a/Documentation/crypto/crypto_engine.rst +++ b/Documentation/crypto/crypto_engine.rst @@ -69,6 +69,8 @@ the crypto engine via one of: * crypto_transfer_hash_request_to_engine() +* crypto_transfer_kpp_request_to_engine() + * crypto_transfer_skcipher_request_to_engine() At the end of the request process, a call to one of the following functions is needed: @@ -79,4 +81,6 @@ At the end of the request process, a call to one of the following functions is n * crypto_finalize_hash_request() +* crypto_finalize_kpp_request() + * crypto_finalize_skcipher_request() diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst index f0956e9ea2d8..b52452bc2963 100644 --- a/Documentation/dev-tools/checkpatch.rst +++ b/Documentation/dev-tools/checkpatch.rst @@ -710,6 +710,39 @@ Indentation and Line Breaks See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings + **SPLIT_STRING** + Quoted strings that appear as messages in userspace and can be + grepped, should not be split across multiple lines. + + See: https://lore.kernel.org/lkml/20120203052727.GA15035@leaf/ + + **MULTILINE_DEREFERENCE** + A single dereferencing identifier spanned on multiple lines like:: + + struct_identifier->member[index]. + member = <foo>; + + is generally hard to follow. It can easily lead to typos and so makes + the code vulnerable to bugs. + + If fixing the multiple line dereferencing leads to an 80 column + violation, then either rewrite the code in a more simple way or if the + starting part of the dereferencing identifier is the same and used at + multiple places then store it in a temporary variable, and use that + temporary variable only at all the places. For example, if there are + two dereferencing identifiers:: + + member1->member2->member3.foo1; + member1->member2->member3.foo2; + + then store the member1->member2->member3 part in a temporary variable. + It not only helps to avoid the 80 column violation but also reduces + the program size by removing the unnecessary dereferences. + + But if none of the above methods work then ignore the 80 column + violation because it is much easier to read a dereferencing identifier + on a single line. + **TRAILING_STATEMENTS** Trailing statements (for example after any conditional) should be on the next line. @@ -845,6 +878,38 @@ Macros, Attributes and Symbols Use the `fallthrough;` pseudo keyword instead of `/* fallthrough */` like comments. + **TRAILING_SEMICOLON** + Macro definition should not end with a semicolon. The macro + invocation style should be consistent with function calls. + This can prevent any unexpected code paths:: + + #define MAC do_something; + + If this macro is used within a if else statement, like:: + + if (some_condition) + MAC; + + else + do_something; + + Then there would be a compilation error, because when the macro is + expanded there are two trailing semicolons, so the else branch gets + orphaned. + + See: https://lore.kernel.org/lkml/1399671106.2912.21.camel@joe-AO725/ + + **SINGLE_STATEMENT_DO_WHILE_MACRO** + For the multi-statement macros, it is necessary to use the do-while + loop to avoid unpredictable code paths. The do-while loop helps to + group the multiple statements into a single one so that a + function-like macro can be used as a function only. + + But for the single statement macros, it is unnecessary to use the + do-while loop. Although the code is syntactically correct but using + the do-while loop is redundant. So remove the do-while loop for single + statement macros. + **WEAK_DECLARATION** Using weak declarations like __attribute__((weak)) or __weak can have unintended link defects. Avoid using them. @@ -920,6 +985,11 @@ Functions and Variables Your compiler (or rather your loader) automatically does it for you. + **MULTIPLE_ASSIGNMENTS** + Multiple assignments on a single line makes the code unnecessarily + complicated. So on a single line assign value to a single variable + only, this makes the code more readable and helps avoid typos. + **RETURN_PARENTHESES** return is not a function and as such doesn't need parentheses:: @@ -957,6 +1027,17 @@ Permissions Permission bits should use 4 digit octal permissions (like 0700 or 0444). Avoid using any other base like decimal. + **SYMBOLIC_PERMS** + Permission bits in the octal form are more readable and easier to + understand than their symbolic counterparts because many command-line + tools use this notation. Experienced kernel developers have been using + these traditional Unix permission bits for decades and so they find it + easier to understand the octal notation than the symbolic macros. + For example, it is harder to read S_IWUSR|S_IRUGO than 0644, which + obscures the developer's intent rather than clarifying it. + + See: https://lore.kernel.org/lkml/CA+55aFw5v23T-zvDZp-MmD_EYxF8WbafwwB59934FV7g21uMGQ@mail.gmail.com/ + Spacing and Brackets -------------------- diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index 21dc03bc10a4..8089c559d339 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -194,14 +194,17 @@ additional boot parameters that allow disabling KASAN or controlling features: - ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``). -- ``kasan.mode=sync`` or ``=async`` controls whether KASAN is configured in - synchronous or asynchronous mode of execution (default: ``sync``). +- ``kasan.mode=sync``, ``=async`` or ``=asymm`` controls whether KASAN + is configured in synchronous, asynchronous or asymmetric mode of + execution (default: ``sync``). Synchronous mode: a bad access is detected immediately when a tag check fault occurs. Asynchronous mode: a bad access detection is delayed. When a tag check fault occurs, the information is stored in hardware (in the TFSR_EL1 register for arm64). The kernel periodically checks the hardware and only reports tag faults during these checks. + Asymmetric mode: a bad access is detected synchronously on reads and + asynchronously on writes. - ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack traces collection (default: ``on``). diff --git a/Documentation/dev-tools/kcov.rst b/Documentation/dev-tools/kcov.rst index d2c4c27e1702..d83c9ab49427 100644 --- a/Documentation/dev-tools/kcov.rst +++ b/Documentation/dev-tools/kcov.rst @@ -50,6 +50,7 @@ program using kcov: #include <sys/mman.h> #include <unistd.h> #include <fcntl.h> + #include <linux/types.h> #define KCOV_INIT_TRACE _IOR('c', 1, unsigned long) #define KCOV_ENABLE _IO('c', 100) @@ -177,6 +178,8 @@ Comparison operands collection is similar to coverage collection: /* Read number of comparisons collected. */ n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED); for (i = 0; i < n; i++) { + uint64_t ip; + type = cover[i * KCOV_WORDS_PER_CMP + 1]; /* arg1 and arg2 - operands of the comparison. */ arg1 = cover[i * KCOV_WORDS_PER_CMP + 2]; @@ -251,6 +254,8 @@ selectively from different subsystems. .. code-block:: c + /* Same includes and defines as above. */ + struct kcov_remote_arg { __u32 trace_mode; __u32 area_size; diff --git a/Documentation/dev-tools/kfence.rst b/Documentation/dev-tools/kfence.rst index 0fbe3308bf37..ac6b89d1a8c3 100644 --- a/Documentation/dev-tools/kfence.rst +++ b/Documentation/dev-tools/kfence.rst @@ -231,10 +231,14 @@ Guarded allocations are set up based on the sample interval. After expiration of the sample interval, the next allocation through the main allocator (SLAB or SLUB) returns a guarded allocation from the KFENCE object pool (allocation sizes up to PAGE_SIZE are supported). At this point, the timer is reset, and -the next allocation is set up after the expiration of the interval. To "gate" a -KFENCE allocation through the main allocator's fast-path without overhead, -KFENCE relies on static branches via the static keys infrastructure. The static -branch is toggled to redirect the allocation to KFENCE. +the next allocation is set up after the expiration of the interval. + +When using ``CONFIG_KFENCE_STATIC_KEYS=y``, KFENCE allocations are "gated" +through the main allocator's fast-path by relying on static branches via the +static keys infrastructure. The static branch is toggled to redirect the +allocation to KFENCE. Depending on sample interval, target workloads, and +system architecture, this may perform better than the simple dynamic branch. +Careful benchmarking is recommended. KFENCE objects each reside on a dedicated page, at either the left or right page boundaries selected at random. The pages to the left and right of the @@ -269,6 +273,17 @@ tail of KFENCE's freelist, so that the least recently freed objects are reused first, and the chances of detecting use-after-frees of recently freed objects is increased. +If pool utilization reaches 75% (default) or above, to reduce the risk of the +pool eventually being fully occupied by allocated objects yet ensure diverse +coverage of allocations, KFENCE limits currently covered allocations of the +same source from further filling up the pool. The "source" of an allocation is +based on its partial allocation stack trace. A side-effect is that this also +limits frequent long-lived allocations (e.g. pagecache) of the same source +filling up the pool permanently, which is the most common risk for the pool +becoming full and the sampled allocation rate dropping to zero. The threshold +at which to start limiting currently covered allocations can be configured via +the boot parameter ``kfence.skip_covered_thresh`` (pool usage%). + Interface --------- diff --git a/Documentation/dev-tools/kunit/running_tips.rst b/Documentation/dev-tools/kunit/running_tips.rst index 30d2147eb5b5..7b6d26a25959 100644 --- a/Documentation/dev-tools/kunit/running_tips.rst +++ b/Documentation/dev-tools/kunit/running_tips.rst @@ -25,8 +25,8 @@ It can be handy to create a bash function like: Running a subset of tests ------------------------- -``kunit.py run`` accepts an optional glob argument to filter tests. Currently -this only matches against suite names, but this may change in the future. +``kunit.py run`` accepts an optional glob argument to filter tests. The format +is ``"<suite_glob>[.test_glob]"``. Say that we wanted to run the sysctl tests, we could do so via: @@ -35,6 +35,13 @@ Say that we wanted to run the sysctl tests, we could do so via: $ echo -e 'CONFIG_KUNIT=y\nCONFIG_KUNIT_ALL_TESTS=y' > .kunit/.kunitconfig $ ./tools/testing/kunit/kunit.py run 'sysctl*' +We can filter down to just the "write" tests via: + +.. code-block:: bash + + $ echo -e 'CONFIG_KUNIT=y\nCONFIG_KUNIT_ALL_TESTS=y' > .kunit/.kunitconfig + $ ./tools/testing/kunit/kunit.py run 'sysctl*.*write*' + We're paying the cost of building more tests than we need this way, but it's easier than fiddling with ``.kunitconfig`` files or commenting out ``kunit_suite``'s. diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index a072e95de626..c9abfbe3f0aa 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -9,6 +9,11 @@ DT_SCHEMA_MIN_VERSION = 2021.2.1 PHONY += check_dtschema_version check_dtschema_version: + @which $(DT_DOC_CHECKER) >/dev/null || \ + { echo "Error: '$(DT_DOC_CHECKER)' not found!" >&2; \ + echo "Ensure dtschema python package is installed and in your PATH." >&2; \ + echo "Current PATH is:" >&2; \ + echo "$$PATH" >&2; false; } @{ echo $(DT_SCHEMA_MIN_VERSION); \ $(DT_DOC_CHECKER) --version 2>/dev/null || echo 0; } | sort -Vc >/dev/null || \ { echo "ERROR: dtschema minimum version is v$(DT_SCHEMA_MIN_VERSION)" >&2; false; } @@ -22,13 +27,20 @@ $(obj)/%.example.dts: $(src)/%.yaml check_dtschema_version FORCE # Use full schemas when checking %.example.dts DT_TMP_SCHEMA := $(obj)/processed-schema-examples.json -find_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \ +find_all_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \ -name 'processed-schema*' ! \ -name '*.example.dt.yaml' \) +ifeq ($(DT_SCHEMA_FILES),) +find_cmd = $(find_all_cmd) +else +find_cmd = echo $(addprefix $(srctree)/, $(DT_SCHEMA_FILES)) +endif + quiet_cmd_yamllint = LINT $(src) cmd_yamllint = ($(find_cmd) | \ - xargs $(DT_SCHEMA_LINT) -f parsable -c $(srctree)/$(src)/.yamllint >&2) || true + xargs -n200 -P$$(nproc) \ + $(DT_SCHEMA_LINT) -f parsable -c $(srctree)/$(src)/.yamllint >&2) || true quiet_cmd_chk_bindings = CHKDT $@ cmd_chk_bindings = ($(find_cmd) | \ @@ -38,7 +50,7 @@ quiet_cmd_mk_schema = SCHEMA $@ cmd_mk_schema = f=$$(mktemp) ; \ $(if $(DT_MK_SCHEMA_FLAGS), \ printf '%s\n' $(real-prereqs), \ - $(find_cmd)) > $$f ; \ + $(find_all_cmd)) > $$f ; \ $(DT_MK_SCHEMA) -j $(DT_MK_SCHEMA_FLAGS) @$$f > $@ ; \ rm -f $$f @@ -48,7 +60,7 @@ define rule_chkdt $(call cmd,mk_schema) endef -DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_cmd))) +DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_all_cmd))) override DTC_FLAGS := \ -Wno-avoid_unnecessary_addr_size \ diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 6423377710ee..36081734f720 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -86,6 +86,7 @@ properties: - enum: - amlogic,p281 - oranth,tx3-mini + - jethome,jethub-j80 - const: amlogic,s905w - const: amlogic,meson-gxl @@ -133,6 +134,7 @@ properties: items: - enum: - amlogic,s400 + - jethome,jethub-j100 - const: amlogic,a113d - const: amlogic,meson-axg @@ -141,6 +143,7 @@ properties: - enum: - amediatech,x96-max - amlogic,u200 + - radxa,zero - seirobotics,sei510 - const: amlogic,g12a diff --git a/Documentation/devicetree/bindings/arm/arm,cci-400.yaml b/Documentation/devicetree/bindings/arm/arm,cci-400.yaml new file mode 100644 index 000000000000..4682f991a5c8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,cci-400.yaml @@ -0,0 +1,216 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,cci-400.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM CCI Cache Coherent Interconnect Device Tree Binding + +maintainers: + - Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> + +description: > + ARM multi-cluster systems maintain intra-cluster coherency through a cache + coherent interconnect (CCI) that is capable of monitoring bus transactions + and manage coherency, TLB invalidations and memory barriers. + + It allows snooping and distributed virtual memory message broadcast across + clusters, through memory mapped interface, with a global control register + space and multiple sets of interface control registers, one per slave + interface. + +properties: + $nodename: + pattern: "^cci(@[0-9a-f]+)?$" + + compatible: + enum: + - arm,cci-400 + - arm,cci-500 + - arm,cci-550 + + reg: + maxItems: 1 + description: > + Specifies base physical address of CCI control registers common to all + interfaces. + + "#address-cells": true + "#size-cells": true + ranges: true + +patternProperties: + "^slave-if@[0-9a-f]+$": + type: object + + properties: + compatible: + const: arm,cci-400-ctrl-if + + interface-type: + enum: + - ace + - ace-lite + + reg: + maxItems: 1 + + required: + - compatible + - interface-type + - reg + + additionalProperties: false + + "^pmu@[0-9a-f]+$": + type: object + + properties: + compatible: + oneOf: + - const: arm,cci-400-pmu,r0 + - const: arm,cci-400-pmu,r1 + - const: arm,cci-400-pmu + deprecated: true + description: > + Permitted only where OS has secure access to CCI registers + - const: arm,cci-500-pmu,r0 + - const: arm,cci-550-pmu,r0 + + interrupts: + minItems: 1 + maxItems: 8 + description: > + List of counter overflow interrupts, one per counter. The interrupts + must be specified starting with the cycle counter overflow interrupt, + followed by counter0 overflow interrupt, counter1 overflow + interrupt,... ,counterN overflow interrupt. + + The CCI PMU has an interrupt signal for each counter. The number of + interrupts must be equal to the number of counters. + + reg: + maxItems: 1 + + required: + - compatible + - interrupts + - reg + + additionalProperties: false + +required: + - "#address-cells" + - "#size-cells" + - compatible + - ranges + - reg + +additionalProperties: false + +examples: + - | + / { + #address-cells = <2>; + #size-cells = <2>; + + compatible = "arm,vexpress,v2p-ca15_a7", "arm,vexpress"; + model = "V2P-CA15_CA7"; + arm,hbi = <0x249>; + interrupt-parent = <&gic>; + + /* + * This CCI node corresponds to a CCI component whose control + * registers sits at address 0x000000002c090000. + * + * CCI slave interface @0x000000002c091000 is connected to dma + * controller dma0. + * + * CCI slave interface @0x000000002c094000 is connected to CPUs + * {CPU0, CPU1}; + * + * CCI slave interface @0x000000002c095000 is connected to CPUs + * {CPU2, CPU3}; + */ + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + cci-control-port = <&cci_control1>; + reg = <0x0>; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + cci-control-port = <&cci_control1>; + reg = <0x1>; + }; + + CPU2: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + cci-control-port = <&cci_control2>; + reg = <0x100>; + }; + + CPU3: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + cci-control-port = <&cci_control2>; + reg = <0x101>; + }; + }; + + dma0: dma@3000000 { + /* compatible = "arm,pl330", "arm,primecell"; */ + cci-control-port = <&cci_control0>; + reg = <0x0 0x3000000 0x0 0x1000>; + interrupts = <10>; + #dma-cells = <1>; + #dma-channels = <8>; + #dma-requests = <32>; + }; + + cci@2c090000 { + compatible = "arm,cci-400"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x0 0x2c090000 0 0x1000>; + ranges = <0x0 0x0 0x2c090000 0x10000>; + + cci_control0: slave-if@1000 { + compatible = "arm,cci-400-ctrl-if"; + interface-type = "ace-lite"; + reg = <0x1000 0x1000>; + }; + + cci_control1: slave-if@4000 { + compatible = "arm,cci-400-ctrl-if"; + interface-type = "ace"; + reg = <0x4000 0x1000>; + }; + + cci_control2: slave-if@5000 { + compatible = "arm,cci-400-ctrl-if"; + interface-type = "ace"; + reg = <0x5000 0x1000>; + }; + + pmu@9000 { + compatible = "arm,cci-400-pmu"; + reg = <0x9000 0x5000>; + interrupts = <0 101 4>, + <0 102 4>, + <0 103 4>, + <0 104 4>, + <0 105 4>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml index 55ef656d1192..a4b4452afc1d 100644 --- a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml +++ b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml @@ -119,22 +119,6 @@ properties: - const: arm,foundation-aarch64 - const: arm,vexpress - arm,hbi: - $ref: '/schemas/types.yaml#/definitions/uint32' - description: This indicates the ARM HBI (Hardware Board ID), this is - ARM's unique board model ID, visible on the PCB's silkscreen. - - arm,vexpress,site: - description: As Versatile Express can be configured in number of physically - different setups, the device tree should describe platform topology. - For this reason the root node and main motherboard node must define this - property, describing the physical location of the children nodes. - 0 means motherboard site, while 1 and 2 are daughterboard sites, and - 0xf means "sisterboard" which is the site containing the main CPU tile. - $ref: '/schemas/types.yaml#/definitions/uint32' - minimum: 0 - maximum: 15 - arm,vexpress,position: description: When daughterboards are stacked on one site, their position in the stack be be described this attribute. @@ -154,9 +138,9 @@ patternProperties: description: Static Memory Bus (SMB) node, if this exists it describes the connection between the motherboard and any tiles. Sometimes the compatible is placed directly under this node, sometimes it is placed - in a subnode named "motherboard". Sometimes the compatible includes + in a subnode named "motherboard-bus". Sometimes the compatible includes "arm,vexpress,v2?-p1" sometimes (on software models) is is just - "simple-bus". If the compatible is placed in the "motherboard" node, + "simple-bus". If the compatible is placed in the "motherboard-bus" node, it is stricter and always has two compatibles. type: object $ref: '/schemas/simple-bus.yaml' @@ -170,7 +154,9 @@ patternProperties: - arm,vexpress,v2p-p1 - const: simple-bus - const: simple-bus - motherboard: + + patternProperties: + '^motherboard-bus@': type: object description: The motherboard description provides a single "motherboard" node using 2 address cells corresponding to the Static Memory Bus @@ -183,6 +169,8 @@ patternProperties: const: 2 "#size-cells": const: 1 + ranges: true + compatible: items: - enum: @@ -196,8 +184,28 @@ patternProperties: - rs1 - rs2 + arm,hbi: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: This indicates the ARM HBI (Hardware Board ID), this is + ARM's unique board model ID, visible on the PCB's silkscreen. + + arm,vexpress,site: + description: As Versatile Express can be configured in number of physically + different setups, the device tree should describe platform topology. + For this reason the root node and main motherboard node must define this + property, describing the physical location of the children nodes. + 0 means motherboard site, while 1 and 2 are daughterboard sites, and + 0xf means "sisterboard" which is the site containing the main CPU tile. + $ref: '/schemas/types.yaml#/definitions/uint32' + minimum: 0 + maximum: 15 + required: - compatible + + additionalProperties: + type: object + required: - compatible diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml index fba071b9af1d..c612e1f48dba 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml @@ -126,6 +126,18 @@ properties: - const: atmel,sama5d3 - const: atmel,sama5 + - description: CalAmp LMU5000 board + items: + - const: calamp,lmu5000 + - const: atmel,at91sam9g20 + - const: atmel,at91sam9 + + - description: Exegin Q5xR5 board + items: + - const: exegin,q5xr5 + - const: atmel,at91sam9g20 + - const: atmel,at91sam9 + - items: - enum: - atmel,sama5d31 @@ -150,6 +162,18 @@ properties: - const: microchip,sama7g5 - const: microchip,sama7 + - description: Microchip LAN9662 PCB8291 Evaluation Board. + items: + - const: microchip,lan9662-pcb8291 + - const: microchip,lan9662 + - const: microchip,lan966 + + - description: Microchip LAN9668 PCB8290 Evaluation Board. + items: + - const: microchip,lan9668-pcb8290 + - const: microchip,lan9668 + - const: microchip,lan966 + - items: - enum: - atmel,sams70j19 diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml index 230b80d9d6cf..5dc48241efb3 100644 --- a/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml @@ -19,6 +19,7 @@ properties: items: - enum: - raspberrypi,400 + - raspberrypi,4-compute-module - raspberrypi,4-model-b - const: brcm,bcm2711 diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.yaml index 476bc23a7f75..7d184ba7d180 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.yaml @@ -22,16 +22,61 @@ properties: $nodename: const: '/' compatible: - items: - - enum: - - brcm,bcm58522 - - brcm,bcm58525 - - brcm,bcm58535 - - brcm,bcm58622 - - brcm,bcm58623 - - brcm,bcm58625 - - brcm,bcm88312 - - const: brcm,nsp + oneOf: + - description: BCM58522 based boards + items: + - enum: + - brcm,bcm958522er + - const: brcm,bcm58522 + - const: brcm,nsp + + - description: BCM58525 based boards + items: + - enum: + - brcm,bcm958525er + - brcm,bcm958525xmc + - const: brcm,bcm58525 + - const: brcm,nsp + + - description: BCM58535 based boards + items: + - const: brcm,bcm58535 + - const: brcm,nsp + + - description: BCM58622 based boards + items: + - enum: + - brcm,bcm958622hr + - const: brcm,bcm58622 + - const: brcm,nsp + + - description: BCM58623 based boards + items: + - enum: + - brcm,bcm958623hr + - const: brcm,bcm58623 + - const: brcm,nsp + + - description: BCM58625 based boards + items: + - enum: + - brcm,bcm958625hr + - brcm,bcm958625k + - meraki,mx64 + - meraki,mx64-a0 + - meraki,mx64w + - meraki,mx64w-a0 + - meraki,mx65 + - meraki,mx65w + - const: brcm,bcm58625 + - const: brcm,nsp + + - description: BCM88312 based boards + items: + - enum: + - brcm,bcm988312hr + - const: brcm,bcm88312 + - const: brcm,nsp additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/cci-control-port.yaml b/Documentation/devicetree/bindings/arm/cci-control-port.yaml new file mode 100644 index 000000000000..c9114866213f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cci-control-port.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/cci-control-port.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CCI Interconnect Bus Masters binding + +maintainers: + - Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> + +description: | + Masters in the device tree connected to a CCI port (inclusive of CPUs + and their cpu nodes). + +select: true + +properties: + cci-control-port: + $ref: /schemas/types.yaml#/definitions/phandle + +additionalProperties: true + +examples: + - | + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + compatible = "arm,cortex-a15"; + device_type = "cpu"; + cci-control-port = <&cci_control1>; + reg = <0>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/arm/cci.txt b/Documentation/devicetree/bindings/arm/cci.txt deleted file mode 100644 index 9600761f2d5b..000000000000 --- a/Documentation/devicetree/bindings/arm/cci.txt +++ /dev/null @@ -1,224 +0,0 @@ -======================================================= -ARM CCI cache coherent interconnect binding description -======================================================= - -ARM multi-cluster systems maintain intra-cluster coherency through a -cache coherent interconnect (CCI) that is capable of monitoring bus -transactions and manage coherency, TLB invalidations and memory barriers. - -It allows snooping and distributed virtual memory message broadcast across -clusters, through memory mapped interface, with a global control register -space and multiple sets of interface control registers, one per slave -interface. - -* CCI interconnect node - - Description: Describes a CCI cache coherent Interconnect component - - Node name must be "cci". - Node's parent must be the root node /, and the address space visible - through the CCI interconnect is the same as the one seen from the - root node (ie from CPUs perspective as per DT standard). - Every CCI node has to define the following properties: - - - compatible - Usage: required - Value type: <string> - Definition: must contain one of the following: - "arm,cci-400" - "arm,cci-500" - "arm,cci-550" - - - reg - Usage: required - Value type: Integer cells. A register entry, expressed as a pair - of cells, containing base and size. - Definition: A standard property. Specifies base physical - address of CCI control registers common to all - interfaces. - - - ranges: - Usage: required - Value type: Integer cells. An array of range entries, expressed - as a tuple of cells, containing child address, - parent address and the size of the region in the - child address space. - Definition: A standard property. Follow rules in the Devicetree - Specification for hierarchical bus addressing. CCI - interfaces addresses refer to the parent node - addressing scheme to declare their register bases. - - CCI interconnect node can define the following child nodes: - - - CCI control interface nodes - - Node name must be "slave-if". - Parent node must be CCI interconnect node. - - A CCI control interface node must contain the following - properties: - - - compatible - Usage: required - Value type: <string> - Definition: must be set to - "arm,cci-400-ctrl-if" - - - interface-type: - Usage: required - Value type: <string> - Definition: must be set to one of {"ace", "ace-lite"} - depending on the interface type the node - represents. - - - reg: - Usage: required - Value type: Integer cells. A register entry, expressed - as a pair of cells, containing base and - size. - Definition: the base address and size of the - corresponding interface programming - registers. - - - CCI PMU node - - Parent node must be CCI interconnect node. - - A CCI pmu node must contain the following properties: - - - compatible - Usage: required - Value type: <string> - Definition: Must contain one of: - "arm,cci-400-pmu,r0" - "arm,cci-400-pmu,r1" - "arm,cci-400-pmu" - DEPRECATED, permitted only where OS has - secure access to CCI registers - "arm,cci-500-pmu,r0" - "arm,cci-550-pmu,r0" - - reg: - Usage: required - Value type: Integer cells. A register entry, expressed - as a pair of cells, containing base and - size. - Definition: the base address and size of the - corresponding interface programming - registers. - - - interrupts: - Usage: required - Value type: Integer cells. Array of interrupt specifier - entries, as defined in - ../interrupt-controller/interrupts.txt. - Definition: list of counter overflow interrupts, one per - counter. The interrupts must be specified - starting with the cycle counter overflow - interrupt, followed by counter0 overflow - interrupt, counter1 overflow interrupt,... - ,counterN overflow interrupt. - - The CCI PMU has an interrupt signal for each - counter. The number of interrupts must be - equal to the number of counters. - -* CCI interconnect bus masters - - Description: masters in the device tree connected to a CCI port - (inclusive of CPUs and their cpu nodes). - - A CCI interconnect bus master node must contain the following - properties: - - - cci-control-port: - Usage: required - Value type: <phandle> - Definition: a phandle containing the CCI control interface node - the master is connected to. - -Example: - - cpus { - #size-cells = <0>; - #address-cells = <1>; - - CPU0: cpu@0 { - device_type = "cpu"; - compatible = "arm,cortex-a15"; - cci-control-port = <&cci_control1>; - reg = <0x0>; - }; - - CPU1: cpu@1 { - device_type = "cpu"; - compatible = "arm,cortex-a15"; - cci-control-port = <&cci_control1>; - reg = <0x1>; - }; - - CPU2: cpu@100 { - device_type = "cpu"; - compatible = "arm,cortex-a7"; - cci-control-port = <&cci_control2>; - reg = <0x100>; - }; - - CPU3: cpu@101 { - device_type = "cpu"; - compatible = "arm,cortex-a7"; - cci-control-port = <&cci_control2>; - reg = <0x101>; - }; - - }; - - dma0: dma@3000000 { - compatible = "arm,pl330", "arm,primecell"; - cci-control-port = <&cci_control0>; - reg = <0x0 0x3000000 0x0 0x1000>; - interrupts = <10>; - #dma-cells = <1>; - #dma-channels = <8>; - #dma-requests = <32>; - }; - - cci@2c090000 { - compatible = "arm,cci-400"; - #address-cells = <1>; - #size-cells = <1>; - reg = <0x0 0x2c090000 0 0x1000>; - ranges = <0x0 0x0 0x2c090000 0x10000>; - - cci_control0: slave-if@1000 { - compatible = "arm,cci-400-ctrl-if"; - interface-type = "ace-lite"; - reg = <0x1000 0x1000>; - }; - - cci_control1: slave-if@4000 { - compatible = "arm,cci-400-ctrl-if"; - interface-type = "ace"; - reg = <0x4000 0x1000>; - }; - - cci_control2: slave-if@5000 { - compatible = "arm,cci-400-ctrl-if"; - interface-type = "ace"; - reg = <0x5000 0x1000>; - }; - - pmu@9000 { - compatible = "arm,cci-400-pmu"; - reg = <0x9000 0x5000>; - interrupts = <0 101 4>, - <0 102 4>, - <0 103 4>, - <0 104 4>, - <0 105 4>; - }; - }; - -This CCI node corresponds to a CCI component whose control registers sits -at address 0x000000002c090000. -CCI slave interface @0x000000002c091000 is connected to dma controller dma0. -CCI slave interface @0x000000002c094000 is connected to CPUs {CPU0, CPU1}; -CCI slave interface @0x000000002c095000 is connected to CPUs {CPU2, CPU3}; diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt index 7f9c1ca87487..c68d93a35b6c 100644 --- a/Documentation/devicetree/bindings/arm/coresight.txt +++ b/Documentation/devicetree/bindings/arm/coresight.txt @@ -127,6 +127,11 @@ its hardware characteristcs. * arm,scatter-gather: boolean. Indicates that the TMC-ETR can safely use the SG mode on this system. + * arm,max-burst-size: The maximum burst size initiated by TMC on the + AXI master interface. The burst size can be in the range [0..15], + the setting supports one data transfer per burst up to a maximum of + 16 data transfers per burst. + * Optional property for CATU : * interrupts : Exactly one SPI may be listed for reporting the address error diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index 9a2432a88074..f2ab6423b4af 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -171,6 +171,8 @@ properties: - qcom,kryo385 - qcom,kryo468 - qcom,kryo485 + - qcom,kryo560 + - qcom,kryo570 - qcom,kryo685 - qcom,scorpion @@ -209,6 +211,9 @@ properties: - qcom,gcc-msm8660 - qcom,kpss-acc-v1 - qcom,kpss-acc-v2 + - qcom,msm8226-smp + # Only valid on ARM 32-bit, see above for ARM v8 64-bit + - qcom,msm8916-smp - renesas,apmu - renesas,r9a06g032-smp - rockchip,rk3036-smp @@ -240,6 +245,8 @@ properties: DMIPS/MHz, relative to highest capacity-dmips-mhz in the system. + cci-control-port: true + dynamic-power-coefficient: $ref: '/schemas/types.yaml#/definitions/uint32' description: @@ -293,7 +300,8 @@ properties: Specifies the ACC* node associated with this CPU. Required for systems that have an "enable-method" property - value of "qcom,kpss-acc-v1" or "qcom,kpss-acc-v2" + value of "qcom,kpss-acc-v1", "qcom,kpss-acc-v2", "qcom,msm8226-smp" or + "qcom,msm8916-smp". * arm/msm/qcom,kpss-acc.txt diff --git a/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt b/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt deleted file mode 100644 index 780d0392a66b..000000000000 --- a/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt +++ /dev/null @@ -1,20 +0,0 @@ -Trusted Foundations -------------------- - -Boards that use the Trusted Foundations secure monitor can signal its -presence by declaring a node compatible with "tlm,trusted-foundations" -under the /firmware/ node - -Required properties: -- compatible: "tlm,trusted-foundations" -- tlm,version-major: major version number of Trusted Foundations firmware -- tlm,version-minor: minor version number of Trusted Foundations firmware - -Example: - firmware { - trusted-foundations { - compatible = "tlm,trusted-foundations"; - tlm,version-major = <2>; - tlm,version-minor = <8>; - }; - }; diff --git a/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml b/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml new file mode 100644 index 000000000000..9d1857c0aa07 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/firmware/tlm,trusted-foundations.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Trusted Foundations + +description: | + Boards that use the Trusted Foundations secure monitor can signal its + presence by declaring a node compatible under the /firmware/ node + +maintainers: + - Stephen Warren <swarren@nvidia.com> + +properties: + $nodename: + const: trusted-foundations + + compatible: + const: tlm,trusted-foundations + + tlm,version-major: + $ref: /schemas/types.yaml#/definitions/uint32 + description: major version number of Trusted Foundations firmware + + tlm,version-minor: + $ref: /schemas/types.yaml#/definitions/uint32 + description: minor version number of Trusted Foundations firmware + +required: + - compatible + - tlm,version-major + - tlm,version-minor + +additionalProperties: false + +examples: + - | + firmware { + trusted-foundations { + compatible = "tlm,trusted-foundations"; + tlm,version-major = <2>; + tlm,version-minor = <8>; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 60f4862ba15e..0b595b26061f 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -235,7 +235,7 @@ properties: - technexion,imx6q-pico-pi # TechNexion i.MX6Q Pico-Pi - technologic,imx6q-ts4900 - technologic,imx6q-ts7970 - - toradex,apalis_imx6q # Apalis iMX6 Module + - toradex,apalis_imx6q # Apalis iMX6 Modules - udoo,imx6q-udoo # Udoo i.MX6 Quad Board - uniwest,imx6q-evi # Uniwest Evi - variscite,dt6customboard @@ -314,18 +314,12 @@ properties: - const: phytec,imx6q-pfla02 # PHYTEC phyFLEX-i.MX6 Quad - const: fsl,imx6q - - description: i.MX6Q Boards with Toradex Apalis iMX6Q/D Module + - description: i.MX6Q Boards with Toradex Apalis iMX6Q/D Modules items: - enum: - - toradex,apalis_imx6q-ixora # Apalis iMX6Q/D Module on Ixora Carrier Board - - toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board - - const: toradex,apalis_imx6q - - const: fsl,imx6q - - - description: i.MX6Q Toradex Apalis iMX6Q/D Module on Ixora Carrier Board V1.1 - items: - - const: toradex,apalis_imx6q-ixora-v1.1 - - const: toradex,apalis_imx6q-ixora + - toradex,apalis_imx6q-ixora # Apalis iMX6Q/D Module on Ixora Carrier Board + - toradex,apalis_imx6q-ixora-v1.1 # Apalis iMX6Q/D Module on Ixora V1.1 Carrier Board + - toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board - const: toradex,apalis_imx6q - const: fsl,imx6q @@ -393,6 +387,8 @@ properties: - technexion,imx6dl-pico-pi # TechNexion i.MX6DL Pico-Pi - technologic,imx6dl-ts4900 - technologic,imx6dl-ts7970 + - toradex,colibri_imx6dl # Colibri iMX6 Modules + - toradex,colibri_imx6dl-v1_1 # Colibri iMX6 V1.1 Modules - udoo,imx6dl-udoo # Udoo i.MX6 Dual-lite Board - vdl,lanmcu # Van der Laan LANMCU board - wand,imx6dl-wandboard # Wandboard i.MX6 Dual Lite Board @@ -466,20 +462,18 @@ properties: - const: phytec,imx6dl-pfla02 # PHYTEC phyFLEX-i.MX6 Quad - const: fsl,imx6dl - - description: i.MX6DL Toradex Colibri iMX6 Module on Colibri - Evaluation Board V3 + - description: i.MX6DL Boards with Toradex Colibri iMX6DL/S Modules items: - - const: toradex,colibri_imx6dl-eval-v3 - - const: toradex,colibri_imx6dl # Colibri iMX6 Module + - enum: + - toradex,colibri_imx6dl-eval-v3 # Colibri iMX6DL/S Module on Colibri Evaluation Board V3 + - const: toradex,colibri_imx6dl # Colibri iMX6DL/S Module - const: fsl,imx6dl - - description: i.MX6DL Toradex Colibri iMX6 Module V1.1 on Colibri - Evaluation Board V3 + - description: i.MX6DL Boards with Toradex Colibri iMX6DL/S V1.1 Modules items: - - const: toradex,colibri_imx6dl-v1_1-eval-v3 - - const: toradex,colibri_imx6dl-v1_1 # Colibri iMX6 Module V1.1 - - const: toradex,colibri_imx6dl-eval-v3 - - const: toradex,colibri_imx6dl # Colibri iMX6 Module + - enum: + - toradex,colibri_imx6dl-v1_1-eval-v3 # Colibri iMX6DL/S V1.1 M. on Colibri Evaluation Board V3 + - const: toradex,colibri_imx6dl-v1_1 # Colibri iMX6DL/S V1.1 Module - const: fsl,imx6dl - description: i.MX6S DHCOM DRC02 Board @@ -494,6 +488,7 @@ properties: - fsl,imx6sl-evk # i.MX6 SoloLite EVK Board - kobo,tolino-shine2hd - kobo,tolino-shine3 + - kobo,tolino-vision5 - revotics,imx6sl-warp # Revotics WaRP Board - const: fsl,imx6sl @@ -502,6 +497,7 @@ properties: - enum: - fsl,imx6sll-evk - kobo,clarahd + - kobo,librah2o - const: fsl,imx6sll - description: i.MX6SX based Boards @@ -586,8 +582,9 @@ properties: - fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board - kontron,imx6ull-n6411-som # Kontron N6411 SOM - myir,imx6ull-mys-6ulx-eval # MYiR Tech iMX6ULL Evaluation Board - - toradex,colibri-imx6ull-eval # Colibri iMX6ULL Module on Colibri Eval Board - - toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / BT Module on Colibri Eval Board + - toradex,colibri-imx6ull # Colibri iMX6ULL Modules + - toradex,colibri-imx6ull-emmc # Colibri iMX6ULL 1GB (eMMC) Module + - toradex,colibri-imx6ull-wifi # Colibri iMX6ULL Wi-Fi / BT Modules - const: fsl,imx6ull - description: i.MX6ULL Armadeus Systems OPOS6ULDev Board @@ -605,6 +602,27 @@ properties: - const: phytec,imx6ull-pcl063 # PHYTEC phyCORE-i.MX 6ULL - const: fsl,imx6ull + - description: i.MX6ULL Boards with Toradex Colibri iMX6ULL Modules + items: + - enum: + - toradex,colibri-imx6ull-eval # Colibri iMX6ULL Module on Colibri Evaluation Board + - const: toradex,colibri-imx6ull # Colibri iMX6ULL Module + - const: fsl,imx6dl + + - description: i.MX6ULL Boards with Toradex Colibri iMX6ULL 1GB (eMMC) Module + items: + - enum: + - toradex,colibri-imx6ull-emmc-eval # Colibri iMX6ULL 1GB (eMMC) M. on Colibri Evaluation Board + - const: toradex,colibri-imx6ull-emmc # Colibri iMX6ULL 1GB (eMMC) Module + - const: fsl,imx6dl + + - description: i.MX6ULL Boards with Toradex Colibri iMX6ULL Wi-Fi / BT Modules + items: + - enum: + - toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / BT M. on Colibri Evaluation Board + - const: toradex,colibri-imx6ull-wifi # Colibri iMX6ULL Wi-Fi / BT Module + - const: fsl,imx6dl + - description: Kontron N6411 S Board items: - const: kontron,imx6ull-n6411-s @@ -622,6 +640,7 @@ properties: items: - enum: - element14,imx7s-warp # Element14 Warp i.MX7 Board + - toradex,colibri-imx7s # Colibri iMX7S Module - const: fsl,imx7s - description: i.MX7S Boards with Toradex Colibri iMX7S Module @@ -653,15 +672,8 @@ properties: - technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit - technexion,imx7d-pico-nymph # TechNexion i.MX7D Pico-Nymph - technexion,imx7d-pico-pi # TechNexion i.MX7D Pico-Pi - - toradex,colibri-imx7d # Colibri iMX7 Dual Module - - toradex,colibri-imx7d-aster # Colibri iMX7 Dual Module on Aster Carrier Board - - toradex,colibri-imx7d-emmc # Colibri iMX7 Dual 1GB (eMMC) Module - - toradex,colibri-imx7d-emmc-aster # Colibri iMX7 Dual 1GB (eMMC) Module on - # Aster Carrier Board - - toradex,colibri-imx7d-emmc-eval-v3 # Colibri iMX7 Dual 1GB (eMMC) Module on - # Colibri Evaluation Board V3 - - toradex,colibri-imx7d-eval-v3 # Colibri iMX7 Dual Module on - # Colibri Evaluation Board V3 + - toradex,colibri-imx7d # Colibri iMX7D Module + - toradex,colibri-imx7d-emmc # Colibri iMX7D 1GB (eMMC) Module - zii,imx7d-rmu2 # ZII RMU2 Board - zii,imx7d-rpu2 # ZII RPU2 Board - const: fsl,imx7d @@ -686,12 +698,12 @@ properties: - description: i.MX7D Boards with Toradex Colibri i.MX7D Module items: - enum: - - toradex,colibri-imx7d-aster # Module on Aster Carrier Board - - toradex,colibri-imx7d-eval-v3 # Module on Colibri Evaluation Board V3 + - toradex,colibri-imx7d-aster # Colibri iMX7D Module on Aster Carrier Board + - toradex,colibri-imx7d-eval-v3 # Colibri iMX7D Module on Colibri Evaluation Board V3 - const: toradex,colibri-imx7d - const: fsl,imx7d - - description: i.MX7D Boards with Toradex Colibri i.MX7D eMMC Module + - description: i.MX7D Boards with Toradex Colibri i.MX7D 1GB (eMMC) Module items: - enum: - toradex,colibri-imx7d-emmc-aster # Module on Aster Carrier Board @@ -812,10 +824,10 @@ properties: - enum: - einfochips,imx8qxp-ai_ml # i.MX8QXP AI_ML Board - fsl,imx8qxp-mek # i.MX8QXP MEK Board - - toradex,colibri-imx8x # Colibri iMX8X Module + - toradex,colibri-imx8x # Colibri iMX8X Modules - const: fsl,imx8qxp - - description: Toradex Colibri i.MX8 Evaluation Board + - description: i.MX8QXP Boards with Toradex Coilbri iMX8X Modules items: - enum: - toradex,colibri-imx8x-eval-v3 # Colibri iMX8X Module on Colibri Evaluation Board V3 @@ -847,9 +859,10 @@ properties: - description: VF610 based Boards items: - enum: + - fsl,vf610-twr # VF610 Tower Board - lwn,bk4 # Liebherr BK4 controller - phytec,vf610-cosmic # PHYTEC Cosmic/Cosmic+ Board - - fsl,vf610-twr # VF610 Tower Board + - toradex,vf610-colibri_vf61 # Colibri VF61 Modules - const: fsl,vf610 - description: Toradex Colibri VF61 Module on Colibri Evaluation Board @@ -886,6 +899,7 @@ properties: - enum: - fsl,ls1021a-moxa-uc-8410a - fsl,ls1021a-qds + - fsl,ls1021a-tsn - fsl,ls1021a-twr - const: fsl,ls1021a @@ -977,6 +991,8 @@ properties: - description: LX2160A based Boards items: - enum: + - fsl,lx2160a-bluebox3 + - fsl,lx2160a-bluebox3-rev-a - fsl,lx2160a-qds - fsl,lx2160a-rdb - fsl,lx2162a-qds @@ -990,6 +1006,13 @@ properties: - const: solidrun,lx2160a-cex7 - const: fsl,lx2160a + - description: S32G2 based Boards + items: + - enum: + - nxp,s32g274a-evb + - nxp,s32g274a-rdb2 + - const: nxp,s32g2 + - description: S32V234 based Boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 80a05f6fee85..0fa55497b96f 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -32,6 +32,7 @@ properties: - const: mediatek,mt6580 - items: - enum: + - fairphone,fp1 - mundoreader,bq-aquaris5 - const: mediatek,mt6589 - items: diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index f9ffa5b703a5..763c62323a74 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -43,6 +43,9 @@ properties: "#clock-cells": const: 1 + '#reset-cells': + const: 1 + required: - compatible - reg @@ -56,4 +59,5 @@ examples: compatible = "mediatek,mt8173-mmsys", "syscon"; reg = <0x14000000 0x1000>; #clock-cells = <1>; + #reset-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml new file mode 100644 index 000000000000..17fcbb45d121 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml @@ -0,0 +1,254 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-clock.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek Functional Clock Controller for MT8195 + +maintainers: + - Chun-Jie Chen <chun-jie.chen@mediatek.com> + +description: + The clock architecture in Mediatek like below + PLLs --> + dividers --> + muxes + --> + clock gate + + The devices except apusys_pll provide clock gate control in different IP blocks. + The apusys_pll provides Plls which generated from SoC 26m for AI Processing Unit. + +properties: + compatible: + items: + - enum: + - mediatek,mt8195-scp_adsp + - mediatek,mt8195-imp_iic_wrap_s + - mediatek,mt8195-imp_iic_wrap_w + - mediatek,mt8195-mfgcfg + - mediatek,mt8195-vppsys0 + - mediatek,mt8195-wpesys + - mediatek,mt8195-wpesys_vpp0 + - mediatek,mt8195-wpesys_vpp1 + - mediatek,mt8195-vppsys1 + - mediatek,mt8195-imgsys + - mediatek,mt8195-imgsys1_dip_top + - mediatek,mt8195-imgsys1_dip_nr + - mediatek,mt8195-imgsys1_wpe + - mediatek,mt8195-ipesys + - mediatek,mt8195-camsys + - mediatek,mt8195-camsys_rawa + - mediatek,mt8195-camsys_yuva + - mediatek,mt8195-camsys_rawb + - mediatek,mt8195-camsys_yuvb + - mediatek,mt8195-camsys_mraw + - mediatek,mt8195-ccusys + - mediatek,mt8195-vdecsys_soc + - mediatek,mt8195-vdecsys + - mediatek,mt8195-vdecsys_core1 + - mediatek,mt8195-vencsys + - mediatek,mt8195-vencsys_core1 + - mediatek,mt8195-apusys_pll + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + scp_adsp: clock-controller@10720000 { + compatible = "mediatek,mt8195-scp_adsp"; + reg = <0x10720000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_s: clock-controller@11d03000 { + compatible = "mediatek,mt8195-imp_iic_wrap_s"; + reg = <0x11d03000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_w: clock-controller@11e05000 { + compatible = "mediatek,mt8195-imp_iic_wrap_w"; + reg = <0x11e05000 0x1000>; + #clock-cells = <1>; + }; + + - | + mfgcfg: clock-controller@13fbf000 { + compatible = "mediatek,mt8195-mfgcfg"; + reg = <0x13fbf000 0x1000>; + #clock-cells = <1>; + }; + + - | + vppsys0: clock-controller@14000000 { + compatible = "mediatek,mt8195-vppsys0"; + reg = <0x14000000 0x1000>; + #clock-cells = <1>; + }; + + - | + wpesys: clock-controller@14e00000 { + compatible = "mediatek,mt8195-wpesys"; + reg = <0x14e00000 0x1000>; + #clock-cells = <1>; + }; + + - | + wpesys_vpp0: clock-controller@14e02000 { + compatible = "mediatek,mt8195-wpesys_vpp0"; + reg = <0x14e02000 0x1000>; + #clock-cells = <1>; + }; + + - | + wpesys_vpp1: clock-controller@14e03000 { + compatible = "mediatek,mt8195-wpesys_vpp1"; + reg = <0x14e03000 0x1000>; + #clock-cells = <1>; + }; + + - | + vppsys1: clock-controller@14f00000 { + compatible = "mediatek,mt8195-vppsys1"; + reg = <0x14f00000 0x1000>; + #clock-cells = <1>; + }; + + - | + imgsys: clock-controller@15000000 { + compatible = "mediatek,mt8195-imgsys"; + reg = <0x15000000 0x1000>; + #clock-cells = <1>; + }; + + - | + imgsys1_dip_top: clock-controller@15110000 { + compatible = "mediatek,mt8195-imgsys1_dip_top"; + reg = <0x15110000 0x1000>; + #clock-cells = <1>; + }; + + - | + imgsys1_dip_nr: clock-controller@15130000 { + compatible = "mediatek,mt8195-imgsys1_dip_nr"; + reg = <0x15130000 0x1000>; + #clock-cells = <1>; + }; + + - | + imgsys1_wpe: clock-controller@15220000 { + compatible = "mediatek,mt8195-imgsys1_wpe"; + reg = <0x15220000 0x1000>; + #clock-cells = <1>; + }; + + - | + ipesys: clock-controller@15330000 { + compatible = "mediatek,mt8195-ipesys"; + reg = <0x15330000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys: clock-controller@16000000 { + compatible = "mediatek,mt8195-camsys"; + reg = <0x16000000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys_rawa: clock-controller@1604f000 { + compatible = "mediatek,mt8195-camsys_rawa"; + reg = <0x1604f000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys_yuva: clock-controller@1606f000 { + compatible = "mediatek,mt8195-camsys_yuva"; + reg = <0x1606f000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys_rawb: clock-controller@1608f000 { + compatible = "mediatek,mt8195-camsys_rawb"; + reg = <0x1608f000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys_yuvb: clock-controller@160af000 { + compatible = "mediatek,mt8195-camsys_yuvb"; + reg = <0x160af000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys_mraw: clock-controller@16140000 { + compatible = "mediatek,mt8195-camsys_mraw"; + reg = <0x16140000 0x1000>; + #clock-cells = <1>; + }; + + - | + ccusys: clock-controller@17200000 { + compatible = "mediatek,mt8195-ccusys"; + reg = <0x17200000 0x1000>; + #clock-cells = <1>; + }; + + - | + vdecsys_soc: clock-controller@1800f000 { + compatible = "mediatek,mt8195-vdecsys_soc"; + reg = <0x1800f000 0x1000>; + #clock-cells = <1>; + }; + + - | + vdecsys: clock-controller@1802f000 { + compatible = "mediatek,mt8195-vdecsys"; + reg = <0x1802f000 0x1000>; + #clock-cells = <1>; + }; + + - | + vdecsys_core1: clock-controller@1803f000 { + compatible = "mediatek,mt8195-vdecsys_core1"; + reg = <0x1803f000 0x1000>; + #clock-cells = <1>; + }; + + - | + vencsys: clock-controller@1a000000 { + compatible = "mediatek,mt8195-vencsys"; + reg = <0x1a000000 0x1000>; + #clock-cells = <1>; + }; + + - | + vencsys_core1: clock-controller@1b000000 { + compatible = "mediatek,mt8195-vencsys_core1"; + reg = <0x1b000000 0x1000>; + #clock-cells = <1>; + }; + + - | + apusys_pll: clock-controller@190f3000 { + compatible = "mediatek,mt8195-apusys_pll"; + reg = <0x190f3000 0x1000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml new file mode 100644 index 000000000000..57a1503d95fe --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-sys-clock.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek System Clock Controller for MT8195 + +maintainers: + - Chun-Jie Chen <chun-jie.chen@mediatek.com> + +description: + The clock architecture in Mediatek like below + PLLs --> + dividers --> + muxes + --> + clock gate + + The apmixedsys provides most of PLLs which generated from SoC 26m. + The topckgen provides dividers and muxes which provide the clock source to other IP blocks. + The infracfg_ao and pericfg_ao provides clock gate in peripheral and infrastructure IP blocks. + +properties: + compatible: + items: + - enum: + - mediatek,mt8195-topckgen + - mediatek,mt8195-infracfg_ao + - mediatek,mt8195-apmixedsys + - mediatek,mt8195-pericfg_ao + - const: syscon + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + topckgen: syscon@10000000 { + compatible = "mediatek,mt8195-topckgen", "syscon"; + reg = <0x10000000 0x1000>; + #clock-cells = <1>; + }; + + - | + infracfg_ao: syscon@10001000 { + compatible = "mediatek,mt8195-infracfg_ao", "syscon"; + reg = <0x10001000 0x1000>; + #clock-cells = <1>; + }; + + - | + apmixedsys: syscon@1000c000 { + compatible = "mediatek,mt8195-apmixedsys", "syscon"; + reg = <0x1000c000 0x1000>; + #clock-cells = <1>; + }; + + - | + pericfg_ao: syscon@11003000 { + compatible = "mediatek,mt8195-pericfg_ao", "syscon"; + reg = <0x11003000 0x1000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 880ddafc634e..c8808e0f9e64 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -25,6 +25,7 @@ description: | The 'SoC' element must be one of the following strings: apq8016 + apq8026 apq8074 apq8084 apq8096 @@ -44,6 +45,8 @@ description: | sdm660 sdm845 sdx55 + sdx65 + sm7225 sm8150 sm8250 sm8350 @@ -94,6 +97,14 @@ properties: - items: - enum: + - lg,lenok + - const: qcom,apq8026 + + - items: + - enum: + - asus,nexus7-flo + - lg,nexus4-mako + - sony,xperia-yuga - qcom,apq8064-cm-qs600 - qcom,apq8064-ifc6410 - const: qcom,apq8064 @@ -129,6 +140,7 @@ properties: - enum: - fairphone,fp2 - lge,hammerhead + - samsung,klte - sony,xperia-amami - sony,xperia-castor - sony,xperia-honami @@ -163,6 +175,7 @@ properties: - items: - enum: + - qcom,ipq4019-ap-dk01.1-c1 - qcom,ipq4019-ap-dk04.1-c3 - qcom,ipq4019-ap-dk07.1-c1 - qcom,ipq4019-ap-dk07.1-c2 @@ -208,6 +221,11 @@ properties: - items: - enum: + - qcom,sdx65-mtp + - const: qcom,sdx65 + + - items: + - enum: - qcom,ipq6018-cp01 - qcom,ipq6018-cp01-c1 - const: qcom,ipq6018 @@ -219,6 +237,11 @@ properties: - items: - enum: + - fairphone,fp4 + - const: qcom,sm7225 + + - items: + - enum: - qcom,sm8150-mtp - const: qcom,sm8150 diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index 8a11918866b8..517206507801 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -255,12 +255,19 @@ properties: - enum: - renesas,h3ulcb - renesas,m3ulcb + - renesas,m3nulcb - enum: + - renesas,r8a779m0 - renesas,r8a779m1 + - renesas,r8a779m2 - renesas,r8a779m3 + - renesas,r8a779m4 + - renesas,r8a779m5 + - renesas,r8a779m8 - enum: - renesas,r8a7795 - renesas,r8a77961 + - renesas,r8a77965 - description: R-Car M3-N (R8A77965) items: @@ -308,6 +315,14 @@ properties: - const: renesas,falcon-cpu - const: renesas,r8a779a0 + - description: R-Car H3e (R8A779M0) + items: + - enum: + - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier) + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version) + - const: renesas,r8a779m0 + - const: renesas,r8a7795 + - description: R-Car H3e-2G (R8A779M1) items: - enum: @@ -316,6 +331,14 @@ properties: - const: renesas,r8a779m1 - const: renesas,r8a7795 + - description: R-Car M3e (R8A779M2) + items: + - enum: + - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro) + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version) + - const: renesas,r8a779m2 + - const: renesas,r8a77961 + - description: R-Car M3e-2G (R8A779M3) items: - enum: @@ -324,6 +347,44 @@ properties: - const: renesas,r8a779m3 - const: renesas,r8a77961 + - description: R-Car M3Ne (R8A779M4) + items: + - enum: + - renesas,m3nulcb # M3NULCB (R-Car Starter Kit Pro) + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version) + - const: renesas,r8a779m4 + - const: renesas,r8a77965 + + - description: R-Car M3Ne-2G (R8A779M5) + items: + - enum: + - renesas,m3nulcb # M3NULCB (R-Car Starter Kit Pro) + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version) + - const: renesas,r8a779m5 + - const: renesas,r8a77965 + + - description: R-Car E3e (R8A779M6) + items: + - enum: + - renesas,ebisu # Ebisu + - const: renesas,r8a779m6 + - const: renesas,r8a77990 + + - description: R-Car D3e (R8A779M7) + items: + - enum: + - renesas,draak # Draak + - const: renesas,r8a779m7 + - const: renesas,r8a77995 + + - description: R-Car H3Ne (R8A779M8) + items: + - enum: + - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier) + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version) + - const: renesas,r8a779m8 + - const: renesas,r8a7795 + - description: RZ/N1D (R9A06G032) items: - enum: diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 6546b015fc62..4aed16176434 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -115,6 +115,11 @@ properties: - const: firefly,roc-rk3328-cc - const: rockchip,rk3328 + - description: Firefly ROC-RK3328-PC + items: + - const: firefly,roc-rk3328-pc + - const: rockchip,rk3328 + - description: Firefly ROC-RK3399-PC items: - enum: @@ -122,6 +127,12 @@ properties: - firefly,roc-rk3399-pc-mezzanine - const: rockchip,rk3399 + - description: Firefly ROC-RK3399-PC-PLUS + items: + - enum: + - firefly,roc-rk3399-pc-plus + - const: rockchip,rk3399 + - description: FriendlyElec NanoPi R2S items: - const: friendlyarm,nanopi-r2s @@ -287,6 +298,34 @@ properties: - const: google,veyron - const: rockchip,rk3288 + - description: Google Scarlet - Dumo (ASUS Chromebook Tablet CT100) + items: + - const: google,scarlet-rev15-sku0 + - const: google,scarlet-rev15 + - const: google,scarlet-rev14-sku0 + - const: google,scarlet-rev14 + - const: google,scarlet-rev13-sku0 + - const: google,scarlet-rev13 + - const: google,scarlet-rev12-sku0 + - const: google,scarlet-rev12 + - const: google,scarlet-rev11-sku0 + - const: google,scarlet-rev11 + - const: google,scarlet-rev10-sku0 + - const: google,scarlet-rev10 + - const: google,scarlet-rev9-sku0 + - const: google,scarlet-rev9 + - const: google,scarlet-rev8-sku0 + - const: google,scarlet-rev8 + - const: google,scarlet-rev7-sku0 + - const: google,scarlet-rev7 + - const: google,scarlet-rev6-sku0 + - const: google,scarlet-rev6 + - const: google,scarlet-rev5-sku0 + - const: google,scarlet-rev5 + - const: google,scarlet + - const: google,gru + - const: rockchip,rk3399 + - description: Google Scarlet - Kingdisplay (Acer Chromebook Tab 10) items: - const: google,scarlet-rev15-sku7 @@ -455,16 +494,23 @@ properties: - const: pine64,rockpro64 - const: rockchip,rk3399 + - description: Pine64 Quartz64 Model A + items: + - const: pine64,quartz64-a + - const: rockchip,rk3566 + - description: Radxa Rock items: - const: radxa,rock - const: rockchip,rk3188 - - description: Radxa ROCK Pi 4A/B/C + - description: Radxa ROCK Pi 4A/A+/B/B+/C items: - enum: - radxa,rockpi4a + - radxa,rockpi4a-plus - radxa,rockpi4b + - radxa,rockpi4b-plus - radxa,rockpi4c - const: radxa,rockpi4 - const: rockchip,rk3399 diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml index 53115b92d17f..5ece38065e54 100644 --- a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml @@ -22,7 +22,9 @@ select: - rockchip,px30-pmu - rockchip,rk3066-pmu - rockchip,rk3288-pmu + - rockchip,rk3368-pmu - rockchip,rk3399-pmu + - rockchip,rk3568-pmu required: - compatible @@ -34,7 +36,9 @@ properties: - rockchip,px30-pmu - rockchip,rk3066-pmu - rockchip,rk3288-pmu + - rockchip,rk3368-pmu - rockchip,rk3399-pmu + - rockchip,rk3568-pmu - const: syscon - const: simple-mfd diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml index f99c0c6df21b..bfc352a2fdd6 100644 --- a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml @@ -11,8 +11,9 @@ maintainers: properties: compatible: - items: - - const: samsung,exynos4210-chipid + enum: + - samsung,exynos4210-chipid + - samsung,exynos850-chipid reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml index 0796f0c87727..ef6dc14be4b5 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml @@ -199,6 +199,12 @@ properties: - samsung,exynos7-espresso # Samsung Exynos7 Espresso - const: samsung,exynos7 + - description: Exynos Auto v9 based boards + items: + - enum: + - samsung,exynosautov9-sadk # Samsung Exynos Auto v9 SADK + - const: samsung,exynosautov9 + required: - compatible diff --git a/Documentation/devicetree/bindings/arm/sprd/sprd.yaml b/Documentation/devicetree/bindings/arm/sprd/sprd.yaml index 7b6ae3070396..2c12e571394b 100644 --- a/Documentation/devicetree/bindings/arm/sprd/sprd.yaml +++ b/Documentation/devicetree/bindings/arm/sprd/sprd.yaml @@ -30,6 +30,11 @@ properties: - sprd,sp9863a-1h10 - const: sprd,sc9863a + - items: + - enum: + - sprd,ums512-1h10 + - const: sprd,ums512 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/sti.yaml b/Documentation/devicetree/bindings/arm/sti.yaml index b1f28d16d3fb..a41cd8764885 100644 --- a/Documentation/devicetree/bindings/arm/sti.yaml +++ b/Documentation/devicetree/bindings/arm/sti.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ST STi Platforms Device Tree Bindings maintainers: - - Patrice Chotard <patrice.chotard@st.com> + - Patrice Chotard <patrice.chotard@foss.st.com> properties: $nodename: diff --git a/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml b/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml index 8e711bd202fd..ecb28e90fd11 100644 --- a/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml @@ -7,8 +7,8 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: STMicroelectronics STM32 ML-AHB interconnect bindings maintainers: - - Fabien Dessenne <fabien.dessenne@st.com> - - Arnaud Pouliquen <arnaud.pouliquen@st.com> + - Fabien Dessenne <fabien.dessenne@foss.st.com> + - Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> description: | These bindings describe the STM32 SoCs ML-AHB interconnect bus which connects diff --git a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml index 149afb5df5af..6f846d69c5e1 100644 --- a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml @@ -7,8 +7,8 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: STMicroelectronics STM32 Platforms System Controller bindings maintainers: - - Alexandre Torgue <alexandre.torgue@st.com> - - Christophe Roullier <christophe.roullier@st.com> + - Alexandre Torgue <alexandre.torgue@foss.st.com> + - Christophe Roullier <christophe.roullier@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 9a77ab74be99..bcaf7be3ab37 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 Platforms Device Tree Bindings maintainers: - - Alexandre Torgue <alexandre.torgue@st.com> + - Alexandre Torgue <alexandre.torgue@foss.st.com> properties: $nodename: @@ -57,6 +57,10 @@ properties: - const: st,stm32h750 - items: - enum: + - st,stm32mp135f-dk + - const: st,stm32mp135 + - items: + - enum: - shiratech,stm32mp157a-iot-box # IoT Box - shiratech,stm32mp157a-stinger96 # Stinger96 - st,stm32mp157c-ed1 diff --git a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml index e713a6fe4cf7..29c9961ee2d8 100644 --- a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml @@ -30,6 +30,7 @@ properties: enum: - allwinner,sun5i-a13-mbus - allwinner,sun8i-h3-mbus + - allwinner,sun8i-r40-mbus - allwinner,sun50i-a64-mbus reg: diff --git a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml new file mode 100644 index 000000000000..f3878e0b3cc4 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner CPU Configuration Controller Device Tree Bindings + +maintainers: + - Chen-Yu Tsai <wens@csie.org> + - Maxime Ripard <mripard@kernel.org> + +properties: + compatible: + enum: + - allwinner,sun6i-a31-cpuconfig + - allwinner,sun8i-a23-cpuconfig + - allwinner,sun8i-a83t-cpucfg + - allwinner,sun8i-a83t-r-cpucfg + - allwinner,sun9i-a80-cpucfg + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + cpucfg@1f01c00 { + compatible = "allwinner,sun6i-a31-cpuconfig"; + reg = <0x01f01c00 0x300>; + }; + +... diff --git a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml new file mode 100644 index 000000000000..668aadbfe4c0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/sunxi/allwinner,sun9i-a80-prcm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A80 PRCM Device Tree Bindings + +maintainers: + - Chen-Yu Tsai <wens@csie.org> + - Maxime Ripard <mripard@kernel.org> + +properties: + compatible: + const: allwinner,sun9i-a80-prcm + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + prcm@8001400 { + compatible = "allwinner,sun9i-a80-prcm"; + reg = <0x08001400 0x200>; + }; + +... diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index c5aa362e4026..cf327230fc0e 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -24,16 +24,27 @@ properties: - enum: - ti,am654-evm - siemens,iot2050-basic + - siemens,iot2050-basic-pg2 - siemens,iot2050-advanced + - siemens,iot2050-advanced-pg2 - const: ti,am654 - description: K3 J721E SoC - items: + oneOf: - const: ti,j721e + - items: + - enum: + - ti,j721e-evm + - ti,j721e-sk + - const: ti,j721e - description: K3 J7200 SoC - items: + oneOf: - const: ti,j7200 + - items: + - enum: + - ti,j7200-evm + - const: ti,j7200 - description: K3 AM642 SoC items: diff --git a/Documentation/devicetree/bindings/arm/toshiba.yaml b/Documentation/devicetree/bindings/arm/toshiba.yaml index 001bbbcd1432..9c1cacbdc916 100644 --- a/Documentation/devicetree/bindings/arm/toshiba.yaml +++ b/Documentation/devicetree/bindings/arm/toshiba.yaml @@ -18,6 +18,7 @@ properties: items: - enum: - toshiba,tmpv7708-rm-mbrc # TMPV7708 RM main board + - toshiba,tmpv7708-visrobo-vrb # TMPV7708 VisROBO VRB board - const: toshiba,tmpv7708 additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/xilinx.yaml b/Documentation/devicetree/bindings/arm/xilinx.yaml index f52c7e8ce654..4dc0e0195974 100644 --- a/Documentation/devicetree/bindings/arm/xilinx.yaml +++ b/Documentation/devicetree/bindings/arm/xilinx.yaml @@ -87,6 +87,7 @@ properties: - xlnx,zynqmp-zcu102-revA - xlnx,zynqmp-zcu102-revB - xlnx,zynqmp-zcu102-rev1.0 + - xlnx,zynqmp-zcu102-rev1.1 - const: xlnx,zynqmp-zcu102 - const: xlnx,zynqmp @@ -115,6 +116,22 @@ properties: - const: xlnx,zynqmp-zcu111 - const: xlnx,zynqmp + - description: Xilinx Kria SOMs + items: + - const: xlnx,zynqmp-sm-k26-rev1 + - const: xlnx,zynqmp-sm-k26-revB + - const: xlnx,zynqmp-sm-k26-revA + - const: xlnx,zynqmp-sm-k26 + - const: xlnx,zynqmp + + - description: Xilinx Kria SOMs (starter) + items: + - const: xlnx,zynqmp-smk-k26-rev1 + - const: xlnx,zynqmp-smk-k26-revB + - const: xlnx,zynqmp-smk-k26-revA + - const: xlnx,zynqmp-smk-k26 + - const: xlnx,zynqmp + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml index 64ffff460026..fc4873deb76f 100644 --- a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml +++ b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml @@ -14,14 +14,21 @@ allOf: properties: compatible: - const: holtek,ht16k33 + oneOf: + - items: + - enum: + - adafruit,3108 # 0.56" 4-Digit 7-Segment FeatherWing Display (Red) + - adafruit,3130 # 0.54" Quad Alphanumeric FeatherWing Display (Red) + - const: holtek,ht16k33 + + - const: holtek,ht16k33 # Generic 16*8 LED controller with dot-matrix display reg: maxItems: 1 refresh-rate-hz: maxItems: 1 - description: Display update interval in Hertz + description: Display update interval in Hertz for dot-matrix displays interrupts: maxItems: 1 @@ -41,10 +48,22 @@ properties: default: 16 description: Initial brightness level + led: + type: object + $ref: /schemas/leds/common.yaml# + unevaluatedProperties: false + required: - compatible - reg - - refresh-rate-hz + +if: + properties: + compatible: + const: holtek,ht16k33 +then: + required: + - refresh-rate-hz additionalProperties: false @@ -52,6 +71,7 @@ examples: - | #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/input/input.h> + #include <dt-bindings/leds/common.h> i2c1 { #address-cells = <1>; #size-cells = <0>; @@ -73,5 +93,11 @@ examples: <MATRIX_KEY(4, 1, KEY_F9)>, <MATRIX_KEY(5, 1, KEY_F3)>, <MATRIX_KEY(6, 1, KEY_F1)>; + + led { + color = <LED_COLOR_ID_RED>; + function = LED_FUNCTION_BACKLIGHT; + linux,default-trigger = "backlight"; + }; }; }; diff --git a/Documentation/devicetree/bindings/bus/palmbus.yaml b/Documentation/devicetree/bindings/bus/palmbus.yaml new file mode 100644 index 000000000000..f5cbfaf52d53 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/palmbus.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/palmbus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink PalmBus Device Tree Bindings + +maintainers: + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +description: | + The ralink palmbus controller can be found in all ralink MIPS + SoCs. It provides an external bus for connecting multiple + external devices to the SoC. + +properties: + $nodename: + pattern: "^palmbus(@[0-9a-f]+)?$" + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + compatible: + const: palmbus + + reg: + maxItems: 1 + + ranges: true + +patternProperties: + # All other properties should be child nodes with unit-address and 'reg' + "@[0-9a-f]+$": + type: object + properties: + reg: + maxItems: 1 + + required: + - reg + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/mips-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + palmbus@1e000000 { + compatible = "palmbus"; + reg = <0x1e000000 0x100000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x1e000000 0x0fffff>; + + gpio@600 { + #gpio-cells = <2>; + #interrupt-cells = <2>; + compatible = "mediatek,mt7621-gpio"; + gpio-controller; + gpio-ranges = <&pinctrl 0 0 95>; + interrupt-controller; + reg = <0x600 0x100>; + interrupt-parent = <&gic>; + interrupts = <GIC_SHARED 12 IRQ_TYPE_LEVEL_HIGH>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.txt b/Documentation/devicetree/bindings/bus/ti-sysc.txt deleted file mode 100644 index c984143d08d2..000000000000 --- a/Documentation/devicetree/bindings/bus/ti-sysc.txt +++ /dev/null @@ -1,139 +0,0 @@ -Texas Instruments sysc interconnect target module wrapper binding - -Texas Instruments SoCs can have a generic interconnect target module -hardware for devices connected to various interconnects such as L3 -interconnect (Arteris NoC) and L4 interconnect (Sonics s3220). The sysc -is mostly used for interaction between module and PRCM. It participates -in the OCP Disconnect Protocol but other than that is mostly independent -of the interconnect. - -Each interconnect target module can have one or more devices connected to -it. There is a set of control registers for managing interconnect target -module clocks, idle modes and interconnect level resets for the module. - -These control registers are sprinkled into the unused register address -space of the first child device IP block managed by the interconnect -target module and typically are named REVISION, SYSCONFIG and SYSSTATUS. - -Required standard properties: - -- compatible shall be one of the following generic types: - - "ti,sysc" - "ti,sysc-omap2" - "ti,sysc-omap4" - "ti,sysc-omap4-simple" - - or one of the following derivative types for hardware - needing special workarounds: - - "ti,sysc-omap2-timer" - "ti,sysc-omap4-timer" - "ti,sysc-omap3430-sr" - "ti,sysc-omap3630-sr" - "ti,sysc-omap4-sr" - "ti,sysc-omap3-sham" - "ti,sysc-omap-aes" - "ti,sysc-mcasp" - "ti,sysc-dra7-mcasp" - "ti,sysc-usb-host-fs" - "ti,sysc-dra7-mcan" - "ti,sysc-pruss" - -- reg shall have register areas implemented for the interconnect - target module in question such as revision, sysc and syss - -- reg-names shall contain the register names implemented for the - interconnect target module in question such as - "rev, "sysc", and "syss" - -- ranges shall contain the interconnect target module IO range - available for one or more child device IP blocks managed - by the interconnect target module, the ranges may include - multiple ranges such as device L4 range for control and - parent L3 range for DMA access - -Optional properties: - -- ti,sysc-mask shall contain mask of supported register bits for the - SYSCONFIG register as documented in the Technical Reference - Manual (TRM) for the interconnect target module - -- ti,sysc-midle list of master idle modes supported by the interconnect - target module as documented in the TRM for SYSCONFIG - register MIDLEMODE bits - -- ti,sysc-sidle list of slave idle modes supported by the interconnect - target module as documented in the TRM for SYSCONFIG - register SIDLEMODE bits - -- ti,sysc-delay-us delay needed after OCP softreset before accssing - SYSCONFIG register again - -- ti,syss-mask optional mask of reset done status bits as described in the - TRM for SYSSTATUS registers, typically 1 with some devices - having separate reset done bits for children like OHCI and - EHCI - -- clocks clock specifier for each name in the clock-names as - specified in the binding documentation for ti-clkctrl, - typically available for all interconnect targets on TI SoCs - based on omap4 except if it's read-only register in hwauto - mode as for example omap4 L4_CFG_CLKCTRL - -- clock-names should contain at least "fck", and optionally also "ick" - depending on the SoC and the interconnect target module, - some interconnect target modules also need additional - optional clocks that can be specified as listed in TRM - for the related CLKCTRL register bits 8 to 15 such as - "dbclk" or "clk32k" depending on their role - -- ti,hwmods optional TI interconnect module name to use legacy - hwmod platform data - -- ti,no-reset-on-init interconnect target module should not be reset at init - -- ti,no-idle-on-init interconnect target module should not be idled at init - -- ti,no-idle interconnect target module should not be idled - -Example: Single instance of MUSB controller on omap4 using interconnect ranges -using offsets from l4_cfg second segment (0x4a000000 + 0x80000 = 0x4a0ab000): - - target-module@2b000 { /* 0x4a0ab000, ap 84 12.0 */ - compatible = "ti,sysc-omap2"; - ti,hwmods = "usb_otg_hs"; - reg = <0x2b400 0x4>, - <0x2b404 0x4>, - <0x2b408 0x4>; - reg-names = "rev", "sysc", "syss"; - clocks = <&l3_init_clkctrl OMAP4_USB_OTG_HS_CLKCTRL 0>; - clock-names = "fck"; - ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP | - SYSC_OMAP2_SOFTRESET | - SYSC_OMAP2_AUTOIDLE)>; - ti,sysc-midle = <SYSC_IDLE_FORCE>, - <SYSC_IDLE_NO>, - <SYSC_IDLE_SMART>; - ti,sysc-sidle = <SYSC_IDLE_FORCE>, - <SYSC_IDLE_NO>, - <SYSC_IDLE_SMART>, - <SYSC_IDLE_SMART_WKUP>; - ti,syss-mask = <1>; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x2b000 0x1000>; - - usb_otg_hs: otg@0 { - compatible = "ti,omap4-musb"; - reg = <0x0 0x7ff>; - interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>; - usb-phy = <&usb2_phy>; - ... - }; - }; - -Note that other SoCs, such as am335x can have multiple child devices. On am335x -there are two MUSB instances, two USB PHY instances, and a single CPPI41 DMA -instance as children of a single interconnect target module. diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.yaml b/Documentation/devicetree/bindings/bus/ti-sysc.yaml new file mode 100644 index 000000000000..bd40213302da --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ti-sysc.yaml @@ -0,0 +1,216 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/ti-sysc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments interconnect target module binding + +maintainers: + - Tony Lindgren <tony@atomide.com> + +description: + Texas Instruments SoCs can have a generic interconnect target module + for devices connected to various interconnects such as L3 interconnect + using Arteris NoC, and L4 interconnect using Sonics s3220. This module + is mostly used for interaction between module and Power, Reset and Clock + Manager PRCM. It participates in the OCP Disconnect Protocol, but other + than that it is mostly independent of the interconnect. + + Each interconnect target module can have one or more devices connected to + it. There is a set of control registers for managing the interconnect target + module clocks, idle modes and interconnect level resets. + + The interconnect target module control registers are sprinkled into the + unused register address space of the first child device IP block managed by + the interconnect target module. Typically the register names are REVISION, + SYSCONFIG and SYSSTATUS. + +properties: + $nodename: + pattern: "^target-module(@[0-9a-f]+)?$" + + compatible: + oneOf: + - items: + - enum: + - ti,sysc-omap2 + - ti,sysc-omap2 + - ti,sysc-omap4 + - ti,sysc-omap4-simple + - ti,sysc-omap2-timer + - ti,sysc-omap4-timer + - ti,sysc-omap3430-sr + - ti,sysc-omap3630-sr + - ti,sysc-omap4-sr + - ti,sysc-omap3-sham + - ti,sysc-omap-aes + - ti,sysc-mcasp + - ti,sysc-dra7-mcasp + - ti,sysc-usb-host-fs + - ti,sysc-dra7-mcan + - ti,sysc-pruss + - const: ti,sysc + - items: + - const: ti,sysc + + reg: + description: + Interconnect target module control registers consisting of + REVISION, SYSCONFIG and SYSSTATUS registers as defined in the + Technical Reference Manual for the SoC. + minItems: 1 + maxItems: 3 + + reg-names: + description: + Interconnect target module control register names consisting + of "rev", "sysc" and "syss". + oneOf: + - minItems: 1 + items: + - const: rev + - const: sysc + - const: syss + - items: + - const: rev + - const: syss + - enum: [ sysc, syss ] + + power-domains: + description: Target module power domain if available. + maxItems: 1 + + clocks: + description: + Target module clocks consisting of one functional clock, one + interface clock, and up to 8 module specific optional clocks. + Some modules may have only the functional clock, and some have + no configurable clocks. + minItems: 1 + maxItems: 4 + + clock-names: + description: + Target module clock names like "fck", "ick", "optck1", "optck2" + if the clocks are configurable. + oneOf: + - enum: [ ick, fck, sys_clk ] + - items: + - const: fck + - enum: [ ick. dbclk, osc, sys_clk, dss_clk, ahclkx ] + - items: + - const: fck + - const: phy-clk + - const: phy-clk-div + - items: + - const: fck + - const: hdmi_clk + - const: sys_clk + - const: tv_clk + - items: + - const: fck + - const: ahclkx + - const: ahclkr + + resets: + description: + Target module reset bit in the RSTCTRL register if wired for the module. + Note that the other reset bits should be mapped for the child device + driver to use. + maxItems: 1 + + reset-names: + description: + Target module reset names in the RSTCTRL register, typically named + "rstctrl" if only one reset bit is wired for the module. + items: + - const: rstctrl + + '#address-cells': + enum: [ 1, 2 ] + + '#size-cells': + enum: [ 1, 2 ] + + ranges: true + + dma-ranges: true + + ti,sysc-mask: + description: Mask of supported register bits for the SYSCONFIG register + $ref: /schemas/types.yaml#/definitions/uint32 + + ti,sysc-midle: + description: List of hardware supported idle modes + $ref: /schemas/types.yaml#/definitions/uint32-array + + ti,sysc-sidle: + description: List of hardware supported idle modes + $ref: /schemas/types.yaml#/definitions/uint32-array + + ti,syss-mask: + description: Mask of supported register bits for the SYSSTATUS register + $ref: /schemas/types.yaml#/definitions/uint32 + + ti,sysc-delay-us: + description: Delay needed after OCP softreset before accessing SYCONFIG + default: 0 + minimum: 0 + maximum: 2 + + ti,no-reset-on-init: + description: Interconnect target module shall not be reset at init + type: boolean + + ti,no-idle-on-init: + description: Interconnect target module shall not be idled at init + type: boolean + + ti,no-idle: + description: Interconnect target module shall not be idled + type: boolean + + ti,hwmods: + description: Interconnect module name to use with legacy hwmod data + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + +required: + - compatible + - '#address-cells' + - '#size-cells' + - ranges + +additionalProperties: + type: object + +examples: + - | + #include <dt-bindings/bus/ti-sysc.h> + #include <dt-bindings/clock/omap4.h> + + target-module@2b000 { + compatible = "ti,sysc-omap2", "ti,sysc"; + ti,hwmods = "usb_otg_hs"; + reg = <0x2b400 0x4>, + <0x2b404 0x4>, + <0x2b408 0x4>; + reg-names = "rev", "sysc", "syss"; + clocks = <&l3_init_clkctrl OMAP4_USB_OTG_HS_CLKCTRL 0>; + clock-names = "fck"; + ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP | + SYSC_OMAP2_SOFTRESET | + SYSC_OMAP2_AUTOIDLE)>; + ti,sysc-midle = <SYSC_IDLE_FORCE>, + <SYSC_IDLE_NO>, + <SYSC_IDLE_SMART>; + ti,sysc-sidle = <SYSC_IDLE_FORCE>, + <SYSC_IDLE_NO>, + <SYSC_IDLE_SMART>, + <SYSC_IDLE_SMART_WKUP>; + ti,syss-mask = <1>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x2b000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml index 3f995d2b30eb..e79eeac5f086 100644 --- a/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml +++ b/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml @@ -24,7 +24,7 @@ properties: - const: allwinner,sun8i-v3s-de2-clk - const: allwinner,sun50i-a64-de2-clk - const: allwinner,sun50i-h5-de2-clk - - const: allwinner,sun50i-h6-de2-clk + - const: allwinner,sun50i-h6-de3-clk - items: - const: allwinner,sun8i-r40-de2-clk - const: allwinner,sun8i-h3-de2-clk diff --git a/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml b/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml index 118c5543e037..90eadf6869b2 100644 --- a/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml +++ b/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml @@ -69,6 +69,10 @@ properties: - arm,impd1-vco1 - arm,impd1-vco2 + reg: + maxItems: 1 + description: The VCO register + clocks: description: Parent clock for the ICST VCO maxItems: 1 @@ -83,6 +87,7 @@ properties: vco-offset: $ref: '/schemas/types.yaml#/definitions/uint32' description: Offset to the VCO register for the oscillator + deprecated: true required: - "#clock-cells" diff --git a/Documentation/devicetree/bindings/clock/fixed-mmio-clock.txt b/Documentation/devicetree/bindings/clock/fixed-mmio-clock.txt deleted file mode 100644 index c359367fd1a9..000000000000 --- a/Documentation/devicetree/bindings/clock/fixed-mmio-clock.txt +++ /dev/null @@ -1,24 +0,0 @@ -Binding for simple memory mapped io fixed-rate clock sources. -The driver reads a clock frequency value from a single 32-bit memory mapped -I/O register and registers it as a fixed rate clock. - -It was designed for test systems, like FPGA, not for complete, finished SoCs. - -This binding uses the common clock binding[1]. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt - -Required properties: -- compatible : shall be "fixed-mmio-clock". -- #clock-cells : from common clock binding; shall be set to 0. -- reg : Address and length of the clock value register set. - -Optional properties: -- clock-output-names : From common clock binding. - -Example: -sysclock: sysclock@fd020004 { - #clock-cells = <0>; - compatible = "fixed-mmio-clock"; - reg = <0xfd020004 0x4>; -}; diff --git a/Documentation/devicetree/bindings/clock/fixed-mmio-clock.yaml b/Documentation/devicetree/bindings/clock/fixed-mmio-clock.yaml new file mode 100644 index 000000000000..1453ac849a65 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/fixed-mmio-clock.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/fixed-mmio-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for simple memory mapped IO fixed-rate clock sources + +description: + This binding describes a fixed-rate clock for which the frequency can + be read from a single 32-bit memory mapped I/O register. + + It was designed for test systems, like FPGA, not for complete, + finished SoCs. + +maintainers: + - Jan Kotas <jank@cadence.com> + +properties: + compatible: + const: fixed-mmio-clock + + reg: + maxItems: 1 + + "#clock-cells": + const: 0 + + clock-output-names: + maxItems: 1 + +required: + - compatible + - reg + - "#clock-cells" + +additionalProperties: false + +examples: + - | + sysclock: sysclock@fd020004 { + compatible = "fixed-mmio-clock"; + #clock-cells = <0>; + reg = <0xfd020004 0x4>; + clock-output-names = "sysclk"; + }; +... diff --git a/Documentation/devicetree/bindings/clock/imx8ulp-cgc-clock.yaml b/Documentation/devicetree/bindings/clock/imx8ulp-cgc-clock.yaml new file mode 100644 index 000000000000..71f7186b135b --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx8ulp-cgc-clock.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx8ulp-cgc-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8ULP Clock Generation & Control(CGC) Module Binding + +maintainers: + - Jacky Bai <ping.bai@nxp.com> + +description: | + On i.MX8ULP, The clock sources generation, distribution and management is + under the control of several CGCs & PCCs modules. The CGC modules generate + and distribute clocks on the device. + +properties: + compatible: + enum: + - fsl,imx8ulp-cgc1 + - fsl,imx8ulp-cgc2 + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + # Clock Generation & Control Module node: + - | + clock-controller@292c0000 { + compatible = "fsl,imx8ulp-cgc1"; + reg = <0x292c0000 0x10000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/imx8ulp-pcc-clock.yaml b/Documentation/devicetree/bindings/clock/imx8ulp-pcc-clock.yaml new file mode 100644 index 000000000000..00612725bf8b --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx8ulp-pcc-clock.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx8ulp-pcc-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8ULP Peripheral Clock Controller(PCC) Module Binding + +maintainers: + - Jacky Bai <ping.bai@nxp.com> + +description: | + On i.MX8ULP, The clock sources generation, distribution and management is + under the control of several CGCs & PCCs modules. The PCC modules control + software reset, clock selection, optional division and clock gating mode + for peripherals. + +properties: + compatible: + enum: + - fsl,imx8ulp-pcc3 + - fsl,imx8ulp-pcc4 + - fsl,imx8ulp-pcc5 + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + - '#reset-cells' + +additionalProperties: false + +examples: + # Peripheral Clock Control Module node: + - | + clock-controller@292d0000 { + compatible = "fsl,imx8ulp-pcc3"; + reg = <0x292d0000 0x10000>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml index 6e80dbc8b8b9..aa1df03ef4a6 100644 --- a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml +++ b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml @@ -104,7 +104,7 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/jz4770-cgu.h> + #include <dt-bindings/clock/ingenic,jz4770-cgu.h> cgu: clock-controller@10000000 { compatible = "ingenic,jz4770-cgu", "simple-mfd"; reg = <0x10000000 0x100>; diff --git a/Documentation/devicetree/bindings/clock/maxim,max77686.txt b/Documentation/devicetree/bindings/clock/maxim,max77686.txt index 3472b461ca93..c10849efb444 100644 --- a/Documentation/devicetree/bindings/clock/maxim,max77686.txt +++ b/Documentation/devicetree/bindings/clock/maxim,max77686.txt @@ -49,7 +49,7 @@ Example: max77686: max77686@9 { compatible = "maxim,max77686"; interrupt-parent = <&wakeup_eint>; - interrupts = <26 0>; + interrupts = <26 IRQ_TYPE_LEVEL_LOW>; reg = <0x09>; #clock-cells = <1>; @@ -74,7 +74,7 @@ Example: max77802: max77802@9 { compatible = "maxim,max77802"; interrupt-parent = <&wakeup_eint>; - interrupts = <26 0>; + interrupts = <26 IRQ_TYPE_LEVEL_LOW>; reg = <0x09>; #clock-cells = <1>; diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml index 6667261dc665..31497677e8de 100644 --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml @@ -56,6 +56,16 @@ properties: reg: maxItems: 1 + power-domains: + description: + A phandle and PM domain specifier for the MMCX power domain. + maxItems: 1 + + required-opps: + description: + A phandle to an OPP node describing required MMCX performance point. + maxItems: 1 + required: - compatible - reg @@ -70,6 +80,7 @@ additionalProperties: false examples: - | #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/power/qcom-rpmpd.h> clock-controller@af00000 { compatible = "qcom,sm8250-dispcc"; reg = <0x0af00000 0x10000>; @@ -90,5 +101,7 @@ examples: #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; + power-domains = <&rpmhpd SM8250_MMCX>; + required-opps = <&rpmhpd_opp_low_svs>; }; ... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml new file mode 100644 index 000000000000..22e67b238bb6 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8994.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding for MSM8994 + +maintainers: + - Konrad Dybcio <konrad.dybcio@somainline.org> + +description: | + Qualcomm global clock control module which supports the clocks, resets and + power domains on MSM8994 and MSM8992. + + See also: + - dt-bindings/clock/qcom,gcc-msm8994.h + +properties: + compatible: + enum: + - qcom,gcc-msm8992 + - qcom,gcc-msm8994 + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + + clock-names: + items: + - const: xo + - const: sleep + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - reg + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + clock-controller@300000 { + compatible = "qcom,gcc-msm8994"; + reg = <0x00300000 0x90000>; + clocks = <&xo_board>, <&sleep_clk>; + clock-names = "xo", "sleep"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml index a0bb713929b0..8151c0a05649 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml @@ -25,21 +25,17 @@ properties: items: - description: Board XO source - description: Sleep clock source - - description: USB 3.0 phy pipe clock - - description: UFS phy rx symbol clock for pipe 0 - - description: UFS phy rx symbol clock for pipe 1 - - description: UFS phy tx symbol clock - - description: PCIE phy pipe clock + - description: Audio reference clock (Optional clock) + - description: PLL test clock source (Optional clock) + minItems: 2 clock-names: items: - const: xo - const: sleep_clk - - const: usb3_pipe - - const: ufs_rx_symbol0 - - const: ufs_rx_symbol1 - - const: ufs_tx_symbol0 - - const: pcie0_pipe + - const: aud_ref_clk # Optional clock + - const: core_bi_pll_test_se # Optional clock + minItems: 2 '#clock-cells': const: 1 @@ -80,16 +76,10 @@ examples: clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, <&sleep>, <0>, - <0>, - <0>, - <0>, <0>; clock-names = "xo", "sleep_clk", - "usb3_pipe", - "ufs_rx_symbol0", - "ufs_rx_symbol1", - "ufs_tx_symbol0", - "pcie0_pipe"; + "aud_ref_clk", + "core_bi_pll_test_se"; }; ... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-qcm2290.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-qcm2290.yaml new file mode 100644 index 000000000000..5de9c8263138 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-qcm2290.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-qcm2290.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding for QCM2290 + +maintainers: + - Shawn Guo <shawn.guo@linaro.org> + +description: | + Qualcomm global clock control module which supports the clocks, resets + and power domains on QCM2290. + + See also: + - dt-bindings/clock/qcom,gcc-qcm2290.h + +properties: + compatible: + const: qcom,gcc-qcm2290 + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + + clock-names: + items: + - const: bi_tcxo + - const: sleep_clk + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + + protected-clocks: + description: + Protected clock specifier list as per common clock binding. + +required: + - compatible + - clocks + - clock-names + - reg + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmcc.h> + clock-controller@1400000 { + compatible = "qcom,gcc-qcm2290"; + reg = <0x01400000 0x1f0000>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + clock-names = "bi_tcxo", "sleep_clk"; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, <&sleep_clk>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml index 2f20f8aa932a..f66d703bd913 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml @@ -29,7 +29,6 @@ description: | - dt-bindings/reset/qcom,gcc-msm8660.h - dt-bindings/clock/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974) - dt-bindings/reset/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974) - - dt-bindings/clock/qcom,gcc-msm8994.h - dt-bindings/clock/qcom,gcc-mdm9607.h - dt-bindings/clock/qcom,gcc-mdm9615.h - dt-bindings/reset/qcom,gcc-mdm9615.h @@ -52,7 +51,6 @@ properties: - qcom,gcc-msm8974 - qcom,gcc-msm8974pro - qcom,gcc-msm8974pro-ac - - qcom,gcc-msm8994 - qcom,gcc-mdm9615 - qcom,gcc-sdm630 - qcom,gcc-sdm660 diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt index a4877881f1d8..da295c3c004b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt @@ -25,6 +25,7 @@ Required properties : "qcom,rpmcc-msm8994",·"qcom,rpmcc" "qcom,rpmcc-msm8996", "qcom,rpmcc" "qcom,rpmcc-msm8998", "qcom,rpmcc" + "qcom,rpmcc-qcm2290", "qcom,rpmcc" "qcom,rpmcc-qcs404", "qcom,rpmcc" "qcom,rpmcc-sdm660", "qcom,rpmcc" "qcom,rpmcc-sm6115", "qcom,rpmcc" diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml new file mode 100644 index 000000000000..f27ca6f03ffa --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sc7280-camcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Camera Clock & Reset Controller Binding for SC7280 + +maintainers: + - Taniya Das <tdas@codeaurora.org> + +description: | + Qualcomm camera clock control module which supports the clocks, resets and + power domains on SC7280. + + See also dt-bindings/clock/qcom,camcc-sc7280.h + +properties: + compatible: + const: qcom,sc7280-camcc + + clocks: + items: + - description: Board XO source + - description: Board XO active source + - description: Sleep clock source + + clock-names: + items: + - const: bi_tcxo + - const: bi_tcxo_ao + - const: sleep_clk + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@ad00000 { + compatible = "qcom,sc7280-camcc"; + reg = <0x0ad00000 0x10000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&rpmhcc RPMH_CXO_CLK_A>, + <&sleep_clk>; + clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml new file mode 100644 index 000000000000..47028d7b98e4 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sc7280-lpasscc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm LPASS Core Clock Controller Binding for SC7280 + +maintainers: + - Taniya Das <tdas@codeaurora.org> + +description: | + Qualcomm LPASS core clock control module which supports the clocks and + power domains on SC7280. + + See also: + - dt-bindings/clock/qcom,lpass-sc7280.h + +properties: + compatible: + enum: + - qcom,sc7280-lpasscc + + clocks: + items: + - description: gcc_cfg_noc_lpass_clk from GCC + + clock-names: + items: + - const: iface + + '#clock-cells': + const: 1 + + reg: + items: + - description: LPASS qdsp6ss register + - description: LPASS top-cc register + - description: LPASS cc register + + reg-names: + items: + - const: qdsp6ss + - const: top_cc + - const: cc + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sc7280.h> + #include <dt-bindings/clock/qcom,lpass-sc7280.h> + clock-controller@3000000 { + compatible = "qcom,sc7280-lpasscc"; + reg = <0x03000000 0x40>, <0x03c04000 0x4>, <0x03389000 0x24>; + reg-names = "qdsp6ss", "top_cc", "cc"; + clocks = <&gcc GCC_CFG_NOC_LPASS_CLK>; + clock-names = "iface"; + #clock-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml index 0d224f114b5b..3cdbcebdc1a1 100644 --- a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml @@ -49,6 +49,16 @@ properties: reg: maxItems: 1 + power-domains: + description: + A phandle and PM domain specifier for the MMCX power domain. + maxItems: 1 + + required-opps: + description: + A phandle to an OPP node describing required MMCX performance point. + maxItems: 1 + required: - compatible - reg @@ -63,6 +73,7 @@ additionalProperties: false examples: - | #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/power/qcom-rpmpd.h> clock-controller@ab00000 { compatible = "qcom,sdm845-videocc"; reg = <0x0ab00000 0x10000>; @@ -71,5 +82,7 @@ examples: #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; + power-domains = <&rpmhpd SM8250_MMCX>; + required-opps = <&rpmhpd_opp_low_svs>; }; ... diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml new file mode 100644 index 000000000000..7f8c91a29b91 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml @@ -0,0 +1,185 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/samsung,exynos850-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos850 SoC clock controller + +maintainers: + - Sam Protsenko <semen.protsenko@linaro.org> + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + - Tomasz Figa <tomasz.figa@gmail.com> + +description: | + Exynos850 clock controller is comprised of several CMU units, generating + clocks for different domains. Those CMU units are modeled as separate device + tree nodes, and might depend on each other. Root clocks in that clock tree are + two external clocks:: OSCCLK (26 MHz) and RTCCLK (32768 Hz). Those external + clocks must be defined as fixed-rate clocks in dts. + + CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and + dividers; all other leaf clocks (other CMUs) are usually derived from CMU_TOP. + + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All clocks available for usage + in clock consumer nodes are defined as preprocessor macros in + 'dt-bindings/clock/exynos850.h' header. + +properties: + compatible: + enum: + - samsung,exynos850-cmu-top + - samsung,exynos850-cmu-core + - samsung,exynos850-cmu-dpu + - samsung,exynos850-cmu-hsi + - samsung,exynos850-cmu-peri + + clocks: + minItems: 1 + maxItems: 5 + + clock-names: + minItems: 1 + maxItems: 5 + + "#clock-cells": + const: 1 + + reg: + maxItems: 1 + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos850-cmu-top + + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + + clock-names: + items: + - const: oscclk + + - if: + properties: + compatible: + contains: + const: samsung,exynos850-cmu-core + + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: CMU_CORE bus clock (from CMU_TOP) + - description: CCI clock (from CMU_TOP) + - description: eMMC clock (from CMU_TOP) + - description: SSS clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: dout_core_bus + - const: dout_core_cci + - const: dout_core_mmc_embd + - const: dout_core_sss + + - if: + properties: + compatible: + contains: + const: samsung,exynos850-cmu-dpu + + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: DPU clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: dout_dpu + + - if: + properties: + compatible: + contains: + const: samsung,exynos850-cmu-hsi + + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: External RTC clock (32768 Hz) + - description: CMU_HSI bus clock (from CMU_TOP) + - description: SD card clock (from CMU_TOP) + - description: "USB 2.0 DRD clock (from CMU_TOP)" + + clock-names: + items: + - const: oscclk + - const: rtcclk + - const: dout_hsi_bus + - const: dout_hsi_mmc_card + - const: dout_hsi_usb20drd + + - if: + properties: + compatible: + contains: + const: samsung,exynos850-cmu-peri + + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: CMU_PERI bus clock (from CMU_TOP) + - description: UART clock (from CMU_TOP) + - description: Parent clock for HSI2C and SPI (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: dout_peri_bus + - const: dout_peri_uart + - const: dout_peri_ip + +required: + - compatible + - "#clock-cells" + - clocks + - clock-names + - reg + +additionalProperties: false + +examples: + # Clock controller node for CMU_PERI + - | + #include <dt-bindings/clock/exynos850.h> + + cmu_peri: clock-controller@10030000 { + compatible = "samsung,exynos850-cmu-peri"; + reg = <0x10030000 0x8000>; + #clock-cells = <1>; + + clocks = <&oscclk>, <&cmu_top CLK_DOUT_PERI_BUS>, + <&cmu_top CLK_DOUT_PERI_UART>, + <&cmu_top CLK_DOUT_PERI_IP>; + clock-names = "oscclk", "dout_peri_bus", + "dout_peri_uart", "dout_peri_ip"; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt b/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt deleted file mode 100644 index 2726c1d58a79..000000000000 --- a/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt +++ /dev/null @@ -1,49 +0,0 @@ -Binding for Samsung S2M and S5M family clock generator block -============================================================ - -This is a part of device tree bindings for S2M and S5M family multi-function -devices. -More information can be found in bindings/mfd/sec-core.txt file. - -The S2MPS11/13/15 and S5M8767 provide three(AP/CP/BT) buffered 32.768 kHz -outputs. The S2MPS14 provides two (AP/BT) buffered 32.768 KHz outputs. - -To register these as clocks with common clock framework instantiate under -main device node a sub-node named "clocks". - -It uses the common clock binding documented in: - - Documentation/devicetree/bindings/clock/clock-bindings.txt - - -Required properties of the "clocks" sub-node: - - #clock-cells: should be 1. - - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk", - "samsung,s2mps14-clk", "samsung,s5m8767-clk" - The S2MPS15 uses the same compatible as S2MPS13, as both provides similar - clocks. - - -Each clock is assigned an identifier and client nodes use this identifier -to specify the clock which they consume. - Clock ID Devices - ---------------------------------------------------------- - 32KhzAP 0 S2MPS11/13/14/15, S5M8767 - 32KhzCP 1 S2MPS11/13/15, S5M8767 - 32KhzBT 2 S2MPS11/13/14/15, S5M8767 - -Include dt-bindings/clock/samsung,s2mps11.h file to use preprocessor defines -in device tree sources. - - -Example: - - s2mps11_pmic@66 { - compatible = "samsung,s2mps11-pmic"; - reg = <0x66>; - - s2m_osc: clocks { - compatible = "samsung,s2mps11-clk"; - #clock-cells = <1>; - clock-output-names = "xx", "yy", "zz"; - }; - }; diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml new file mode 100644 index 000000000000..1410c51e0e7d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/samsung,s2mps11.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2M and S5M family clock generator block + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPS11/13/15 and S5M8767 provide three(AP/CP/BT) buffered 32.768 kHz + outputs. The S2MPS14 provides two (AP/BT) buffered 32.768 KHz outputs. + + All available clocks are defined as preprocessor macros in + dt-bindings/clock/samsung,s2mps11.h header. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for + additional information and example. + +properties: + compatible: + enum: + - samsung,s2mps11-clk + - samsung,s2mps13-clk # S2MPS13 and S2MPS15 + - samsung,s2mps14-clk + - samsung,s5m8767-clk + + "#clock-cells": + const: 1 + + clock-output-names: + minItems: 3 + maxItems: 3 + description: Names for AP, CP and BT clocks. + +required: + - compatible + - "#clock-cells" + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/clock/sifive/fu740-prci.yaml b/Documentation/devicetree/bindings/clock/sifive/fu740-prci.yaml index e17143cac316..252085a0cf65 100644 --- a/Documentation/devicetree/bindings/clock/sifive/fu740-prci.yaml +++ b/Documentation/devicetree/bindings/clock/sifive/fu740-prci.yaml @@ -42,6 +42,9 @@ properties: "#clock-cells": const: 1 + "#reset-cells": + const: 1 + required: - compatible - reg @@ -57,4 +60,5 @@ examples: reg = <0x10000000 0x1000>; clocks = <&hfclk>, <&rtcclk>; #clock-cells = <1>; + #reset-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt index 8fe6f80afade..bfda6af76bee 100644 --- a/Documentation/devicetree/bindings/clock/silabs,si5351.txt +++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt @@ -2,7 +2,7 @@ Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator. Reference [1] Si5351A/B/C Data Sheet - https://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf + https://www.skyworksinc.com/-/media/Skyworks/SL/documents/public/data-sheets/Si5351-B.pdf The Si5351a/b/c are programmable i2c clock generators with up to 8 output clocks. Si5351a also has a reduced pin-count package (MSOP10) where only diff --git a/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml b/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml index c3930edc410f..9a0cc7341630 100644 --- a/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml +++ b/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml @@ -23,6 +23,7 @@ properties: - socionext,uniphier-ld11-clock - socionext,uniphier-ld20-clock - socionext,uniphier-pxs3-clock + - socionext,uniphier-nx1-clock - description: Media I/O (MIO) clock, SD clock enum: - socionext,uniphier-ld4-mio-clock @@ -33,6 +34,7 @@ properties: - socionext,uniphier-ld11-mio-clock - socionext,uniphier-ld20-sd-clock - socionext,uniphier-pxs3-sd-clock + - socionext,uniphier-nx1-sd-clock - description: Peripheral clock enum: - socionext,uniphier-ld4-peri-clock @@ -43,6 +45,10 @@ properties: - socionext,uniphier-ld11-peri-clock - socionext,uniphier-ld20-peri-clock - socionext,uniphier-pxs3-peri-clock + - socionext,uniphier-nx1-peri-clock + - description: SoC-glue clock + enum: + - socionext,uniphier-pro4-sg-clock "#clock-cells": const: 1 diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml index 8b1ecb2ecdd5..a0ae4867ed27 100644 --- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml +++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Reset Clock Controller Binding maintainers: - - Gabriel Fernandez <gabriel.fernandez@st.com> + - Gabriel Fernandez <gabriel.fernandez@foss.st.com> description: | The RCC IP is both a reset and a clock controller. diff --git a/Documentation/devicetree/bindings/clock/stericsson,u8500-clks.yaml b/Documentation/devicetree/bindings/clock/stericsson,u8500-clks.yaml new file mode 100644 index 000000000000..9bc95a308477 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/stericsson,u8500-clks.yaml @@ -0,0 +1,121 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/stericsson,u8500-clks.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ST-Ericsson DB8500 (U8500) clocks + +maintainers: + - Ulf Hansson <ulf.hansson@linaro.org> + - Linus Walleij <linus.walleij@linaro.org> + +description: While named "U8500 clocks" these clocks are inside the + DB8500 digital baseband system-on-chip and its siblings such as + DB8520. These bindings consider the clocks present in the SoC + itself, not off-chip clocks. There are four different on-chip + clocks - RTC (32 kHz), CPU clock (SMP TWD), PRCMU (power reset and + control management unit) clocks and PRCC (peripheral reset and + clock controller) clocks. For some reason PRCC 4 does not exist so + the itemization can be a bit unintuitive. + +properties: + compatible: + enum: + - stericsson,u8500-clks + - stericsson,u8540-clks + - stericsson,u9540-clks + + reg: + items: + - description: PRCC 1 register area + - description: PRCC 2 register area + - description: PRCC 3 register area + - description: PRCC 5 register area + - description: PRCC 6 register area + + prcmu-clock: + description: A subnode with one clock cell for PRCMU (power, reset, control + management unit) clocks. The cell indicates which PRCMU clock in the + prcmu-clock node the consumer wants to use. + type: object + + properties: + '#clock-cells': + const: 1 + + additionalProperties: false + + prcc-periph-clock: + description: A subnode with two clock cells for PRCC (peripheral + reset and clock controller) peripheral clocks. The first cell indicates + which PRCC block the consumer wants to use, possible values are 1, 2, 3, + 5, 6. The second cell indicates which clock inside the PRCC block it + wants, possible values are 0 thru 31. + type: object + + properties: + '#clock-cells': + const: 2 + + additionalProperties: false + + prcc-kernel-clock: + description: A subnode with two clock cells for PRCC (peripheral reset + and clock controller) kernel clocks. The first cell indicates which PRCC + block the consumer wants to use, possible values are 1, 2, 3, 5, 6. The + second cell indicates which clock inside the PRCC block it wants, possible + values are 0 thru 31. + type: object + + properties: + '#clock-cells': + const: 2 + + additionalProperties: false + + prcc-reset-controller: + description: A subnode with two reset cells for the reset portions of the + PRCC (peripheral reset and clock controller). The first cell indicates + which PRCC block the consumer wants to use, possible values are 1, 2, 3 + 5 and 6. The second cell indicates which reset line inside the PRCC block + it wants to control, possible values are 0 thru 31. + type: object + + properties: + '#reset-cells': + const: 2 + + additionalProperties: false + + rtc32k-clock: + description: A subnode with zero clock cells for the 32kHz RTC clock. + type: object + + properties: + '#clock-cells': + const: 0 + + additionalProperties: false + + smp-twd-clock: + description: A subnode for the ARM SMP Timer Watchdog cluster with zero + clock cells. + type: object + + properties: + '#clock-cells': + const: 0 + + additionalProperties: false + +required: + - compatible + - reg + - prcmu-clock + - prcc-periph-clock + - prcc-kernel-clock + - rtc32k-clock + - smp-twd-clock + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/clock/ux500.txt b/Documentation/devicetree/bindings/clock/ux500.txt deleted file mode 100644 index e52bd4b72348..000000000000 --- a/Documentation/devicetree/bindings/clock/ux500.txt +++ /dev/null @@ -1,64 +0,0 @@ -Clock bindings for ST-Ericsson Ux500 clocks - -Required properties : -- compatible : shall contain only one of the following: - "stericsson,u8500-clks" - "stericsson,u8540-clks" - "stericsson,u9540-clks" -- reg : shall contain base register location and length for - CLKRST1, 2, 3, 5, and 6 in an array. Note the absence of - CLKRST4, which does not exist. - -Required subnodes: -- prcmu-clock: a subnode with one clock cell for PRCMU (power, - reset, control unit) clocks. The cell indicates which PRCMU - clock in the prcmu-clock node the consumer wants to use. -- prcc-periph-clock: a subnode with two clock cells for - PRCC (programmable reset- and clock controller) peripheral clocks. - The first cell indicates which PRCC block the consumer - wants to use, possible values are 1, 2, 3, 5, 6. The second - cell indicates which clock inside the PRCC block it wants, - possible values are 0 thru 31. -- prcc-kernel-clock: a subnode with two clock cells for - PRCC (programmable reset- and clock controller) kernel clocks - The first cell indicates which PRCC block the consumer - wants to use, possible values are 1, 2, 3, 5, 6. The second - cell indicates which clock inside the PRCC block it wants, - possible values are 0 thru 31. -- rtc32k-clock: a subnode with zero clock cells for the 32kHz - RTC clock. -- smp-twd-clock: a subnode for the ARM SMP Timer Watchdog cluster - with zero clock cells. - -Example: - -clocks { - compatible = "stericsson,u8500-clks"; - /* - * Registers for the CLKRST block on peripheral - * groups 1, 2, 3, 5, 6, - */ - reg = <0x8012f000 0x1000>, <0x8011f000 0x1000>, - <0x8000f000 0x1000>, <0xa03ff000 0x1000>, - <0xa03cf000 0x1000>; - - prcmu_clk: prcmu-clock { - #clock-cells = <1>; - }; - - prcc_pclk: prcc-periph-clock { - #clock-cells = <2>; - }; - - prcc_kclk: prcc-kernel-clock { - #clock-cells = <2>; - }; - - rtc_clk: rtc32k-clock { - #clock-cells = <0>; - }; - - smp_twd_clk: smp-twd-clock { - #clock-cells = <0>; - }; -}; diff --git a/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-ecc.yaml b/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-ecc.yaml new file mode 100644 index 000000000000..a3c16451b1ad --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-ecc.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/intel,keembay-ocs-ecc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel Keem Bay OCS ECC Device Tree Bindings + +maintainers: + - Daniele Alessandrelli <daniele.alessandrelli@intel.com> + - Prabhjot Khurana <prabhjot.khurana@intel.com> + +description: + The Intel Keem Bay Offload and Crypto Subsystem (OCS) Elliptic Curve + Cryptography (ECC) device provides hardware acceleration for elliptic curve + cryptography using the NIST P-256 and NIST P-384 elliptic curves. + +properties: + compatible: + const: intel,keembay-ocs-ecc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + crypto@30001000 { + compatible = "intel,keembay-ocs-ecc"; + reg = <0x30001000 0x1000>; + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&scmi_clk 95>; + }; diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-crc.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-crc.yaml index cee624c14f07..b72e4858f9aa 100644 --- a/Documentation/devicetree/bindings/crypto/st,stm32-crc.yaml +++ b/Documentation/devicetree/bindings/crypto/st,stm32-crc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 CRC bindings maintainers: - - Lionel Debieve <lionel.debieve@st.com> + - Lionel Debieve <lionel.debieve@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml index a4574552502a..ed23bf94a8e0 100644 --- a/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml +++ b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 CRYP bindings maintainers: - - Lionel Debieve <lionel.debieve@st.com> + - Lionel Debieve <lionel.debieve@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml index 6dd658f0912c..10ba94792d95 100644 --- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml +++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 HASH bindings maintainers: - - Lionel Debieve <lionel.debieve@st.com> + - Lionel Debieve <lionel.debieve@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/ddr/lpddr2.txt b/Documentation/devicetree/bindings/ddr/lpddr2.txt deleted file mode 100644 index ddd40121e6f6..000000000000 --- a/Documentation/devicetree/bindings/ddr/lpddr2.txt +++ /dev/null @@ -1,102 +0,0 @@ -* LPDDR2 SDRAM memories compliant to JEDEC JESD209-2 - -Required properties: -- compatible : Should be one of - "jedec,lpddr2-nvm", "jedec,lpddr2-s2", - "jedec,lpddr2-s4" - - "ti,jedec-lpddr2-s2" should be listed if the memory part is LPDDR2-S2 type - - "ti,jedec-lpddr2-s4" should be listed if the memory part is LPDDR2-S4 type - - "ti,jedec-lpddr2-nvm" should be listed if the memory part is LPDDR2-NVM type - -- density : <u32> representing density in Mb (Mega bits) - -- io-width : <u32> representing bus width. Possible values are 8, 16, and 32 - -Optional properties: - -The following optional properties represent the minimum value of some AC -timing parameters of the DDR device in terms of number of clock cycles. -These values shall be obtained from the device data-sheet. -- tRRD-min-tck -- tWTR-min-tck -- tXP-min-tck -- tRTP-min-tck -- tCKE-min-tck -- tRPab-min-tck -- tRCD-min-tck -- tWR-min-tck -- tRASmin-min-tck -- tCKESR-min-tck -- tFAW-min-tck - -Child nodes: -- The lpddr2 node may have one or more child nodes of type "lpddr2-timings". - "lpddr2-timings" provides AC timing parameters of the device for - a given speed-bin. The user may provide the timings for as many - speed-bins as is required. Please see Documentation/devicetree/ - bindings/ddr/lpddr2-timings.txt for more information on "lpddr2-timings" - -Example: - -elpida_ECB240ABACN : lpddr2 { - compatible = "Elpida,ECB240ABACN","jedec,lpddr2-s4"; - density = <2048>; - io-width = <32>; - - tRPab-min-tck = <3>; - tRCD-min-tck = <3>; - tWR-min-tck = <3>; - tRASmin-min-tck = <3>; - tRRD-min-tck = <2>; - tWTR-min-tck = <2>; - tXP-min-tck = <2>; - tRTP-min-tck = <2>; - tCKE-min-tck = <3>; - tCKESR-min-tck = <3>; - tFAW-min-tck = <8>; - - timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 { - compatible = "jedec,lpddr2-timings"; - min-freq = <10000000>; - max-freq = <400000000>; - tRPab = <21000>; - tRCD = <18000>; - tWR = <15000>; - tRAS-min = <42000>; - tRRD = <10000>; - tWTR = <7500>; - tXP = <7500>; - tRTP = <7500>; - tCKESR = <15000>; - tDQSCK-max = <5500>; - tFAW = <50000>; - tZQCS = <90000>; - tZQCL = <360000>; - tZQinit = <1000000>; - tRAS-max-ns = <70000>; - }; - - timings_elpida_ECB240ABACN_200mhz: lpddr2-timings@1 { - compatible = "jedec,lpddr2-timings"; - min-freq = <10000000>; - max-freq = <200000000>; - tRPab = <21000>; - tRCD = <18000>; - tWR = <15000>; - tRAS-min = <42000>; - tRRD = <10000>; - tWTR = <10000>; - tXP = <7500>; - tRTP = <7500>; - tCKESR = <15000>; - tDQSCK-max = <5500>; - tFAW = <50000>; - tZQCS = <90000>; - tZQCL = <360000>; - tZQinit = <1000000>; - tRAS-max-ns = <70000>; - }; - -} diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt index 3fbeb3733c48..58fc8a6cebc7 100644 --- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt @@ -174,7 +174,7 @@ Example: compatible = "rockchip,rk3399-dmc"; devfreq-events = <&dfi>; interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cru SCLK_DDRCLK>; + clocks = <&cru SCLK_DDRC>; clock-names = "dmc_clk"; operating-points-v2 = <&dmc_opp_table>; center-supply = <&ppvar_centerlogic>; diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml index 32608578a352..c8b2459d64f6 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml @@ -47,6 +47,9 @@ properties: interrupts: maxItems: 1 + power-domains: + maxItems: 1 + required: - "#clock-cells" - compatible diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml index 031e35e76db2..48c8cad0d96d 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml @@ -51,6 +51,9 @@ properties: dma-names: const: audio-rx + power-domains: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml index 8a73780f573d..c55a8217de25 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml @@ -24,6 +24,9 @@ properties: interrupts: maxItems: 1 + power-domains: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml index 9b24081a0dbd..5d921e30394e 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml @@ -24,6 +24,9 @@ properties: interrupts: maxItems: 1 + power-domains: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index 304a1367faaa..1faae3e323a4 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -49,11 +49,26 @@ properties: properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base description: | For LVDS encoders, port 0 is the parallel input For LVDS decoders, port 0 is the LVDS input + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-mapping: + enum: + - jeida-18 + - jeida-24 + - vesa-24 + description: | + The color signals mapping order. See details in + Documentation/devicetree/bindings/display/panel/lvds.yaml + port@1: $ref: /schemas/graph.yaml#/properties/port description: | @@ -71,6 +86,22 @@ properties: power-supply: true +if: + not: + properties: + compatible: + contains: + const: lvds-decoder +then: + properties: + ports: + properties: + port@0: + properties: + endpoint: + properties: + data-mapping: false + required: - compatible - ports diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml index fce82b605c8b..cdaf7a7a8f88 100644 --- a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml @@ -40,6 +40,9 @@ properties: vdd33-supply: description: Regulator for 3.3V digital core power. + aux-bus: + $ref: /schemas/display/dp-aux-bus.yaml# + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -98,7 +101,21 @@ examples: reg = <1>; ps8640_out: endpoint { remote-endpoint = <&panel_in>; - }; + }; + }; + }; + + aux-bus { + panel { + compatible = "boe,nv133fhm-n62"; + power-supply = <&pp3300_dx_edp>; + backlight = <&backlight>; + + port { + panel_in: endpoint { + remote-endpoint = <&ps8640_out>; + }; + }; }; }; }; diff --git a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml index 3c3e51af154b..11fd68a70dca 100644 --- a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Synopsys DesignWare MIPI DSI host controller maintainers: - - Philippe CORNU <philippe.cornu@st.com> + - Philippe CORNU <philippe.cornu@foss.st.com> description: | This document defines device tree properties for the Synopsys DesignWare MIPI diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index 07b20383cbca..b446d0f0f1b4 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -50,7 +50,6 @@ properties: data-lanes: description: array of physical DSI data lane indexes. minItems: 1 - maxItems: 4 items: - const: 1 - const: 2 @@ -71,7 +70,6 @@ properties: data-lanes: description: array of physical DSI data lane indexes. minItems: 1 - maxItems: 4 items: - const: 1 - const: 2 diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml index 1c2daf7c24cc..911564468c5e 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -18,7 +18,7 @@ properties: const: ti,sn65dsi86 reg: - const: 0x2d + enum: [ 0x2c, 0x2d ] enable-gpios: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt deleted file mode 100644 index 583c5e9dbe6b..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt +++ /dev/null @@ -1,54 +0,0 @@ -Toshiba TC358767 eDP bridge bindings - -Required properties: - - compatible: "toshiba,tc358767" - - reg: i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins - - clock-names: should be "ref" - - clocks: OF device-tree clock specification for refclk input. The reference - clock rate must be 13 MHz, 19.2 MHz, 26 MHz, or 38.4 MHz. - -Optional properties: - - shutdown-gpios: OF device-tree gpio specification for SD pin - (active high shutdown input) - - reset-gpios: OF device-tree gpio specification for RSTX pin - (active low system reset) - - toshiba,hpd-pin: TC358767 GPIO pin number to which HPD is connected to (0 or 1) - - ports: the ports node can contain video interface port nodes to connect - to a DPI/DSI source and to an eDP/DP sink according to [1][2]: - - port@0: DSI input port - - port@1: DPI input port - - port@2: eDP/DP output port - -[1]: Documentation/devicetree/bindings/graph.txt -[2]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - edp-bridge@68 { - compatible = "toshiba,tc358767"; - reg = <0x68>; - shutdown-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>; - clock-names = "ref"; - clocks = <&edp_refclk>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@1 { - reg = <1>; - - bridge_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; - - port@2 { - reg = <2>; - - bridge_out: endpoint { - remote-endpoint = <&panel_in>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml new file mode 100644 index 000000000000..f1541cc05297 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml @@ -0,0 +1,158 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358767.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Toshiba TC358767 eDP bridge bindings + +maintainers: + - Andrey Gusakov <andrey.gusakov@cogentembedded.com> + +description: The TC358767 is bridge device which converts DSI/DPI to eDP/DP + +properties: + compatible: + const: toshiba,tc358767 + + reg: + enum: + - 0x68 + - 0x0f + description: | + i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins + + clock-names: + const: "ref" + + clocks: + maxItems: 1 + description: | + OF device-tree clock specification for refclk input. The reference. + clock rate must be 13 MHz, 19.2 MHz, 26 MHz, or 38.4 MHz. + + shutdown-gpios: + maxItems: 1 + description: | + OF device-tree gpio specification for SD pin(active high shutdown input) + + reset-gpios: + maxItems: 1 + description: | + OF device-tree gpio specification for RSTX pin(active low system reset) + + toshiba,hpd-pin: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 + - 1 + description: TC358767 GPIO pin number to which HPD is connected to (0 or 1) + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: | + DSI input port. The remote endpoint phandle should be a + reference to a valid DSI output endpoint node + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: | + DPI input port. The remote endpoint phandle should be a + reference to a valid DPI output endpoint node + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: | + eDP/DP output port. The remote endpoint phandle should be a + reference to a valid eDP panel input endpoint node. This port is + optional, treated as DP panel if not defined + + oneOf: + - required: + - port@0 + - required: + - port@1 + + +required: + - compatible + - reg + - clock-names + - clocks + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + /* DPI input and eDP output */ + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + edp-bridge@68 { + compatible = "toshiba,tc358767"; + reg = <0x68>; + shutdown-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>; + clock-names = "ref"; + clocks = <&edp_refclk>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + + bridge_in_0: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + + port@2 { + reg = <2>; + + bridge_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + }; + }; + - | + /* DPI input and DP output */ + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + edp-bridge@68 { + compatible = "toshiba,tc358767"; + reg = <0x68>; + shutdown-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>; + clock-names = "ref"; + clocks = <&edp_refclk>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + + bridge_in_1: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/ingenic,ipu.yaml b/Documentation/devicetree/bindings/display/ingenic,ipu.yaml index e679f48a3886..3f93def2c5a2 100644 --- a/Documentation/devicetree/bindings/display/ingenic,ipu.yaml +++ b/Documentation/devicetree/bindings/display/ingenic,ipu.yaml @@ -45,7 +45,7 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/jz4770-cgu.h> + #include <dt-bindings/clock/ingenic,jz4770-cgu.h> ipu@13080000 { compatible = "ingenic,jz4770-ipu", "ingenic,jz4760-ipu"; reg = <0x13080000 0x800>; diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.yaml b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml index 50d2b0a50e8a..0049010b37ca 100644 --- a/Documentation/devicetree/bindings/display/ingenic,lcd.yaml +++ b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml @@ -88,7 +88,7 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/jz4740-cgu.h> + #include <dt-bindings/clock/ingenic,jz4740-cgu.h> lcd-controller@13050000 { compatible = "ingenic,jz4740-lcd"; reg = <0x13050000 0x1000>; @@ -107,7 +107,7 @@ examples: }; - | - #include <dt-bindings/clock/jz4725b-cgu.h> + #include <dt-bindings/clock/ingenic,jz4725b-cgu.h> lcd-controller@13050000 { compatible = "ingenic,jz4725b-lcd"; reg = <0x13050000 0x1000>; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt index d30428b9fb33..36b01458f45c 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt @@ -19,6 +19,11 @@ Required properties: Documentation/devicetree/bindings/graph.txt. This port should be connected to the input port of an attached DSI panel or DSI-to-eDP encoder chip. +Optional properties: +- resets: list of phandle + reset specifier pair, as described in [1]. + +[1] Documentation/devicetree/bindings/reset/reset.txt + MIPI TX Configuration Module ============================ @@ -45,6 +50,7 @@ dsi0: dsi@1401b000 { clocks = <&mmsys MM_DSI0_ENGINE>, <&mmsys MM_DSI0_DIGITAL>, <&mipi_tx0>; clock-names = "engine", "digital", "hs"; + resets = <&mmsys MT8173_MMSYS_SW0_RST_B_DISP_DSI0>; phys = <&mipi_tx0>; phy-names = "dphy"; diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index 64d8d9e5e47a..63e585f48789 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -17,9 +17,16 @@ properties: compatible: enum: - qcom,sc7180-dp + - qcom,sc8180x-dp + - qcom,sc8180x-edp reg: - maxItems: 1 + items: + - description: ahb register block + - description: aux register block + - description: link register block + - description: p0 register block + - description: p1 register block interrupts: maxItems: 1 @@ -95,12 +102,15 @@ examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/clock/qcom,dispcc-sc7180.h> - #include <dt-bindings/power/qcom-aoss-qmp.h> #include <dt-bindings/power/qcom-rpmpd.h> displayport-controller@ae90000 { compatible = "qcom,sc7180-dp"; - reg = <0xae90000 0x1400>; + reg = <0xae90000 0x200>, + <0xae90200 0x200>, + <0xae90400 0xc00>, + <0xae91000 0x400>, + <0xae91400 0x400>; interrupt-parent = <&mdss>; interrupts = <12>; clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml new file mode 100644 index 000000000000..fbeb931a026e --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml @@ -0,0 +1,232 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dpu-sc7280.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DPU dt properties for SC7280 + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +description: | + Device tree bindings for MSM Mobile Display Subsystem (MDSS) that encapsulates + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree + bindings of MDSS and DPU are mentioned for SC7280. + +properties: + compatible: + const: qcom,sc7280-mdss + + reg: + maxItems: 1 + + reg-names: + const: mdss + + power-domains: + maxItems: 1 + + clocks: + items: + - description: Display AHB clock from gcc + - description: Display AHB clock from dispcc + - description: Display core clock + + clock-names: + items: + - const: iface + - const: ahb + - const: core + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#address-cells": true + + "#size-cells": true + + "#interrupt-cells": + const: 1 + + iommus: + items: + - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0 + + ranges: true + + interconnects: + items: + - description: Interconnect path specifying the port ids for data bus + + interconnect-names: + const: mdp0-mem + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + description: Node containing the properties of DPU. + + properties: + compatible: + const: qcom,sc7280-dpu + + reg: + items: + - description: Address offset and size for mdp register set + - description: Address offset and size for vbif register set + + reg-names: + items: + - const: mdp + - const: vbif + + clocks: + items: + - description: Display hf axi clock + - description: Display sf axi clock + - description: Display ahb clock + - description: Display lut clock + - description: Display core clock + - description: Display vsync clock + + clock-names: + items: + - const: bus + - const: nrt_bus + - const: iface + - const: lut + - const: core + - const: vsync + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + operating-points-v2: true + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + Contains the list of output ports from DPU device. These ports + connect to interfaces that are external to the DPU hardware, + such as DSI, DP etc. Each output port contains an endpoint that + describes how it is connected to an external interface. + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF1 (DSI) + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF5 (EDP) + + required: + - port@0 + + required: + - compatible + - reg + - reg-names + - clocks + - interrupts + - power-domains + - operating-points-v2 + - ports + +required: + - compatible + - reg + - reg-names + - power-domains + - clocks + - interrupts + - interrupt-controller + - iommus + - ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sc7280.h> + #include <dt-bindings/clock/qcom,gcc-sc7280.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interconnect/qcom,sc7280.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + display-subsystem@ae00000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,sc7280-mdss"; + reg = <0xae00000 0x1000>; + reg-names = "mdss"; + power-domains = <&dispcc DISP_CC_MDSS_CORE_GDSC>; + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", + "ahb", + "core"; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + interconnects = <&mmss_noc MASTER_MDP0 &mc_virt SLAVE_EBI1>; + interconnect-names = "mdp0-mem"; + + iommus = <&apps_smmu 0x900 0x402>; + ranges; + + display-controller@ae01000 { + compatible = "qcom,sc7280-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_HF_AXI_CLK>, + <&gcc GCC_DISP_SF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "bus", + "nrt_bus", + "iface", + "lut", + "core", + "vsync"; + + interrupt-parent = <&mdss>; + interrupts = <0>; + power-domains = <&rpmhpd SC7280_CX>; + operating-points-v2 = <&mdp_opp_table>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + + port@1 { + reg = <1>; + dpu_intf5_out: endpoint { + remote-endpoint = <&edp_in>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml index 064df50e21a5..81dbee4803c0 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml @@ -17,6 +17,7 @@ properties: enum: - qcom,dsi-phy-14nm - qcom,dsi-phy-14nm-660 + - qcom,dsi-phy-14nm-8953 reg: items: diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt deleted file mode 100644 index 090dcb3fc34d..000000000000 --- a/Documentation/devicetree/bindings/display/msm/gpu.txt +++ /dev/null @@ -1,157 +0,0 @@ -Qualcomm adreno/snapdragon GPU - -Required properties: -- compatible: "qcom,adreno-XYZ.W", "qcom,adreno" or - "amd,imageon-XYZ.W", "amd,imageon" - for example: "qcom,adreno-306.0", "qcom,adreno" - Note that you need to list the less specific "qcom,adreno" (since this - is what the device is matched on), in addition to the more specific - with the chip-id. - If "amd,imageon" is used, there should be no top level msm device. -- reg: Physical base address and length of the controller's registers. -- interrupts: The interrupt signal from the gpu. -- clocks: device clocks (if applicable) - See ../clocks/clock-bindings.txt for details. -- clock-names: the following clocks are required by a3xx, a4xx and a5xx - cores: - * "core" - * "iface" - * "mem_iface" - For GMU attached devices the GPU clocks are not used and are not required. The - following devices should not list clocks: - - qcom,adreno-630.2 -- iommus: optional phandle to an adreno iommu instance -- operating-points-v2: optional phandle to the OPP operating points -- interconnects: optional phandle to an interconnect provider. See - ../interconnect/interconnect.txt for details. Some A3xx and all A4xx platforms - will have two paths; all others will have one path. -- interconnect-names: The names of the interconnect paths that correspond to the - interconnects property. Values must be gfx-mem and ocmem. -- qcom,gmu: For GMU attached devices a phandle to the GMU device that will - control the power for the GPU. Applicable targets: - - qcom,adreno-630.2 -- zap-shader: For a5xx and a6xx devices this node contains a memory-region that - points to reserved memory to store the zap shader that can be used to help - bring the GPU out of secure mode. -- firmware-name: optional property of the 'zap-shader' node, listing the - relative path of the device specific zap firmware. -- sram: phandle to the On Chip Memory (OCMEM) that's present on some a3xx and - a4xx Snapdragon SoCs. See - Documentation/devicetree/bindings/sram/qcom,ocmem.yaml. - -Optional properties: -- #cooling-cells: The value must be 2. For details, please refer - Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml. - -Example 3xx/4xx: - -/ { - ... - - gpu: adreno@fdb00000 { - compatible = "qcom,adreno-330.2", - "qcom,adreno"; - reg = <0xfdb00000 0x10000>; - reg-names = "kgsl_3d0_reg_memory"; - interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "kgsl_3d0_irq"; - clock-names = "core", - "iface", - "mem_iface"; - clocks = <&mmcc OXILI_GFX3D_CLK>, - <&mmcc OXILICX_AHB_CLK>, - <&mmcc OXILICX_AXI_CLK>; - sram = <&gpu_sram>; - power-domains = <&mmcc OXILICX_GDSC>; - operating-points-v2 = <&gpu_opp_table>; - iommus = <&gpu_iommu 0>; - #cooling-cells = <2>; - }; - - gpu_sram: ocmem@fdd00000 { - compatible = "qcom,msm8974-ocmem"; - - reg = <0xfdd00000 0x2000>, - <0xfec00000 0x180000>; - reg-names = "ctrl", - "mem"; - - clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>, - <&mmcc OCMEMCX_OCMEMNOC_CLK>; - clock-names = "core", - "iface"; - - #address-cells = <1>; - #size-cells = <1>; - - gpu_sram: gpu-sram@0 { - reg = <0x0 0x100000>; - ranges = <0 0 0xfec00000 0x100000>; - }; - }; -}; - -Example a6xx (with GMU): - -/ { - ... - - gpu@5000000 { - compatible = "qcom,adreno-630.2", "qcom,adreno"; - #stream-id-cells = <16>; - - reg = <0x5000000 0x40000>, <0x509e000 0x10>; - reg-names = "kgsl_3d0_reg_memory", "cx_mem"; - - #cooling-cells = <2>; - - /* - * Look ma, no clocks! The GPU clocks and power are - * controlled entirely by the GMU - */ - - interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>; - - iommus = <&adreno_smmu 0>; - - operating-points-v2 = <&gpu_opp_table>; - - interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>; - interconnect-names = "gfx-mem"; - - gpu_opp_table: opp-table { - compatible = "operating-points-v2"; - - opp-430000000 { - opp-hz = /bits/ 64 <430000000>; - opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>; - opp-peak-kBps = <5412000>; - }; - - opp-355000000 { - opp-hz = /bits/ 64 <355000000>; - opp-level = <RPMH_REGULATOR_LEVEL_SVS>; - opp-peak-kBps = <3072000>; - }; - - opp-267000000 { - opp-hz = /bits/ 64 <267000000>; - opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>; - opp-peak-kBps = <3072000>; - }; - - opp-180000000 { - opp-hz = /bits/ 64 <180000000>; - opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>; - opp-peak-kBps = <1804000>; - }; - }; - - qcom,gmu = <&gmu>; - - zap-shader { - memory-region = <&zap_shader_region>; - firmware-name = "qcom/LENOVO/81JL/qcdxkmsuc850.mbn" - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml new file mode 100644 index 000000000000..99a1ba3ada56 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml @@ -0,0 +1,288 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: "http://devicetree.org/schemas/display/msm/gpu.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Devicetree bindings for the Adreno or Snapdragon GPUs + +maintainers: + - Rob Clark <robdclark@gmail.com> + +properties: + compatible: + oneOf: + - description: | + The driver is parsing the compat string for Adreno to + figure out the gpu-id and patch level. + items: + - pattern: '^qcom,adreno-[3-6][0-9][0-9]\.[0-9]$' + - const: qcom,adreno + - description: | + The driver is parsing the compat string for Imageon to + figure out the gpu-id and patch level. + items: + - pattern: '^amd,imageon-200\.[0-1]$' + - const: amd,imageon + + clocks: true + + clock-names: true + + reg: + minItems: 1 + maxItems: 3 + + reg-names: + minItems: 1 + items: + - const: kgsl_3d0_reg_memory + - const: cx_mem + - const: cx_dbgc + + interrupts: + maxItems: 1 + + interrupt-names: + maxItems: 1 + + interconnects: + minItems: 1 + maxItems: 2 + + interconnect-names: + minItems: 1 + items: + - const: gfx-mem + - const: ocmem + + iommus: + maxItems: 1 + + sram: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 4 + description: | + phandles to one or more reserved on-chip SRAM regions. + phandle to the On Chip Memory (OCMEM) that's present on some a3xx and + a4xx Snapdragon SoCs. See + Documentation/devicetree/bindings/sram/qcom,ocmem.yaml + + operating-points-v2: true + opp-table: + type: object + + power-domains: + maxItems: 1 + + zap-shader: + type: object + description: | + For a5xx and a6xx devices this node contains a memory-region that + points to reserved memory to store the zap shader that can be used to + help bring the GPU out of secure mode. + properties: + memory-region: + $ref: /schemas/types.yaml#/definitions/phandle + + firmware-name: + description: | + Default name of the firmware to load to the remote processor. + + "#cooling-cells": + const: 2 + + nvmem-cell-names: + maxItems: 1 + + nvmem-cells: + description: efuse registers + maxItems: 1 + + qcom,gmu: + $ref: /schemas/types.yaml#/definitions/phandle + description: | + For GMU attached devices a phandle to the GMU device that will + control the power for the GPU. + + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + pattern: '^qcom,adreno-[3-5][0-9][0-9]\.[0-9]$' + + then: + properties: + clocks: + minItems: 2 + maxItems: 7 + + clock-names: + items: + anyOf: + - const: core + description: GPU Core clock + - const: iface + description: GPU Interface clock + - const: mem + description: GPU Memory clock + - const: mem_iface + description: GPU Memory Interface clock + - const: alt_mem_iface + description: GPU Alternative Memory Interface clock + - const: gfx3d + description: GPU 3D engine clock + - const: rbbmtimer + description: GPU RBBM Timer for Adreno 5xx series + minItems: 2 + maxItems: 7 + + required: + - clocks + - clock-names + - if: + properties: + compatible: + contains: + pattern: '^qcom,adreno-6[0-9][0-9]\.[0-9]$' + + then: # Since Adreno 6xx series clocks should be defined in GMU + properties: + clocks: false + clock-names: false + +examples: + - | + + // Example a3xx/4xx: + + #include <dt-bindings/clock/qcom,mmcc-msm8974.h> + #include <dt-bindings/clock/qcom,rpmcc.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + gpu: gpu@fdb00000 { + compatible = "qcom,adreno-330.2", "qcom,adreno"; + + reg = <0xfdb00000 0x10000>; + reg-names = "kgsl_3d0_reg_memory"; + + clock-names = "core", "iface", "mem_iface"; + clocks = <&mmcc OXILI_GFX3D_CLK>, + <&mmcc OXILICX_AHB_CLK>, + <&mmcc OXILICX_AXI_CLK>; + + interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "kgsl_3d0_irq"; + + sram = <&gpu_sram>; + power-domains = <&mmcc OXILICX_GDSC>; + operating-points-v2 = <&gpu_opp_table>; + iommus = <&gpu_iommu 0>; + #cooling-cells = <2>; + }; + + ocmem@fdd00000 { + compatible = "qcom,msm8974-ocmem"; + + reg = <0xfdd00000 0x2000>, + <0xfec00000 0x180000>; + reg-names = "ctrl", "mem"; + + clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>, + <&mmcc OCMEMCX_OCMEMNOC_CLK>; + clock-names = "core", "iface"; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0xfec00000 0x100000>; + + gpu_sram: gpu-sram@0 { + reg = <0x0 0x100000>; + }; + }; + - | + + // Example a6xx (with GMU): + + #include <dt-bindings/clock/qcom,gpucc-sdm845.h> + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interconnect/qcom,sdm845.h> + + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + + zap_shader_region: gpu@8f200000 { + compatible = "shared-dma-pool"; + reg = <0x0 0x90b00000 0x0 0xa00000>; + no-map; + }; + }; + + gpu@5000000 { + compatible = "qcom,adreno-630.2", "qcom,adreno"; + + reg = <0x5000000 0x40000>, <0x509e000 0x10>; + reg-names = "kgsl_3d0_reg_memory", "cx_mem"; + + #cooling-cells = <2>; + + interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>; + + iommus = <&adreno_smmu 0>; + + operating-points-v2 = <&gpu_opp_table>; + + interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>; + interconnect-names = "gfx-mem"; + + qcom,gmu = <&gmu>; + + gpu_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-430000000 { + opp-hz = /bits/ 64 <430000000>; + opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>; + opp-peak-kBps = <5412000>; + }; + + opp-355000000 { + opp-hz = /bits/ 64 <355000000>; + opp-level = <RPMH_REGULATOR_LEVEL_SVS>; + opp-peak-kBps = <3072000>; + }; + + opp-267000000 { + opp-hz = /bits/ 64 <267000000>; + opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>; + opp-peak-kBps = <3072000>; + }; + + opp-180000000 { + opp-hz = /bits/ 64 <180000000>; + opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>; + opp-peak-kBps = <1804000>; + }; + }; + + zap-shader { + memory-region = <&zap_shader_region>; + firmware-name = "qcom/LENOVO/81JL/qcdxkmsuc850.mbn"; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml index b87a2e28c866..a2384bd74cf2 100644 --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml @@ -26,6 +26,10 @@ properties: - auo,b101uan08.3 # BOE TV105WUM-NW0 10.5" WUXGA TFT LCD panel - boe,tv105wum-nw0 + # BOE TV110C9M-LL3 10.95" WUXGA TFT LCD panel + - boe,tv110c9m-ll3 + # INX HJ110IZ-01A 10.95" WUXGA TFT LCD panel + - innolux,hj110iz-01a reg: description: the virtual channel number of a DSI peripheral @@ -36,6 +40,9 @@ properties: pp1800-supply: description: core voltage supply + pp3300-supply: + description: core voltage supply + avdd-supply: description: phandle of the regulator that provides positive voltage diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml index 2ed010f91e2d..20ce88ab4b3a 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml @@ -22,7 +22,7 @@ properties: items: - enum: # ili9341 240*320 Color on stm32f429-disco board - - st,sf-tc240t-9370-t + - st,sf-tc240t-9370-t - const: ilitek,ili9341 reg: true diff --git a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml index 4b6dda6dbc0f..17cbd0ad32bf 100644 --- a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml +++ b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Orise Tech OTM8009A 3.97" 480x800 TFT LCD panel (MIPI-DSI video mode) maintainers: - - Philippe CORNU <philippe.cornu@st.com> + - Philippe CORNU <philippe.cornu@foss.st.com> description: | The Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD panel connected using diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp.yaml b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml new file mode 100644 index 000000000000..bb0cf6827e79 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml @@ -0,0 +1,188 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-edp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Probeable (via DP AUX / EDID) eDP Panels with simple poweron sequences + +maintainers: + - Douglas Anderson <dianders@chromium.org> + +description: | + This binding file can be used to indicate that an eDP panel is connected + to a Embedded DisplayPort AUX bus (see display/dp-aux-bus.yaml) without + actually specifying exactly what panel is connected. This is useful for + the case that more than one different panel could be connected to the + board, either for second-sourcing purposes or to support multiple SKUs + with different LCDs that hook up to a common board. + + As per above, a requirement for using this binding is that the panel is + represented under the DP AUX bus. This means that we can use any + information provided by the DP AUX bus (including the EDID) to identify + the panel. We can use this to identify display size, resolution, and + timings among other things. + + One piece of information about eDP panels that is typically _not_ + provided anywhere on the DP AUX bus is the power sequencing timings. + This is the reason why, historically, we've always had to explicitly + list eDP panels. We solve that here with two tricks. The "worst case" + power on timings for any panels expected to be connected to a board are + specified in these bindings. Once we've powered on, it's expected that + the operating system will lookup the panel in a table (based on EDID + information) to figure out other power sequencing timings. + + eDP panels in general can have somewhat arbitrary power sequencing + requirements. However, even though it's arbitrary in general, the + vast majority of panel datasheets have a power sequence diagram that + looks the exactly the same as every other panel. Each panel datasheet + cares about different timings in this diagram but the fact that the + diagram is so similar means we can come up with a single driver to + handle it. + + These diagrams all look roughly like this, sometimes labeled with + slightly different numbers / lines but all pretty much the same + sequence. This is because much of this diagram comes straight from + the eDP Standard. + + __________________________________________________ + Vdd ___/: :\____ / + _/ : : \_____/ + :<T1>:<T2>: :<--T10-->:<T11>:<T12>: + : +-----------------------+---------+---------+ + eDP -----------+ Black video | Src vid | Blk vid + + Display : +-----------------------+---------+---------+ + : _______________________:_________:_________: + HPD :<T3>| : : | + ___________| : : |_____________ + : : : : + Sink +-----------------------:---------:---------+ + AUX CH -----------+ AUX Ch operational : : +------------- + +-----------------------:---------:---------+ + : : : : + :<T4>: :<T7>: : : + Src main +------+------+--------------+---------+ + lnk data----------------+LnkTrn| Idle |Valid vid data| Idle/off+------------- + +------+------+--------------+---------+ + : <T5> :<-T6->:<-T8->: : + :__:<T9>: + LED_EN | | + _____________________________________| |____________________________ + : : + __________:__:_ + PWM | : : | + __________________________| : : |__________________________ + : : : : + _____________:__________:__:_:______ + Bklight ____/: : : : : :\____ + power _______/ :<---T13---->: : : :<T16>: \______________ + (Vbl) :<T17>:<---------T14--------->: :<-T15->:<T18>: + + The above looks fairly complex but, as per above, each panel only cares + about a subset of those timings. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: edp-panel + + hpd-reliable-delay-ms: + description: + A fixed amount of time that must be waited after powering on the + panel's power-supply before the HPD signal is a reliable way to know + when the AUX channel is ready. This is useful for panels that glitch + the HPD at the start of power-on. This value is not needed if HPD is + always reliable for all panels that might be connected. + + hpd-absent-delay-ms: + description: + The panel specifies that HPD will be asserted this many milliseconds + from power on (timing T3 in the diagram above). If we have no way to + measure HPD then a fixed delay of this many milliseconds can be used. + This can also be used as a timeout when waiting for HPD. Does not + include the hpd-reliable-delay, so if hpd-reliable-delay was 80 ms + and hpd-absent-delay was 200 ms then we'd do a fixed 80 ms delay and + then we know HPD would assert in the next 120 ms. This value is not + needed if HPD hooked up, either through a GPIO in the panel node or + hooked up directly to the eDP controller. + + backlight: true + enable-gpios: true + port: true + power-supply: true + no-hpd: true + hpd-gpios: true + +additionalProperties: false + +required: + - compatible + - power-supply + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2d { + compatible = "ti,sn65dsi86"; + reg = <0x2d>; + + interrupt-parent = <&tlmm>; + interrupts = <10 IRQ_TYPE_LEVEL_HIGH>; + + enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>; + + vpll-supply = <&src_pp1800_s4a>; + vccio-supply = <&src_pp1800_s4a>; + vcca-supply = <&src_pp1200_l2a>; + vcc-supply = <&src_pp1200_l2a>; + + clocks = <&rpmhcc RPMH_LN_BB_CLK2>; + clock-names = "refclk"; + + no-hpd; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + + port@1 { + reg = <1>; + sn65dsi86_out: endpoint { + remote-endpoint = <&panel_in_edp>; + }; + }; + }; + + aux-bus { + panel { + compatible = "edp-panel"; + power-supply = <&pp3300_dx_edp>; + backlight = <&backlight>; + hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>; + hpd-reliable-delay-ms = <15>; + + port { + panel_in_edp: endpoint { + remote-endpoint = <&sn65dsi86_out>; + }; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 335776c45474..f3c9395d23b6 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -166,6 +166,8 @@ properties: - innolux,at070tn92 # Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel - innolux,g070y2-l01 + # Innolux G070Y2-T02 7" WVGA (800x480) TFT LCD TTL panel + - innolux,g070y2-t02 # Innolux Corporation 10.1" G101ICE-L01 WXGA (1280x800) LVDS panel - innolux,g101ice-l01 # Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel @@ -309,6 +311,8 @@ properties: - urt,umsh-8596md-11t - urt,umsh-8596md-19t - urt,umsh-8596md-20t + # Vivax TPC-9150 tablet 9.0" WSVGA TFT LCD panel + - vivax,tpc9150-panel # VXT 800x480 color TFT LCD panel - vxt,vl050-8048nt-c01 # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel @@ -317,6 +321,7 @@ properties: - yes-optoelectronics,ytc700tlag-05-201c backlight: true + ddc-i2c-bus: true enable-gpios: true port: true power-supply: true diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml index 39477793d289..e8ce2315631a 100644 --- a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Raydium Semiconductor Corporation RM68200 5.5" 720p MIPI-DSI TFT LCD panel maintainers: - - Philippe CORNU <philippe.cornu@st.com> + - Philippe CORNU <philippe.cornu@foss.st.com> description: | The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml new file mode 100644 index 000000000000..26e3c820a2f7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,s6d27a1.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S6D27A1 display panel + +description: The S6D27A1 is a 480x800 DPI display panel from Samsung Mobile + Displays (SMD). The panel must obey the rules for a SPI slave device + as specified in spi/spi-controller.yaml + +maintainers: + - Markuss Broks <markuss.broks@gmail.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,s6d27a1 + + reg: true + + interrupts: + description: provides an optional ESD (electrostatic discharge) + interrupt that signals abnormalities in the display hardware. + This can also be raised for other reasons like erroneous + configuration. + maxItems: 1 + + reset-gpios: true + + vci-supply: + description: regulator that supplies the VCI analog voltage + usually around 3.0 V + + vccio-supply: + description: regulator that supplies the VCCIO voltage usually + around 1.8 V + + backlight: true + + spi-cpha: true + + spi-cpol: true + + spi-max-frequency: + maximum: 1200000 + + port: true + +required: + - compatible + - reg + - vci-supply + - vccio-supply + - spi-cpha + - spi-cpol + - port + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + spi { + compatible = "spi-gpio"; + sck-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; + miso-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; + mosi-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>; + cs-gpios = <&gpio 3 GPIO_ACTIVE_HIGH>; + num-chipselects = <1>; + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "samsung,s6d27a1"; + spi-max-frequency = <1200000>; + spi-cpha; + spi-cpol; + reg = <0>; + vci-supply = <&lcd_3v0_reg>; + vccio-supply = <&lcd_1v8_reg>; + reset-gpios = <&gpio 4 GPIO_ACTIVE_LOW>; + interrupt-parent = <&gpio>; + interrupts = <5 IRQ_TYPE_EDGE_RISING>; + + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/sharp,ls060t1sx01.yaml b/Documentation/devicetree/bindings/display/panel/sharp,ls060t1sx01.yaml new file mode 100644 index 000000000000..271c097cc9a4 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sharp,ls060t1sx01.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/sharp,ls060t1sx01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sharp Microelectronics 6.0" FullHD TFT LCD panel + +maintainers: + - Dmitry Baryskov <dmitry.baryshkov@linaro.org> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: sharp,ls060t1sx01 + + reg: true + backlight: true + reset-gpios: true + port: true + + avdd-supply: + description: handle of the regulator that provides the positive supply voltage + avee-supply: + description: handle of the regulator that provides the negative supply voltage + vddi-supply: + description: handle of the regulator that provides the I/O supply voltage + vddh-supply: + description: handle of the regulator that provides the analog supply voltage + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "sharp,ls060t1sx01"; + reg = <0>; + avdd-supply = <&pm8941_l22>; + backlight = <&backlight>; + reset-gpios = <&pm8916_gpios 25 GPIO_ACTIVE_LOW>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index e3ca5389c17d..13efea574584 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -39,6 +39,7 @@ properties: - renesas,du-r8a77980 # for R-Car V3H compatible DU - renesas,du-r8a77990 # for R-Car E3 compatible DU - renesas,du-r8a77995 # for R-Car D3 compatible DU + - renesas,du-r8a779a0 # for R-Car V3U compatible DU reg: maxItems: 1 @@ -773,6 +774,56 @@ allOf: - reset-names - renesas,vsps + - if: + properties: + compatible: + contains: + enum: + - renesas,du-r8a779a0 + then: + properties: + clocks: + items: + - description: Functional clock + + clock-names: + maxItems: 1 + items: + - const: du.0 + + interrupts: + maxItems: 2 + + resets: + maxItems: 1 + + reset-names: + items: + - const: du.0 + + ports: + properties: + port@0: + description: DSI 0 + port@1: + description: DSI 1 + port@2: false + port@3: false + + required: + - port@0 + - port@1 + + renesas,vsps: + minItems: 2 + + required: + - clock-names + - interrupts + - resets + - reset-names + - renesas,vsps + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml index ed310bbe3afe..ce1ef93cce93 100644 --- a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml +++ b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml @@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 DSI host controller maintainers: - - Philippe Cornu <philippe.cornu@st.com> - - Yannick Fertre <yannick.fertre@st.com> + - Philippe Cornu <philippe.cornu@foss.st.com> + - Yannick Fertre <yannick.fertre@foss.st.com> description: The STMicroelectronics STM32 DSI controller uses the Synopsys DesignWare MIPI-DSI host controller. diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml b/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml index 4ae3d75492d3..01e2da23790b 100644 --- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml @@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 lcd-tft display controller maintainers: - - Philippe Cornu <philippe.cornu@st.com> - - Yannick Fertre <yannick.fertre@st.com> + - Philippe Cornu <philippe.cornu@foss.st.com> + - Yannick Fertre <yannick.fertre@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt index 3e64075ac7ec..3b3d0bbfcfff 100644 --- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt +++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt @@ -60,7 +60,7 @@ Example: blue-and-red-wiring = "crossed"; port { - lcdc_0: endpoint@0 { + lcdc_0: endpoint { remote-endpoint = <&hdmi_0>; }; }; @@ -75,7 +75,7 @@ Example: pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>; port { - hdmi_0: endpoint@0 { + hdmi_0: endpoint { remote-endpoint = <&lcdc_0>; }; }; diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml index d88bd93f4b80..10ec78ca1c65 100644 --- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml @@ -160,8 +160,8 @@ examples: <&xlnx_dpdma 2>, <&xlnx_dpdma 3>; - phys = <&psgtr 1 PHY_TYPE_DP 0 3 27000000>, - <&psgtr 0 PHY_TYPE_DP 1 3 27000000>; + phys = <&psgtr 1 PHY_TYPE_DP 0 3>, + <&psgtr 0 PHY_TYPE_DP 1 3>; phy-names = "dp-phy0", "dp-phy1"; }; diff --git a/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml new file mode 100644 index 000000000000..fc02c5d50ce4 --- /dev/null +++ b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml @@ -0,0 +1,301 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 Bootlin +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/display/xylon,logicvc-display.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Xylon LogiCVC display controller + +maintainers: + - Paul Kocialkowski <paul.kocialkowski@bootlin.com> + +description: | + The Xylon LogiCVC is a display controller that supports multiple layers. + It is usually implemented as programmable logic and was optimized for use + with Xilinx Zynq-7000 SoCs and Xilinx FPGAs. + + Because the controller is intended for use in a FPGA, most of the + configuration of the controller takes place at logic configuration bitstream + synthesis time. As a result, many of the device-tree bindings are meant to + reflect the synthesis configuration and must not be configured differently. + Matching synthesis parameters are provided when applicable. + + Layers are declared in the "layers" sub-node and have dedicated configuration. + In version 3 of the controller, each layer has fixed memory offset and address + starting from the video memory base address for its framebuffer. In version 4, + framebuffers are configured with a direct memory address instead. + +properties: + compatible: + enum: + - xylon,logicvc-3.02.a-display + - xylon,logicvc-4.01.a-display + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 4 + + clock-names: + minItems: 1 + items: + # vclk is required and must be provided as first item. + - const: vclk + # Other clocks are optional and can be provided in any order. + - enum: + - vclk2 + - lvdsclk + - lvdsclkn + - enum: + - vclk2 + - lvdsclk + - lvdsclkn + - enum: + - vclk2 + - lvdsclk + - lvdsclkn + + interrupts: + maxItems: 1 + + memory-region: + maxItems: 1 + + xylon,display-interface: + enum: + # Parallel RGB interface (C_DISPLAY_INTERFACE == 0) + - parallel-rgb + # ITU-T BR656 interface (C_DISPLAY_INTERFACE == 1) + - bt656 + # 4-bit LVDS interface (C_DISPLAY_INTERFACE == 2) + - lvds-4bits + # 3-bit LVDS interface (C_DISPLAY_INTERFACE == 4) + - lvds-3bits + # DVI interface (C_DISPLAY_INTERFACE == 5) + - dvi + description: Display output interface (C_DISPLAY_INTERFACE). + + xylon,display-colorspace: + enum: + # RGB colorspace (C_DISPLAY_COLOR_SPACE == 0) + - rgb + # YUV 4:2:2 colorspace (C_DISPLAY_COLOR_SPACE == 1) + - yuv422 + # YUV 4:4:4 colorspace (C_DISPLAY_COLOR_SPACE == 2) + - yuv444 + description: Display output colorspace (C_DISPLAY_COLOR_SPACE). + + xylon,display-depth: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: Display output depth (C_PIXEL_DATA_WIDTH). + + xylon,row-stride: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: Fixed number of pixels in a framebuffer row (C_ROW_STRIDE). + + xylon,dithering: + $ref: "/schemas/types.yaml#/definitions/flag" + description: Dithering module is enabled (C_XCOLOR) + + xylon,background-layer: + $ref: "/schemas/types.yaml#/definitions/flag" + description: | + The last layer is used to display a black background (C_USE_BACKGROUND). + The layer must still be registered. + + xylon,layers-configurable: + $ref: "/schemas/types.yaml#/definitions/flag" + description: | + Configuration of layers' size, position and offset is enabled + (C_USE_SIZE_POSITION). + + layers: + type: object + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + "^layer@[0-9]+$": + type: object + + properties: + reg: + maxItems: 1 + + xylon,layer-depth: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: Layer depth (C_LAYER_X_DATA_WIDTH). + + xylon,layer-colorspace: + enum: + # RGB colorspace (C_LAYER_X_TYPE == 0) + - rgb + # YUV packed colorspace (C_LAYER_X_TYPE == 0) + - yuv + description: Layer colorspace (C_LAYER_X_TYPE). + + xylon,layer-alpha-mode: + enum: + # Alpha is configured layer-wide (C_LAYER_X_ALPHA_MODE == 0) + - layer + # Alpha is configured per-pixel (C_LAYER_X_ALPHA_MODE == 1) + - pixel + description: Alpha mode for the layer (C_LAYER_X_ALPHA_MODE). + + xylon,layer-base-offset: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: | + Offset in number of lines (C_LAYER_X_OFFSET) starting from the + video RAM base (C_VMEM_BASEADDR), only for version 3. + + xylon,layer-buffer-offset: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: | + Offset in number of lines (C_BUFFER_*_OFFSET) starting from the + layer base offset for the second buffer used in double-buffering. + + xylon,layer-primary: + $ref: "/schemas/types.yaml#/definitions/flag" + description: | + Layer should be registered as a primary plane (exactly one is + required). + + additionalProperties: false + + required: + - reg + - xylon,layer-depth + - xylon,layer-colorspace + - xylon,layer-alpha-mode + + required: + - "#address-cells" + - "#size-cells" + - layer@0 + + additionalProperties: false + + description: | + The description of the display controller layers, containing layer + sub-nodes that each describe a registered layer. + + port: + $ref: /schemas/graph.yaml#/properties/port + description: | + Video output port, typically connected to a panel or bridge. + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - xylon,display-interface + - xylon,display-colorspace + - xylon,display-depth + - xylon,row-stride + - layers + - port + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + logicvc: logicvc@43c00000 { + compatible = "xylon,logicvc-3.02.a", "syscon", "simple-mfd"; + reg = <0x43c00000 0x6000>; + + #address-cells = <1>; + #size-cells = <1>; + + logicvc_display: display@0 { + compatible = "xylon,logicvc-3.02.a-display"; + reg = <0x0 0x6000>; + + memory-region = <&logicvc_cma>; + + clocks = <&logicvc_vclk 0>, <&logicvc_lvdsclk 0>; + clock-names = "vclk", "lvdsclk"; + + interrupt-parent = <&intc>; + interrupts = <0 34 IRQ_TYPE_LEVEL_HIGH>; + + xylon,display-interface = "lvds-4bits"; + xylon,display-colorspace = "rgb"; + xylon,display-depth = <16>; + xylon,row-stride = <1024>; + + xylon,layers-configurable; + + layers { + #address-cells = <1>; + #size-cells = <0>; + + layer@0 { + reg = <0>; + xylon,layer-depth = <16>; + xylon,layer-colorspace = "rgb"; + xylon,layer-alpha-mode = "layer"; + xylon,layer-base-offset = <0>; + xylon,layer-buffer-offset = <480>; + xylon,layer-primary; + }; + + layer@1 { + reg = <1>; + xylon,layer-depth = <16>; + xylon,layer-colorspace = "rgb"; + xylon,layer-alpha-mode = "layer"; + xylon,layer-base-offset = <2400>; + xylon,layer-buffer-offset = <480>; + }; + + layer@2 { + reg = <2>; + xylon,layer-depth = <16>; + xylon,layer-colorspace = "rgb"; + xylon,layer-alpha-mode = "layer"; + xylon,layer-base-offset = <960>; + xylon,layer-buffer-offset = <480>; + }; + + layer@3 { + reg = <3>; + xylon,layer-depth = <16>; + xylon,layer-colorspace = "rgb"; + xylon,layer-alpha-mode = "layer"; + xylon,layer-base-offset = <480>; + xylon,layer-buffer-offset = <480>; + }; + + layer@4 { + reg = <4>; + xylon,layer-depth = <16>; + xylon,layer-colorspace = "rgb"; + xylon,layer-alpha-mode = "layer"; + xylon,layer-base-offset = <8192>; + xylon,layer-buffer-offset = <480>; + }; + }; + + port { + #address-cells = <1>; + #size-cells = <0>; + + logicvc_output: endpoint@0 { + reg = <0>; + remote-endpoint = <&panel_input>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml index ac4d59494fc8..dc059d6fd037 100644 --- a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml +++ b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml @@ -68,7 +68,7 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/jz4780-cgu.h> + #include <dt-bindings/clock/ingenic,jz4780-cgu.h> dma: dma-controller@13420000 { compatible = "ingenic,jz4780-dma"; reg = <0x13420000 0x400>, <0x13421000 0x40>; diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt index cf5b9e44432c..6e9a5497b3f2 100644 --- a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt +++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt @@ -15,6 +15,8 @@ Required properties: the secure world. - qcom,controlled-remotely : optional, indicates that the bam is controlled by remote proccessor i.e. execution environment. +- qcom,powered-remotely : optional, indicates that the bam is powered up by + a remote processor but must be initialized by the local processor. - num-channels : optional, indicates supported number of DMA channels in a remotely controlled bam. - qcom,num-ees : optional, indicates supported number of Execution Environments diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml index 4bf676fd25dc..55faab6a468e 100644 --- a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml +++ b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml @@ -50,7 +50,7 @@ description: | maintainers: - - Amelie Delaunay <amelie.delaunay@st.com> + - Amelie Delaunay <amelie.delaunay@foss.st.com> allOf: - $ref: "dma-controller.yaml#" diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml index c8d2b51d8410..f751796531c9 100644 --- a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml +++ b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 DMA MUX (DMA request router) bindings maintainers: - - Amelie Delaunay <amelie.delaunay@st.com> + - Amelie Delaunay <amelie.delaunay@foss.st.com> allOf: - $ref: "dma-router.yaml#" diff --git a/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml b/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml index c30be840be1c..87b4afd2cf62 100644 --- a/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml +++ b/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml @@ -50,7 +50,7 @@ description: | if no HW ack signal is used by the MDMA client maintainers: - - Amelie Delaunay <amelie.delaunay@st.com> + - Amelie Delaunay <amelie.delaunay@foss.st.com> allOf: - $ref: "dma-controller.yaml#" diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml index 7afc9f2be13a..e66ef2da7879 100644 --- a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml +++ b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml @@ -8,6 +8,7 @@ title: NXP i.MX8 DSP core maintainers: - Daniel Baluta <daniel.baluta@nxp.com> + - Shengjiu Wang <shengjiu.wang@nxp.com> description: | Some boards from i.MX8 family contain a DSP core used for @@ -19,6 +20,10 @@ properties: - fsl,imx8qxp-dsp - fsl,imx8qm-dsp - fsl,imx8mp-dsp + - fsl,imx8qxp-hifi4 + - fsl,imx8qm-hifi4 + - fsl,imx8mp-hifi4 + - fsl,imx8ulp-hifi4 reg: maxItems: 1 @@ -28,37 +33,53 @@ properties: - description: ipg clock - description: ocram clock - description: core clock + - description: debug interface clock + - description: message unit clock + minItems: 3 clock-names: items: - const: ipg - const: ocram - const: core + - const: debug + - const: mu + minItems: 3 power-domains: description: List of phandle and PM domain specifier as documented in Documentation/devicetree/bindings/power/power_domain.txt + minItems: 1 maxItems: 4 mboxes: description: List of <&phandle type channel> - 2 channels for TXDB, 2 channels for RXDB + or - 1 channel for TX, 1 channel for RX, 1 channel for RXDB (see mailbox/fsl,mu.txt) + minItems: 3 maxItems: 4 mbox-names: - items: - - const: txdb0 - - const: txdb1 - - const: rxdb0 - - const: rxdb1 + minItems: 3 + maxItems: 4 memory-region: description: phandle to a node describing reserved memory (System RAM memory) used by DSP (see bindings/reserved-memory/reserved-memory.txt) - maxItems: 1 + minItems: 1 + maxItems: 4 + + firmware-name: + description: | + Default name of the firmware to load to the remote processor. + + fsl,dsp-ctrl: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to syscon block which provide access for processor enablement required: - compatible @@ -70,6 +91,58 @@ required: - mbox-names - memory-region +allOf: + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8qxp-dsp + - fsl,imx8qm-dsp + - fsl,imx8qxp-hifi4 + - fsl,imx8qm-hifi4 + then: + properties: + power-domains: + minItems: 4 + else: + properties: + power-domains: + maxItems: 1 + + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8qxp-hifi4 + - fsl,imx8qm-hifi4 + - fsl,imx8mp-hifi4 + - fsl,imx8ulp-hifi4 + then: + properties: + memory-region: + minItems: 4 + mboxes: + maxItems: 3 + mbox-names: + items: + - const: tx + - const: rx + - const: rxdb + else: + properties: + memory-region: + maxItems: 1 + mboxes: + minItems: 4 + mbox-names: + items: + - const: txdb0 + - const: txdb1 + - const: rxdb0 + - const: rxdb1 + additionalProperties: false examples: @@ -91,3 +164,41 @@ examples: mboxes = <&lsio_mu13 2 0>, <&lsio_mu13 2 1>, <&lsio_mu13 3 0>, <&lsio_mu13 3 1>; memory-region = <&dsp_reserved>; }; + - | + #include <dt-bindings/clock/imx8mp-clock.h> + dsp_reserved: dsp@92400000 { + reg = <0x92400000 0x1000000>; + no-map; + }; + dsp_vdev0vring0: vdev0vring0@942f0000 { + reg = <0x942f0000 0x8000>; + no-map; + }; + dsp_vdev0vring1: vdev0vring1@942f8000 { + reg = <0x942f8000 0x8000>; + no-map; + }; + dsp_vdev0buffer: vdev0buffer@94300000 { + compatible = "shared-dma-pool"; + reg = <0x94300000 0x100000>; + no-map; + }; + + dsp: dsp@3b6e8000 { + compatible = "fsl,imx8mp-hifi4"; + reg = <0x3b6e8000 0x88000>; + clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_DSP_ROOT>, + <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_OCRAMA_IPG>, + <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_DSP_ROOT>, + <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_DSPDBG_ROOT>; + clock-names = "ipg", "ocram", "core", "debug"; + firmware-name = "imx/dsp/hifi4.bin"; + power-domains = <&audiomix_pd>; + mbox-names = "tx", "rx", "rxdb"; + mboxes = <&mu2 0 0>, + <&mu2 1 0>, + <&mu2 3 0>; + memory-region = <&dsp_vdev0buffer>, <&dsp_vdev0vring0>, + <&dsp_vdev0vring1>, <&dsp_reserved>; + fsl,dsp-ctrl = <&audio_blk_ctrl>; + }; diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml index 914a423ec449..4c5396a9744f 100644 --- a/Documentation/devicetree/bindings/eeprom/at24.yaml +++ b/Documentation/devicetree/bindings/eeprom/at24.yaml @@ -98,6 +98,12 @@ properties: - const: nxp,se97b - const: atmel,24c02 - items: + - const: onnn,cat24c04 + - const: atmel,24c04 + - items: + - const: onnn,cat24c05 + - const: atmel,24c04 + - items: - const: renesas,r1ex24002 - const: atmel,24c02 - items: diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml index ff6ec65145cf..c078796ae1b5 100644 --- a/Documentation/devicetree/bindings/example-schema.yaml +++ b/Documentation/devicetree/bindings/example-schema.yaml @@ -119,7 +119,7 @@ properties: # valid for this binding. clock-frequency: - # The type is set in the core schema. Per device schema only need to set + # The type is set in the core schema. Per-device schema only need to set # constraints on the possible values. minimum: 100 maximum: 400000 @@ -133,24 +133,24 @@ properties: # *-supply is always a single phandle, so nothing more to define. foo-supply: true - # Vendor specific properties + # Vendor-specific properties # - # Vendor specific properties have slightly different schema requirements than + # Vendor-specific properties have slightly different schema requirements than # common properties. They must have at least a type definition and # 'description'. vendor,int-property: - description: Vendor specific properties must have a description + description: Vendor-specific properties must have a description $ref: /schemas/types.yaml#/definitions/uint32 enum: [2, 4, 6, 8, 10] vendor,bool-property: - description: Vendor specific properties must have a description. Boolean + description: Vendor-specific properties must have a description. Boolean properties are one case where the json-schema 'type' keyword can be used directly. type: boolean vendor,string-array-property: - description: Vendor specific properties should reference a type in the + description: Vendor-specific properties should reference a type in the core schema. $ref: /schemas/types.yaml#/definitions/string-array items: @@ -158,7 +158,7 @@ properties: - enum: [baz, boo] vendor,property-in-standard-units-microvolt: - description: Vendor specific properties having a standard unit suffix + description: Vendor-specific properties having a standard unit suffix don't need a type. enum: [ 100, 200, 300 ] diff --git a/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml b/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml index 9875b4d5c356..71a9f2e5d0dc 100644 --- a/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml +++ b/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml @@ -11,7 +11,9 @@ maintainers: properties: compatible: - const: ti,tusb320 + enum: + - ti,tusb320 + - ti,tusb320l reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt index a7333ad938d2..d7e3cda8924e 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt @@ -13,8 +13,10 @@ Required properties: * "qcom,scm-ipq806x" * "qcom,scm-ipq8074" * "qcom,scm-mdm9607" + * "qcom,scm-msm8226" * "qcom,scm-msm8660" * "qcom,scm-msm8916" + * "qcom,scm-msm8953" * "qcom,scm-msm8960" * "qcom,scm-msm8974" * "qcom,scm-msm8994" @@ -33,7 +35,7 @@ Required properties: * core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660" and "qcom,scm-msm8960" * core, iface and bus clocks required for "qcom,scm-apq8084", - "qcom,scm-msm8916" and "qcom,scm-msm8974" + "qcom,scm-msm8916", "qcom,scm-msm8953" and "qcom,scm-msm8974" - clock-names: Must contain "core" for the core clock, "iface" for the interface clock and "bus" for the bus clock per the requirements of the compatible. - qcom,dload-mode: phandle to the TCSR hardware block and offset of the diff --git a/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml b/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml new file mode 100644 index 000000000000..396101a223e7 --- /dev/null +++ b/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gnss/u-blox,neo-6m.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: U-blox GNSS Receiver Device Tree Bindings + +maintainers: + - Johan Hovold <johan@kernel.org> + +description: > + The U-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces. + +properties: + compatible: + enum: + - u-blox,neo-6m + - u-blox,neo-8 + - u-blox,neo-m8 + + reg: + description: > + The DDC Slave Address, SPI chip select address, the number of the USB hub + port or the USB host-controller port to which this device is attached, + depending on the bus used. Required for the DDC, SPI or USB busses. + + vcc-supply: + description: > + Main voltage regulator + + timepulse-gpios: + maxItems: 1 + description: > + Time pulse GPIO + + u-blox,extint-gpios: + maxItems: 1 + description: > + GPIO connected to the "external interrupt" input pin + + v-bckp-supply: + description: > + Backup voltage regulator + + current-speed: true + +required: + - compatible + - vcc-supply + +additionalProperties: false + +examples: + - | + serial { + gnss { + compatible = "u-blox,neo-8"; + v-bckp-supply = <&gnss_v_bckp_reg>; + vcc-supply = <&gnss_vcc_reg>; + }; + }; diff --git a/Documentation/devicetree/bindings/gnss/u-blox.txt b/Documentation/devicetree/bindings/gnss/u-blox.txt deleted file mode 100644 index 7cdefd058fe0..000000000000 --- a/Documentation/devicetree/bindings/gnss/u-blox.txt +++ /dev/null @@ -1,45 +0,0 @@ -u-blox GNSS Receiver DT binding - -The u-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces. - -Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic -properties. - -Required properties: - -- compatible : Must be one of - - "u-blox,neo-6m" - "u-blox,neo-8" - "u-blox,neo-m8" - -- vcc-supply : Main voltage regulator - -Required properties (DDC): -- reg : DDC (I2C) slave address - -Required properties (SPI): -- reg : SPI chip select address - -Required properties (USB): -- reg : Number of the USB hub port or the USB host-controller port - to which this device is attached - -Optional properties: - -- timepulse-gpios : Time pulse GPIO -- u-blox,extint-gpios : GPIO connected to the "external interrupt" input pin -- v-bckp-supply : Backup voltage regulator - -Example: - -serial@1234 { - compatible = "ns16550a"; - - gnss { - compatible = "u-blox,neo-8"; - - v-bckp-supply = <&gnss_v_bckp_reg>; - vcc-supply = <&gnss_vcc_reg>; - }; -}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-axp209.txt b/Documentation/devicetree/bindings/gpio/gpio-axp209.txt deleted file mode 100644 index fc42b2caa06d..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-axp209.txt +++ /dev/null @@ -1,75 +0,0 @@ -AXP209 GPIO & pinctrl controller - -This driver follows the usual GPIO bindings found in -Documentation/devicetree/bindings/gpio/gpio.txt - -This driver follows the usual pinctrl bindings found in -Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt - -This driver employs the per-pin muxing pattern. - -Required properties: -- compatible: Should be one of: - - "x-powers,axp209-gpio" - - "x-powers,axp813-gpio" -- #gpio-cells: Should be two. The first cell is the pin number and the - second is the GPIO flags. -- gpio-controller: Marks the device node as a GPIO controller. - -This node must be a subnode of the axp20x PMIC, documented in -Documentation/devicetree/bindings/mfd/axp20x.txt - -Example: - -axp209: pmic@34 { - compatible = "x-powers,axp209"; - reg = <0x34>; - interrupt-parent = <&nmi_intc>; - interrupts = <0 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #interrupt-cells = <1>; - - axp_gpio: gpio { - compatible = "x-powers,axp209-gpio"; - gpio-controller; - #gpio-cells = <2>; - }; -}; - -The GPIOs can be muxed to other functions and therefore, must be a subnode of -axp_gpio. - -Example: - -&axp_gpio { - gpio0_adc: gpio0-adc { - pins = "GPIO0"; - function = "adc"; - }; -}; - -&example_node { - pinctrl-names = "default"; - pinctrl-0 = <&gpio0_adc>; -}; - -GPIOs and their functions -------------------------- - -Each GPIO is independent from the other (i.e. GPIO0 in gpio_in function does -not force GPIO1 and GPIO2 to be in gpio_in function as well). - -axp209 ------- -GPIO | Functions ------------------------- -GPIO0 | gpio_in, gpio_out, ldo, adc -GPIO1 | gpio_in, gpio_out, ldo, adc -GPIO2 | gpio_in, gpio_out - -axp813 ------- -GPIO | Functions ------------------------- -GPIO0 | gpio_in, gpio_out, ldo, adc -GPIO1 | gpio_in, gpio_out, ldo diff --git a/Documentation/devicetree/bindings/gpio/gpio-xlp.txt b/Documentation/devicetree/bindings/gpio/gpio-xlp.txt deleted file mode 100644 index 47fc64922fe0..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-xlp.txt +++ /dev/null @@ -1,49 +0,0 @@ -Netlogic XLP Family GPIO -======================== - -This GPIO driver is used for following Netlogic XLP SoCs: - XLP832, XLP316, XLP208, XLP980, XLP532 -This GPIO driver is also compatible with GPIO controller found on -Broadcom Vulcan ARM64. - -Required properties: -------------------- - -- compatible: Should be one of the following: - - "netlogic,xlp832-gpio": For Netlogic XLP832 - - "netlogic,xlp316-gpio": For Netlogic XLP316 - - "netlogic,xlp208-gpio": For Netlogic XLP208 - - "netlogic,xlp980-gpio": For Netlogic XLP980 - - "netlogic,xlp532-gpio": For Netlogic XLP532 - - "brcm,vulcan-gpio": For Broadcom Vulcan ARM64 -- reg: Physical base address and length of the controller's registers. -- #gpio-cells: Should be two. The first cell is the pin number and the second - cell is used to specify optional parameters (currently unused). -- gpio-controller: Marks the device node as a GPIO controller. -- nr-gpios: Number of GPIO pins supported by the controller. -- interrupt-cells: Should be two. The first cell is the GPIO Number. The - second cell is used to specify flags. The following subset of flags is - supported: - - trigger type: - 1 = low to high edge triggered. - 2 = high to low edge triggered. - 4 = active high level-sensitive. - 8 = active low level-sensitive. -- interrupts: Interrupt number for this device. -- interrupt-controller: Identifies the node as an interrupt controller. - -Example: - - gpio: xlp_gpio@34000 { - compatible = "netlogic,xlp316-gpio"; - reg = <0 0x34100 0x1000 - 0 0x35100 0x1000>; - #gpio-cells = <2>; - gpio-controller; - nr-gpios = <57>; - - #interrupt-cells = <2>; - interrupt-parent = <&pic>; - interrupts = <39>; - interrupt-controller; - }; diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml index 0d62c28fb58d..d4e42c2b995b 100644 --- a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml @@ -29,6 +29,8 @@ properties: gpio-controller: true + gpio-line-names: true + "#gpio-cells": const: 2 diff --git a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml new file mode 100644 index 000000000000..0f628b088cec --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/gpio/x-powers,axp209-gpio.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: X-Powers AXP209 GPIO Device Tree Bindings + +maintainers: + - Chen-Yu Tsai <wens@csie.org> + +properties: + "#gpio-cells": + const: 2 + description: > + The first cell is the pin number and the second is the GPIO flags. + + compatible: + oneOf: + - enum: + - x-powers,axp209-gpio + - x-powers,axp813-gpio + - items: + - const: x-powers,axp803-gpio + - const: x-powers,axp813-gpio + + gpio-controller: true + +patternProperties: + "^.*-pins?$": + $ref: /schemas/pinctrl/pinmux-node.yaml# + + properties: + pins: + items: + enum: + - GPIO0 + - GPIO1 + - GPIO2 + + function: + enum: + - adc + - ldo + - gpio_in + - gpio_out + +required: + - compatible + - "#gpio-cells" + - gpio-controller + +additionalProperties: false + +... diff --git a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml new file mode 100644 index 000000000000..31c0fc345903 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: ZynqMP Mode Pin GPIO controller + +description: + PS_MODE is 4-bits boot mode pins sampled on POR deassertion. Mode Pin + GPIO controller with configurable from numbers of pins (from 0 to 3 per + PS_MODE). Every pin can be configured as input/output. + +maintainers: + - Piyush Mehta <piyush.mehta@xilinx.com> + +properties: + compatible: + const: xlnx,zynqmp-gpio-modepin + + gpio-controller: true + + "#gpio-cells": + const: 2 + +required: + - compatible + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + zynqmp-firmware { + gpio { + compatible = "xlnx,zynqmp-gpio-modepin"; + gpio-controller; + #gpio-cells = <2>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml new file mode 100644 index 000000000000..3cf862976448 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Device tree binding for NVIDIA Tegra NVDEC + +description: | + NVDEC is the hardware video decoder present on NVIDIA Tegra210 + and newer chips. It is located on the Host1x bus and typically + programmed through Host1x channels. + +maintainers: + - Thierry Reding <treding@gmail.com> + - Mikko Perttunen <mperttunen@nvidia.com> + +properties: + $nodename: + pattern: "^nvdec@[0-9a-f]*$" + + compatible: + enum: + - nvidia,tegra210-nvdec + - nvidia,tegra186-nvdec + - nvidia,tegra194-nvdec + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: nvdec + + resets: + maxItems: 1 + + reset-names: + items: + - const: nvdec + + power-domains: + maxItems: 1 + + iommus: + maxItems: 1 + + dma-coherent: true + + interconnects: + items: + - description: DMA read memory client + - description: DMA read 2 memory client + - description: DMA write memory client + + interconnect-names: + items: + - const: dma-mem + - const: read-1 + - const: write + + nvidia,host1x-class: + description: | + Host1x class of the engine, used to specify the targeted engine + when programming the engine through Host1x channels or when + configuring engine-specific behavior in Host1x. + default: 0xf0 + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - power-domains + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra186-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/memory/tegra186-mc.h> + #include <dt-bindings/power/tegra186-powergate.h> + #include <dt-bindings/reset/tegra186-reset.h> + + nvdec@15480000 { + compatible = "nvidia,tegra186-nvdec"; + reg = <0x15480000 0x40000>; + clocks = <&bpmp TEGRA186_CLK_NVDEC>; + clock-names = "nvdec"; + resets = <&bpmp TEGRA186_RESET_NVDEC>; + reset-names = "nvdec"; + + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_NVDEC>; + interconnects = <&mc TEGRA186_MEMORY_CLIENT_NVDECSRD &emc>, + <&mc TEGRA186_MEMORY_CLIENT_NVDECSRD1 &emc>, + <&mc TEGRA186_MEMORY_CLIENT_NVDECSWR &emc>; + interconnect-names = "dma-mem", "read-1", "write"; + iommus = <&smmu TEGRA186_SID_NVDEC>; + }; diff --git a/Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.yaml index 47cf9c8d97e9..b18c616035a8 100644 --- a/Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.yaml +++ b/Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.yaml @@ -7,8 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 Hardware Spinlock bindings maintainers: - - Benjamin Gaignard <benjamin.gaignard@st.com> - - Fabien Dessenne <fabien.dessenne@st.com> + - Fabien Dessenne <fabien.dessenne@foss.st.com> properties: "#hwlock-cells": diff --git a/Documentation/devicetree/bindings/hwmon/dps650ab.txt b/Documentation/devicetree/bindings/hwmon/dps650ab.txt deleted file mode 100644 index 76780e795899..000000000000 --- a/Documentation/devicetree/bindings/hwmon/dps650ab.txt +++ /dev/null @@ -1,11 +0,0 @@ -Bindings for Delta Electronics DPS-650-AB power supply - -Required properties: -- compatible : "delta,dps650ab" -- reg : I2C address, one of 0x58, 0x59. - -Example: - dps650ab@58 { - compatible = "delta,dps650ab"; - reg = <0x58>; - }; diff --git a/Documentation/devicetree/bindings/hwmon/hih6130.txt b/Documentation/devicetree/bindings/hwmon/hih6130.txt deleted file mode 100644 index 2c43837af4c2..000000000000 --- a/Documentation/devicetree/bindings/hwmon/hih6130.txt +++ /dev/null @@ -1,12 +0,0 @@ -Honeywell Humidicon HIH-6130 humidity/temperature sensor --------------------------------------------------------- - -Requires node properties: -- compatible : "honeywell,hi6130" -- reg : the I2C address of the device. This is 0x27. - -Example: - hih6130@27 { - compatible = "honeywell,hih6130"; - reg = <0x27>; - }; diff --git a/Documentation/devicetree/bindings/hwmon/ibm,cffps1.txt b/Documentation/devicetree/bindings/hwmon/ibm,cffps1.txt deleted file mode 100644 index d9a2719f9243..000000000000 --- a/Documentation/devicetree/bindings/hwmon/ibm,cffps1.txt +++ /dev/null @@ -1,26 +0,0 @@ -Device-tree bindings for IBM Common Form Factor Power Supply Versions 1 and 2 ------------------------------------------------------------------------------ - -Required properties: - - compatible : Must be one of the following: - "ibm,cffps1" - "ibm,cffps2" - or "ibm,cffps" if the system - must support any version of the - power supply - - reg = < I2C bus address >; : Address of the power supply on the - I2C bus. - -Example: - - i2c-bus@100 { - #address-cells = <1>; - #size-cells = <0>; - #interrupt-cells = <1>; - < more properties > - - power-supply@68 { - compatible = "ibm,cffps1"; - reg = <0x68>; - }; - }; diff --git a/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml new file mode 100644 index 000000000000..f5a6cc3efd33 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/hwmon/iio-hwmon.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: ADC-attached Hardware Sensor Device Tree Bindings + +maintainers: + - Jonathan Cameron <jic23@kernel.org> + +description: > + Bindings for hardware monitoring devices connected to ADC controllers + supporting the Industrial I/O bindings. + +properties: + compatible: + const: iio-hwmon + + io-channels: + minItems: 1 + maxItems: 8 # Should be enough + description: > + List of phandles to ADC channels to read the monitoring values + +required: + - compatible + - io-channels + +additionalProperties: false + +examples: + - | + iio-hwmon { + compatible = "iio-hwmon"; + io-channels = <&adc 1>, <&adc 2>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/jc42.txt b/Documentation/devicetree/bindings/hwmon/jc42.txt deleted file mode 100644 index f569db58f64a..000000000000 --- a/Documentation/devicetree/bindings/hwmon/jc42.txt +++ /dev/null @@ -1,46 +0,0 @@ -Properties for Jedec JC-42.4 compatible temperature sensors - -Required properties: -- compatible: May include a device-specific string consisting of the - manufacturer and the name of the chip. A list of supported - chip names follows. - Must include "jedec,jc-42.4-temp" for any Jedec JC-42.4 - compatible temperature sensor. - - Supported chip names: - adi,adt7408 - atmel,at30ts00 - atmel,at30tse004 - onnn,cat6095 - onnn,cat34ts02 - maxim,max6604 - microchip,mcp9804 - microchip,mcp9805 - microchip,mcp9808 - microchip,mcp98243 - microchip,mcp98244 - microchip,mcp9843 - nxp,se97 - nxp,se98 - st,stts2002 - st,stts2004 - st,stts3000 - st,stts424 - st,stts424e - idt,tse2002 - idt,tse2004 - idt,ts3000 - idt,ts3001 - -- reg: I2C address - -Optional properties: -- smbus-timeout-disable: When set, the smbus timeout function will be disabled. - This is not supported on all chips. - -Example: - -temp-sensor@1a { - compatible = "jedec,jc-42.4-temp"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml b/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml new file mode 100644 index 000000000000..0e49b3901161 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/jedec,jc42.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Jedec JC-42.4 compatible temperature sensors + +maintainers: + - Jean Delvare <jdelvare@suse.com> + - Guenter Roeck <linux@roeck-us.net> + +select: + properties: + compatible: + const: jedec,jc-42.4-temp + + required: + - compatible + +properties: + compatible: + oneOf: + - const: jedec,jc-42.4-temp + - items: + - enum: + - adi,adt7408 + - atmel,at30ts00 + - atmel,at30tse004 + - idt,tse2002 + - idt,tse2004 + - idt,ts3000 + - idt,ts3001 + - maxim,max6604 + - microchip,mcp9804 + - microchip,mcp9805 + - microchip,mcp9808 + - microchip,mcp98243 + - microchip,mcp98244 + - microchip,mcp9843 + - nxp,se97 + - nxp,se97b + - nxp,se98 + - onnn,cat6095 + - onnn,cat34ts02 + - st,stts2002 + - st,stts2004 + - st,stts3000 + - st,stts424 + - st,stts424e + - const: jedec,jc-42.4-temp + + reg: + maxItems: 1 + + smbus-timeout-disable: + description: | + When set, the smbus timeout function will be disabled. This is not + supported on all chips. + type: boolean + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + temp-sensor@1a { + compatible = "jedec,jc-42.4-temp"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml b/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml new file mode 100644 index 000000000000..4b5851c326f7 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/lltc,ltc4151.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LTC4151 High Voltage I2C Current and Voltage Monitor + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + const: lltc,ltc4151 + + reg: + maxItems: 1 + + shunt-resistor-micro-ohms: + description: + Shunt resistor value in micro-Ohms + default: 1000 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@6e { + compatible = "lltc,ltc4151"; + reg = <0x6e>; + shunt-resistor-micro-ohms = <1500>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/lm70.txt b/Documentation/devicetree/bindings/hwmon/lm70.txt deleted file mode 100644 index ea417a0d32af..000000000000 --- a/Documentation/devicetree/bindings/hwmon/lm70.txt +++ /dev/null @@ -1,22 +0,0 @@ -* LM70/TMP121/LM71/LM74 thermometer. - -Required properties: -- compatible: one of - "ti,lm70" - "ti,tmp121" - "ti,tmp122" - "ti,lm71" - "ti,lm74" - -See Documentation/devicetree/bindings/spi/spi-bus.txt for more required and -optional properties. - -Example: - -spi_master { - temperature-sensor@0 { - compatible = "ti,lm70"; - reg = <0>; - spi-max-frequency = <1000000>; - }; -}; diff --git a/Documentation/devicetree/bindings/hwmon/lm90.txt b/Documentation/devicetree/bindings/hwmon/lm90.txt deleted file mode 100644 index 398dcb965751..000000000000 --- a/Documentation/devicetree/bindings/hwmon/lm90.txt +++ /dev/null @@ -1,51 +0,0 @@ -* LM90 series thermometer. - -Required node properties: -- compatible: manufacturer and chip name, one of - "adi,adm1032" - "adi,adt7461" - "adi,adt7461a" - "gmt,g781" - "national,lm90" - "national,lm86" - "national,lm89" - "national,lm99" - "dallas,max6646" - "dallas,max6647" - "dallas,max6649" - "dallas,max6657" - "dallas,max6658" - "dallas,max6659" - "dallas,max6680" - "dallas,max6681" - "dallas,max6695" - "dallas,max6696" - "onnn,nct1008" - "winbond,w83l771" - "nxp,sa56004" - "ti,tmp451" - -- reg: I2C bus address of the device - -- vcc-supply: vcc regulator for the supply voltage. - -Optional properties: -- interrupts: Contains a single interrupt specifier which describes the - LM90 "-ALERT" pin output. - See interrupt-controller/interrupts.txt for the format. - -- #thermal-sensor-cells: should be set to 1. See thermal/thermal-sensor.yaml - for details. See <include/dt-bindings/thermal/lm90.h> for the - definition of the local, remote and 2nd remote sensor index - constants. - -Example LM90 node: - -temp-sensor { - compatible = "onnn,nct1008"; - reg = <0x4c>; - vcc-supply = <&palmas_ldo6_reg>; - interrupt-parent = <&gpio>; - interrupts = <TEGRA_GPIO(O, 4) IRQ_TYPE_LEVEL_LOW>; - #thermal-sensor-cells = <1>; -} diff --git a/Documentation/devicetree/bindings/hwmon/ltc4151.txt b/Documentation/devicetree/bindings/hwmon/ltc4151.txt deleted file mode 100644 index d008a5ef525a..000000000000 --- a/Documentation/devicetree/bindings/hwmon/ltc4151.txt +++ /dev/null @@ -1,18 +0,0 @@ -LTC4151 High Voltage I2C Current and Voltage Monitor - -Required properties: -- compatible: Must be "lltc,ltc4151" -- reg: I2C address - -Optional properties: -- shunt-resistor-micro-ohms - Shunt resistor value in micro-Ohms - Defaults to <1000> if unset. - -Example: - -ltc4151@6e { - compatible = "lltc,ltc4151"; - reg = <0x6e>; - shunt-resistor-micro-ohms = <1500>; -}; diff --git a/Documentation/devicetree/bindings/hwmon/mcp3021.txt b/Documentation/devicetree/bindings/hwmon/mcp3021.txt deleted file mode 100644 index 294318ba6914..000000000000 --- a/Documentation/devicetree/bindings/hwmon/mcp3021.txt +++ /dev/null @@ -1,21 +0,0 @@ -mcp3021 properties - -Required properties: -- compatible: Must be one of the following: - - "microchip,mcp3021" for mcp3021 - - "microchip,mcp3221" for mcp3221 -- reg: I2C address - -Optional properties: - -- reference-voltage-microvolt - Reference voltage in microvolt (uV) - -Example: - -mcp3021@4d { - compatible = "microchip,mcp3021"; - reg = <0x4d>; - - reference-voltage-microvolt = <4500000>; /* 4.5 V */ -}; diff --git a/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml b/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml new file mode 100644 index 000000000000..c42051f8a191 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/microchip,mcp3021.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MCP3021 A/D converter + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + enum: + - microchip,mcp3021 + - microchip,mcp3221 + + reg: + maxItems: 1 + + reference-voltage-microvolt: + description: + VDD supply power and reference voltage + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + adc@4d { + compatible = "microchip,mcp3021"; + reg = <0x4d>; + + reference-voltage-microvolt = <4500000>; /* 4.5 V */ + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml new file mode 100644 index 000000000000..6e1d54ff5d5b --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/national,lm90.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LM90 series thermometer + +maintainers: + - Jean Delvare <jdelvare@suse.com> + - Guenter Roeck <linux@roeck-us.net> + +properties: + compatible: + enum: + - adi,adm1032 + - adi,adt7461 + - adi,adt7461a + - dallas,max6646 + - dallas,max6647 + - dallas,max6649 + - dallas,max6657 + - dallas,max6658 + - dallas,max6659 + - dallas,max6680 + - dallas,max6681 + - dallas,max6695 + - dallas,max6696 + - gmt,g781 + - national,lm86 + - national,lm89 + - national,lm90 + - national,lm99 + - nxp,sa56004 + - onnn,nct1008 + - ti,tmp451 + - winbond,w83l771 + + + interrupts: + items: + - description: | + Single interrupt specifier which describes the LM90 "-ALERT" pin + output. + + reg: + maxItems: 1 + + "#thermal-sensor-cells": + const: 1 + + vcc-supply: + description: phandle to the regulator that provides the +VCC supply + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/tegra-gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@4c { + compatible = "onnn,nct1008"; + reg = <0x4c>; + vcc-supply = <&palmas_ldo6_reg>; + interrupt-parent = <&gpio>; + interrupts = <TEGRA_GPIO(O, 4) IRQ_TYPE_LEVEL_LOW>; + #thermal-sensor-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml new file mode 100644 index 000000000000..9e77cee07dbc --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml @@ -0,0 +1,141 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +--- +$id: http://devicetree.org/schemas/hwmon/ntc-thermistor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NTC thermistor temperature sensors + +maintainers: + - Naveen Krishna Chatradhi <ch.naveen@samsung.com> + - Linus Walleij <linus.walleij@linaro.org> + +description: | + Thermistors with negative temperature coefficient (NTC) are resistors that + vary in resistance in an often non-linear way in relation to temperature. + The negative temperature coefficient means that the resistance decreases + as the temperature rises. Since the relationship between resistance and + temperature is non-linear, software drivers most often need to use a look + up table and interpolation to get from resistance to temperature. + + When used in practice, a thermistor is often connected between ground, a + pull-up resistor or/and a pull-down resistor and a fixed voltage like this: + + + e.g. 5V = pull-up voltage (puv) + | + +-+ + | | + | | Pull-up resistor + | | (puo) + +-+ + |-------------------------o + +-+ | ^ + | |/ | + | / | + |/| Thermistor | Measured voltage (mv) + / | | "connected ground" + /| | | + +-+ | + |-------------------------o + +-+ ^ + | | | + | | Pull-down resistor | Measured voltage (mv) + | | (pdo) | "connected positive" + +-+ | + | | + | v + + GND GND + + The arrangements of where we measure the voltage over the thermistor are + called "connected ground" and "connected positive" and shall be understood as + the cases when either pull-up or pull-down resistance is zero. + + If the pull-up resistance is 0 one end of the thermistor is connected to the + positive voltage and we get the thermistor on top of a pull-down resistor + and we take the measure between the thermistor and the pull-down resistor. + + Conversely if the pull-down resistance is zero, one end of the thermistor is + connected to ground and we get the thermistor under the pull-up resistor + and we take the measure between the pull-up resistor and the thermistor. + + We can use both pull-up and pull-down resistors at the same time, and then + the figure illustrates where the voltage will be measured for the "connected + ground" and "connected positive" cases. + +properties: + $nodename: + pattern: "^thermistor(.*)?$" + + compatible: + oneOf: + - const: epcos,b57330v2103 + - const: epcos,b57891s0103 + - const: murata,ncp15wb473 + - const: murata,ncp18wb473 + - const: murata,ncp21wb473 + - const: murata,ncp03wb473 + - const: murata,ncp15wl333 + - const: murata,ncp03wf104 + - const: murata,ncp15xh103 + # Deprecated "ntp," compatible strings + - const: ntc,ncp15wb473 + deprecated: true + - const: ntc,ncp18wb473 + deprecated: true + - const: ntc,ncp21wb473 + deprecated: true + - const: ntc,ncp03wb473 + deprecated: true + - const: ntc,ncp15wl333 + deprecated: true + + "#thermal-sensor-cells": + description: Thermal sensor cells if used for thermal sensoring. + const: 0 + + pullup-uv: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Pull-up voltage in micro volts. Must always be specified. + + pullup-ohm: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Pull-up resistance in ohms. Must always be specified, even + if zero. + + pulldown-ohm: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Pull-down resistance in ohms. Must always be specified, even + if zero. + + connected-positive: + $ref: /schemas/types.yaml#/definitions/flag + description: Indicates how the thermistor is connected in series with + a pull-up and/or a pull-down resistor. See the description above for + an illustration. If this flag is NOT specified, the thermistor is assumed + to be connected-ground, which usually means a pull-down resistance of + zero but complex arrangements are possible. + + # See /schemas/iio/adc/adc.yaml + io-channels: + maxItems: 1 + description: IIO ADC channel to read the voltage over the resistor. Must + always be specified. + +required: + - compatible + - pullup-uv + - pullup-ohm + - pulldown-ohm + - io-channels + +additionalProperties: false + +examples: + - | + thermistor0 { + compatible = "murata,ncp18wb473"; + io-channels = <&gpadc 0x06>; + pullup-uv = <1800000>; + pullup-ohm = <220000>; + pulldown-ohm = <0>; + #thermal-sensor-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt deleted file mode 100644 index 4c5c3712970e..000000000000 --- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt +++ /dev/null @@ -1,44 +0,0 @@ -NTC Thermistor hwmon sensors -------------------------------- - -Requires node properties: -- "compatible" value : one of - "epcos,b57330v2103" - "epcos,b57891s0103" - "murata,ncp15wb473" - "murata,ncp18wb473" - "murata,ncp21wb473" - "murata,ncp03wb473" - "murata,ncp15wl333" - "murata,ncp03wf104" - "murata,ncp15xh103" - -/* Usage of vendor name "ntc" is deprecated */ -<DEPRECATED> "ntc,ncp15wb473" -<DEPRECATED> "ntc,ncp18wb473" -<DEPRECATED> "ntc,ncp21wb473" -<DEPRECATED> "ntc,ncp03wb473" -<DEPRECATED> "ntc,ncp15wl333" - -- "pullup-uv" Pull up voltage in micro volts -- "pullup-ohm" Pull up resistor value in ohms -- "pulldown-ohm" Pull down resistor value in ohms -- "connected-positive" Always ON, If not specified. - Status change is possible. -- "io-channels" Channel node of ADC to be used for - conversion. - -Optional node properties: -- "#thermal-sensor-cells" Used to expose itself to thermal fw. - -Read more about iio bindings at - https://github.com/devicetree-org/dt-schema/blob/master/schemas/iio/ - -Example: - ncp15wb473@0 { - compatible = "murata,ncp15wb473"; - pullup-uv = <1800000>; - pullup-ohm = <47000>; - pulldown-ohm = <0>; - io-channels = <&adc 3>; - }; diff --git a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml new file mode 100644 index 000000000000..2f0620ecccc9 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml @@ -0,0 +1,145 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/hwmon/nuvoton,nct7802.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton NCT7802Y Hardware Monitoring IC + +maintainers: + - Guenter Roeck <linux@roeck-us.net> + +description: | + The NCT7802Y is a hardware monitor IC which supports one on-die and up to + 5 remote temperature sensors with SMBus interface. + + Datasheets: + https://www.nuvoton.com/export/resource-files/Nuvoton_NCT7802Y_Datasheet_V12.pdf + +additionalProperties: false + +properties: + compatible: + enum: + - nuvoton,nct7802 + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^channel@[0-3]$": + type: object + + additionalProperties: false + + properties: + reg: + items: + - enum: + - 0 # Local Temperature Sensor ("LTD") + - 1 # Remote Temperature Sensor or Voltage Sensor 1 ("RTD1") + - 2 # Remote Temperature Sensor or Voltage Sensor 2 ("RTD2") + - 3 # Remote Temperature Sensor or Voltage Sensor 3 ("RTD3") + + sensor-type: + items: + - enum: + - temperature + - voltage + + temperature-mode: + items: + - enum: + - thermistor + - thermal-diode + + required: + - reg + + allOf: + # For channels RTD1, RTD2 and RTD3, require sensor-type to be set. + # Otherwise (for all other channels), do not allow temperature-mode to be + # set. + - if: + properties: + reg: + items: + - enum: + - 1 + - 2 + - 3 + then: + required: + - sensor-type + else: + not: + required: + - sensor-type + + # For channels RTD1 and RTD2 and if sensor-type is "temperature", require + # temperature-mode to be set. Otherwise (for all other channels or + # sensor-type settings), do not allow temperature-mode to be set + - if: + properties: + reg: + items: + - enum: + - 1 + - 2 + sensor-type: + items: + - enum: + - temperature + then: + required: + - temperature-mode + else: + not: + required: + - temperature-mode + +required: + - compatible + - reg + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + nct7802@28 { + compatible = "nuvoton,nct7802"; + reg = <0x28>; + + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { /* LTD */ + reg = <0>; + }; + + channel@1 { /* RTD1 */ + reg = <1>; + sensor-type = "voltage"; + }; + + channel@2 { /* RTD2 */ + reg = <2>; + sensor-type = "temperature"; + temperature-mode = "thermal-diode"; + }; + + channel@3 { /* RTD3 */ + reg = <3>; + sensor-type = "temperature"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml new file mode 100644 index 000000000000..da8292bc32f5 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/hwmon/pmbus/ti,lm25066.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: National Semiconductor/Texas Instruments LM250x6/LM506x power-management ICs + +maintainers: + - Zev Weiss <zev@bewilderbeest.net> + +description: | + The LM25066 family of power-management ICs (a.k.a. hot-swap + controllers or eFuses in various contexts) are PMBus devices that + offer temperature, current, voltage, and power monitoring. + + Datasheet: https://www.ti.com/lit/ds/symlink/lm25066.pdf + +properties: + compatible: + enum: + - ti,lm25056 + - ti,lm25066 + - ti,lm5064 + - ti,lm5066 + - ti,lm5066i + + reg: + maxItems: 1 + + shunt-resistor-micro-ohms: + description: + Shunt (sense) resistor value in micro-Ohms + default: 1000 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@40 { + compatible = "ti,lm25066"; + reg = <0x40>; + shunt-resistor-micro-ohms = <675>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml b/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml new file mode 100644 index 000000000000..4669217d01e1 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/sensirion,sht15.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sensirion SHT15 humidity and temperature sensor + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + const: sensirion,sht15 + + clk-gpios: + maxItems: 1 + + data-gpios: + maxItems: 1 + + vcc-supply: + description: regulator that drives the VCC pin + +required: + - compatible + - clk-gpios + - data-gpios + - vcc-supply + +additionalProperties: false + +examples: + - | + sensor { + compatible = "sensirion,sht15"; + clk-gpios = <&gpio4 12 0>; + data-gpios = <&gpio4 13 0>; + vcc-supply = <®_sht15>; + + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_sensor>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/sht15.txt b/Documentation/devicetree/bindings/hwmon/sht15.txt deleted file mode 100644 index 6a80277cc426..000000000000 --- a/Documentation/devicetree/bindings/hwmon/sht15.txt +++ /dev/null @@ -1,19 +0,0 @@ -Sensirion SHT15 Humidity and Temperature Sensor - -Required properties: - - - "compatible": must be "sensirion,sht15". - - "data-gpios": GPIO connected to the data line. - - "clk-gpios": GPIO connected to the clock line. - - "vcc-supply": regulator that drives the VCC pin. - -Example: - - sensor { - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_sensor>; - compatible = "sensirion,sht15"; - clk-gpios = <&gpio4 12 0>; - data-gpios = <&gpio4 13 0>; - vcc-supply = <®_sht15>; - }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml new file mode 100644 index 000000000000..d3eff4fac107 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/ti,tmp102.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TMP102 temperature sensor + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + enum: + - ti,tmp102 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + "#thermal-sensor-cells": + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@48 { + compatible = "ti,tmp102"; + reg = <0x48>; + interrupt-parent = <&gpio7>; + interrupts = <16 IRQ_TYPE_LEVEL_LOW>; + #thermal-sensor-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml new file mode 100644 index 000000000000..eda55bbc172d --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/ti,tmp108.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TMP108 temperature sensor + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + enum: + - ti,tmp108 + + interrupts: + items: + - description: alert interrupt + + reg: + maxItems: 1 + + "#thermal-sensor-cells": + const: 0 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@48 { + compatible = "ti,tmp108"; + reg = <0x48>; + interrupt-parent = <&gpio1>; + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&tmp_alrt>; + #thermal-sensor-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp421.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp421.yaml new file mode 100644 index 000000000000..36f649938fb7 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp421.yaml @@ -0,0 +1,110 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/ti,tmp421.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TMP42x/TMP44x temperature sensor + +maintainers: + - Guenter Roeck <linux@roeck-us.net> + +description: | + ±1°C Remote and Local temperature sensor + https://www.ti.com/lit/ds/symlink/tmp422.pdf + +properties: + compatible: + enum: + - ti,tmp421 + - ti,tmp422 + - ti,tmp423 + - ti,tmp441 + - ti,tmp442 + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +required: + - compatible + - reg + +additionalProperties: false + +patternProperties: + "^channel@([0-3])$": + type: object + description: | + Represents channels of the device and their specific configuration. + + properties: + reg: + description: | + The channel number. 0 is local channel, 1-3 are remote channels + items: + minimum: 0 + maximum: 3 + + 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/uint32 + items: + minimum: 0 + maximum: 255 + + required: + - reg + + additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@4c { + compatible = "ti,tmp422"; + reg = <0x4c>; + }; + }; + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@4c { + compatible = "ti,tmp422"; + reg = <0x4c>; + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0x0>; + ti,n-factor = <0x1>; + label = "local"; + }; + + channel@1 { + reg = <0x1>; + ti,n-factor = <0x0>; + label = "somelabel"; + }; + + channel@2 { + reg = <0x2>; + status = "disabled"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/tmp108.txt b/Documentation/devicetree/bindings/hwmon/tmp108.txt deleted file mode 100644 index 54d4beed4ee5..000000000000 --- a/Documentation/devicetree/bindings/hwmon/tmp108.txt +++ /dev/null @@ -1,18 +0,0 @@ -TMP108 temperature sensor -------------------------- - -This device supports I2C only. - -Requires node properties: -- compatible : "ti,tmp108" -- reg : the I2C address of the device. This is 0x48, 0x49, 0x4a, or 0x4b. - -Optional properties: -- interrupts: Reference to the TMP108 alert interrupt. -- #thermal-sensor-cells: should be set to 0. - -Example: - tmp108@48 { - compatible = "ti,tmp108"; - reg = <0x48>; - }; diff --git a/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml b/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml index 6097e8ac46c1..1b03810d4b4d 100644 --- a/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml +++ b/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml @@ -55,7 +55,7 @@ examples: #size-cells = <0>; axp221: pmic@68 { - compatible = "x-powers,axp221"; + /* compatible = "x-powers,axp221"; */ reg = <0x68>; }; }; diff --git a/Documentation/devicetree/bindings/i2c/apple,i2c.yaml b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml new file mode 100644 index 000000000000..22fc8483256f --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/i2c/apple,i2c.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Apple/PASemi I2C controller + +maintainers: + - Sven Peter <sven@svenpeter.dev> + +description: | + Apple SoCs such as the M1 come with a I2C controller based on the one found + in machines with P. A. Semi's PWRficient processors. + The bus is used to communicate with e.g. USB PD chips or the speaker + amp. + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + enum: + - apple,t8103-i2c + - apple,i2c + + reg: + maxItems: 1 + + clocks: + items: + - description: I2C bus reference clock + + interrupts: + maxItems: 1 + + clock-frequency: + description: | + Desired I2C bus clock frequency in Hz. If not specified, 100 kHz will be + used. This frequency is generated by dividing the reference clock. + Allowed values are between ref_clk/(16*4) and ref_clk/(16*255). + +required: + - compatible + - reg + - clocks + - interrupts + +unevaluatedProperties: false + +examples: + - | + i2c@35010000 { + compatible = "apple,t8103-i2c"; + reg = <0x35010000 0x4000>; + interrupt-parent = <&aic>; + interrupts = <0 627 4>; + clocks = <&ref_clk>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml index 29b9447f3b84..fe0c89edf7c1 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml @@ -17,9 +17,10 @@ properties: oneOf: - enum: - fsl,imx7ulp-lpi2c - - fsl,imx8qm-lpi2c - items: - - const: fsl,imx8qxp-lpi2c + - enum: + - fsl,imx8qxp-lpi2c + - fsl,imx8qm-lpi2c - const: fsl,imx7ulp-lpi2c reg: diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml index 3592d49235e0..c167958ae2a9 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml @@ -57,7 +57,9 @@ properties: const: ipg clock-frequency: - enum: [ 100000, 400000 ] + minimum: 1 + default: 100000 + maximum: 400000 dmas: items: diff --git a/Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt b/Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt deleted file mode 100644 index f818ef507ab7..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt +++ /dev/null @@ -1,22 +0,0 @@ -Device tree configuration for the I2C controller on the XLP9xx/5xx SoC - -Required properties: -- compatible : should be "netlogic,xlp980-i2c" -- reg : bus address start and address range size of device -- interrupts : interrupt number - -Optional properties: -- clock-frequency : frequency of bus clock in Hz - Defaults to 100 KHz when the property is not specified - -Example: - -i2c0: i2c@113100 { - compatible = "netlogic,xlp980-i2c"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0 0x113100 0x100>; - clock-frequency = <400000>; - interrupts = <30>; - interrupt-parent = <&pic>; -}; diff --git a/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml b/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml index e1e65eb4f795..febde6cc5f69 100644 --- a/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml @@ -60,7 +60,7 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/jz4780-cgu.h> + #include <dt-bindings/clock/ingenic,jz4780-cgu.h> #include <dt-bindings/dma/jz4780-dma.h> #include <dt-bindings/interrupt-controller/irq.h> i2c@10054000 { diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml index d747f4990ad8..c07289a643d8 100644 --- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: I2C controller embedded in STMicroelectronics STM32 I2C platform maintainers: - - Pierre-Yves MORDRET <pierre-yves.mordret@st.com> + - Pierre-Yves MORDRET <pierre-yves.mordret@foss.st.com> allOf: - $ref: /schemas/i2c/i2c-controller.yaml# diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl313.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl313.yaml new file mode 100644 index 000000000000..d6afc1b8c272 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl313.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/adi,adxl313.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADXL313 3-Axis Digital Accelerometer + +maintainers: + - Lucas Stankus <lucas.p.stankus@gmail.com> + +description: | + Analog Devices ADXL313 3-Axis Digital Accelerometer that supports + both I2C & SPI interfaces. + https://www.analog.com/en/products/adxl313.html + +properties: + compatible: + enum: + - adi,adxl313 + + reg: + maxItems: 1 + + spi-3wire: true + + spi-max-frequency: true + + vs-supply: + description: Regulator that supplies power to the accelerometer + + vdd-supply: + description: Regulator that supplies the digital interface supply voltage + + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + minItems: 1 + maxItems: 2 + items: + enum: + - INT1 + - INT2 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + /* Example for a I2C device node */ + accelerometer@53 { + compatible = "adi,adxl313"; + reg = <0x53>; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "INT1"; + }; + }; + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + /* Example for a SPI device node */ + accelerometer@0 { + compatible = "adi,adxl313"; + reg = <0>; + spi-max-frequency = <5000000>; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "INT1"; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl355.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl355.yaml new file mode 100644 index 000000000000..ba54d6998f2e --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl355.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/adi,adxl355.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADXL355 3-Axis, Low noise MEMS Accelerometer + +maintainers: + - Puranjay Mohan <puranjay12@gmail.com> + +description: | + Analog Devices ADXL355 3-Axis, Low noise MEMS Accelerometer that supports + both I2C & SPI interfaces + https://www.analog.com/en/products/adxl355.html + +properties: + compatible: + enum: + - adi,adxl355 + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 3 + description: | + Type for DRDY should be IRQ_TYPE_EDGE_RISING. + Three configurable interrupt lines exist. + + interrupt-names: + description: Specify which interrupt line is in use. + items: + enum: + - INT1 + - INT2 + - DRDY + minItems: 1 + maxItems: 3 + + vdd-supply: + description: Regulator that provides power to the sensor + + vddio-supply: + description: Regulator that provides power to the bus + + spi-max-frequency: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + /* Example for a I2C device node */ + accelerometer@1d { + compatible = "adi,adxl355"; + reg = <0x1d>; + interrupt-parent = <&gpio>; + interrupts = <25 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "DRDY"; + }; + }; + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@0 { + compatible = "adi,adxl355"; + reg = <0>; + spi-max-frequency = <1000000>; + interrupt-parent = <&gpio>; + interrupts = <25 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "DRDY"; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml index 52fa0f7c2d0e..714e48e613de 100644 --- a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml +++ b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml @@ -21,6 +21,9 @@ properties: reg: maxItems: 1 + interrupts: + maxItems: 1 + vdd-supply: true vddio-supply: true diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7949.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7949.yaml index 9b56bd4d5510..0b10ed5f74ae 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7949.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7949.yaml @@ -26,19 +26,43 @@ properties: reg: maxItems: 1 + vrefin-supply: + description: + Buffered ADC reference voltage supply. + vref-supply: description: - ADC reference voltage supply + Unbuffered ADC reference voltage supply. + + adi,internal-ref-microvolt: + description: | + Internal reference voltage selection in microvolts. + + If no internal reference is specified, the channel will default to the + external reference defined by vrefin-supply (or vref-supply). + vrefin-supply will take precedence over vref-supply if both are defined. + + If no supplies are defined, the reference selection will default to + 4096mV internal reference. + + enum: [2500000, 4096000] + default: 4096000 + spi-max-frequency: true - "#io-channel-cells": + '#io-channel-cells': const: 1 + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + required: - compatible - reg - - vref-supply additionalProperties: false @@ -49,9 +73,30 @@ examples: #size-cells = <0>; adc@0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "adi,ad7949"; reg = <0>; vref-supply = <&vdd_supply>; }; + + adc@1 { + #address-cells = <1>; + #size-cells = <0>; + + compatible = "adi,ad7949"; + reg = <1>; + vrefin-supply = <&vdd_supply>; + }; + + adc@2 { + #address-cells = <1>; + #size-cells = <0>; + + compatible = "adi,ad7949"; + reg = <2>; + adi,internal-ref-microvolt = <4096000>; + }; }; ... diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad799x.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad799x.yaml new file mode 100644 index 000000000000..29641ce7175b --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad799x.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/adi,ad799x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD799x analog to digital converters + +maintainers: + - Michael Hennerich <Michael.Hennerich@analog.com> + +description: | + Support for Analog Devices AD7991, AD7992, AD7993, AD7994, AD7995, AD7997, AD7998, + AD7999 and similar analog to digital converters. + Specifications on the converters can be found at: + AD7991, AD7995, AD7999: + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7991_7995_7999.pdf + AD7992: + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7992.pdf + AD7993, AD7994: + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7993_7994.pdf + AD7997, AD7998: + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7997_7998.pdf + +properties: + compatible: + enum: + - adi,ad7991 + - adi,ad7992 + - adi,ad7993 + - adi,ad7994 + - adi,ad7995 + - adi,ad7997 + - adi,ad7998 + - adi,ad7999 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vcc-supply: + description: + ADC power supply + + vref-supply: + description: + ADC reference voltage supply, optional for AD7991, AD7995 and AD7999 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + adc1: adc@28 { + reg = <0x28>; + compatible = "adi,ad7991"; + interrupts = <13 2>; + interrupt-parent = <&gpio6>; + + vcc-supply = <&vcc_3v3>; + vref-supply = <&adc_vref>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/adc/aspeed,ast2600-adc.yaml b/Documentation/devicetree/bindings/iio/adc/aspeed,ast2600-adc.yaml new file mode 100644 index 000000000000..b283c8ca2bbf --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/aspeed,ast2600-adc.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/aspeed,ast2600-adc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADC that forms part of an ASPEED server management processor. + +maintainers: + - Billy Tsai <billy_tsai@aspeedtech.com> + +description: | + • 10-bits resolution for 16 voltage channels. + • The device split into two individual engine and each contains 8 voltage + channels. + • Channel scanning can be non-continuous. + • Programmable ADC clock frequency. + • Programmable upper and lower threshold for each channels. + • Interrupt when larger or less than threshold for each channels. + • Support hysteresis for each channels. + • Built-in a compensating method. + • Built-in a register to trim internal reference voltage. + • Internal or External reference voltage. + • Support 2 Internal reference voltage 1.2v or 2.5v. + • Integrate dividing circuit for battery sensing. + +properties: + compatible: + enum: + - aspeed,ast2600-adc0 + - aspeed,ast2600-adc1 + description: + Their trimming data, which is used to calibrate internal reference volage, + locates in different address of OTP. + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + description: + Input clock used to derive the sample clock. Expected to be the + SoC's APB clock. + + resets: + maxItems: 1 + + "#io-channel-cells": + const: 1 + + vref-supply: + description: + The external regulator supply ADC reference voltage. + + aspeed,int-vref-microvolt: + enum: [1200000, 2500000] + description: + ADC internal reference voltage in microvolts. + + aspeed,battery-sensing: + type: boolean + description: + Inform the driver that last channel will be used to sensor battery. + + aspeed,trim-data-valid: + type: boolean + description: | + The ADC reference voltage can be calibrated to obtain the trimming + data which will be stored in otp. This property informs the driver that + the data store in the otp is valid. + +required: + - compatible + - reg + - clocks + - resets + - "#io-channel-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/ast2600-clock.h> + adc0: adc@1e6e9000 { + compatible = "aspeed,ast2600-adc0"; + reg = <0x1e6e9000 0x100>; + clocks = <&syscon ASPEED_CLK_APB2>; + resets = <&syscon ASPEED_RESET_ADC>; + #io-channel-cells = <1>; + aspeed,int-vref-microvolt = <2500000>; + }; + adc1: adc@1e6e9100 { + compatible = "aspeed,ast2600-adc1"; + reg = <0x1e6e9100 0x100>; + clocks = <&syscon ASPEED_CLK_APB2>; + resets = <&syscon ASPEED_RESET_ADC>; + #io-channel-cells = <1>; + aspeed,int-vref-microvolt = <2500000>; + }; +... diff --git a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml index 79c13b408eda..efed361215b4 100644 --- a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml @@ -15,6 +15,7 @@ properties: enum: - atmel,sama5d2-adc - microchip,sam9x60-adc + - microchip,sama7g5-adc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml index 3eb7aa8822c3..698beb896f76 100644 --- a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml @@ -74,7 +74,7 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/jz4740-cgu.h> + #include <dt-bindings/clock/ingenic,jz4740-cgu.h> #include <dt-bindings/iio/adc/ingenic,adc.h> adc@10070000 { diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml new file mode 100644 index 000000000000..9c59a20a6032 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/nxp,imx8qxp-adc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP IMX8QXP ADC bindings + +maintainers: + - Cai Huoqing <caihuoqing@baidu.com> + +description: + Supports the ADC found on the IMX8QXP SoC. + +properties: + compatible: + const: nxp,imx8qxp-adc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: per + - const: ipg + + assigned-clocks: + maxItems: 1 + + assigned-clock-rates: + maxItems: 1 + + power-domains: + maxItems: 1 + + "#io-channel-cells": + const: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - assigned-clocks + - assigned-clock-rates + - power-domains + - "#io-channel-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/firmware/imx/rsrc.h> + soc { + #address-cells = <2>; + #size-cells = <2>; + adc@5a880000 { + compatible = "nxp,imx8qxp-adc"; + reg = <0x0 0x5a880000 0x0 0x10000>; + interrupts = <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX_SC_R_ADC_0>, + <&clk IMX_SC_R_ADC_0>; + clock-names = "per", "ipg"; + assigned-clocks = <&clk IMX_SC_R_ADC_0>; + assigned-clock-rates = <24000000>; + power-domains = <&pd IMX_SC_R_ADC_0>; + #io-channel-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml index a390343d0c2a..2287697f1f61 100644 --- a/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml +++ b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Device-Tree bindings for sigma delta modulator maintainers: - - Arnaud Pouliquen <arnaud.pouliquen@st.com> + - Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml index a58334c3bb76..4d6074518b5c 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml @@ -19,7 +19,7 @@ description: | Each STM32 ADC block can have up to 3 ADC instances. maintainers: - - Fabrice Gasnier <fabrice.gasnier@st.com> + - Fabrice Gasnier <fabrice.gasnier@foss.st.com> properties: compatible: @@ -222,6 +222,12 @@ patternProperties: '#io-channel-cells': const: 1 + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + interrupts: description: | IRQ Line for the ADC instance. Valid values are: @@ -256,6 +262,7 @@ patternProperties: - 20 channels, numbered from 0 to 19 (for in0..in19) on stm32h7 and stm32mp1. $ref: /schemas/types.yaml#/definitions/uint32-array + deprecated: true st,adc-diff-channels: description: | @@ -265,7 +272,9 @@ patternProperties: <vinp vinn>, <vinp vinn>,... vinp and vinn are numbered from 0 to 19. Note: At least one of "st,adc-channels" or "st,adc-diff-channels" is - required. Both properties can be used together. Some channels can be + required if no adc generic channel is defined. These legacy channel + properties are exclusive with adc generic channel bindings. + Both properties can be used together. Some channels can be used as single-ended and some other ones as differential (mixed). But channels can't be configured both as single-ended and differential. $ref: /schemas/types.yaml#/definitions/uint32-matrix @@ -279,6 +288,7 @@ patternProperties: "vinn" indicates negative input number minimum: 0 maximum: 19 + deprecated: true st,min-sample-time-nsecs: description: @@ -289,6 +299,50 @@ patternProperties: list, to set sample time resp. for all channels, or independently for each channel. $ref: /schemas/types.yaml#/definitions/uint32-array + deprecated: true + + nvmem-cells: + items: + - description: Phandle to the calibration vrefint data provided by otp + + nvmem-cell-names: + items: + - const: vrefint + + patternProperties: + "^channel@([0-9]|1[0-9])$": + type: object + $ref: "adc.yaml" + description: Represents the external channels which are connected to the ADC. + + properties: + reg: + items: + minimum: 0 + maximum: 19 + + label: + description: | + Unique name to identify which channel this is. + Reserved label names "vddcore", "vrefint" and "vbat" + are used to identify internal channels with matching names. + + diff-channels: + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + minimum: 0 + maximum: 19 + + st,min-sample-time-ns: + description: | + Minimum sampling time in nanoseconds. Depending on hardware (board) + e.g. high/low analog input source impedance, fine tune of ADC + sampling time may be recommended. + + required: + - reg + + additionalProperties: false allOf: - if: @@ -369,12 +423,6 @@ patternProperties: additionalProperties: false - anyOf: - - required: - - st,adc-channels - - required: - - st,adc-diff-channels - required: - compatible - reg @@ -451,4 +499,50 @@ examples: // other adc child node follow... }; + - | + // Example 3: with stm32mp157c to setup ADC2 with: + // - internal channels 13, 14, 15. + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/stm32mp1-clks.h> + adc122: adc@48003000 { + compatible = "st,stm32mp1-adc-core"; + reg = <0x48003000 0x400>; + interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&rcc ADC12>, <&rcc ADC12_K>; + clock-names = "bus", "adc"; + booster-supply = <&booster>; + vdd-supply = <&vdd>; + vdda-supply = <&vdda>; + vref-supply = <&vref>; + st,syscfg = <&syscfg>; + interrupt-controller; + #interrupt-cells = <1>; + #address-cells = <1>; + #size-cells = <0>; + adc@100 { + compatible = "st,stm32mp1-adc"; + #io-channel-cells = <1>; + reg = <0x100>; + interrupts = <1>; + #address-cells = <1>; + #size-cells = <0>; + channel@13 { + reg = <13>; + label = "vrefint"; + st,min-sample-time-ns = <9000>; + }; + channel@14 { + reg = <14>; + label = "vddcore"; + st,min-sample-time-ns = <9000>; + }; + channel@15 { + reg = <15>; + label = "vbat"; + st,min-sample-time-ns = <9000>; + }; + }; + }; + ... diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml index 733351dee252..7c260f209687 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml @@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 DFSDM ADC device driver maintainers: - - Fabrice Gasnier <fabrice.gasnier@st.com> - - Olivier Moysan <olivier.moysan@st.com> + - Fabrice Gasnier <fabrice.gasnier@foss.st.com> + - Olivier Moysan <olivier.moysan@foss.st.com> description: | STM32 DFSDM ADC is a sigma delta analog-to-digital converter dedicated to diff --git a/Documentation/devicetree/bindings/iio/adc/ti,am3359-adc.yaml b/Documentation/devicetree/bindings/iio/adc/ti,am3359-adc.yaml new file mode 100644 index 000000000000..d6f21d5cccd7 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/ti,am3359-adc.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/ti,am3359-adc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI AM3359 ADC + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +properties: + compatible: + enum: + - ti,am3359-adc + - ti,am4372-adc + + '#io-channel-cells': + const: 1 + + ti,adc-channels: + description: List of analog inputs available for ADC. AIN0 = 0, AIN1 = 1 and + so on until AIN7 = 7. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + + ti,chan-step-opendelay: + description: List of open delays for each channel of ADC in the order of + ti,adc-channels. The value corresponds to the number of ADC clock cycles + to wait after applying the step configuration registers and before sending + the start of ADC conversion. Maximum value is 0x3FFFF. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + + ti,chan-step-sampledelay: + description: List of sample delays for each channel of ADC in the order of + ti,adc-channels. The value corresponds to the number of ADC clock cycles + to sample (to hold start of conversion high). Maximum value is 0xFF. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + + ti,chan-step-avg: + description: Number of averages to be performed for each channel of ADC. If + average is 16 (this is also the maximum) then input is sampled 16 times + and averaged to get more accurate value. This increases the time taken by + ADC to generate a sample. Maximum value is 16. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + +required: + - compatible + - '#io-channel-cells' + - ti,adc-channels + +additionalProperties: false + +examples: + - | + adc { + compatible = "ti,am3359-adc"; + #io-channel-cells = <1>; + ti,adc-channels = <4 5 6 7>; + ti,chan-step-opendelay = <0x098 0x3ffff 0x098 0x0>; + ti,chan-step-sampledelay = <0xff 0x0 0xf 0x0>; + ti,chan-step-avg = <16 2 4 8>; + }; diff --git a/Documentation/devicetree/bindings/iio/chemical/senseair,sunrise.yaml b/Documentation/devicetree/bindings/iio/chemical/senseair,sunrise.yaml new file mode 100644 index 000000000000..337fe09e4bb8 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/chemical/senseair,sunrise.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/chemical/senseair,sunrise.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Senseair Sunrise 006-0-0007 CO2 Sensor + +maintainers: + - Jacopo Mondi <jacopo@jmondi.org> + +description: | + Senseair Sunrise 006-0-0007 is a NDIR CO2 sensor. It supports I2C or UART buses + for communications and control. + + Datasheets: + https://rmtplusstoragesenseair.blob.core.windows.net/docs/Dev/publicerat/PSP11704.pdf + https://rmtplusstoragesenseair.blob.core.windows.net/docs/Dev/publicerat/PSH11649.pdf + https://rmtplusstoragesenseair.blob.core.windows.net/docs/Dev/publicerat/TDE5531.pdf + https://rmtplusstoragesenseair.blob.core.windows.net/docs/Market/publicerat/TDE7318.pdf + +properties: + compatible: + const: senseair,sunrise-006-0-0007 + + reg: + maxItems: 1 + + ndry-gpios: + maxItems: 1 + description: + Phandle to the GPIO line connected to the nDRY pin. Typically active low. + + en-gpios: + maxItems: 1 + description: + Phandle to the GPIO line connected to the EN pin. Typically active high. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + co2-sensor@68 { + compatible = "senseair,sunrise-006-0-0007"; + reg = <0x68>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/chemical/sensirion,scd4x.yaml b/Documentation/devicetree/bindings/iio/chemical/sensirion,scd4x.yaml new file mode 100644 index 000000000000..798f48d05279 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/chemical/sensirion,scd4x.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/chemical/sensirion,scd4x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sensirion SCD4X carbon dioxide sensor + +maintainers: + - Roan van Dijk <roan@protonic.nl> + +description: | + Air quality sensor capable of measuring co2 concentration, temperature + and relative humidity. + +properties: + compatible: + enum: + - sensirion,scd40 + - sensirion,scd41 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vdd-supply: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + co2-sensor@62 { + compatible = "sensirion,scd41"; + reg = <0x62>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml index d5c54813ce87..a8f7720d1e3e 100644 --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml @@ -54,7 +54,7 @@ examples: ad5766@0 { compatible = "adi,ad5766"; - output-range-microvolts = <(-5000) 5000>; + output-range-microvolts = <(-5000000) 5000000>; reg = <0>; spi-cpol; spi-max-frequency = <1000000>; diff --git a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml index 393f7005941a..6adeda4087fc 100644 --- a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml +++ b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml @@ -15,7 +15,7 @@ description: | current. maintainers: - - Fabrice Gasnier <fabrice.gasnier@st.com> + - Fabrice Gasnier <fabrice.gasnier@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,adrf6780.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,adrf6780.yaml new file mode 100644 index 000000000000..3a8ea93f4e0c --- /dev/null +++ b/Documentation/devicetree/bindings/iio/frequency/adi,adrf6780.yaml @@ -0,0 +1,131 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/frequency/adi,adrf6780.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADRF6780 Microwave Upconverter + +maintainers: + - Antoniu Miclaus <antoniu.miclaus@analog.com> + +description: | + Wideband, microwave upconverter optimized for point to point microwave + radio designs operating in the 5.9 GHz to 23.6 GHz frequency range. + + https://www.analog.com/en/products/adrf6780.html + +properties: + compatible: + enum: + - adi,adrf6780 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 1000000 + + clocks: + description: + Definition of the external clock. + minItems: 1 + + clock-names: + items: + - const: lo_in + + clock-output-names: + maxItems: 1 + + adi,vga-buff-en: + description: + RF Variable Gain Amplifier Buffer Enable. Gain is controlled by + the voltage on the VATT pin. + type: boolean + + adi,lo-buff-en: + description: + Local Oscillator Amplifier Enable. Disable to put the part in + a power down state. + type: boolean + + adi,if-mode-en: + description: + Intermediate Frequency Mode Enable. Either IF Mode or I/Q Mode + can be enabled at a time. + type: boolean + + adi,iq-mode-en: + description: + I/Q Mode Enable. Either IF Mode or I/Q Mode can be enabled at a + time. + type: boolean + + adi,lo-x2-en: + description: + Double the Local Oscillator output frequency from the Local + Oscillator Input Frequency. Either LOx1 or LOx2 can be enabled + at a time. + type: boolean + + adi,lo-ppf-en: + description: + Local Oscillator input frequency equal to the Local Oscillator + output frequency (LO x1). Either LOx1 or LOx2 can be enabled + at a time. + type: boolean + + adi,lo-en: + description: + Enable additional cirtuitry in the LO chain. Disable to put the + part in a power down state. + type: boolean + + adi,uc-bias-en: + description: + Enable all bias circuitry thourghout the entire part. + Disable to put the part in a power down state. + type: boolean + + adi,lo-sideband: + description: + Switch to the Lower LO Sideband. By default the Upper LO + sideband is enabled. + type: boolean + + adi,vdet-out-en: + description: + VDET Output Select Enable. Expose the RF detector output to the + VDET external pin. + type: boolean + + '#clock-cells': + const: 0 + +dependencies: + adi,lo-x2-en: [ "adi,lo-en" ] + adi,lo-ppf-en: [ "adi,lo-en" ] + +required: + - compatible + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + adrf6780@0 { + compatible = "adi,adrf6780"; + reg = <0>; + spi-max-frequency = <1000000>; + clocks = <&adrf6780_lo>; + clock-names = "lo_in"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml new file mode 100644 index 000000000000..db0407bc9209 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/liteon,ltr501.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LiteON LTR501 I2C Proximity and Light sensor + +maintainers: + - Nikita Travkin <nikita@trvn.ru> + +properties: + compatible: + enum: + - liteon,ltr501 + - liteon,ltr559 + - liteon,ltr301 + + reg: + maxItems: 1 + + vdd-supply: true + vddio-supply: true + + interrupts: + maxItems: 1 + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + light-sensor@23 { + compatible = "liteon,ltr559"; + reg = <0x23>; + vdd-supply = <&pm8916_l17>; + vddio-supply = <&pm8916_l6>; + + interrupt-parent = <&msmgpio>; + interrupts = <115 IRQ_TYPE_EDGE_FALLING>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml index a0a1ffe017df..9790f75fc669 100644 --- a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml +++ b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml @@ -17,11 +17,13 @@ properties: - asahi-kasei,ak8963 - asahi-kasei,ak09911 - asahi-kasei,ak09912 + - asahi-kasei,ak09916 - enum: - ak8975 - ak8963 - ak09911 - ak09912 + - ak09916 deprecated: true reg: @@ -43,6 +45,11 @@ properties: an optional regulator that needs to be on to provide VDD power to the sensor. + vid-supply: + description: | + an optional regulator that needs to be on to provide VID power to + the sensor. + mount-matrix: description: an optional 3x3 mounting rotation matrix. diff --git a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml index 870b043406d8..611ad4444cf0 100644 --- a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml +++ b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml @@ -35,9 +35,18 @@ properties: mux-control-names: true channels: - $ref: /schemas/types.yaml#/definitions/string-array + $ref: /schemas/types.yaml#/definitions/non-unique-string-array description: - List of strings, labeling the mux controller states. + List of strings, labeling the mux controller states. An empty + string for a state means that the channel is not available. + + settle-time-us: + default: 0 + description: + Time required for analog signals to settle after muxing. + + "#io-channel-cells": + const: 1 required: - compatible diff --git a/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml b/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml new file mode 100644 index 000000000000..aafb33b16549 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/temperature/maxim,max31865.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX31865 Resistance Temperature Detector. + +maintainers: + - Navin Sankar Velliangiri <navin@linumiz.com> + +description: | + https://datasheets.maximintegrated.com/en/ds/MAX31865.pdf + +properties: + compatible: + const: maxim,max31865 + + reg: + maxItems: 1 + + maxim,3-wire: + description: + Identifies the number of wires used by the RTD. Setting this property + enables 3-wire RTD connection. Else 2-wire or 4-wire RTD connection. + type: boolean + + spi-max-frequency: true + spi-cpha: true + +required: + - compatible + - reg + - spi-cpha + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + temp_sensor@0 { + compatible = "maxim,max31865"; + reg = <0>; + spi-max-frequency = <400000>; + spi-cpha; + maxim,3-wire; + }; + }; +... diff --git a/Documentation/devicetree/bindings/input/cap11xx.txt b/Documentation/devicetree/bindings/input/cap11xx.txt deleted file mode 100644 index 8c67a0b5058d..000000000000 --- a/Documentation/devicetree/bindings/input/cap11xx.txt +++ /dev/null @@ -1,78 +0,0 @@ -Device tree bindings for Microchip CAP11xx based capacitive touch sensors - -The node for this device must be a child of a I2C controller node, as the -device communication via I2C only. - -Required properties: - - compatible: Must contain one of: - "microchip,cap1106" - "microchip,cap1126" - "microchip,cap1188" - - reg: The I2C slave address of the device. - - interrupts: Property describing the interrupt line the - device's ALERT#/CM_IRQ# pin is connected to. - The device only has one interrupt source. - -Optional properties: - - autorepeat: Enables the Linux input system's autorepeat - feature on the input device. - - microchip,sensor-gain: Defines the gain of the sensor circuitry. This - effectively controls the sensitivity, as a - smaller delta capacitance is required to - generate the same delta count values. - Valid values are 1, 2, 4, and 8. - By default, a gain of 1 is set. - - microchip,irq-active-high: By default the interrupt pin is active low - open drain. This property allows using the active - high push-pull output. - - linux,keycodes: Specifies an array of numeric keycode values to - be used for the channels. If this property is - omitted, KEY_A, KEY_B, etc are used as - defaults. The array must have exactly six - entries. - -Example: - -i2c_controller { - cap1106@28 { - compatible = "microchip,cap1106"; - interrupt-parent = <&gpio1>; - interrupts = <0 0>; - reg = <0x28>; - autorepeat; - microchip,sensor-gain = <2>; - - linux,keycodes = <103>, /* KEY_UP */ - <106>, /* KEY_RIGHT */ - <108>, /* KEY_DOWN */ - <105>, /* KEY_LEFT */ - <109>, /* KEY_PAGEDOWN */ - <104>; /* KEY_PAGEUP */ - - #address-cells = <1>; - #size-cells = <0>; - - usr@0 { - label = "cap11xx:green:usr0"; - reg = <0>; - }; - - usr@1 { - label = "cap11xx:green:usr1"; - reg = <1>; - }; - - alive@2 { - label = "cap11xx:green:alive"; - reg = <2>; - linux,default_trigger = "heartbeat"; - }; - }; -} diff --git a/Documentation/devicetree/bindings/input/cypress-sf.yaml b/Documentation/devicetree/bindings/input/cypress-sf.yaml new file mode 100644 index 000000000000..c0b051466272 --- /dev/null +++ b/Documentation/devicetree/bindings/input/cypress-sf.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/cypress-sf.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cypress StreetFighter touchkey controller + +maintainers: + - Yassine Oudjana <y.oudjana@protonmail.com> + +allOf: + - $ref: input.yaml# + +properties: + compatible: + const: cypress,sf3155 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + avdd-supply: + description: Regulator for AVDD analog voltage + + vdd-supply: + description: Regulator for VDD digital voltage + + linux,keycodes: + minItems: 1 + maxItems: 8 + +required: + - compatible + - reg + - interrupts + - avdd-supply + - vdd-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/input/input.h> + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touchkey@28 { + compatible = "cypress,sf3155"; + reg = <0x28>; + interrupt-parent = <&msmgpio>; + interrupts = <77 IRQ_TYPE_EDGE_FALLING>; + avdd-supply = <&vreg_l6a_1p8>; + vdd-supply = <&vdd_3v2_tp>; + linux,keycodes = <KEY_BACK KEY_MENU>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/elan,ekth3000.yaml b/Documentation/devicetree/bindings/input/elan,ekth3000.yaml new file mode 100644 index 000000000000..2a9bb6ace021 --- /dev/null +++ b/Documentation/devicetree/bindings/input/elan,ekth3000.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/elan,ekth3000.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Elantech I2C Touchpad + +maintainers: + - Dmitry Torokhov <dmitry.torokhov@gmail.com> + +allOf: + - $ref: touchscreen/touchscreen.yaml# + +properties: + compatible: + const: elan,ekth3000 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + wakeup-source: + type: boolean + description: touchpad can be used as a wakeup source + + vcc-supply: + description: a phandle for the regulator supplying 3.3V power + + elan,trackpoint: + type: boolean + description: touchpad can support a trackpoint + + elan,clickpad: + type: boolean + description: touchpad is a clickpad (the entire surface is a button) + + elan,middle-button: + type: boolean + description: touchpad has a physical middle button + + elan,x_traces: + $ref: /schemas/types.yaml#/definitions/uint32 + description: number of antennas on the x axis + + elan,y_traces: + $ref: /schemas/types.yaml#/definitions/uint32 + description: number of antennas on the y axis + + touchscreen-size-x: true + + touchscreen-size-y: true + + touchscreen-x-mm: true + + touchscreen-y-mm: true + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touchpad@15 { + compatible = "elan,ekth3000"; + reg = <0x15>; + interrupt-parent = <&gpio4>; + interrupts = <0x0 IRQ_TYPE_EDGE_FALLING>; + wakeup-source; + }; + }; diff --git a/Documentation/devicetree/bindings/input/elan_i2c.txt b/Documentation/devicetree/bindings/input/elan_i2c.txt deleted file mode 100644 index 9963247706f2..000000000000 --- a/Documentation/devicetree/bindings/input/elan_i2c.txt +++ /dev/null @@ -1,44 +0,0 @@ -Elantech I2C Touchpad - -Required properties: -- compatible: must be "elan,ekth3000". -- reg: I2C address of the chip. -- interrupts: interrupt to which the chip is connected (see interrupt - binding[0]). - -Optional properties: -- wakeup-source: touchpad can be used as a wakeup source. -- pinctrl-names: should be "default" (see pinctrl binding [1]). -- pinctrl-0: a phandle pointing to the pin settings for the device (see - pinctrl binding [1]). -- vcc-supply: a phandle for the regulator supplying 3.3V power. -- elan,trackpoint: touchpad can support a trackpoint (boolean) -- elan,clickpad: touchpad is a clickpad (the entire surface is a button) -- elan,middle-button: touchpad has a physical middle button -- elan,x_traces: number of antennas on the x axis -- elan,y_traces: number of antennas on the y axis -- some generic touchscreen properties [2]: - * touchscreen-size-x - * touchscreen-size-y - * touchscreen-x-mm - * touchscreen-y-mm - - -[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt -[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt -[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt - -Example: - &i2c1 { - /* ... */ - - touchpad@15 { - compatible = "elan,ekth3000"; - reg = <0x15>; - interrupt-parent = <&gpio4>; - interrupts = <0x0 IRQ_TYPE_EDGE_FALLING>; - wakeup-source; - }; - - /* ... */ - }; diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml new file mode 100644 index 000000000000..d5d6bced3148 --- /dev/null +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml @@ -0,0 +1,149 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/input/microchip,cap11xx.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Device tree bindings for Microchip CAP11xx based capacitive touch sensors + +description: | + The Microchip CAP1xxx Family of RightTouchTM multiple-channel capacitive + touch controllers and LED drivers. The device communication via I2C only. + +maintainers: + - Rob Herring <robh@kernel.org> + +properties: + compatible: + enum: + - microchip,cap1106 + - microchip,cap1126 + - microchip,cap1188 + - microchip,cap1206 + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + interrupts: + maxItems: 1 + description: | + Property describing the interrupt line the + device's ALERT#/CM_IRQ# pin is connected to. + The device only has one interrupt source. + + autorepeat: + description: | + Enables the Linux input system's autorepeat feature on the input device. + + linux,keycodes: + minItems: 6 + maxItems: 6 + description: | + Specifies an array of numeric keycode values to + be used for the channels. If this property is + omitted, KEY_A, KEY_B, etc are used as defaults. + The array must have exactly six entries. + + microchip,sensor-gain: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 1 + enum: [1, 2, 4, 8] + description: | + Defines the gain of the sensor circuitry. This + effectively controls the sensitivity, as a + smaller delta capacitance is required to + generate the same delta count values. + + microchip,irq-active-high: + type: boolean + description: | + By default the interrupt pin is active low + open drain. This property allows using the active + high push-pull output. + +patternProperties: + "^led@[0-7]$": + type: object + description: CAP11xx LEDs + $ref: /schemas/leds/common.yaml# + + properties: + reg: + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + label: true + + linux,default-trigger: true + + default-state: true + + required: + - reg + + additionalProperties: false + +allOf: + - $ref: input.yaml + - if: + properties: + compatible: + contains: + enum: + - microchip,cap1106 + then: + patternProperties: + "^led@[0-7]$": false + +required: + - compatible + - interrupts + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + cap1188@28 { + compatible = "microchip,cap1188"; + interrupt-parent = <&gpio1>; + interrupts = <0 0>; + reg = <0x28>; + autorepeat; + microchip,sensor-gain = <2>; + + linux,keycodes = <103>, /* KEY_UP */ + <106>, /* KEY_RIGHT */ + <108>, /* KEY_DOWN */ + <105>, /* KEY_LEFT */ + <109>, /* KEY_PAGEDOWN */ + <104>; /* KEY_PAGEUP */ + + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + label = "cap11xx:green:usr0"; + reg = <0>; + }; + + led@1 { + label = "cap11xx:green:usr1"; + reg = <1>; + }; + + led@2 { + label = "cap11xx:green:alive"; + reg = <2>; + linux,default-trigger = "heartbeat"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml b/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml new file mode 100644 index 000000000000..eec6f7f6f0a3 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/silead,gsl1680.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silead GSL1680 Touchscreen Controller Device Tree Bindings + +maintainers: + - Dmitry Torokhov <dmitry.torokhov@gmail.com> + +allOf: + - $ref: touchscreen.yaml# + +properties: + compatible: + enum: + - silead,gsl1680 + - silead,gsl1688 + - silead,gsl3670 + - silead,gsl3675 + - silead,gsl3692 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-gpios: + maxItems: 1 + + firmware-name: + $ref: /schemas/types.yaml#/definitions/string + description: > + File basename for board specific firmware + + silead,max-fingers: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 5 + description: > + Maximum number of fingers the touchscreen can detect + + silead,home-button: + type: boolean + description: > + Does the device have a capacitive home-button build into the + touchscreen? + + avdd-supply: + description: > + Regulator phandle for controller AVDD + + vddio-supply: + description: > + Regulator phandle for controller VDDIO + +unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - power-gpios + - touchscreen-size-x + - touchscreen-size-y + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touchscreen@40 { + compatible = "silead,gsl1680"; + reg = <0x40>; + interrupt-parent = <&pio>; + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; + touchscreen-size-x = <480>; + touchscreen-size-y = <800>; + touchscreen-inverted-x; + touchscreen-swapped-x-y; + silead,max-fingers = <5>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt deleted file mode 100644 index d67e558e5ab5..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt +++ /dev/null @@ -1,44 +0,0 @@ -* GSL 1680 touchscreen controller - -Required properties: -- compatible : Must be one of the following, depending on the model: - "silead,gsl1680" - "silead,gsl1688" - "silead,gsl3670" - "silead,gsl3675" - "silead,gsl3692" -- reg : I2C slave address of the chip (0x40) -- interrupts : interrupt specification for the gsl1680 interrupt -- power-gpios : Specification for the pin connected to the gsl1680's - shutdown input. This needs to be driven high to take the - gsl1680 out of its low power state -- touchscreen-size-x : See touchscreen.txt -- touchscreen-size-y : See touchscreen.txt - -Optional properties: -- firmware-name : File basename (string) for board specific firmware -- touchscreen-inverted-x : See touchscreen.txt -- touchscreen-inverted-y : See touchscreen.txt -- touchscreen-swapped-x-y : See touchscreen.txt -- silead,max-fingers : maximum number of fingers the touchscreen can detect -- silead,home-button : Boolean, set to true on devices which have a - capacitive home-button build into the touchscreen -- vddio-supply : regulator phandle for controller VDDIO -- avdd-supply : regulator phandle for controller AVDD - -Example: - -i2c@00000000 { - gsl1680: touchscreen@40 { - compatible = "silead,gsl1680"; - reg = <0x40>; - interrupt-parent = <&pio>; - interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; - power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; - touchscreen-size-x = <480>; - touchscreen-size-y = <800>; - touchscreen-inverted-x; - touchscreen-swapped-x-y; - silead,max-fingers = <5>; - }; -}; diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti,am3359-tsc.yaml b/Documentation/devicetree/bindings/input/touchscreen/ti,am3359-tsc.yaml new file mode 100644 index 000000000000..e44cc65abc8c --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/ti,am3359-tsc.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/ti,am3359-tsc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI AM3359 Touchscreen controller + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +properties: + compatible: + const: ti,am3359-tsc + + ti,wires: + description: Wires refer to application modes i.e. 4/5/8 wire touchscreen + support on the platform. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [4, 5, 8] + + ti,x-plate-resistance: + description: X plate resistance + $ref: /schemas/types.yaml#/definitions/uint32 + + ti,coordinate-readouts: + description: The sequencer supports a total of 16 programmable steps. Each + step is used to read a single coordinate. A single readout is enough but + multiple reads can increase the quality. A value of 5 means, 5 reads for + X, 5 for Y and 2 for Z (always). This utilises 12 of the 16 software steps + available. The remaining 4 can be used by the ADC. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 6 + + ti,wire-config: + description: Different boards could have a different order for connecting + wires on touchscreen. We need to provide an 8-bit number where the + first four bits represent the analog lines and the next 4 bits represent + positive/negative terminal on that input line. Notations to represent the + input lines and terminals respectively are as follows, AIN0 = 0, AIN1 = 1 + and so on until AIN7 = 7. XP = 0, XN = 1, YP = 2, YN = 3. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 4 + maxItems: 8 + + ti,charge-delay: + description: Length of touch screen charge delay step in terms of ADC clock + cycles. Charge delay value should be large in order to avoid false pen-up + events. This value effects the overall sampling speed, hence need to be + kept as low as possible, while avoiding false pen-up event. Start from a + lower value, say 0x400, and increase value until false pen-up events are + avoided. The pen-up detection happens immediately after the charge step, + so this does in fact function as a hardware knob for adjusting the amount + of "settling time". + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - ti,wires + - ti,x-plate-resistance + - ti,coordinate-readouts + - ti,wire-config + +additionalProperties: false + +examples: + - | + tsc { + compatible = "ti,am3359-tsc"; + ti,wires = <4>; + ti,x-plate-resistance = <200>; + ti,coordinate-readouts = <5>; + ti,wire-config = <0x00 0x11 0x22 0x33>; + ti,charge-delay = <0x400>; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt deleted file mode 100644 index aad5e34965eb..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt +++ /dev/null @@ -1,91 +0,0 @@ -* TI - TSC ADC (Touschscreen and analog digital converter) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Required properties: -- mfd - compatible: Should be - "ti,am3359-tscadc" for AM335x/AM437x SoCs - "ti,am654-tscadc", "ti,am3359-tscadc" for AM654 SoCs -- child "tsc" - compatible: Should be "ti,am3359-tsc". - ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen - support on the platform. - ti,x-plate-resistance: X plate resistance - ti,coordinate-readouts: The sequencer supports a total of 16 - programmable steps each step is used to - read a single coordinate. A single - readout is enough but multiple reads can - increase the quality. - A value of 5 means, 5 reads for X, 5 for - Y and 2 for Z (always). This utilises 12 - of the 16 software steps available. The - remaining 4 can be used by the ADC. - ti,wire-config: Different boards could have a different order for - connecting wires on touchscreen. We need to provide an - 8 bit number where in the 1st four bits represent the - analog lines and the next 4 bits represent positive/ - negative terminal on that input line. Notations to - represent the input lines and terminals resoectively - is as follows: - AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. - XP = 0, XN = 1, YP = 2, YN = 3. -- child "adc" - compatible: Should be - "ti,am3359-adc" for AM335x/AM437x SoCs - "ti,am654-adc", "ti,am3359-adc" for AM654 SoCs - ti,adc-channels: List of analog inputs available for ADC. - AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. - -Optional properties: -- child "tsc" - ti,charge-delay: Length of touch screen charge delay step in terms of - ADC clock cycles. Charge delay value should be large - in order to avoid false pen-up events. This value - effects the overall sampling speed, hence need to be - kept as low as possible, while avoiding false pen-up - event. Start from a lower value, say 0x400, and - increase value until false pen-up events are avoided. - The pen-up detection happens immediately after the - charge step, so this does in fact function as a - hardware knob for adjusting the amount of "settling - time". - -- child "adc" - ti,chan-step-opendelay: List of open delays for each channel of - ADC in the order of ti,adc-channels. The - value corresponds to the number of ADC - clock cycles to wait after applying the - step configuration registers and before - sending the start of ADC conversion. - Maximum value is 0x3FFFF. - ti,chan-step-sampledelay: List of sample delays for each channel - of ADC in the order of ti,adc-channels. - The value corresponds to the number of - ADC clock cycles to sample (to hold - start of conversion high). - Maximum value is 0xFF. - ti,chan-step-avg: Number of averages to be performed for each - channel of ADC. If average is 16 then input - is sampled 16 times and averaged to get more - accurate value. This increases the time taken - by ADC to generate a sample. Valid range is 0 - average to 16 averages. Maximum value is 16. - -Example: - tscadc: tscadc@44e0d000 { - compatible = "ti,am3359-tscadc"; - tsc { - ti,wires = <4>; - ti,x-plate-resistance = <200>; - ti,coordiante-readouts = <5>; - ti,wire-config = <0x00 0x11 0x22 0x33>; - ti,charge-delay = <0x400>; - }; - - adc { - ti,adc-channels = <4 5 6 7>; - ti,chan-step-opendelay = <0x098 0x3ffff 0x098 0x0>; - ti,chan-step-sampledelay = <0xff 0x0 0xf 0x0>; - ti,chan-step-avg = <16 2 4 8>; - }; - } diff --git a/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml b/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml new file mode 100644 index 000000000000..50003880ee6f --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/microchip,eic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip External Interrupt Controller + +maintainers: + - Claudiu Beznea <claudiu.beznea@microchip.com> + +description: + This interrupt controller is found in Microchip SoCs (SAMA7G5) and provides + support for handling up to 2 external interrupt lines. + +properties: + compatible: + enum: + - microchip,sama7g5-eic + + reg: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + description: + The first cell is the input IRQ number (between 0 and 1), the second cell + is the trigger type as defined in interrupt.txt present in this directory. + + interrupts: + description: | + Contains the GIC SPI IRQs mapped to the external interrupt lines. They + should be specified sequentially from output 0 to output 1. + minItems: 2 + maxItems: 2 + + clocks: + maxItems: 1 + + clock-names: + const: pclk + +required: + - compatible + - reg + - interrupt-controller + - '#interrupt-cells' + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + eic: interrupt-controller@e1628000 { + compatible = "microchip,sama7g5-eic"; + reg = <0xe1628000 0x100>; + interrupt-parent = <&gic>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 37>; + clock-names = "pclk"; + }; + +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/msi-controller.yaml b/Documentation/devicetree/bindings/interrupt-controller/msi-controller.yaml new file mode 100644 index 000000000000..449d6067ec88 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/msi-controller.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/msi-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MSI controller + +maintainers: + - Marc Zyngier <maz@kernel.org> + +description: | + An MSI controller signals interrupts to a CPU when a write is made + to an MMIO address by some master. An MSI controller may feature a + number of doorbells. + +properties: + "#msi-cells": + description: | + The number of cells in an msi-specifier, required if not zero. + + Typically this will encode information related to sideband data, + and will not encode doorbells or payloads as these can be + configured dynamically. + + The meaning of the msi-specifier is defined by the device tree + binding of the specific MSI controller. + enum: [0, 1] + + msi-controller: + description: + Identifies the node as an MSI controller. + $ref: /schemas/types.yaml#/definitions/flag + + msi-ranges: + description: + A list of <phandle intspec span> tuples, where "phandle" is the + parent interrupt controller, "intspec" is the starting/base + interrupt specifier and "span" is the size of the + range. Multiple ranges can be provided. + $ref: /schemas/types.yaml#/definitions/phandle-array + +dependencies: + "#msi-cells": [ msi-controller ] + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml index abb22db3bb28..79d0358e2f61 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml @@ -27,6 +27,7 @@ properties: - renesas,intc-ex-r8a774a1 # RZ/G2M - renesas,intc-ex-r8a774b1 # RZ/G2N - renesas,intc-ex-r8a774c0 # RZ/G2E + - renesas,intc-ex-r8a774e1 # RZ/G2H - renesas,intc-ex-r8a7795 # R-Car H3 - renesas,intc-ex-r8a7796 # R-Car M3-W - renesas,intc-ex-r8a77961 # R-Car M3-W+ diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml index 6d3e68eb2e8b..d19c881b4abc 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml @@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STM32 External Interrupt Controller Device Tree Bindings maintainers: - - Alexandre Torgue <alexandre.torgue@st.com> - - Ludovic Barre <ludovic.barre@st.com> + - Alexandre Torgue <alexandre.torgue@foss.st.com> + - Ludovic Barre <ludovic.barre@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 03f2b2d4db30..f66a3effba73 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -33,10 +33,12 @@ properties: - description: Qcom SoCs implementing "arm,mmu-500" items: - enum: + - qcom,qcm2290-smmu-500 - qcom,sc7180-smmu-500 - qcom,sc7280-smmu-500 - qcom,sc8180x-smmu-500 - qcom,sdm845-smmu-500 + - qcom,sm6350-smmu-500 - qcom,sm8150-smmu-500 - qcom,sm8250-smmu-500 - qcom,sm8350-smmu-500 diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml index 02c69a95c332..ce0c715205c6 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml @@ -43,6 +43,7 @@ properties: - renesas,ipmmu-r8a77980 # R-Car V3H - renesas,ipmmu-r8a77990 # R-Car E3 - renesas,ipmmu-r8a77995 # R-Car D3 + - renesas,ipmmu-r8a779a0 # R-Car V3U reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt index 028268fd99ee..c9902fd4b38b 100644 --- a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt +++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt @@ -9,6 +9,7 @@ Required properties: - compatible : should be one of "aspeed,ast2400-ibt-bmc" "aspeed,ast2500-ibt-bmc" + "aspeed,ast2600-ibt-bmc" - reg: physical address and size of the registers Optional properties: diff --git a/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml new file mode 100644 index 000000000000..93d8f8e88cf5 --- /dev/null +++ b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ipmi/ipmi-ipmb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: IPMI IPMB device bindings + +description: IPMI IPMB device bindings + +maintainers: + - Corey Minyard <cminyard@mvista.com> + +properties: + compatible: + enum: + - ipmi-ipmb + + device_type: + items: + - const: "ipmi" + + reg: + maxItems: 1 + + bmcaddr: + $ref: /schemas/types.yaml#/definitions/uint8 + description: The address of the BMC on the IPMB bus. Defaults to 0x20. + + retry-time: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Time between retries of sends, in milliseconds. Defaults to 250. + + max-retries: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of retries before a failure is declared. Defaults to 1. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ipmi-ipmb@40 { + compatible = "ipmi-ipmb"; + device_type = "ipmi"; + reg = <0x40>; + bmcaddr = /bits/ 8 <0x20>; + retry-time = <250>; + max-retries = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/leds/register-bit-led.txt b/Documentation/devicetree/bindings/leds/register-bit-led.txt deleted file mode 100644 index c7af6f70a97b..000000000000 --- a/Documentation/devicetree/bindings/leds/register-bit-led.txt +++ /dev/null @@ -1,94 +0,0 @@ -Device Tree Bindings for Register Bit LEDs - -Register bit leds are used with syscon multifunctional devices -where single bits in a certain register can turn on/off a -single LED. The register bit LEDs appear as children to the -syscon device, with the proper compatible string. For the -syscon bindings see: -Documentation/devicetree/bindings/mfd/syscon.yaml - -Each LED is represented as a sub-node of the syscon device. Each -node's name represents the name of the corresponding LED. - -LED sub-node properties: - -Required properties: -- compatible : must be "register-bit-led" -- offset : register offset to the register controlling this LED -- mask : bit mask for the bit controlling this LED in the register - typically 0x01, 0x02, 0x04 ... - -Optional properties: -- label : (optional) - see Documentation/devicetree/bindings/leds/common.txt -- linux,default-trigger : (optional) - see Documentation/devicetree/bindings/leds/common.txt -- default-state: (optional) The initial state of the LED - see Documentation/devicetree/bindings/leds/common.txt - -Example: - -syscon: syscon@10000000 { - compatible = "arm,realview-pb1176-syscon", "syscon"; - reg = <0x10000000 0x1000>; - - led@8.0 { - compatible = "register-bit-led"; - offset = <0x08>; - mask = <0x01>; - label = "versatile:0"; - linux,default-trigger = "heartbeat"; - default-state = "on"; - }; - led@8.1 { - compatible = "register-bit-led"; - offset = <0x08>; - mask = <0x02>; - label = "versatile:1"; - linux,default-trigger = "mmc0"; - default-state = "off"; - }; - led@8.2 { - compatible = "register-bit-led"; - offset = <0x08>; - mask = <0x04>; - label = "versatile:2"; - linux,default-trigger = "cpu0"; - default-state = "off"; - }; - led@8.3 { - compatible = "register-bit-led"; - offset = <0x08>; - mask = <0x08>; - label = "versatile:3"; - default-state = "off"; - }; - led@8.4 { - compatible = "register-bit-led"; - offset = <0x08>; - mask = <0x10>; - label = "versatile:4"; - default-state = "off"; - }; - led@8.5 { - compatible = "register-bit-led"; - offset = <0x08>; - mask = <0x20>; - label = "versatile:5"; - default-state = "off"; - }; - led@8.6 { - compatible = "register-bit-led"; - offset = <0x08>; - mask = <0x40>; - label = "versatile:6"; - default-state = "off"; - }; - led@8.7 { - compatible = "register-bit-led"; - offset = <0x08>; - mask = <0x80>; - label = "versatile:7"; - default-state = "off"; - }; -}; diff --git a/Documentation/devicetree/bindings/leds/register-bit-led.yaml b/Documentation/devicetree/bindings/leds/register-bit-led.yaml new file mode 100644 index 000000000000..79b8fc0f9d23 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/register-bit-led.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/register-bit-led.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Device Tree Bindings for Register Bit LEDs + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: |+ + Register bit leds are used with syscon multifunctional devices where single + bits in a certain register can turn on/off a single LED. The register bit LEDs + appear as children to the syscon device, with the proper compatible string. + For the syscon bindings see: + Documentation/devicetree/bindings/mfd/syscon.yaml + +allOf: + - $ref: /schemas/leds/common.yaml# + +properties: + $nodename: + description: + The unit-address is in the form of @<reg addr>,<bit offset> + pattern: '^led@[0-9a-f]+,[0-9a-f]{1,2}$' + + compatible: + const: register-bit-led + + reg: + description: + The register address and size + maxItems: 1 + + mask: + description: + bit mask for the bit controlling this LED in the register + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + [ 0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 0x80, 0x100, 0x200, 0x400, 0x800, + 0x1000, 0x2000, 0x4000, 0x8000, 0x10000, 0x20000, 0x40000, 0x80000, + 0x100000, 0x200000, 0x400000, 0x800000, 0x1000000, 0x2000000, 0x4000000, + 0x8000000, 0x10000000, 0x20000000, 0x40000000, 0x80000000 ] + + offset: + description: + register offset to the register controlling this LED + $ref: /schemas/types.yaml#/definitions/uint32 + deprecated: true + +required: + - compatible + - mask + - reg + +unevaluatedProperties: false + +examples: + - | + + syscon@10000000 { + compatible = "arm,realview-pb1176-syscon", "syscon"; + reg = <0x10000000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x10000000 0x1000>; + + led@8,0 { + compatible = "register-bit-led"; + reg = <0x08 0x04>; + offset = <0x08>; + mask = <0x01>; + label = "versatile:0"; + linux,default-trigger = "heartbeat"; + default-state = "on"; + }; + led@8,1 { + compatible = "register-bit-led"; + reg = <0x08 0x04>; + offset = <0x08>; + mask = <0x02>; + label = "versatile:1"; + default-state = "off"; + }; + led@8,2 { + compatible = "register-bit-led"; + reg = <0x08 0x04>; + offset = <0x08>; + mask = <0x04>; + label = "versatile:2"; + default-state = "off"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml new file mode 100644 index 000000000000..2c1704b34e7a --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/apple,mailbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Mailbox Controller + +maintainers: + - Hector Martin <marcan@marcan.st> + - Sven Peter <sven@svenpeter.dev> + +description: + The Apple mailbox consists of two FIFOs used to exchange 64+32 bit + messages between the main CPU and a co-processor. Multiple instances + of this mailbox can be found on Apple SoCs. + One of the two FIFOs is used to send data to a co-processor while the other + FIFO is used for the other direction. + Various clients implement different IPC protocols based on these simple + messages and shared memory buffers. + +properties: + compatible: + oneOf: + - description: + ASC mailboxes are the most common variant found on the M1 used + for example for the display controller, the system management + controller and the NVMe coprocessor. + items: + - const: apple,t8103-asc-mailbox + + - description: + M3 mailboxes are an older variant with a slightly different MMIO + interface still found on the M1. It is used for the Thunderbolt + co-processors. + items: + - const: apple,t8103-m3-mailbox + + reg: + maxItems: 1 + + interrupts: + items: + - description: send fifo is empty interrupt + - description: send fifo is not empty interrupt + - description: receive fifo is empty interrupt + - description: receive fifo is not empty interrupt + + interrupt-names: + items: + - const: send-empty + - const: send-not-empty + - const: recv-empty + - const: recv-not-empty + + "#mbox-cells": + const: 0 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - "#mbox-cells" + +additionalProperties: false + +examples: + - | + mailbox@77408000 { + compatible = "apple,t8103-asc-mailbox"; + reg = <0x77408000 0x4000>; + interrupts = <1 583 4>, <1 584 4>, <1 585 4>, <1 586 4>; + interrupt-names = "send-empty", "send-not-empty", + "recv-empty", "recv-not-empty"; + #mbox-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml index 675ad9de15bb..a337bcd80c4a 100644 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml @@ -28,6 +28,7 @@ properties: - const: fsl,imx7ulp-mu - const: fsl,imx8ulp-mu - const: fsl,imx8-mu-scu + - const: fsl,imx8ulp-mu-s4 - items: - enum: - fsl,imx7s-mu diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 89a59b9c81f9..98fe37e8b17b 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -40,8 +40,8 @@ Optional properties for a client mutex node: defined in 'dt-bindings/gce/<chip>-gce.h'. Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h', -'dt-binding/gce/mt8183-gce.h', 'dt-binding/gce/mt8192-gce.h', -'dt-binding/gce/mt8195-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. +'dt-bindings/gce/mt8183-gce.h', 'dt-bindings/gce/mt8192-gce.h', +'dt-bindings/gce/mt8195-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. Such as sub-system ids, thread priority, event ids. Example: diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 6395281b0cec..01e9d9155c83 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -11,7 +11,7 @@ description: platforms. maintainers: - - Sivaprakash Murugesan <sivaprak@codeaurora.org> + - Jassi Brar <jassisinghbrar@gmail.com> properties: compatible: @@ -24,6 +24,7 @@ properties: - qcom,msm8994-apcs-kpss-global - qcom,msm8996-apcs-hmss-global - qcom,msm8998-apcs-hmss-global + - qcom,qcm2290-apcs-hmss-global - qcom,qcs404-apcs-apps-global - qcom,sc7180-apss-shared - qcom,sc8180x-apss-shared diff --git a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml index b15da9ba90b2..8eb4bf52ea27 100644 --- a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml @@ -13,8 +13,8 @@ description: channels (N) can be read from a dedicated register. maintainers: - - Fabien Dessenne <fabien.dessenne@st.com> - - Arnaud Pouliquen <arnaud.pouliquen@st.com> + - Fabien Dessenne <fabien.dessenne@foss.st.com> + - Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml index de15cebe2955..c19d8391e2d5 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml @@ -4,23 +4,24 @@ $id: http://devicetree.org/schemas/media/i2c/adv7604.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Analog Devices ADV7604/11/12 video decoder with HDMI receiver +title: Analog Devices ADV7604/10/11/12 video decoder with HDMI receiver maintainers: - Hans Verkuil <hverkuil-cisco@xs4all.nl> description: - The ADV7604 and ADV7611/12 are multiformat video decoders with an integrated - HDMI receiver. The ADV7604 has four multiplexed HDMI inputs and one analog - input, and the ADV7611 has one HDMI input and no analog input. The 7612 is - similar to the 7611 but has 2 HDMI inputs. + The ADV7604 and ADV7610/11/12 are multiformat video decoders with + an integrated HDMI receiver. The ADV7604 has four multiplexed HDMI inputs + and one analog input, and the ADV7610/11 have one HDMI input and no analog + input. The ADV7612 is similar to the ADV7610/11 but has 2 HDMI inputs. - These device tree bindings support the ADV7611/12 only at the moment. + These device tree bindings support the ADV7610/11/12 only at the moment. properties: compatible: items: - enum: + - adi,adv7610 - adi,adv7611 - adi,adv7612 diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml b/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml new file mode 100644 index 000000000000..c2ba78116dbb --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml @@ -0,0 +1,108 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/aptina,mt9p031.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +description: | + The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor + with an active array size of 2592H x 1944V. It is programmable through a + simple two-wire serial interface. + +properties: + compatible: + enum: + - aptina,mt9p031 + - aptina,mt9p031m + + reg: + description: I2C device address + maxItems: 1 + + clocks: + maxItems: 1 + + vdd-supply: + description: Digital supply voltage, 1.8 V + + vdd_io-supply: + description: I/O supply voltage, 1.8 or 2.8 V + + vaa-supply: + description: Analog supply voltage, 2.8 V + + reset-gpios: + maxItems: 1 + description: Chip reset GPIO + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + input-clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 6000000 + maximum: 96000000 + description: Input clock frequency + + pixel-clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 96000000 + description: Target pixel clock frequency + + pclk-sample: + default: 0 + + required: + - input-clock-frequency + - pixel-clock-frequency + +required: + - compatible + - reg + - clocks + - vdd-supply + - vdd_io-supply + - vaa-supply + - port + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + mt9p031@5d { + compatible = "aptina,mt9p031"; + reg = <0x5d>; + reset-gpios = <&gpio_sensor 0 0>; + + clocks = <&sensor_clk>; + + vdd-supply = <®_vdd>; + vdd_io-supply = <®_vdd_io>; + vaa-supply = <®_vaa>; + + port { + mt9p031_1: endpoint { + input-clock-frequency = <6000000>; + pixel-clock-frequency = <96000000>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml new file mode 100644 index 000000000000..85a8877c2f38 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/hynix,hi846.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SK Hynix Hi-846 1/4" 8M Pixel MIPI CSI-2 sensor + +maintainers: + - Martin Kepplinger <martin.kepplinger@puri.sm> + +description: |- + The Hi-846 is a raw image sensor with an MIPI CSI-2 image data + interface and CCI (I2C compatible) control bus. The output format + is raw Bayer. + +properties: + compatible: + const: hynix,hi846 + + reg: + maxItems: 1 + + clocks: + items: + - description: Reference to the mclk clock. + + assigned-clocks: + maxItems: 1 + + assigned-clock-rates: + maxItems: 1 + + reset-gpios: + description: Reference to the GPIO connected to the RESETB pin. Active low. + maxItems: 1 + + shutdown-gpios: + description: Reference to the GPIO connected to the XSHUTDOWN pin. Active low. + maxItems: 1 + + vddio-supply: + description: Definition of the regulator used for the VDDIO power supply. + + vdda-supply: + description: Definition of the regulator used for the VDDA power supply. + + vddd-supply: + description: Definition of the regulator used for the VDDD power supply. + + port: + $ref: /schemas/graph.yaml#/properties/port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + oneOf: + - items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + - items: + - const: 1 + - const: 2 + + required: + - data-lanes + +required: + - compatible + - reg + - clocks + - assigned-clocks + - assigned-clock-rates + - vddio-supply + - vdda-supply + - vddd-supply + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + hi846: camera@20 { + compatible = "hynix,hi846"; + reg = <0x20>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_csi1>; + clocks = <&clk 0>; + assigned-clocks = <&clk 0>; + assigned-clock-rates = <25000000>; + vdda-supply = <®_camera_vdda>; + vddd-supply = <®_camera_vddd>; + vddio-supply = <®_camera_vddio>; + reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>; + shutdown-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>; + + port { + camera_out: endpoint { + remote-endpoint = <&csi1_ep1>; + link-frequencies = /bits/ 64 + <80000000 200000000>; + data-lanes = <1 2>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/i2c/mt9p031.txt b/Documentation/devicetree/bindings/media/i2c/mt9p031.txt deleted file mode 100644 index cb60443ff78f..000000000000 --- a/Documentation/devicetree/bindings/media/i2c/mt9p031.txt +++ /dev/null @@ -1,40 +0,0 @@ -* Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor - -The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor with -an active array size of 2592H x 1944V. It is programmable through a simple -two-wire serial interface. - -Required Properties: -- compatible: value should be either one among the following - (a) "aptina,mt9p031" for mt9p031 sensor - (b) "aptina,mt9p031m" for mt9p031m sensor - -- input-clock-frequency: Input clock frequency. - -- pixel-clock-frequency: Pixel clock frequency. - -Optional Properties: -- reset-gpios: Chip reset GPIO - -For further reading on port node refer to -Documentation/devicetree/bindings/media/video-interfaces.txt. - -Example: - - i2c0@1c22000 { - ... - ... - mt9p031@5d { - compatible = "aptina,mt9p031"; - reg = <0x5d>; - reset-gpios = <&gpio3 30 0>; - - port { - mt9p031_1: endpoint { - input-clock-frequency = <6000000>; - pixel-clock-frequency = <96000000>; - }; - }; - }; - ... - }; diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt b/Documentation/devicetree/bindings/media/i2c/ov5640.txt deleted file mode 100644 index c97c2f2da12d..000000000000 --- a/Documentation/devicetree/bindings/media/i2c/ov5640.txt +++ /dev/null @@ -1,92 +0,0 @@ -* Omnivision OV5640 MIPI CSI-2 / parallel sensor - -Required Properties: -- compatible: should be "ovti,ov5640" -- clocks: reference to the xclk input clock. -- clock-names: should be "xclk". -- DOVDD-supply: Digital I/O voltage supply, 1.8 volts -- AVDD-supply: Analog voltage supply, 2.8 volts -- DVDD-supply: Digital core voltage supply, 1.5 volts - -Optional Properties: -- reset-gpios: reference to the GPIO connected to the reset pin, if any. - This is an active low signal to the OV5640. -- powerdown-gpios: reference to the GPIO connected to the powerdown pin, - if any. This is an active high signal to the OV5640. -- rotation: as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt, - valid values are 0 (sensor mounted upright) and 180 (sensor - mounted upside down). - -The device node must contain one 'port' child node for its digital output -video port, in accordance with the video interface bindings defined in -Documentation/devicetree/bindings/media/video-interfaces.txt. - -OV5640 can be connected to a MIPI CSI-2 bus or a parallel bus endpoint. - -Endpoint node required properties for CSI-2 connection are: -- remote-endpoint: a phandle to the bus receiver's endpoint node. -- clock-lanes: should be set to <0> (clock lane on hardware lane 0) -- data-lanes: should be set to <1> or <1 2> (one or two CSI-2 lanes supported) - -Endpoint node required properties for parallel connection are: -- remote-endpoint: a phandle to the bus receiver's endpoint node. -- bus-width: shall be set to <8> for 8 bits parallel bus - or <10> for 10 bits parallel bus -- data-shift: shall be set to <2> for 8 bits parallel bus - (lines 9:2 are used) or <0> for 10 bits parallel bus -- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively. -- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively. -- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock - signal. - -Examples: - -&i2c1 { - ov5640: camera@3c { - compatible = "ovti,ov5640"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_ov5640>; - reg = <0x3c>; - clocks = <&clks IMX6QDL_CLK_CKO>; - clock-names = "xclk"; - DOVDD-supply = <&vgen4_reg>; /* 1.8v */ - AVDD-supply = <&vgen3_reg>; /* 2.8v */ - DVDD-supply = <&vgen2_reg>; /* 1.5v */ - powerdown-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>; - rotation = <180>; - - port { - /* MIPI CSI-2 bus endpoint */ - ov5640_to_mipi_csi2: endpoint { - remote-endpoint = <&mipi_csi2_from_ov5640>; - clock-lanes = <0>; - data-lanes = <1 2>; - }; - }; - }; -}; - -&i2c1 { - ov5640: camera@3c { - compatible = "ovti,ov5640"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_ov5640>; - reg = <0x3c>; - clocks = <&clk_ext_camera>; - clock-names = "xclk"; - - port { - /* Parallel bus endpoint */ - ov5640_to_parallel: endpoint { - remote-endpoint = <¶llel_from_ov5640>; - bus-width = <8>; - data-shift = <2>; /* lines 9:2 are used */ - hsync-active = <0>; - vsync-active = <0>; - pclk-sample = <1>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml new file mode 100644 index 000000000000..540fd69ac39f --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml @@ -0,0 +1,154 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ovti,ov5640.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OmniVision OV5640 Image Sensor Device Tree Bindings + +maintainers: + - Steve Longerbeam <slongerbeam@gmail.com> + +allOf: + - $ref: /schemas/media/video-interface-devices.yaml# + +properties: + compatible: + const: ovti,ov5640 + + reg: + maxItems: 1 + + clocks: + description: XCLK Input Clock + + clock-names: + const: xclk + + AVDD-supply: + description: Analog voltage supply, 2.8 volts + + DVDD-supply: + description: Digital core voltage supply, 1.5 volts + + DOVDD-supply: + description: Digital I/O voltage supply, 1.8 volts + + powerdown-gpios: + maxItems: 1 + description: > + Reference to the GPIO connected to the powerdown pin, if any. + + reset-gpios: + maxItems: 1 + description: > + Reference to the GPIO connected to the reset pin, if any. + + rotation: + enum: + - 0 + - 180 + + port: + description: Digital Output Port + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + const: 0 + + data-lanes: + minItems: 1 + maxItems: 2 + items: + enum: [1, 2] + + bus-width: + enum: [8, 10] + + data-shift: + enum: [0, 2] + +required: + - compatible + - reg + - clocks + - clock-names + - AVDD-supply + - DVDD-supply + - DOVDD-supply + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx6qdl-clock.h> + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + camera@3c { + compatible = "ovti,ov5640"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_ov5640>; + reg = <0x3c>; + clocks = <&clks IMX6QDL_CLK_CKO>; + clock-names = "xclk"; + DOVDD-supply = <&vgen4_reg>; /* 1.8v */ + AVDD-supply = <&vgen3_reg>; /* 2.8v */ + DVDD-supply = <&vgen2_reg>; /* 1.5v */ + powerdown-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>; + rotation = <180>; + + port { + /* MIPI CSI-2 bus endpoint */ + ov5640_to_mipi_csi2: endpoint { + remote-endpoint = <&mipi_csi2_from_ov5640>; + clock-lanes = <0>; + data-lanes = <1 2>; + }; + }; + }; + }; + + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + camera@3c { + compatible = "ovti,ov5640"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_ov5640>; + reg = <0x3c>; + clocks = <&clk_ext_camera>; + clock-names = "xclk"; + DOVDD-supply = <&vgen4_reg>; /* 1.8v */ + AVDD-supply = <&vgen3_reg>; /* 2.8v */ + DVDD-supply = <&vgen2_reg>; /* 1.5v */ + + port { + /* Parallel bus endpoint */ + ov5640_to_parallel: endpoint { + remote-endpoint = <¶llel_from_ov5640>; + bus-width = <8>; + data-shift = <2>; /* lines 9:2 are used */ + hsync-active = <0>; + vsync-active = <0>; + pclk-sample = <1>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml index 3e5d82df90a2..a2abed06a099 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml @@ -31,7 +31,7 @@ properties: maxItems: 1 port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base additionalProperties: false properties: diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml index ad42992c6da3..bf115ab9d926 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml @@ -38,7 +38,7 @@ properties: port: additionalProperties: false - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base properties: endpoint: diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml index 881f79532501..cf2ca2702cc9 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml @@ -38,7 +38,7 @@ properties: port: additionalProperties: false - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base properties: endpoint: diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml index 1edeabf39e6a..afcf70947f7e 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml @@ -38,7 +38,7 @@ properties: port: additionalProperties: false - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base properties: endpoint: diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt index ad1321e5a22d..665a9508708e 100644 --- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt @@ -10,6 +10,8 @@ Required properties: "mediatek,mt8183-vcodec-enc" for MT8183 encoder. "mediatek,mt8173-vcodec-dec" for MT8173 decoder. "mediatek,mt8192-vcodec-enc" for MT8192 encoder. + "mediatek,mt8183-vcodec-dec" for MT8183 decoder. + "mediatek,mt8195-vcodec-enc" for MT8195 encoder. - reg : Physical base address of the video codec registers and length of memory mapped region. - interrupts : interrupt number to the cpu. diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml new file mode 100644 index 000000000000..e2874683b4d5 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml @@ -0,0 +1,161 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/qcom,sc7280-venus.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Venus video encode and decode accelerators + +maintainers: + - Stanimir Varbanov <stanimir.varbanov@linaro.org> + +description: | + The Venus Iris2 IP is a video encode and decode accelerator present + on Qualcomm platforms + +properties: + compatible: + const: qcom,sc7280-venus + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + minItems: 2 + maxItems: 3 + + power-domain-names: + minItems: 2 + items: + - const: venus + - const: vcodec0 + - const: cx + + clocks: + maxItems: 5 + + clock-names: + items: + - const: core + - const: bus + - const: iface + - const: vcodec_core + - const: vcodec_bus + + iommus: + maxItems: 2 + + memory-region: + maxItems: 1 + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: cpu-cfg + - const: video-mem + + video-decoder: + type: object + + properties: + compatible: + const: venus-decoder + + required: + - compatible + + additionalProperties: false + + video-encoder: + type: object + + properties: + compatible: + const: venus-encoder + + required: + - compatible + + additionalProperties: false + + video-firmware: + type: object + + description: | + Firmware subnode is needed when the platform does not + have TrustZone. + + properties: + iommus: + maxItems: 1 + + required: + - iommus + +required: + - compatible + - reg + - interrupts + - power-domains + - power-domain-names + - clocks + - clock-names + - iommus + - memory-region + - video-decoder + - video-encoder + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,videocc-sc7280.h> + #include <dt-bindings/interconnect/qcom,sc7280.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + venus: video-codec@aa00000 { + compatible = "qcom,sc7280-venus"; + reg = <0x0aa00000 0xd0600>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&videocc VIDEO_CC_MVSC_CORE_CLK>, + <&videocc VIDEO_CC_MVSC_CTL_AXI_CLK>, + <&videocc VIDEO_CC_VENUS_AHB_CLK>, + <&videocc VIDEO_CC_MVS0_CORE_CLK>, + <&videocc VIDEO_CC_MVS0_AXI_CLK>; + clock-names = "core", "bus", "iface", + "vcodec_core", "vcodec_bus"; + + power-domains = <&videocc MVSC_GDSC>, + <&videocc MVS0_GDSC>, + <&rpmhpd SC7280_CX>; + power-domain-names = "venus", "vcodec0", "cx"; + + interconnects = <&gem_noc MASTER_APPSS_PROC 0 &cnoc2 SLAVE_VENUS_CFG 0>, + <&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI1 0>; + interconnect-names = "cpu-cfg", "video-mem"; + + iommus = <&apps_smmu 0x2180 0x20>, + <&apps_smmu 0x2184 0x20>; + + memory-region = <&video_mem>; + + video-decoder { + compatible = "venus-decoder"; + }; + + video-encoder { + compatible = "venus-encoder"; + }; + + video-firmware { + iommus = <&apps_smmu 0x21a2 0x0>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml new file mode 100644 index 000000000000..33da7d3cfd38 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml @@ -0,0 +1,186 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/qcom,sdm660-venus.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Venus video encode and decode accelerators + +maintainers: + - Stanimir Varbanov <stanimir.varbanov@linaro.org> + - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> + +description: | + The Venus IP is a video encode and decode accelerator present + on Qualcomm platforms + +properties: + compatible: + const: qcom,sdm660-venus + + reg: + maxItems: 1 + + clocks: + maxItems: 4 + + clock-names: + items: + - const: core + - const: iface + - const: bus + - const: bus_throttle + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: cpu-cfg + - const: video-mem + + interrupts: + maxItems: 1 + + iommus: + maxItems: 20 + + memory-region: + maxItems: 1 + + power-domains: + maxItems: 1 + + video-decoder: + type: object + + properties: + compatible: + const: venus-decoder + + clocks: + maxItems: 1 + + clock-names: + items: + - const: vcodec0_core + + power-domains: + maxItems: 1 + + required: + - compatible + - clocks + - clock-names + - power-domains + + additionalProperties: false + + video-encoder: + type: object + + properties: + compatible: + const: venus-encoder + + clocks: + maxItems: 1 + + clock-names: + items: + - const: vcodec0_core + + power-domains: + maxItems: 1 + + required: + - compatible + - clocks + - clock-names + - power-domains + + additionalProperties: false + + video-firmware: + type: object + + description: | + Firmware subnode is needed when the platform does not + have TrustZone. + + properties: + iommus: + maxItems: 1 + + required: + - iommus + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - iommus + - memory-region + - power-domains + - video-decoder + - video-encoder + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,mmcc-sdm660.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + video-codec@cc00000 { + compatible = "qcom,sdm660-venus"; + reg = <0x0cc00000 0xff000>; + clocks = <&mmcc VIDEO_CORE_CLK>, + <&mmcc VIDEO_AHB_CLK>, + <&mmcc VIDEO_AXI_CLK>, + <&mmcc THROTTLE_VIDEO_AXI_CLK>; + clock-names = "core", "iface", "bus", "bus_throttle"; + interconnects = <&gnoc 0 &mnoc 13>, + <&mnoc 4 &bimc 5>; + interconnect-names = "cpu-cfg", "video-mem"; + interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>; + iommus = <&mmss_smmu 0x400>, + <&mmss_smmu 0x401>, + <&mmss_smmu 0x40a>, + <&mmss_smmu 0x407>, + <&mmss_smmu 0x40e>, + <&mmss_smmu 0x40f>, + <&mmss_smmu 0x408>, + <&mmss_smmu 0x409>, + <&mmss_smmu 0x40b>, + <&mmss_smmu 0x40c>, + <&mmss_smmu 0x40d>, + <&mmss_smmu 0x410>, + <&mmss_smmu 0x421>, + <&mmss_smmu 0x428>, + <&mmss_smmu 0x429>, + <&mmss_smmu 0x42b>, + <&mmss_smmu 0x42c>, + <&mmss_smmu 0x42d>, + <&mmss_smmu 0x411>, + <&mmss_smmu 0x431>; + memory-region = <&venus_region>; + power-domains = <&mmcc VENUS_GDSC>; + + video-decoder { + compatible = "venus-decoder"; + clocks = <&mmcc VIDEO_SUBCORE0_CLK>; + clock-names = "vcodec0_core"; + power-domains = <&mmcc VENUS_CORE0_GDSC>; + }; + + video-encoder { + compatible = "venus-encoder"; + clocks = <&mmcc VIDEO_SUBCORE0_CLK>; + clock-names = "vcodec0_core"; + power-domains = <&mmcc VENUS_CORE0_GDSC>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.yaml b/Documentation/devicetree/bindings/media/renesas,csi2.yaml index 23703b767f5b..e6a036721082 100644 --- a/Documentation/devicetree/bindings/media/renesas,csi2.yaml +++ b/Documentation/devicetree/bindings/media/renesas,csi2.yaml @@ -30,6 +30,7 @@ properties: - renesas,r8a77970-csi2 # R-Car V3M - renesas,r8a77980-csi2 # R-Car V3H - renesas,r8a77990-csi2 # R-Car E3 + - renesas,r8a779a0-csi2 # R-Car V3U reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/renesas,imr.txt b/Documentation/devicetree/bindings/media/renesas,imr.txt deleted file mode 100644 index b0614153ed36..000000000000 --- a/Documentation/devicetree/bindings/media/renesas,imr.txt +++ /dev/null @@ -1,31 +0,0 @@ -Renesas R-Car Image Renderer (Distortion Correction Engine) ------------------------------------------------------------ - -The image renderer, or the distortion correction engine, is a drawing processor -with a simple instruction system capable of referencing video capture data or -data in an external memory as 2D texture data and performing texture mapping -and drawing with respect to any shape that is split into triangular objects. - -Required properties: - -- compatible: "renesas,<soctype>-imr-lx4", "renesas,imr-lx4" as a fallback for - the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs, - where the examples with <soctype> are: - - "renesas,r8a7795-imr-lx4" for R-Car H3, - - "renesas,r8a7796-imr-lx4" for R-Car M3-W. -- reg: offset and length of the register block; -- interrupts: single interrupt specifier; -- clocks: single clock phandle/specifier pair; -- power-domains: power domain phandle/specifier pair; -- resets: reset phandle/specifier pair. - -Example: - - imr-lx4@fe860000 { - compatible = "renesas,r8a7795-imr-lx4", "renesas,imr-lx4"; - reg = <0 0xfe860000 0 0x2000>; - interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 823>; - power-domains = <&sysc R8A7795_PD_A3VC>; - resets = <&cpg 823>; - }; diff --git a/Documentation/devicetree/bindings/media/renesas,imr.yaml b/Documentation/devicetree/bindings/media/renesas,imr.yaml new file mode 100644 index 000000000000..512f57417fd8 --- /dev/null +++ b/Documentation/devicetree/bindings/media/renesas,imr.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/renesas,imr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car Image Renderer (Distortion Correction Engine) + +maintainers: + - Sergei Shtylyov <sergei.shtylyov@gmail.com> + +description: | + The image renderer, or the distortion correction engine, is a drawing + processor with a simple instruction system capable of referencing video + capture data or data in an external memory as 2D texture data and performing + texture mapping and drawing with respect to any shape that is split into + triangular objects. + + The image renderer light extended 4 (IMR-LX4) is found in R-Car Gen3 SoCs. + +properties: + compatible: + items: + - enum: + - renesas,r8a7795-imr-lx4 # R-Car H3 + - renesas,r8a7796-imr-lx4 # R-Car M3-W + - const: renesas,imr-lx4 # R-Car Gen3 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7795-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7795-sysc.h> + + imr-lx4@fe860000 { + compatible = "renesas,r8a7795-imr-lx4", "renesas,imr-lx4"; + reg = <0xfe860000 0x2000>; + interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 823>; + power-domains = <&sysc R8A7795_PD_A3VC>; + resets = <&cpg 823>; + }; diff --git a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml index a6b1eff879ed..d1489b177331 100644 --- a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml @@ -15,13 +15,22 @@ description: | properties: compatible: - const: rockchip,rk3399-cif-isp + enum: + - rockchip,px30-cif-isp + - rockchip,rk3399-cif-isp reg: maxItems: 1 interrupts: - maxItems: 1 + minItems: 1 + maxItems: 3 + + interrupt-names: + items: + - const: isp + - const: mi + - const: mipi clocks: minItems: 3 @@ -41,7 +50,7 @@ properties: - const: aclk - const: hclk # only for isp1 - - const: pclk_isp + - const: pclk iommus: maxItems: 1 @@ -90,19 +99,29 @@ required: - power-domains - ports -if: - properties: - compatible: - contains: - const: rockchip,rk3399-cif-isp -then: - properties: - clocks: - minItems: 3 - maxItems: 4 - clock-names: - minItems: 3 - maxItems: 4 +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,rk3399-cif-isp + then: + properties: + clocks: + minItems: 3 + maxItems: 4 + clock-names: + minItems: 3 + maxItems: 4 + + - if: + properties: + compatible: + contains: + const: rockchip,px30-cif-isp + then: + required: + - interrupt-names additionalProperties: false @@ -183,3 +202,66 @@ examples: }; }; }; + + - | + + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/px30-power.h> + + parent1: parent { + #address-cells = <2>; + #size-cells = <2>; + + isp: isp@ff4a0000 { + compatible = "rockchip,px30-cif-isp"; + reg = <0x0 0xff4a0000 0x0 0x8000>; + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "isp", "mi", "mipi"; + clocks = <&cru SCLK_ISP0>, + <&cru ACLK_ISP0_WRAPPER>, + <&cru HCLK_ISP0_WRAPPER>, + <&cru PCLK_ISP1_WRAPPER>; + clock-names = "isp", "aclk", "hclk", "pclk"; + iommus = <&isp_mmu>; + phys = <&csi_dphy>; + phy-names = "dphy"; + power-domains = <&power PX30_PD_VI>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + mipi_in_ucam1: endpoint@0 { + reg = <0>; + remote-endpoint = <&ucam1_out>; + data-lanes = <1 2>; + }; + }; + }; + }; + + i2c2: i2c { + #address-cells = <1>; + #size-cells = <0>; + + ov5695: camera@36 { + compatible = "ovti,ov5647"; + reg = <0x36>; + clocks = <&cru SCLK_CIF_OUT>; + + port { + ucam1_out: endpoint { + remote-endpoint = <&mipi_in_ucam1>; + data-lanes = <1 2>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/st,stm32-cec.yaml b/Documentation/devicetree/bindings/media/st,stm32-cec.yaml index d75019c093a4..77144cc6f7db 100644 --- a/Documentation/devicetree/bindings/media/st,stm32-cec.yaml +++ b/Documentation/devicetree/bindings/media/st,stm32-cec.yaml @@ -7,8 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 CEC bindings maintainers: - - Benjamin Gaignard <benjamin.gaignard@st.com> - - Yannick Fertre <yannick.fertre@st.com> + - Yannick Fertre <yannick.fertre@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml index 41e1d0cd80e5..9c1262a276b5 100644 --- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml +++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 Digital Camera Memory Interface (DCMI) binding maintainers: - - Hugues Fruchet <hugues.fruchet@st.com> + - Hugues Fruchet <hugues.fruchet@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/media/ti,cal.yaml b/Documentation/devicetree/bindings/media/ti,cal.yaml index 65177cd69514..66c5d392fa75 100644 --- a/Documentation/devicetree/bindings/media/ti,cal.yaml +++ b/Documentation/devicetree/bindings/media/ti,cal.yaml @@ -154,7 +154,9 @@ examples: camera-sensor@3c { compatible = "ovti,ov5640"; reg = <0x3c>; - + AVDD-supply = <®_2p8v>; + DOVDD-supply = <®_1p8v>; + DVDD-supply = <®_1p5v>; clocks = <&clk_ov5640_fixed>; clock-names = "xclk"; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml new file mode 100644 index 000000000000..25ed0266f6dd --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml @@ -0,0 +1,223 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LPDDR2 SDRAM compliant to JEDEC JESD209-2 + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - elpida,ECB240ABACN + - elpida,B8132B2PB-6D-F + - enum: + - jedec,lpddr2-s4 + - items: + - enum: + - jedec,lpddr2-s2 + - items: + - enum: + - jedec,lpddr2-nvm + + revision-id1: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 255 + description: | + Revision 1 value of SDRAM chip. Obtained from device datasheet. + + revision-id2: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 255 + description: | + Revision 2 value of SDRAM chip. Obtained from device datasheet. + + density: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Density in megabits of SDRAM chip. Obtained from device datasheet. + enum: + - 64 + - 128 + - 256 + - 512 + - 1024 + - 2048 + - 4096 + - 8192 + - 16384 + - 32768 + + io-width: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + IO bus width in bits of SDRAM chip. Obtained from device datasheet. + enum: + - 32 + - 16 + - 8 + + tRRD-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 16 + description: | + Active bank a to active bank b in terms of number of clock cycles. + Obtained from device datasheet. + + tWTR-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 16 + description: | + Internal WRITE-to-READ command delay in terms of number of clock cycles. + Obtained from device datasheet. + + tXP-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 16 + description: | + Exit power-down to next valid command delay in terms of number of clock + cycles. Obtained from device datasheet. + + tRTP-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 16 + description: | + Internal READ to PRECHARGE command delay in terms of number of clock + cycles. Obtained from device datasheet. + + tCKE-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 16 + description: | + CKE minimum pulse width (HIGH and LOW pulse width) in terms of number + of clock cycles. Obtained from device datasheet. + + tRPab-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 16 + description: | + Row precharge time (all banks) in terms of number of clock cycles. + Obtained from device datasheet. + + tRCD-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 16 + description: | + RAS-to-CAS delay in terms of number of clock cycles. Obtained from + device datasheet. + + tWR-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 16 + description: | + WRITE recovery time in terms of number of clock cycles. Obtained from + device datasheet. + + tRASmin-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 16 + description: | + Row active time in terms of number of clock cycles. Obtained from device + datasheet. + + tCKESR-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 16 + description: | + CKE minimum pulse width during SELF REFRESH (low pulse width during + SELF REFRESH) in terms of number of clock cycles. Obtained from device + datasheet. + + tFAW-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 16 + description: | + Four-bank activate window in terms of number of clock cycles. Obtained + from device datasheet. + +patternProperties: + "^lpddr2-timings": + type: object + description: | + The lpddr2 node may have one or more child nodes of type "lpddr2-timings". + "lpddr2-timings" provides AC timing parameters of the device for + a given speed-bin. The user may provide the timings for as many + speed-bins as is required. Please see Documentation/devicetree/ + bindings/memory-controllers/ddr/lpddr2-timings.txt for more information + on "lpddr2-timings". + +required: + - compatible + - density + - io-width + +additionalProperties: false + +examples: + - | + elpida_ECB240ABACN: lpddr2 { + compatible = "elpida,ECB240ABACN", "jedec,lpddr2-s4"; + density = <2048>; + io-width = <32>; + revision-id1 = <1>; + revision-id2 = <0>; + + tRPab-min-tck = <3>; + tRCD-min-tck = <3>; + tWR-min-tck = <3>; + tRASmin-min-tck = <3>; + tRRD-min-tck = <2>; + tWTR-min-tck = <2>; + tXP-min-tck = <2>; + tRTP-min-tck = <2>; + tCKE-min-tck = <3>; + tCKESR-min-tck = <3>; + tFAW-min-tck = <8>; + + timings_elpida_ECB240ABACN_400mhz: lpddr2-timings0 { + compatible = "jedec,lpddr2-timings"; + min-freq = <10000000>; + max-freq = <400000000>; + tRPab = <21000>; + tRCD = <18000>; + tWR = <15000>; + tRAS-min = <42000>; + tRRD = <10000>; + tWTR = <7500>; + tXP = <7500>; + tRTP = <7500>; + tCKESR = <15000>; + tDQSCK-max = <5500>; + tFAW = <50000>; + tZQCS = <90000>; + tZQCL = <360000>; + tZQinit = <1000000>; + tRAS-max-ns = <70000>; + }; + + timings_elpida_ECB240ABACN_200mhz: lpddr2-timings1 { + compatible = "jedec,lpddr2-timings"; + min-freq = <10000000>; + max-freq = <200000000>; + tRPab = <21000>; + tRCD = <18000>; + tWR = <15000>; + tRAS-min = <42000>; + tRRD = <10000>; + tWTR = <10000>; + tXP = <7500>; + tRTP = <7500>; + tCKESR = <15000>; + tDQSCK-max = <5500>; + tFAW = <50000>; + tZQCS = <90000>; + tZQCL = <360000>; + tZQinit = <1000000>; + tRAS-max-ns = <70000>; + }; + }; diff --git a/Documentation/devicetree/bindings/ddr/lpddr2-timings.txt b/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2-timings.txt index 9ceb19e0c7fd..9ceb19e0c7fd 100644 --- a/Documentation/devicetree/bindings/ddr/lpddr2-timings.txt +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2-timings.txt diff --git a/Documentation/devicetree/bindings/ddr/lpddr3-timings.txt b/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt index 84705e50a3fd..84705e50a3fd 100644 --- a/Documentation/devicetree/bindings/ddr/lpddr3-timings.txt +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt diff --git a/Documentation/devicetree/bindings/ddr/lpddr3.txt b/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt index b221e653d384..031af5fb0379 100644 --- a/Documentation/devicetree/bindings/ddr/lpddr3.txt +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt @@ -43,8 +43,9 @@ These values shall be obtained from the device data-sheet. Child nodes: - The lpddr3 node may have one or more child nodes of type "lpddr3-timings". "lpddr3-timings" provides AC timing parameters of the device for - a given speed-bin. Please see Documentation/devicetree/ - bindings/ddr/lpddr3-timings.txt for more information on "lpddr3-timings" + a given speed-bin. Please see + Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt + for more information on "lpddr3-timings" Example: diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/ddr.txt b/Documentation/devicetree/bindings/memory-controllers/fsl/ddr.txt deleted file mode 100644 index dde6d837083a..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/fsl/ddr.txt +++ /dev/null @@ -1,29 +0,0 @@ -Freescale DDR memory controller - -Properties: - -- compatible : Should include "fsl,chip-memory-controller" where - chip is the processor (bsc9132, mpc8572 etc.), or - "fsl,qoriq-memory-controller". -- reg : Address and size of DDR controller registers -- interrupts : Error interrupt of DDR controller -- little-endian : Specifies little-endian access to registers - If omitted, big-endian will be used. - -Example 1: - - memory-controller@2000 { - compatible = "fsl,bsc9132-memory-controller"; - reg = <0x2000 0x1000>; - interrupts = <16 2 1 8>; - }; - - -Example 2: - - ddr1: memory-controller@8000 { - compatible = "fsl,qoriq-memory-controller-v4.7", - "fsl,qoriq-memory-controller"; - reg = <0x8000 0x1000>; - interrupts = <16 2 1 23>; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml new file mode 100644 index 000000000000..af5147f9da72 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/fsl/fsl,ddr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale DDR memory controller + +maintainers: + - Borislav Petkov <bp@alien8.de> + - York Sun <york.sun@nxp.com> + +properties: + $nodename: + pattern: "^memory-controller@[0-9a-f]+$" + + compatible: + oneOf: + - items: + - enum: + - fsl,qoriq-memory-controller-v4.4 + - fsl,qoriq-memory-controller-v4.5 + - fsl,qoriq-memory-controller-v4.7 + - fsl,qoriq-memory-controller-v5.0 + - const: fsl,qoriq-memory-controller + - enum: + - fsl,bsc9132-memory-controller + - fsl,8540-memory-controller + - fsl,8541-memory-controller + - fsl,8544-memory-controller + - fsl,8548-memory-controller + - fsl,8555-memory-controller + - fsl,8568-memory-controller + - fsl,mpc8536-memory-controller + - fsl,mpc8540-memory-controller + - fsl,mpc8541-memory-controller + - fsl,mpc8544-memory-controller + - fsl,mpc8548-memory-controller + - fsl,mpc8555-memory-controller + - fsl,mpc8560-memory-controller + - fsl,mpc8568-memory-controller + - fsl,mpc8569-memory-controller + - fsl,mpc8572-memory-controller + - fsl,mpc8349-memory-controller + - fsl,p1020-memory-controller + - fsl,p1021-memory-controller + - fsl,p2020-memory-controller + - fsl,qoriq-memory-controller + + interrupts: + maxItems: 1 + + little-endian: + description: + Specifies little-endian access to registers. If omitted, big-endian will + be used. + type: boolean + + reg: + maxItems: 1 + +required: + - compatible + - interrupts + - reg + +additionalProperties: false + +examples: + - | + memory-controller@2000 { + compatible = "fsl,bsc9132-memory-controller"; + reg = <0x2000 0x1000>; + interrupts = <16 2 1 8>; + }; + + - | + memory-controller@8000 { + compatible = "fsl,qoriq-memory-controller-v4.7", + "fsl,qoriq-memory-controller"; + reg = <0x8000 0x1000>; + interrupts = <16 2 1 23>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml index fe0ce191a851..24f9e1982028 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml @@ -84,7 +84,7 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/jz4780-cgu.h> + #include <dt-bindings/clock/ingenic,jz4780-cgu.h> #include <dt-bindings/gpio/gpio.h> nemc: memory-controller@13410000 { compatible = "ingenic,jz4780-nemc"; diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,mt7621-memc.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,mt7621-memc.yaml new file mode 100644 index 000000000000..85e02854f083 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,mt7621-memc.yaml @@ -0,0 +1,30 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/mediatek,mt7621-memc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MT7621 SDRAM controller + +maintainers: + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +properties: + compatible: + const: mediatek,mt7621-memc + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + memory-controller@5000 { + compatible = "mediatek,mt7621-memc"; + reg = <0x5000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index e87e4382807c..3a82b0b27fa0 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -16,7 +16,7 @@ description: | MediaTek SMI have two generations of HW architecture, here is the list which generation the SoCs use: generation 1: mt2701 and mt7623. - generation 2: mt2712, mt6779, mt8167, mt8173, mt8183 and mt8192. + generation 2: mt2712, mt6779, mt8167, mt8173, mt8183, mt8192 and mt8195. There's slight differences between the two SMI, for generation 2, the register which control the iommu port is at each larb's register base. But @@ -36,6 +36,9 @@ properties: - mediatek,mt8173-smi-common - mediatek,mt8183-smi-common - mediatek,mt8192-smi-common + - mediatek,mt8195-smi-common-vdo + - mediatek,mt8195-smi-common-vpp + - mediatek,mt8195-smi-sub-common - description: for mt7623 items: @@ -65,6 +68,10 @@ properties: minItems: 2 maxItems: 4 + mediatek,smi: + $ref: /schemas/types.yaml#/definitions/phandle + description: a phandle to the smi-common node above. Only for sub-common. + required: - compatible - reg @@ -91,6 +98,29 @@ allOf: - const: smi - const: async + - if: # only for sub common + properties: + compatible: + contains: + enum: + - mediatek,mt8195-smi-sub-common + then: + required: + - mediatek,smi + properties: + clock: + items: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: apb + - const: smi + - const: gals0 + else: + properties: + mediatek,smi: false + - if: # for gen2 HW that have gals properties: compatible: @@ -98,6 +128,8 @@ allOf: - mediatek,mt6779-smi-common - mediatek,mt8183-smi-common - mediatek,mt8192-smi-common + - mediatek,mt8195-smi-common-vdo + - mediatek,mt8195-smi-common-vpp then: properties: diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index 2353f6cf3c80..eaeff1ada7f8 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -24,6 +24,7 @@ properties: - mediatek,mt8173-smi-larb - mediatek,mt8183-smi-larb - mediatek,mt8192-smi-larb + - mediatek,mt8195-smi-larb - description: for mt7623 items: @@ -74,6 +75,7 @@ allOf: compatible: enum: - mediatek,mt8183-smi-larb + - mediatek,mt8195-smi-larb then: properties: @@ -108,6 +110,7 @@ allOf: - mediatek,mt6779-smi-larb - mediatek,mt8167-smi-larb - mediatek,mt8192-smi-larb + - mediatek,mt8195-smi-larb then: required: diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml index cac6842dc8f1..2fa44951cfde 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml @@ -164,12 +164,20 @@ patternProperties: "#size-cells": const: 0 + lpddr2: + $ref: "ddr/jedec,lpddr2.yaml#" + type: object + patternProperties: "^emc-table@[0-9]+$": $ref: "#/$defs/emc-table" - required: - - nvidia,ram-code + oneOf: + - required: + - nvidia,ram-code + + - required: + - lpddr2 additionalProperties: false @@ -227,4 +235,15 @@ examples: 0x00000000 0x00000000 0x00000000 0x00000000>; }; }; + + emc-tables@1 { + reg = <1>; + + lpddr2 { + compatible = "elpida,B8132B2PB-6D-F", "jedec,lpddr2-s4"; + revision-id1 = <1>; + density = <2048>; + io-width = <16>; + }; + }; }; diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt deleted file mode 100644 index c1359f4d48d7..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt +++ /dev/null @@ -1,157 +0,0 @@ -Device tree bindings for OMAP general purpose memory controllers (GPMC) - -The actual devices are instantiated from the child nodes of a GPMC node. - -Required properties: - - - compatible: Should be set to one of the following: - - ti,omap2420-gpmc (omap2420) - ti,omap2430-gpmc (omap2430) - ti,omap3430-gpmc (omap3430 & omap3630) - ti,omap4430-gpmc (omap4430 & omap4460 & omap543x) - ti,am3352-gpmc (am335x devices) - - - reg: A resource specifier for the register space - (see the example below) - - ti,hwmods: Should be set to "ti,gpmc" until the DT transition is - completed. - - #address-cells: Must be set to 2 to allow memory address translation - - #size-cells: Must be set to 1 to allow CS address passing - - gpmc,num-cs: The maximum number of chip-select lines that controller - can support. - - gpmc,num-waitpins: The maximum number of wait pins that controller can - support. - - ranges: Must be set up to reflect the memory layout with four - integer values for each chip-select line in use: - - <cs-number> 0 <physical address of mapping> <size> - - Currently, calculated values derived from the contents - of the per-CS register GPMC_CONFIG7 (as set up by the - bootloader) are used for the physical address decoding. - As this will change in the future, filling correct - values here is a requirement. - - interrupt-controller: The GPMC driver implements and interrupt controller for - the NAND events "fifoevent" and "termcount" plus the - rising/falling edges on the GPMC_WAIT pins. - The interrupt number mapping is as follows - 0 - NAND_fifoevent - 1 - NAND_termcount - 2 - GPMC_WAIT0 pin edge - 3 - GPMC_WAIT1 pin edge, and so on. - - interrupt-cells: Must be set to 2 - - gpio-controller: The GPMC driver implements a GPIO controller for the - GPMC WAIT pins that can be used as general purpose inputs. - 0 maps to GPMC_WAIT0 pin. - - gpio-cells: Must be set to 2 - -Required properties when using NAND prefetch dma: - - dmas GPMC NAND prefetch dma channel - - dma-names Must be set to "rxtx" - -Timing properties for child nodes. All are optional and default to 0. - - - gpmc,sync-clk-ps: Minimum clock period for synchronous mode, in picoseconds - - Chip-select signal timings (in nanoseconds) corresponding to GPMC_CONFIG2: - - gpmc,cs-on-ns: Assertion time - - gpmc,cs-rd-off-ns: Read deassertion time - - gpmc,cs-wr-off-ns: Write deassertion time - - ADV signal timings (in nanoseconds) corresponding to GPMC_CONFIG3: - - gpmc,adv-on-ns: Assertion time - - gpmc,adv-rd-off-ns: Read deassertion time - - gpmc,adv-wr-off-ns: Write deassertion time - - gpmc,adv-aad-mux-on-ns: Assertion time for AAD - - gpmc,adv-aad-mux-rd-off-ns: Read deassertion time for AAD - - gpmc,adv-aad-mux-wr-off-ns: Write deassertion time for AAD - - WE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4: - - gpmc,we-on-ns Assertion time - - gpmc,we-off-ns: Deassertion time - - OE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4: - - gpmc,oe-on-ns: Assertion time - - gpmc,oe-off-ns: Deassertion time - - gpmc,oe-aad-mux-on-ns: Assertion time for AAD - - gpmc,oe-aad-mux-off-ns: Deassertion time for AAD - - Access time and cycle time timings (in nanoseconds) corresponding to - GPMC_CONFIG5: - - gpmc,page-burst-access-ns: Multiple access word delay - - gpmc,access-ns: Start-cycle to first data valid delay - - gpmc,rd-cycle-ns: Total read cycle time - - gpmc,wr-cycle-ns: Total write cycle time - - gpmc,bus-turnaround-ns: Turn-around time between successive accesses - - gpmc,cycle2cycle-delay-ns: Delay between chip-select pulses - - gpmc,clk-activation-ns: GPMC clock activation time - - gpmc,wait-monitoring-ns: Start of wait monitoring with regard to valid - data - -Boolean timing parameters. If property is present parameter enabled and -disabled if omitted: - - gpmc,adv-extra-delay: ADV signal is delayed by half GPMC clock - - gpmc,cs-extra-delay: CS signal is delayed by half GPMC clock - - gpmc,cycle2cycle-diffcsen: Add "cycle2cycle-delay" between successive - accesses to a different CS - - gpmc,cycle2cycle-samecsen: Add "cycle2cycle-delay" between successive - accesses to the same CS - - gpmc,oe-extra-delay: OE signal is delayed by half GPMC clock - - gpmc,we-extra-delay: WE signal is delayed by half GPMC clock - - gpmc,time-para-granularity: Multiply all access times by 2 - -The following are only applicable to OMAP3+ and AM335x: - - gpmc,wr-access-ns: In synchronous write mode, for single or - burst accesses, defines the number of - GPMC_FCLK cycles from start access time - to the GPMC_CLK rising edge used by the - memory device for the first data capture. - - gpmc,wr-data-mux-bus-ns: In address-data multiplex mode, specifies - the time when the first data is driven on - the address-data bus. - -GPMC chip-select settings properties for child nodes. All are optional. - -- gpmc,burst-length Page/burst length. Must be 4, 8 or 16. -- gpmc,burst-wrap Enables wrap bursting -- gpmc,burst-read Enables read page/burst mode -- gpmc,burst-write Enables write page/burst mode -- gpmc,device-width Total width of device(s) connected to a GPMC - chip-select in bytes. The GPMC supports 8-bit - and 16-bit devices and so this property must be - 1 or 2. -- gpmc,mux-add-data Address and data multiplexing configuration. - Valid values are 1 for address-address-data - multiplexing mode and 2 for address-data - multiplexing mode. -- gpmc,sync-read Enables synchronous read. Defaults to asynchronous - is this is not set. -- gpmc,sync-write Enables synchronous writes. Defaults to asynchronous - is this is not set. -- gpmc,wait-pin Wait-pin used by client. Must be less than - "gpmc,num-waitpins". -- gpmc,wait-on-read Enables wait monitoring on reads. -- gpmc,wait-on-write Enables wait monitoring on writes. - -Example for an AM33xx board: - - gpmc: gpmc@50000000 { - compatible = "ti,am3352-gpmc"; - ti,hwmods = "gpmc"; - reg = <0x50000000 0x2000>; - interrupts = <100>; - dmas = <&edma 52 0>; - dma-names = "rxtx"; - gpmc,num-cs = <8>; - gpmc,num-waitpins = <2>; - #address-cells = <2>; - #size-cells = <1>; - ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */ - interrupt-controller; - #interrupt-cells = <2>; - gpio-controller; - #gpio-cells = <2>; - - /* child nodes go here */ - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml index d25072c414e4..9da80e8f2444 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml @@ -33,6 +33,7 @@ properties: - renesas,r8a77970-rpc-if # R-Car V3M - renesas,r8a77980-rpc-if # R-Car V3H - renesas,r8a77995-rpc-if # R-Car D3 + - renesas,r8a779a0-rpc-if # R-Car V3U - const: renesas,rcar-gen3-rpc-if # a generic R-Car gen3 or RZ/G2 device reg: diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml index 6f4fd5814bf4..fe8639dcffab 100644 --- a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml @@ -51,7 +51,8 @@ properties: $ref: '/schemas/types.yaml#/definitions/phandle' description: | phandle of the connected DRAM memory device. For more information please - refer to documentation file: Documentation/devicetree/bindings/ddr/lpddr3.txt + refer to documentation file: + Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt operating-points-v2: true diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml index cba74205846a..6b516d3895af 100644 --- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml @@ -19,7 +19,7 @@ description: | Select. The FMC2 performs only one access at a time to an external device. maintainers: - - Christophe Kerello <christophe.kerello@st.com> + - Christophe Kerello <christophe.kerello@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml new file mode 100644 index 000000000000..6e3995bb1630 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml @@ -0,0 +1,245 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ti,gpmc-child.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: device tree bindings for children of the Texas Instruments GPMC + +maintainers: + - Tony Lindgren <tony@atomide.com> + - Roger Quadros <rogerq@kernel.org> + +description: + This binding is meant for the child nodes of the GPMC node. The node + represents any device connected to the GPMC bus. It may be a Flash chip, + RAM chip or Ethernet controller, etc. These properties are meant for + configuring the GPMC settings/timings and will accompany the bindings + supported by the respective device. + +properties: + reg: true + +# GPMC Timing properties for child nodes. All are optional and default to 0. + gpmc,sync-clk-ps: + description: Minimum clock period for synchronous mode + default: 0 + +# Chip-select signal timings corresponding to GPMC_CONFIG2: + gpmc,cs-on-ns: + description: Assertion time + default: 0 + + gpmc,cs-rd-off-ns: + description: Read deassertion time + default: 0 + + gpmc,cs-wr-off-ns: + description: Write deassertion time + default: 0 + +# ADV signal timings corresponding to GPMC_CONFIG3: + gpmc,adv-on-ns: + description: Assertion time + default: 0 + + gpmc,adv-rd-off-ns: + description: Read deassertion time + default: 0 + + gpmc,adv-wr-off-ns: + description: Write deassertion time + default: 0 + + gpmc,adv-aad-mux-on-ns: + description: Assertion time for AAD + default: 0 + + gpmc,adv-aad-mux-rd-off-ns: + description: Read deassertion time for AAD + default: 0 + + gpmc,adv-aad-mux-wr-off-ns: + description: Write deassertion time for AAD + default: 0 + +# WE signals timings corresponding to GPMC_CONFIG4: + gpmc,we-on-ns: + description: Assertion time + default: 0 + + gpmc,we-off-ns: + description: Deassertion time + default: 0 + +# OE signals timings corresponding to GPMC_CONFIG4: + gpmc,oe-on-ns: + description: Assertion time + default: 0 + + gpmc,oe-off-ns: + description: Deassertion time + default: 0 + + gpmc,oe-aad-mux-on-ns: + description: Assertion time for AAD + default: 0 + + gpmc,oe-aad-mux-off-ns: + description: Deassertion time for AAD + default: 0 + +# Access time and cycle time timings (in nanoseconds) corresponding to +# GPMC_CONFIG5: + gpmc,page-burst-access-ns: + description: Multiple access word delay + default: 0 + + gpmc,access-ns: + description: Start-cycle to first data valid delay + default: 0 + + gpmc,rd-cycle-ns: + description: Total read cycle time + default: 0 + + gpmc,wr-cycle-ns: + description: Total write cycle time + default: 0 + + gpmc,bus-turnaround-ns: + description: Turn-around time between successive accesses + default: 0 + + gpmc,cycle2cycle-delay-ns: + description: Delay between chip-select pulses + default: 0 + + gpmc,clk-activation-ns: + description: GPMC clock activation time + default: 0 + + gpmc,wait-monitoring-ns: + description: Start of wait monitoring with regard to valid data + default: 0 + +# Boolean timing parameters. If property is present, parameter is enabled +# otherwise disabled. + gpmc,adv-extra-delay: + description: ADV signal is delayed by half GPMC clock + type: boolean + + gpmc,cs-extra-delay: + description: CS signal is delayed by half GPMC clock + type: boolean + + gpmc,cycle2cycle-diffcsen: + description: | + Add "cycle2cycle-delay" between successive accesses + to a different CS + type: boolean + + gpmc,cycle2cycle-samecsen: + description: | + Add "cycle2cycle-delay" between successive accesses + to the same CS + type: boolean + + gpmc,oe-extra-delay: + description: OE signal is delayed by half GPMC clock + type: boolean + + gpmc,we-extra-delay: + description: WE signal is delayed by half GPMC clock + type: boolean + + gpmc,time-para-granularity: + description: Multiply all access times by 2 + type: boolean + +# The following two properties are applicable only to OMAP3+ and AM335x: + gpmc,wr-access-ns: + description: | + In synchronous write mode, for single or + burst accesses, defines the number of + GPMC_FCLK cycles from start access time + to the GPMC_CLK rising edge used by the + memory device for the first data capture. + default: 0 + + gpmc,wr-data-mux-bus-ns: + description: | + In address-data multiplex mode, specifies + the time when the first data is driven on + the address-data bus. + default: 0 + +# GPMC chip-select settings properties for child nodes. All are optional. + gpmc,burst-length: + description: Page/burst length. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 4, 8, 16] + default: 0 + + gpmc,burst-wrap: + description: Enables wrap bursting + type: boolean + + gpmc,burst-read: + description: Enables read page/burst mode + type: boolean + + gpmc,burst-write: + description: Enables write page/burst mode + type: boolean + + gpmc,device-width: + description: | + Total width of device(s) connected to a GPMC + chip-select in bytes. The GPMC supports 8-bit + and 16-bit devices and so this property must be + 1 or 2. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2] + default: 1 + + gpmc,mux-add-data: + description: | + Address and data multiplexing configuration. + Valid values are + 0 for Non multiplexed mode + 1 for address-address-data multiplexing mode and + 2 for address-data multiplexing mode. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + + gpmc,sync-read: + description: | + Enables synchronous read. Defaults to asynchronous + is this is not set. + type: boolean + + gpmc,sync-write: + description: | + Enables synchronous writes. Defaults to asynchronous + is this is not set. + type: boolean + + gpmc,wait-pin: + description: | + Wait-pin used by client. Must be less than "gpmc,num-waitpins". + $ref: /schemas/types.yaml#/definitions/uint32 + + gpmc,wait-on-read: + description: Enables wait monitoring on reads. + type: boolean + + gpmc,wait-on-write: + description: Enables wait monitoring on writes. + type: boolean + +required: + - reg + +# the GPMC child will have its own native properties +additionalProperties: true diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml new file mode 100644 index 000000000000..25b42d68f9b3 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml @@ -0,0 +1,172 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ti,gpmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments GPMC Memory Controller device-tree bindings + +maintainers: + - Tony Lindgren <tony@atomide.com> + - Roger Quadros <rogerq@kernel.org> + +description: + The GPMC is a unified memory controller dedicated for interfacing + with external memory devices like + - Asynchronous SRAM-like memories and ASICs + - Asynchronous, synchronous, and page mode burst NOR flash + - NAND flash + - Pseudo-SRAM devices + +properties: + compatible: + items: + - enum: + - ti,am3352-gpmc + - ti,omap2420-gpmc + - ti,omap2430-gpmc + - ti,omap3430-gpmc + - ti,omap4430-gpmc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + description: | + Functional clock. Used for bus timing calculations and + GPMC configuration. + + clock-names: + items: + - const: fck + + dmas: + items: + - description: DMA channel for GPMC NAND prefetch + + dma-names: + items: + - const: rxtx + + "#address-cells": true + + "#size-cells": true + + gpmc,num-cs: + description: maximum number of supported chip-select lines. + $ref: /schemas/types.yaml#/definitions/uint32 + + gpmc,num-waitpins: + description: maximum number of supported wait pins. + $ref: /schemas/types.yaml#/definitions/uint32 + + ranges: + minItems: 1 + description: | + Must be set up to reflect the memory layout with four + integer values for each chip-select line in use, + <cs-number> 0 <physical address of mapping> <size> + items: + - description: NAND bank 0 + - description: NOR/SRAM bank 0 + - description: NOR/SRAM bank 1 + + '#interrupt-cells': + const: 2 + + interrupt-controller: + description: | + The GPMC driver implements and interrupt controller for + the NAND events "fifoevent" and "termcount" plus the + rising/falling edges on the GPMC_WAIT pins. + The interrupt number mapping is as follows + 0 - NAND_fifoevent + 1 - NAND_termcount + 2 - GPMC_WAIT0 pin edge + 3 - GPMC_WAIT1 pin edge, and so on. + + '#gpio-cells': + const: 2 + + gpio-controller: + description: | + The GPMC driver implements a GPIO controller for the + GPMC WAIT pins that can be used as general purpose inputs. + 0 maps to GPMC_WAIT0 pin. + + ti,hwmods: + description: + Name of the HWMOD associated with GPMC. This is for legacy + omap2/3 platforms only. + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + + ti,no-idle-on-init: + description: + Prevent idling the module at init. This is for legacy omap2/3 + platforms only. + type: boolean + deprecated: true + +patternProperties: + "@[0-7],[a-f0-9]+$": + type: object + description: | + The child device node represents the device connected to the GPMC + bus. The device can be a NAND chip, SRAM device, NOR device + or an ASIC. + + allOf: + - $ref: "ti,gpmc-child.yaml" + + unevaluatedProperties: false + +required: + - compatible + - reg + - gpmc,num-cs + - gpmc,num-waitpins + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/gpio/gpio.h> + + gpmc: memory-controller@50000000 { + compatible = "ti,am3352-gpmc"; + reg = <0x50000000 0x2000>; + interrupts = <100>; + clocks = <&l3s_clkctrl>; + clock-names = "fck"; + dmas = <&edma 52 0>; + dma-names = "rxtx"; + gpmc,num-cs = <8>; + gpmc,num-waitpins = <2>; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */ + interrupt-controller; + #interrupt-cells = <2>; + gpio-controller; + #gpio-cells = <2>; + + nand@0,0 { + compatible = "ti,omap2-nand"; + reg = <0 0 4>; + interrupt-parent = <&gpmc>; + interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */ + <1 IRQ_TYPE_NONE>; /* termcount */ + ti,nand-xfer-type = "prefetch-dma"; + ti,nand-ecc-opt = "bch16"; + ti,elm-id = <&elm>; + rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 pin */ + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/ac100.txt b/Documentation/devicetree/bindings/mfd/ac100.txt deleted file mode 100644 index dff219f07493..000000000000 --- a/Documentation/devicetree/bindings/mfd/ac100.txt +++ /dev/null @@ -1,50 +0,0 @@ -X-Powers AC100 Codec/RTC IC Device Tree bindings - -AC100 is a audio codec and RTC subsystem combo IC. The 2 parts are -separated, including power supplies and interrupt lines, but share -a common register address space and host interface. - -Required properties: -- compatible: "x-powers,ac100" -- reg: The I2C slave address or RSB hardware address for the chip -- sub-nodes: - - codec - - compatible: "x-powers,ac100-codec" - - interrupts: SoC NMI / GPIO interrupt connected to the - IRQ_AUDIO pin - - #clock-cells: Shall be 0 - - clock-output-names: "4M_adda" - - - see clock/clock-bindings.txt for common clock bindings - - - rtc - - compatible: "x-powers,ac100-rtc" - - clocks: A phandle to the codec's "4M_adda" clock - - #clock-cells: Shall be 1 - - clock-output-names: "cko1_rtc", "cko2_rtc", "cko3_rtc" - - - see clock/clock-bindings.txt for common clock bindings - -Example: - -ac100: codec@e89 { - compatible = "x-powers,ac100"; - reg = <0xe89>; - - ac100_codec: codec { - compatible = "x-powers,ac100-codec"; - interrupt-parent = <&r_pio>; - interrupts = <0 9 IRQ_TYPE_LEVEL_LOW>; /* PL9 */ - #clock-cells = <0>; - clock-output-names = "4M_adda"; - }; - - ac100_rtc: rtc { - compatible = "x-powers,ac100-rtc"; - interrupt-parent = <&nmi_intc>; - interrupts = <0 IRQ_TYPE_LEVEL_LOW>; - clocks = <&ac100_codec>; - #clock-cells = <1>; - clock-output-names = "cko1_rtc", "cko2_rtc", "cko3_rtc"; - }; -}; diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt deleted file mode 100644 index 936aa108eab4..000000000000 --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt +++ /dev/null @@ -1,157 +0,0 @@ -====================================================================== -Device tree bindings for the Aspeed Low Pin Count (LPC) Bus Controller -====================================================================== - -The LPC bus is a means to bridge a host CPU to a number of low-bandwidth -peripheral devices, replacing the use of the ISA bus in the age of PCI[0]. The -primary use case of the Aspeed LPC controller is as a slave on the bus -(typically in a Baseboard Management Controller SoC), but under certain -conditions it can also take the role of bus master. - -The LPC controller is represented as a multi-function device to account for the -mix of functionality, which includes, but is not limited to: - -* An IPMI Block Transfer[2] Controller - -* An LPC Host Controller: Manages LPC functions such as host vs slave mode, the - physical properties of some LPC pins, configuration of serial IRQs, and - APB-to-LPC bridging amonst other functions. - -* An LPC Host Interface Controller: Manages functions exposed to the host such - as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART - management and bus snoop configuration. - -* A set of SuperIO[3] scratch registers: Enables implementation of e.g. custom - hardware management protocols for handover between the host and baseboard - management controller. - -Additionally the state of the LPC controller influences the pinmux -configuration, therefore the host portion of the controller is exposed as a -syscon as a means to arbitrate access. - -[0] http://www.intel.com/design/chipsets/industry/25128901.pdf -[1] https://www.renesas.com/en-sg/doc/products/mpumcu/001/rej09b0078_h8s2168.pdf?key=7c88837454702128622bee53acbda8f4 -[2] https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf -[3] https://en.wikipedia.org/wiki/Super_I/O - -Required properties -=================== - -- compatible: One of: - "aspeed,ast2400-lpc-v2", "simple-mfd", "syscon" - "aspeed,ast2500-lpc-v2", "simple-mfd", "syscon" - "aspeed,ast2600-lpc-v2", "simple-mfd", "syscon" - -- reg: contains the physical address and length values of the Aspeed - LPC memory region. - -- #address-cells: <1> -- #size-cells: <1> -- ranges: Maps 0 to the physical address and length of the LPC memory - region - -Example: - -lpc: lpc@1e789000 { - compatible = "aspeed,ast2500-lpc-v2", "simple-mfd", "syscon"; - reg = <0x1e789000 0x1000>; - - #address-cells = <1>; - #size-cells = <1>; - ranges = <0x0 0x1e789000 0x1000>; - - lpc_snoop: lpc-snoop@0 { - compatible = "aspeed,ast2600-lpc-snoop"; - reg = <0x0 0x80>; - interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>; - snoop-ports = <0x80>; - }; -}; - - -LPC Host Interface Controller -------------------- - -The LPC Host Interface Controller manages functions exposed to the host such as -LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART -management and bus snoop configuration. - -Required properties: - -- compatible: One of: - "aspeed,ast2400-lpc-ctrl"; - "aspeed,ast2500-lpc-ctrl"; - "aspeed,ast2600-lpc-ctrl"; - -- reg: contains offset/length values of the host interface controller - memory regions - -- clocks: contains a phandle to the syscon node describing the clocks. - There should then be one cell representing the clock to use - -Optional properties: - -- memory-region: A phandle to a reserved_memory region to be used for the LPC - to AHB mapping - -- flash: A phandle to the SPI flash controller containing the flash to - be exposed over the LPC to AHB mapping - -Example: - -lpc_ctrl: lpc-ctrl@80 { - compatible = "aspeed,ast2500-lpc-ctrl"; - reg = <0x80 0x80>; - clocks = <&syscon ASPEED_CLK_GATE_LCLK>; - memory-region = <&flash_memory>; - flash = <&spi>; -}; - -LPC Host Controller -------------------- - -The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour -between the host and the baseboard management controller. The registers exist -in the "host" portion of the Aspeed LPC controller, which must be the parent of -the LPC host controller node. - -Required properties: - -- compatible: One of: - "aspeed,ast2400-lhc"; - "aspeed,ast2500-lhc"; - "aspeed,ast2600-lhc"; - -- reg: contains offset/length values of the LHC memory regions. In the - AST2400 and AST2500 there are two regions. - -Example: - -lhc: lhc@a0 { - compatible = "aspeed,ast2500-lhc"; - reg = <0xa0 0x24 0xc8 0x8>; -}; - -LPC reset control ------------------ - -The UARTs present in the ASPEED SoC can have their resets tied to the reset -state of the LPC bus. Some systems may chose to modify this configuration. - -Required properties: - - - compatible: One of: - "aspeed,ast2600-lpc-reset"; - "aspeed,ast2500-lpc-reset"; - "aspeed,ast2400-lpc-reset"; - - - reg: offset and length of the IP in the LHC memory region - - #reset-controller indicates the number of reset cells expected - -Example: - -lpc_reset: reset-controller@98 { - compatible = "aspeed,ast2500-lpc-reset"; - reg = <0x98 0x4>; - #reset-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml new file mode 100644 index 000000000000..750996d9a175 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml @@ -0,0 +1,199 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# # Copyright (c) 2021 Aspeed Tehchnology Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/aspeed-lpc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Aspeed Low Pin Count (LPC) Bus Controller + +maintainers: + - Andrew Jeffery <andrew@aj.id.au> + - Chia-Wei Wang <chiawei_wang@aspeedtech.com> + +description: + The LPC bus is a means to bridge a host CPU to a number of low-bandwidth + peripheral devices, replacing the use of the ISA bus in the age of PCI[0]. The + primary use case of the Aspeed LPC controller is as a slave on the bus + (typically in a Baseboard Management Controller SoC), but under certain + conditions it can also take the role of bus master. + + The LPC controller is represented as a multi-function device to account for the + mix of functionality, which includes, but is not limited to + + * An IPMI Block Transfer[2] Controller + + * An LPC Host Interface Controller manages functions exposed to the host such + as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART + management and bus snoop configuration. + + * A set of SuperIO[3] scratch registers enableing implementation of e.g. custom + hardware management protocols for handover between the host and baseboard + management controller. + + Additionally the state of the LPC controller influences the pinmux + configuration, therefore the host portion of the controller is exposed as a + syscon as a means to arbitrate access. + +properties: + compatible: + items: + - enum: + - aspeed,ast2400-lpc-v2 + - aspeed,ast2500-lpc-v2 + - aspeed,ast2600-lpc-v2 + - const: simple-mfd + - const: syscon + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + +patternProperties: + "^lpc-ctrl@[0-9a-f]+$": + type: object + additionalProperties: false + + description: | + The LPC Host Interface Controller manages functions exposed to the host such as + LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART management + and bus snoop configuration. + + properties: + compatible: + items: + - enum: + - aspeed,ast2400-lpc-ctrl + - aspeed,ast2500-lpc-ctrl + - aspeed,ast2600-lpc-ctrl + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + memory-region: + maxItems: 1 + description: handle to memory reservation for the LPC to AHB mapping region + + flash: + $ref: /schemas/types.yaml#/definitions/phandle + description: The SPI flash controller containing the flash to be exposed over the LPC to AHB mapping + + required: + - compatible + - clocks + + "^reset-controller@[0-9a-f]+$": + type: object + additionalProperties: false + + description: + The UARTs present in the ASPEED SoC can have their resets tied to the reset + state of the LPC bus. Some systems may chose to modify this configuration + + properties: + compatible: + items: + - enum: + - aspeed,ast2400-lpc-reset + - aspeed,ast2500-lpc-reset + - aspeed,ast2600-lpc-reset + + reg: + maxItems: 1 + + '#reset-cells': + const: 1 + + required: + - compatible + - '#reset-cells' + + "^lpc-snoop@[0-9a-f]+$": + type: object + additionalProperties: false + + description: + The LPC snoop interface allows the BMC to listen on and record the data + bytes written by the Host to the targeted LPC I/O pots. + + properties: + compatible: + items: + - enum: + - aspeed,ast2400-lpc-snoop + - aspeed,ast2500-lpc-snoop + - aspeed,ast2600-lpc-snoop + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + snoop-ports: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: The LPC I/O ports to snoop + + required: + - compatible + - interrupts + - snoop-ports + + "^uart-routing@[0-9a-f]+$": + $ref: /schemas/soc/aspeed/uart-routing.yaml# + description: The UART routing control under LPC register space + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - ranges + +additionalProperties: + type: object + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/ast2600-clock.h> + + lpc: lpc@1e789000 { + compatible = "aspeed,ast2600-lpc-v2", "simple-mfd", "syscon"; + reg = <0x1e789000 0x1000>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x1e789000 0x1000>; + + lpc_ctrl: lpc-ctrl@80 { + compatible = "aspeed,ast2600-lpc-ctrl"; + reg = <0x80 0x80>; + clocks = <&syscon ASPEED_CLK_GATE_LCLK>; + memory-region = <&flash_memory>; + flash = <&spi>; + }; + + lpc_reset: reset-controller@98 { + compatible = "aspeed,ast2600-lpc-reset"; + reg = <0x98 0x4>; + #reset-cells = <1>; + }; + + lpc_snoop: lpc-snoop@90 { + compatible = "aspeed,ast2600-lpc-snoop"; + reg = <0x90 0x8>; + interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>; + snoop-ports = <0x80>; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt deleted file mode 100644 index 2b53dcc0ea61..000000000000 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt +++ /dev/null @@ -1,273 +0,0 @@ -AXP family PMIC device tree bindings - -The axp20x family current members : -axp152 (X-Powers) -axp202 (X-Powers) -axp209 (X-Powers) -axp221 (X-Powers) -axp223 (X-Powers) -axp803 (X-Powers) -axp806 (X-Powers) -axp809 (X-Powers) -axp813 (X-Powers) - -The AXP813 is 2 chips packaged into 1. The 2 chips do not share anything -other than the packaging. Pins are routed separately. As such they should -be treated as separate entities. The other half is an AC100 RTC/codec -combo chip. Please see ./ac100.txt for its bindings. - -Required properties: -- compatible: should be one of: - * "x-powers,axp152" - * "x-powers,axp202" - * "x-powers,axp209" - * "x-powers,axp221" - * "x-powers,axp223" - * "x-powers,axp803" - * "x-powers,axp806" - * "x-powers,axp805", "x-powers,axp806" - * "x-powers,axp305", "x-powers,axp805", "x-powers,axp806" - * "x-powers,axp809" - * "x-powers,axp813" -- reg: The I2C slave address or RSB hardware address for the AXP chip -- interrupt-controller: The PMIC has its own internal IRQs -- #interrupt-cells: Should be set to 1 - -Supported common regulator properties, see ../regulator/regulator.txt for -more information: -- regulator-ramp-delay: sets the ramp up delay in uV/us - AXP20x/DCDC2: 1600, 800 - AXP20x/LDO3: 1600, 800 -- regulator-soft-start: enable the output at the lowest possible voltage and - only then set the desired voltage - AXP20x/LDO3: software-based implementation - -Optional properties: -- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin -- x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz - AXP152/20X: range: 750-1875, Default: 1.5 MHz - AXP22X/8XX: range: 1800-4050, Default: 3 MHz - -- x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is - used as an output pin to control an external - regulator to drive the OTG VBus, rather then - as an input pin which signals whether the - board is driving OTG VBus or not. - (axp221 / axp223 / axp803/ axp813 only) - -- x-powers,self-working-mode and - x-powers,master-mode: Boolean (axp806 only). Set either of these when the - PMIC is wired for self-working mode or master mode. - If neither is set then slave mode is assumed. - This corresponds to how the MODESET pin is wired. - -- <input>-supply: a phandle to the regulator supply node. May be omitted if - inputs are unregulated, such as using the IPSOUT output - from the PMIC. - -- regulators: A node that houses a sub-node for each regulator. Regulators - not used but preferred to be managed by the OS should be - listed as well. - See Documentation/devicetree/bindings/regulator/regulator.txt - for more information on standard regulator bindings. - -Optional properties for DCDC regulators: -- x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO (PWM/PFM) mode - Default: Current hardware setting - The DCDC regulators work in a mixed PWM/PFM mode, - using PFM under light loads and switching to PWM - for heavier loads. Forcing PWM mode trades efficiency - under light loads for lower output noise. This - probably makes sense for HiFi audio related - applications that aren't battery constrained. - -AXP202/AXP209 regulators, type, and corresponding input supply names: - -Regulator Type Supply Name Notes ---------- ---- ----------- ----- -DCDC2 : DC-DC buck : vin2-supply -DCDC3 : DC-DC buck : vin3-supply -LDO1 : LDO : acin-supply : always on -LDO2 : LDO : ldo24in-supply : shared supply -LDO3 : LDO : ldo3in-supply -LDO4 : LDO : ldo24in-supply : shared supply -LDO5 : LDO : ldo5in-supply - -AXP221/AXP223 regulators, type, and corresponding input supply names: - -Regulator Type Supply Name Notes ---------- ---- ----------- ----- -DCDC1 : DC-DC buck : vin1-supply -DCDC2 : DC-DC buck : vin2-supply -DCDC3 : DC-DC buck : vin3-supply -DCDC4 : DC-DC buck : vin4-supply -DCDC5 : DC-DC buck : vin5-supply -DC1SW : On/Off Switch : : DCDC1 secondary output -DC5LDO : LDO : : input from DCDC5 -ALDO1 : LDO : aldoin-supply : shared supply -ALDO2 : LDO : aldoin-supply : shared supply -ALDO3 : LDO : aldoin-supply : shared supply -DLDO1 : LDO : dldoin-supply : shared supply -DLDO2 : LDO : dldoin-supply : shared supply -DLDO3 : LDO : dldoin-supply : shared supply -DLDO4 : LDO : dldoin-supply : shared supply -ELDO1 : LDO : eldoin-supply : shared supply -ELDO2 : LDO : eldoin-supply : shared supply -ELDO3 : LDO : eldoin-supply : shared supply -LDO_IO0 : LDO : ips-supply : GPIO 0 -LDO_IO1 : LDO : ips-supply : GPIO 1 -RTC_LDO : LDO : ips-supply : always on -DRIVEVBUS : Enable output : drivevbus-supply : external regulator - -AXP803 regulators, type, and corresponding input supply names: - -Regulator Type Supply Name Notes ---------- ---- ----------- ----- -DCDC1 : DC-DC buck : vin1-supply -DCDC2 : DC-DC buck : vin2-supply : poly-phase capable -DCDC3 : DC-DC buck : vin3-supply : poly-phase capable -DCDC4 : DC-DC buck : vin4-supply -DCDC5 : DC-DC buck : vin5-supply : poly-phase capable -DCDC6 : DC-DC buck : vin6-supply : poly-phase capable -DC1SW : On/Off Switch : : DCDC1 secondary output -ALDO1 : LDO : aldoin-supply : shared supply -ALDO2 : LDO : aldoin-supply : shared supply -ALDO3 : LDO : aldoin-supply : shared supply -DLDO1 : LDO : dldoin-supply : shared supply -DLDO2 : LDO : dldoin-supply : shared supply -DLDO3 : LDO : dldoin-supply : shared supply -DLDO4 : LDO : dldoin-supply : shared supply -ELDO1 : LDO : eldoin-supply : shared supply -ELDO2 : LDO : eldoin-supply : shared supply -ELDO3 : LDO : eldoin-supply : shared supply -FLDO1 : LDO : fldoin-supply : shared supply -FLDO2 : LDO : fldoin-supply : shared supply -LDO_IO0 : LDO : ips-supply : GPIO 0 -LDO_IO1 : LDO : ips-supply : GPIO 1 -RTC_LDO : LDO : ips-supply : always on -DRIVEVBUS : Enable output : drivevbus-supply : external regulator - -AXP806 regulators, type, and corresponding input supply names: - -Regulator Type Supply Name Notes ---------- ---- ----------- ----- -DCDCA : DC-DC buck : vina-supply : poly-phase capable -DCDCB : DC-DC buck : vinb-supply : poly-phase capable -DCDCC : DC-DC buck : vinc-supply : poly-phase capable -DCDCD : DC-DC buck : vind-supply : poly-phase capable -DCDCE : DC-DC buck : vine-supply : poly-phase capable -ALDO1 : LDO : aldoin-supply : shared supply -ALDO2 : LDO : aldoin-supply : shared supply -ALDO3 : LDO : aldoin-supply : shared supply -BLDO1 : LDO : bldoin-supply : shared supply -BLDO2 : LDO : bldoin-supply : shared supply -BLDO3 : LDO : bldoin-supply : shared supply -BLDO4 : LDO : bldoin-supply : shared supply -CLDO1 : LDO : cldoin-supply : shared supply -CLDO2 : LDO : cldoin-supply : shared supply -CLDO3 : LDO : cldoin-supply : shared supply -SW : On/Off Switch : swin-supply - -Additionally, the AXP806 DC-DC regulators support poly-phase arrangements -for higher output current. The possible groupings are: A+B, A+B+C, D+E. - -AXP809 regulators, type, and corresponding input supply names: - -Regulator Type Supply Name Notes ---------- ---- ----------- ----- -DCDC1 : DC-DC buck : vin1-supply -DCDC2 : DC-DC buck : vin2-supply -DCDC3 : DC-DC buck : vin3-supply -DCDC4 : DC-DC buck : vin4-supply -DCDC5 : DC-DC buck : vin5-supply -DC1SW : On/Off Switch : : DCDC1 secondary output -DC5LDO : LDO : : input from DCDC5 -ALDO1 : LDO : aldoin-supply : shared supply -ALDO2 : LDO : aldoin-supply : shared supply -ALDO3 : LDO : aldoin-supply : shared supply -DLDO1 : LDO : dldoin-supply : shared supply -DLDO2 : LDO : dldoin-supply : shared supply -ELDO1 : LDO : eldoin-supply : shared supply -ELDO2 : LDO : eldoin-supply : shared supply -ELDO3 : LDO : eldoin-supply : shared supply -LDO_IO0 : LDO : ips-supply : GPIO 0 -LDO_IO1 : LDO : ips-supply : GPIO 1 -RTC_LDO : LDO : ips-supply : always on -SW : On/Off Switch : swin-supply - -AXP813 regulators, type, and corresponding input supply names: - -Regulator Type Supply Name Notes ---------- ---- ----------- ----- -DCDC1 : DC-DC buck : vin1-supply -DCDC2 : DC-DC buck : vin2-supply : poly-phase capable -DCDC3 : DC-DC buck : vin3-supply : poly-phase capable -DCDC4 : DC-DC buck : vin4-supply -DCDC5 : DC-DC buck : vin5-supply : poly-phase capable -DCDC6 : DC-DC buck : vin6-supply : poly-phase capable -DCDC7 : DC-DC buck : vin7-supply -ALDO1 : LDO : aldoin-supply : shared supply -ALDO2 : LDO : aldoin-supply : shared supply -ALDO3 : LDO : aldoin-supply : shared supply -DLDO1 : LDO : dldoin-supply : shared supply -DLDO2 : LDO : dldoin-supply : shared supply -DLDO3 : LDO : dldoin-supply : shared supply -DLDO4 : LDO : dldoin-supply : shared supply -ELDO1 : LDO : eldoin-supply : shared supply -ELDO2 : LDO : eldoin-supply : shared supply -ELDO3 : LDO : eldoin-supply : shared supply -FLDO1 : LDO : fldoin-supply : shared supply -FLDO2 : LDO : fldoin-supply : shared supply -FLDO3 : LDO : fldoin-supply : shared supply -LDO_IO0 : LDO : ips-supply : GPIO 0 -LDO_IO1 : LDO : ips-supply : GPIO 1 -RTC_LDO : LDO : ips-supply : always on -SW : On/Off Switch : swin-supply -DRIVEVBUS : Enable output : drivevbus-supply : external regulator - -Example: - -axp209: pmic@34 { - compatible = "x-powers,axp209"; - reg = <0x34>; - interrupt-parent = <&nmi_intc>; - interrupts = <0 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #interrupt-cells = <1>; - - regulators { - x-powers,dcdc-freq = <1500>; - - vdd_cpu: dcdc2 { - regulator-always-on; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1450000>; - regulator-name = "vdd-cpu"; - }; - - vdd_int_dll: dcdc3 { - regulator-always-on; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1400000>; - regulator-name = "vdd-int-dll"; - }; - - vdd_rtc: ldo1 { - regulator-always-on; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <1400000>; - regulator-name = "vdd-rtc"; - }; - - avcc: ldo2 { - regulator-always-on; - regulator-min-microvolt = <2700000>; - regulator-max-microvolt = <3300000>; - regulator-name = "avcc"; - }; - - ldo3 { - /* unused but preferred to be managed by OS */ - }; - }; -}; diff --git a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml index fc1317ab3226..be4a2df71c25 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml @@ -32,13 +32,19 @@ properties: "#size-cells": const: 1 - pinctrl: - $ref: ../pinctrl/brcm,ns-pinmux.yaml - patternProperties: '^clock-controller@[a-f0-9]+$': $ref: ../clock/brcm,iproc-clocks.yaml + '^phy@[a-f0-9]+$': + $ref: ../phy/bcm-ns-usb2-phy.yaml + + '^pin-controller@[a-f0-9]+$': + $ref: ../pinctrl/brcm,ns-pinmux.yaml + + '^syscon@[a-f0-9]+$': + $ref: syscon.yaml + '^thermal@[a-f0-9]+$': $ref: ../thermal/brcm,ns-thermal.yaml @@ -49,6 +55,7 @@ required: examples: - | + #include <dt-bindings/clock/bcm-nsp.h> cru-bus@1800c100 { compatible = "brcm,ns-cru", "simple-mfd"; reg = <0x1800c100 0x1d0>; @@ -73,9 +80,24 @@ examples: "iprocfast", "sata1", "sata2"; }; - pinctrl { + phy@164 { + compatible = "brcm,ns-usb2-phy"; + reg = <0x164 0x4>; + brcm,syscon-clkset = <&clkset>; + clocks = <&genpll BCM_NSP_GENPLL_USB_PHY_REF_CLK>; + clock-names = "phy-ref-clk"; + #phy-cells = <0>; + }; + + clkset: syscon@180 { + compatible = "brcm,cru-clkset", "syscon"; + reg = <0x180 0x4>; + }; + + pin-controller@1c0 { compatible = "brcm,bcm4708-pinmux"; - offset = <0x1c0>; + reg = <0x1c0 0x24>; + reg-names = "cru_gpio_control"; }; thermal@2c0 { diff --git a/Documentation/devicetree/bindings/mfd/brcm,misc.yaml b/Documentation/devicetree/bindings/mfd/brcm,misc.yaml new file mode 100644 index 000000000000..cff7d772a7db --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/brcm,misc.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/brcm,misc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom's MISC block + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +description: | + Broadcom's MISC is a hardware block used on some SoCs (e.g. bcm63xx and + bcm4908). It's used to implement some simple functions like a watchdog, PCIe + reset, UniMAC control and more. + +properties: + compatible: + items: + - const: brcm,misc + - const: simple-mfd + + reg: + description: MISC block registers + + ranges: true + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + +patternProperties: + '^reset-controller@[a-f0-9]+$': + $ref: ../reset/brcm,bcm4908-misc-pcie-reset.yaml + +additionalProperties: false + +required: + - reg + - '#address-cells' + - '#size-cells' + +examples: + - | + misc@ff802600 { + compatible = "brcm,misc", "simple-mfd"; + reg = <0xff802600 0xe4>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x0 0xe4>; + + reset-controller@44 { + compatible = "brcm,bcm4908-misc-pcie-reset"; + reg = <0x44 0x4>; + #reset-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/max14577.txt b/Documentation/devicetree/bindings/mfd/max14577.txt index 92070b346756..be11943a0560 100644 --- a/Documentation/devicetree/bindings/mfd/max14577.txt +++ b/Documentation/devicetree/bindings/mfd/max14577.txt @@ -71,7 +71,7 @@ max14577@25 { compatible = "maxim,max14577"; reg = <0x25>; interrupt-parent = <&gpx1>; - interrupts = <5 IRQ_TYPE_NONE>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW>; muic: max14577-muic { compatible = "maxim,max14577-muic"; @@ -106,7 +106,7 @@ max77836@25 { compatible = "maxim,max77836"; reg = <0x25>; interrupt-parent = <&gpx1>; - interrupts = <5 IRQ_TYPE_NONE>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW>; muic: max77836-muic { compatible = "maxim,max77836-muic"; diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt b/Documentation/devicetree/bindings/mfd/max77686.txt index 42968b7144e0..4447d074894a 100644 --- a/Documentation/devicetree/bindings/mfd/max77686.txt +++ b/Documentation/devicetree/bindings/mfd/max77686.txt @@ -21,6 +21,6 @@ Example: max77686: pmic@9 { compatible = "maxim,max77686"; interrupt-parent = <&wakeup_eint>; - interrupts = <26 0>; + interrupts = <26 IRQ_TYPE_LEVEL_LOW>; reg = <0x09>; }; diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt index 0ced96e16c16..1032df14498b 100644 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ b/Documentation/devicetree/bindings/mfd/max77693.txt @@ -139,7 +139,7 @@ Example: compatible = "maxim,max77693"; reg = <0x66>; interrupt-parent = <&gpx1>; - interrupts = <5 2>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW>; regulators { esafeout@1 { diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt index 5ef79bf3d035..7a27c500ff63 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt @@ -15,29 +15,38 @@ each. A function can consume one or more of these fixed-size register regions. Required properties: - compatible: Should contain one of: - "qcom,pm8941", - "qcom,pm8841", - "qcom,pma8084", + "qcom,pm660", + "qcom,pm660l", + "qcom,pm7325", + "qcom,pm8004", + "qcom,pm8005", "qcom,pm8019", - "qcom,pm8226", + "qcom,pm8028", "qcom,pm8110", - "qcom,pma8084", - "qcom,pmi8962", - "qcom,pmd9635", - "qcom,pm8994", - "qcom,pmi8994", - "qcom,pm8916", - "qcom,pm8004", + "qcom,pm8150", + "qcom,pm8150b", + "qcom,pm8150c", + "qcom,pm8150l", + "qcom,pm8226", + "qcom,pm8350c", + "qcom,pm8841", + "qcom,pm8901", "qcom,pm8909", + "qcom,pm8916", + "qcom,pm8941", "qcom,pm8950", - "qcom,pmi8950", + "qcom,pm8994", "qcom,pm8998", + "qcom,pma8084", + "qcom,pmd9635", + "qcom,pmi8950", + "qcom,pmi8962", + "qcom,pmi8994", "qcom,pmi8998", - "qcom,pm8005", - "qcom,pm8350c", + "qcom,pmk8002", "qcom,pmk8350", - "qcom,pm7325", "qcom,pmr735a", + "qcom,smb2351", or generalized "qcom,spmi-pmic". - reg: Specifies the SPMI USID slave address for this device. For more information see: diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt b/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt index e90519d566a3..c5f4f0ddfcc3 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt @@ -6,6 +6,7 @@ registers via syscon. Required properties: - compatible: Should contain: + "qcom,tcsr-ipq6018", "syscon", "simple-mfd" for IPQ6018 "qcom,tcsr-ipq8064", "syscon" for IPQ8064 "qcom,tcsr-apq8064", "syscon" for APQ8064 "qcom,tcsr-msm8660", "syscon" for MSM8660 diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml index 9065ec53e643..2568736701be 100644 --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml @@ -16,6 +16,7 @@ description: | properties: compatible: enum: + - qcom,pm8018 - qcom,pm8058 - qcom,pm8821 - qcom,pm8921 diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml new file mode 100644 index 000000000000..017befdf8adb --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/samsung,s2mpa01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPA01 Power Management IC + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The Samsung S2MPA01 is a Power Management IC which includes voltage + and current regulators, RTC, clock outputs and other sub-blocks. + +properties: + compatible: + const: samsung,s2mpa01-pmic + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + regulators: + $ref: ../regulator/samsung,s2mpa01.yaml + description: + List of child nodes that specify the regulators. + + wakeup-source: true + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "samsung,s2mpa01-pmic"; + reg = <0x66>; + + regulators { + ldo1_reg: LDO1 { + regulator-name = "VDD_ALIVE"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + }; + + ldo2_reg: LDO2 { + regulator-name = "VDDQ_MMC2"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-always-on; + }; + + // ... + + buck1_reg: BUCK1 { + regulator-name = "vdd_mif"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + regulator-boot-on; + }; + + buck2_reg: BUCK2 { + regulator-name = "vdd_arm"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + regulator-boot-on; + regulator-ramp-delay = <50000>; + }; + + // ... + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml new file mode 100644 index 000000000000..771b3f16da96 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml @@ -0,0 +1,267 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/samsung,s2mps11.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPS11/13/14/15 and S2MPU02 Power Management IC + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The Samsung S2MPS11/13/14/15 and S2MPU02 is a family of Power Management IC + which include voltage and current regulators, RTC, clock outputs and other + sub-blocks. + +properties: + compatible: + enum: + - samsung,s2mps11-pmic + - samsung,s2mps13-pmic + - samsung,s2mps14-pmic + - samsung,s2mps15-pmic + - samsung,s2mpu02-pmic + + clocks: + $ref: ../clock/samsung,s2mps11.yaml + description: + Child node describing clock provider. + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + regulators: + type: object + description: + List of child nodes that specify the regulators. + + samsung,s2mps11-acokb-ground: + description: | + Indicates that ACOKB pin of S2MPS11 PMIC is connected to the ground so + the PMIC must manually set PWRHOLD bit in CTRL1 register to turn off the + power. Usually the ACOKB is pulled up to VBATT so when PWRHOLD pin goes + low, the rising ACOKB will trigger power off. + type: boolean + + samsung,s2mps11-wrstbi-ground: + description: | + Indicates that WRSTBI pin of PMIC is pulled down. When the system is + suspended it will always go down thus triggerring unwanted buck warm + reset (setting buck voltages to default values). + type: boolean + + wakeup-source: true + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,s2mps11-pmic + then: + properties: + regulators: + $ref: ../regulator/samsung,s2mps11.yaml + samsung,s2mps11-wrstbi-ground: false + + - if: + properties: + compatible: + contains: + const: samsung,s2mps13-pmic + then: + properties: + regulators: + $ref: ../regulator/samsung,s2mps13.yaml + samsung,s2mps11-acokb-ground: false + + - if: + properties: + compatible: + contains: + const: samsung,s2mps14-pmic + then: + properties: + regulators: + $ref: ../regulator/samsung,s2mps14.yaml + samsung,s2mps11-acokb-ground: false + samsung,s2mps11-wrstbi-ground: false + + - if: + properties: + compatible: + contains: + const: samsung,s2mps15-pmic + then: + properties: + regulators: + $ref: ../regulator/samsung,s2mps15.yaml + samsung,s2mps11-acokb-ground: false + samsung,s2mps11-wrstbi-ground: false + + - if: + properties: + compatible: + contains: + const: samsung,s2mpu02-pmic + then: + properties: + regulators: + $ref: ../regulator/samsung,s2mpu02.yaml + samsung,s2mps11-acokb-ground: false + samsung,s2mps11-wrstbi-ground: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "samsung,s2mps11-pmic"; + reg = <0x66>; + + interrupt-parent = <&gpx0>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&s2mps11_irq>; + samsung,s2mps11-acokb-ground; + wakeup-source; + + clocks { + compatible = "samsung,s2mps11-clk"; + #clock-cells = <1>; + clock-output-names = "s2mps11_ap", "s2mps11_cp", "s2mps11_bt"; + }; + + regulators { + LDO1 { + regulator-name = "vdd_ldo1"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-always-on; + }; + + LDO4 { + regulator-name = "vdd_adc"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + // .... + + BUCK1 { + regulator-name = "vdd_mif"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1300000>; + regulator-always-on; + regulator-boot-on; + + 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-coupled-with = <&buck3_reg>; + regulator-coupled-max-spread = <300000>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + BUCK3 { + regulator-name = "vdd_int"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1400000>; + regulator-always-on; + regulator-boot-on; + regulator-coupled-with = <&buck2_reg>; + regulator-coupled-max-spread = <300000>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + // ... + }; + }; + }; + + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "samsung,s2mps14-pmic"; + reg = <0x66>; + + interrupt-parent = <&gpx0>; + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + wakeup-source; + + clocks { + compatible = "samsung,s2mps14-clk"; + #clock-cells = <1>; + clock-output-names = "s2mps14_ap", "unused", "s2mps14_bt"; + }; + + regulators { + LDO1 { + regulator-name = "VLDO1_1.0V"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-always-on; + + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + // ... + + BUCK1 { + regulator-name = "VBUCK1_1.0V"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1000000>; + regulator-always-on; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + // ... + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml b/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml new file mode 100644 index 000000000000..5531718abdf0 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml @@ -0,0 +1,307 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/samsung,s5m8767.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5M8767 Power Management IC + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The Samsung S5M8767 is a Power Management IC which includes voltage + and current regulators, RTC, clock outputs and other sub-blocks. + +properties: + compatible: + const: samsung,s5m8767-pmic + + clocks: + $ref: ../clock/samsung,s2mps11.yaml + description: + Child node describing clock provider. + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + regulators: + $ref: ../regulator/samsung,s5m8767.yaml + description: + List of child nodes that specify the regulators. + + s5m8767,pmic-buck2-dvs-voltage: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 8 + maxItems: 8 + description: | + A set of 8 voltage values in micro-volt (uV) units for buck2 when + changing voltage using gpio dvs. + + s5m8767,pmic-buck3-dvs-voltage: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 8 + maxItems: 8 + description: | + A set of 8 voltage values in micro-volt (uV) units for buck3 when + changing voltage using gpio dvs. + + s5m8767,pmic-buck4-dvs-voltage: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 8 + maxItems: 8 + description: | + A set of 8 voltage values in micro-volt (uV) units for buck4 when + changing voltage using gpio dvs. + + s5m8767,pmic-buck-ds-gpios: + minItems: 3 + maxItems: 3 + description: | + GPIO specifiers for three host gpio's used for selecting GPIO DVS lines. + It is one-to-one mapped to dvs gpio lines. + + s5m8767,pmic-buck2-uses-gpio-dvs: + type: boolean + description: buck2 can be controlled by gpio dvs. + + s5m8767,pmic-buck3-uses-gpio-dvs: + type: boolean + description: buck3 can be controlled by gpio dvs. + + s5m8767,pmic-buck4-uses-gpio-dvs: + type: boolean + description: buck4 can be controlled by gpio dvs. + + s5m8767,pmic-buck-default-dvs-idx: + $ref: /schemas/types.yaml#/definitions/uint32-array + minimum: 0 + maximum: 7 + default: 0 + description: | + Default voltage setting selected from the possible 8 options selectable + by the dvs gpios. The value of this property should be between 0 and 7. + If not specified or if out of range, the default value of this property + is set to 0. + + s5m8767,pmic-buck-dvs-gpios: + minItems: 3 + maxItems: 3 + description: | + GPIO specifiers for three host gpio's used for dvs. + + vinb1-supply: + description: Power supply for buck1 + vinb2-supply: + description: Power supply for buck2 + vinb3-supply: + description: Power supply for buck3 + vinb4-supply: + description: Power supply for buck4 + vinb5-supply: + description: Power supply for buck5 + vinb6-supply: + description: Power supply for buck6 + vinb7-supply: + description: Power supply for buck7 + vinb8-supply: + description: Power supply for buck8 + vinb9-supply: + description: Power supply for buck9 + + vinl1-supply: + description: Power supply for LDO3, LDO10, LDO26, LDO27 + vinl2-supply: + description: Power supply for LDO13, LDO16, LDO25, LDO28 + vinl3-supply: + description: Power supply for LDO11, LDO14 + vinl4-supply: + description: Power supply for LDO4, LDO9 + vinl5-supply: + description: Power supply for LDO12, LDO17, LDO19, LDO23 + vinl6-supply: + description: Power supply for LDO18, LDO20, LDO21, LDO24 + vinl7-supply: + description: Power supply for LDO5, LDO22 + vinl8-supply: + description: Power supply for LDO1, LDO6, LDO7, LDO8, LDO15 + vinl9-supply: + description: Power supply for LDO2 + + wakeup-source: true + +required: + - compatible + - reg + - regulators + - s5m8767,pmic-buck-ds-gpios + +dependencies: + s5m8767,pmic-buck2-dvs-voltage: [ 's5m8767,pmic-buck-dvs-gpios' ] + s5m8767,pmic-buck3-dvs-voltage: [ 's5m8767,pmic-buck-dvs-gpios' ] + s5m8767,pmic-buck4-dvs-voltage: [ 's5m8767,pmic-buck-dvs-gpios' ] + s5m8767,pmic-buck2-uses-gpio-dvs: [ 's5m8767,pmic-buck-dvs-gpios', 's5m8767,pmic-buck2-dvs-voltage' ] + s5m8767,pmic-buck3-uses-gpio-dvs: [ 's5m8767,pmic-buck-dvs-gpios', 's5m8767,pmic-buck3-dvs-voltage' ] + s5m8767,pmic-buck4-uses-gpio-dvs: [ 's5m8767,pmic-buck-dvs-gpios', 's5m8767,pmic-buck4-dvs-voltage' ] + +additionalProperties: false + +allOf: + - if: + required: + - s5m8767,pmic-buck2-uses-gpio-dvs + then: + properties: + s5m8767,pmic-buck3-uses-gpio-dvs: false + s5m8767,pmic-buck4-uses-gpio-dvs: false + + - if: + required: + - s5m8767,pmic-buck3-uses-gpio-dvs + then: + properties: + s5m8767,pmic-buck2-uses-gpio-dvs: false + s5m8767,pmic-buck4-uses-gpio-dvs: false + + - if: + required: + - s5m8767,pmic-buck4-uses-gpio-dvs + then: + properties: + s5m8767,pmic-buck2-uses-gpio-dvs: false + s5m8767,pmic-buck3-uses-gpio-dvs: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "samsung,s5m8767-pmic"; + reg = <0x66>; + + interrupt-parent = <&gpx3>; + interrupts = <2 IRQ_TYPE_LEVEL_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&s5m8767_irq &s5m8767_dvs &s5m8767_ds>; + wakeup-source; + + s5m8767,pmic-buck-default-dvs-idx = <3>; + s5m8767,pmic-buck2-uses-gpio-dvs; + + s5m8767,pmic-buck-dvs-gpios = <&gpd1 0 GPIO_ACTIVE_LOW>, + <&gpd1 1 GPIO_ACTIVE_LOW>, + <&gpd1 2 GPIO_ACTIVE_LOW>; + + s5m8767,pmic-buck-ds-gpios = <&gpx2 3 GPIO_ACTIVE_LOW>, + <&gpx2 4 GPIO_ACTIVE_LOW>, + <&gpx2 5 GPIO_ACTIVE_LOW>; + + s5m8767,pmic-buck2-dvs-voltage = <1350000>, <1300000>, + <1250000>, <1200000>, + <1150000>, <1100000>, + <1000000>, <950000>; + + s5m8767,pmic-buck3-dvs-voltage = <1100000>, <1100000>, + <1100000>, <1100000>, + <1000000>, <1000000>, + <1000000>, <1000000>; + + s5m8767,pmic-buck4-dvs-voltage = <1200000>, <1200000>, + <1200000>, <1200000>, + <1200000>, <1200000>, + <1200000>, <1200000>; + + clocks { + compatible = "samsung,s5m8767-clk"; + #clock-cells = <1>; + clock-output-names = "en32khz_ap", "en32khz_cp", "en32khz_bt"; + }; + + regulators { + LDO1 { + regulator-name = "VDD_ALIVE"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-always-on; + regulator-boot-on; + op_mode = <1>; /* Normal Mode */ + }; + + // ... + + BUCK1 { + regulator-name = "VDD_MIF"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1100000>; + regulator-always-on; + regulator-boot-on; + op_mode = <1>; /* Normal Mode */ + }; + + BUCK2 { + regulator-name = "VDD_ARM"; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + regulator-boot-on; + op_mode = <1>; /* Normal Mode */ + }; + + // ... + }; + }; + }; + + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "samsung,s5m8767-pmic"; + reg = <0x66>; + + interrupt-parent = <&gpx3>; + interrupts = <2 IRQ_TYPE_LEVEL_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&s5m8767_irq &s5m8767_dvs &s5m8767_ds>; + wakeup-source; + + s5m8767,pmic-buck-ds-gpios = <&gpx2 3 GPIO_ACTIVE_LOW>, + <&gpx2 4 GPIO_ACTIVE_LOW>, + <&gpx2 5 GPIO_ACTIVE_LOW>; + + clocks { + compatible = "samsung,s5m8767-clk"; + #clock-cells = <1>; + clock-output-names = "en32khz_ap", "en32khz_cp", "en32khz_bt"; + }; + + regulators { + LDO1 { + regulator-name = "VDD_ALIVE"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-always-on; + regulator-boot-on; + op_mode = <1>; /* Normal Mode */ + }; + + // ... + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt b/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt deleted file mode 100644 index c68cdd365153..000000000000 --- a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt +++ /dev/null @@ -1,86 +0,0 @@ -Binding for Samsung S2M and S5M family multi-function device -============================================================ - -This is a part of device tree bindings for S2M and S5M family multi-function -devices. - -The Samsung S2MPA01, S2MPS11/13/14/15, S2MPU02 and S5M8767 is a family -of multi-function devices which include voltage and current regulators, RTC, -charger controller, clock outputs and other sub-blocks. It is interfaced -to the host controller using an I2C interface. Each sub-block is usually -addressed by the host system using different I2C slave addresses. - - -This document describes bindings for main device node. Optional sub-blocks -must be a sub-nodes to it. Bindings for them can be found in: - - bindings/regulator/samsung,s2mpa01.txt - - bindings/regulator/samsung,s2mps11.txt - - bindings/regulator/samsung,s5m8767.txt - - bindings/clock/samsung,s2mps11.txt - - -Required properties: - - compatible: Should be one of the following - - "samsung,s2mpa01-pmic", - - "samsung,s2mps11-pmic", - - "samsung,s2mps13-pmic", - - "samsung,s2mps14-pmic", - - "samsung,s2mps15-pmic", - - "samsung,s2mpu02-pmic", - - "samsung,s5m8767-pmic". - - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. - -Optional properties: - - interrupts: Interrupt specifiers for interrupt sources. - - samsung,s2mps11-wrstbi-ground: Indicates that WRSTBI pin of PMIC is pulled - down. When the system is suspended it will always go down thus triggerring - unwanted buck warm reset (setting buck voltages to default values). - - samsung,s2mps11-acokb-ground: Indicates that ACOKB pin of S2MPS11 PMIC is - connected to the ground so the PMIC must manually set PWRHOLD bit in CTRL1 - register to turn off the power. Usually the ACOKB is pulled up to VBATT so - when PWRHOLD pin goes low, the rising ACOKB will trigger power off. - -Example: - - s2mps11_pmic@66 { - compatible = "samsung,s2mps11-pmic"; - reg = <0x66>; - - s2m_osc: clocks { - compatible = "samsung,s2mps11-clk"; - #clock-cells = <1>; - clock-output-names = "xx", "yy", "zz"; - }; - - regulators { - ldo1_reg: LDO1 { - regulator-name = "VDD_ABB_3.3V"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - ldo2_reg: LDO2 { - regulator-name = "VDD_ALIVE_1.1V"; - regulator-min-microvolt = <1100000>; - regulator-max-microvolt = <1100000>; - regulator-always-on; - }; - - buck1_reg: BUCK1 { - regulator-name = "vdd_mif"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - }; - - buck2_reg: BUCK2 { - regulator-name = "vdd_arm"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - regulator-ramp-delay = <50000>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml index 8bcea8dd7d90..ec7f0190f46e 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml @@ -17,7 +17,7 @@ description: | - simple counter from IN1 input signal. maintainers: - - Fabrice Gasnier <fabrice.gasnier@st.com> + - Fabrice Gasnier <fabrice.gasnier@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml index dace35362a7a..10b330d42901 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml @@ -17,8 +17,7 @@ description: | programmable prescaler. maintainers: - - Benjamin Gaignard <benjamin.gaignard@st.com> - - Fabrice Gasnier <fabrice.gasnier@st.com> + - Fabrice Gasnier <fabrice.gasnier@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/mfd/st,stmfx.yaml b/Documentation/devicetree/bindings/mfd/st,stmfx.yaml index 19e9afb385ac..b2a4e4aa7ff6 100644 --- a/Documentation/devicetree/bindings/mfd/st,stmfx.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stmfx.yaml @@ -12,7 +12,7 @@ description: ST Multi-Function eXpander (STMFX) is a slave controller using I2C through VDD) and resistive touchscreen controller. maintainers: - - Amelie Delaunay <amelie.delaunay@st.com> + - Amelie Delaunay <amelie.delaunay@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml index 305123e74a58..426658ad81d4 100644 --- a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml @@ -9,7 +9,7 @@ title: STMicroelectonics STPMIC1 Power Management IC bindings description: STMicroelectronics STPMIC1 Power Management IC maintainers: - - pascal Paillet <p.paillet@st.com> + - pascal Paillet <p.paillet@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index abe3fd817e0b..5de16388a089 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -38,6 +38,7 @@ properties: - allwinner,sun8i-h3-system-controller - allwinner,sun8i-v3s-system-controller - allwinner,sun50i-a64-system-controller + - brcm,cru-clkset - hisilicon,dsa-subctrl - hisilicon,hi6220-sramctrl - hisilicon,pcie-sas-subctrl @@ -49,12 +50,14 @@ properties: - rockchip,rk3066-qos - rockchip,rk3228-qos - rockchip,rk3288-qos + - rockchip,rk3368-qos - rockchip,rk3399-qos - rockchip,rk3568-qos - samsung,exynos3-sysreg - samsung,exynos4-sysreg - samsung,exynos5-sysreg - samsung,exynos5433-sysreg + - samsung,exynosautov9-sysreg - const: syscon diff --git a/Documentation/devicetree/bindings/mfd/ti,am3359-tscadc.yaml b/Documentation/devicetree/bindings/mfd/ti,am3359-tscadc.yaml new file mode 100644 index 000000000000..34bf6a01436f --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/ti,am3359-tscadc.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/ti,am3359-tscadc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI AM3359 Touchscreen controller/ADC + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +properties: + compatible: + oneOf: + - const: ti,am3359-tscadc + - items: + - const: ti,am654-tscadc + - const: ti,am3359-tscadc + - const: ti,am4372-magadc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: fck + + dmas: + items: + - description: DMA controller phandle and request line for FIFO0 + - description: DMA controller phandle and request line for FIFO1 + + dma-names: + items: + - const: fifo0 + - const: fifo1 + + adc: + type: object + description: ADC child + + tsc: + type: object + description: Touchscreen controller child + + mag: + type: object + description: Magnetic reader + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + tscadc@0 { + compatible = "ti,am3359-tscadc"; + reg = <0x0 0x1000>; + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&adc_tsc_fck>; + clock-names = "fck"; + dmas = <&edma 53 0>, <&edma 57 0>; + dma-names = "fifo0", "fifo1"; + + tsc { + }; + + adc { + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml b/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml new file mode 100644 index 000000000000..de330c9869ff --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml @@ -0,0 +1,116 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mfd/x-powers,ac100.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: X-Powers AC100 Device Tree Bindings + +maintainers: + - Chen-Yu Tsai <wens@csie.org> + +properties: + compatible: + const: x-powers,ac100 + + reg: + maxItems: 1 + + codec: + type: object + + properties: + "#clock-cells": + const: 0 + + compatible: + const: x-powers,ac100-codec + + interrupts: + maxItems: 1 + + clock-output-names: + maxItems: 1 + description: > + Name of the 4M_adda clock exposed by the codec + + required: + - "#clock-cells" + - compatible + - interrupts + - clock-output-names + + additionalProperties: false + + rtc: + type: object + + properties: + "#clock-cells": + const: 1 + + compatible: + const: x-powers,ac100-rtc + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + description: > + A phandle to the codec's "4M_adda" clock + + clock-output-names: + maxItems: 3 + description: > + Name of the cko1, cko2 and cko3 clocks exposed by the codec + + required: + - "#clock-cells" + - compatible + - interrupts + - clocks + - clock-output-names + + additionalProperties: false + +required: + - compatible + - reg + - codec + - rtc + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + rsb { + #address-cells = <1>; + #size-cells = <0>; + + codec@e89 { + compatible = "x-powers,ac100"; + reg = <0xe89>; + + ac100_codec: codec { + compatible = "x-powers,ac100-codec"; + interrupt-parent = <&r_pio>; + interrupts = <0 9 IRQ_TYPE_LEVEL_LOW>; /* PL9 */ + #clock-cells = <0>; + clock-output-names = "4M_adda"; + }; + + ac100_rtc: rtc { + compatible = "x-powers,ac100-rtc"; + interrupt-parent = <&nmi_intc>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + clocks = <&ac100_codec>; + #clock-cells = <1>; + clock-output-names = "cko1_rtc", "cko2_rtc", "cko3_rtc"; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml new file mode 100644 index 000000000000..3a53bae611bc --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml @@ -0,0 +1,400 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/x-powers,axp152.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: X-Powers AXP PMIC Device Tree Bindings + +maintainers: + - Chen-Yu Tsai <wens@csie.org> + +allOf: + - if: + properties: + compatible: + contains: + enum: + - x-powers,axp152 + - x-powers,axp202 + - x-powers,axp209 + + then: + properties: + regulators: + properties: + x-powers,dcdc-freq: + minimum: 750 + maximum: 1875 + default: 1500 + + else: + properties: + regulators: + properties: + x-powers,dcdc-freq: + minimum: 1800 + maximum: 4050 + default: 3000 + + - if: + properties: + compatible: + contains: + enum: + - x-powers,axp152 + - x-powers,axp202 + - x-powers,axp209 + + then: + not: + required: + - x-powers,drive-vbus-en + + - if: + not: + properties: + compatible: + contains: + const: x-powers,axp806 + + then: + allOf: + - not: + required: + - x-powers,self-working-mode + + - not: + required: + - x-powers,master-mode + + - if: + not: + properties: + compatible: + contains: + const: x-powers,axp305 + + then: + required: + - interrupts + +properties: + compatible: + oneOf: + - enum: + - x-powers,axp152 + - x-powers,axp202 + - x-powers,axp209 + - x-powers,axp221 + - x-powers,axp223 + - x-powers,axp803 + - x-powers,axp806 + - x-powers,axp809 + - x-powers,axp813 + - items: + - const: x-powers,axp805 + - const: x-powers,axp806 + - items: + - const: x-powers,axp305 + - const: x-powers,axp805 + - const: x-powers,axp806 + - items: + - const: x-powers,axp818 + - const: x-powers,axp813 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 1 + + x-powers,drive-vbus-en: + type: boolean + description: > + Set this when the N_VBUSEN pin is used as an output pin to control an + external regulator to drive the OTG VBus, rather then as an input pin + which signals whether the board is driving OTG VBus or not. + + x-powers,self-working-mode: + type: boolean + description: > + Set this when the PMIC is wired for self-working mode through the MODESET + pin. + + x-powers,master-mode: + type: boolean + description: > + Set this when the PMIC is wired for master mode through the MODESET pin. + + vin1-supply: + description: > + DCDC1 power supply node, if present. + + vin2-supply: + description: > + DCDC2 power supply node, if present. + + vin3-supply: + description: > + DCDC3 power supply node, if present. + + vin4-supply: + description: > + DCDC4 power supply node, if present. + + vin5-supply: + description: > + DCDC5 power supply node, if present. + + vin6-supply: + description: > + DCDC6 power supply node, if present. + + vin7-supply: + description: > + DCDC7 power supply node, if present. + + vina-supply: + description: > + DCDCA power supply node, if present. + + vinb-supply: + description: > + DCDCB power supply node, if present. + + vinc-supply: + description: > + DCDCC power supply node, if present. + + vind-supply: + description: > + DCDCD power supply node, if present. + + vine-supply: + description: > + DCDCE power supply node, if present. + + acin-supply: + description: > + LDO1 power supply node, if present. + + ldo24in-supply: + description: > + LDO2 and LDO4 power supply node, if present. + + ldo3in-supply: + description: > + LDO3 power supply node, if present. + + ldo5in-supply: + description: > + LDO5 power supply node, if present. + + aldoin-supply: + description: > + ALDO* power supply node, if present. + + bldoin-supply: + description: > + BLDO* power supply node, if present. + + cldoin-supply: + description: > + CLDO* power supply node, if present. + + dldoin-supply: + description: > + DLDO* power supply node, if present. + + eldoin-supply: + description: > + ELDO* power supply node, if present. + + fldoin-supply: + description: > + FLDO* power supply node, if present. + + ips-supply: + description: > + LDO_IO0, LDO_IO1 and RTC_LDO power supply node, if present. + + drivevbus-supply: + description: > + DRIVEVBUS power supply node, if present. + + swin-supply: + description: > + SW power supply node, if present. + + adc: + $ref: /schemas/iio/adc/x-powers,axp209-adc.yaml# + + gpio: + $ref: /schemas/gpio/x-powers,axp209-gpio.yaml# + + ac-power: + $ref: /schemas/power/supply/x-powers,axp20x-ac-power-supply.yaml# + + battery-power: + $ref: /schemas/power/supply/x-powers,axp20x-battery-power-supply.yaml# + + usb-power: + $ref: /schemas/power/supply/x-powers,axp20x-usb-power-supply.yaml# + + regulators: + type: object + + properties: + x-powers,dcdc-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + Defines the work frequency of DC-DC in kHz. + + patternProperties: + "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|drivevbus|dc5ldo)$": + $ref: /schemas/regulator/regulator.yaml# + type: object + + properties: + regulator-ramp-delay: + description: > + Only 800 and 1600 are valid for the DCDC2 and LDO3 regulators on + the AXP209. + + regulator-soft-start: + description: > + Only valid for the LDO3 regulator. + + x-powers,dcdc-workmode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: > + Only valid for DCDC regulators. Setup 1 for PWM mode, 0 + for AUTO (PWM/PFM) mode. The DCDC regulators work in a + mixed PWM/PFM mode, using PFM under light loads and + switching to PWM for heavier loads. Forcing PWM mode + trades efficiency under light loads for lower output + noise. This probably makes sense for HiFi audio related + applications that aren't battery constrained. + + additionalProperties: false + +required: + - compatible + - reg + - "#interrupt-cells" + - interrupt-controller + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + pmic@30 { + compatible = "x-powers,axp152"; + reg = <0x30>; + interrupts = <0>; + interrupt-controller; + #interrupt-cells = <1>; + }; + }; + + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + pmic@34 { + compatible = "x-powers,axp209"; + reg = <0x34>; + interrupt-parent = <&nmi_intc>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <1>; + + ac_power_supply: ac-power { + compatible = "x-powers,axp202-ac-power-supply"; + }; + + axp_adc: adc { + compatible = "x-powers,axp209-adc"; + #io-channel-cells = <1>; + }; + + axp_gpio: gpio { + compatible = "x-powers,axp209-gpio"; + gpio-controller; + #gpio-cells = <2>; + + gpio0-adc-pin { + pins = "GPIO0"; + function = "adc"; + }; + }; + + battery_power_supply: battery-power { + compatible = "x-powers,axp209-battery-power-supply"; + }; + + regulators { + /* Default work frequency for buck regulators */ + x-powers,dcdc-freq = <1500>; + + reg_dcdc2: dcdc2 { + regulator-always-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1450000>; + regulator-name = "vdd-cpu"; + }; + + reg_dcdc3: dcdc3 { + regulator-always-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1400000>; + regulator-name = "vdd-int-dll"; + }; + + reg_ldo1: ldo1 { + /* LDO1 is a fixed output regulator */ + regulator-always-on; + regulator-min-microvolt = <1300000>; + regulator-max-microvolt = <1300000>; + regulator-name = "vdd-rtc"; + }; + + reg_ldo2: ldo2 { + regulator-always-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-name = "avcc"; + }; + + reg_ldo3: ldo3 { + regulator-name = "ldo3"; + }; + + reg_ldo4: ldo4 { + regulator-name = "ldo4"; + }; + + reg_ldo5: ldo5 { + regulator-name = "ldo5"; + }; + }; + + usb_power_supply: usb-power { + compatible = "x-powers,axp202-usb-power-supply"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml b/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml index 8a1a6625c782..9efd49c39bd2 100644 --- a/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml +++ b/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml @@ -46,6 +46,9 @@ patternProperties: "^gpio@[0-9a-f]+$": $ref: /schemas/gpio/xylon,logicvc-gpio.yaml# + "^display@[0-9a-f]+$": + $ref: /schemas/display/xylon,logicvc-display.yaml# + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml index 6df1a9470d8f..b7e7fa715437 100644 --- a/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml +++ b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml @@ -44,7 +44,7 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/jz4780-cgu.h> + #include <dt-bindings/clock/ingenic,jz4780-cgu.h> cpus { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/mips/ralink.txt b/Documentation/devicetree/bindings/mips/ralink.txt deleted file mode 100644 index 8cc0ab41578c..000000000000 --- a/Documentation/devicetree/bindings/mips/ralink.txt +++ /dev/null @@ -1,32 +0,0 @@ -Ralink MIPS SoC device tree bindings - -1. SoCs - -Each device tree must specify a compatible value for the Ralink SoC -it uses in the compatible property of the root node. The compatible -value must be one of the following values: - - ralink,rt2880-soc - ralink,rt3050-soc - ralink,rt3052-soc - ralink,rt3350-soc - ralink,rt3352-soc - ralink,rt3883-soc - ralink,rt5350-soc - ralink,mt7620a-soc - ralink,mt7620n-soc - ralink,mt7628a-soc - ralink,mt7688a-soc - -2. Boards - -GARDENA smart Gateway (MT7688) - -This board is based on the MediaTek MT7688 and equipped with 128 MiB -of DDR and 8 MiB of flash (SPI NOR) and additional 128MiB SPI NAND -storage. - ------------------------------- -Required root node properties: -- compatible = "gardena,smart-gateway-mt7688", "ralink,mt7688a-soc", - "ralink,mt7628a-soc"; diff --git a/Documentation/devicetree/bindings/mips/ralink.yaml b/Documentation/devicetree/bindings/mips/ralink.yaml new file mode 100644 index 000000000000..0588cee25ae9 --- /dev/null +++ b/Documentation/devicetree/bindings/mips/ralink.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mips/ralink.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink SoC based Platforms Device Tree Bindings + +maintainers: + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +description: | + Boards with a Ralink SoC shall have the following properties. + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: Boards with Ralink RT2880 SoC + items: + - enum: + - ralink,rt2880-eval-board + - const: ralink,rt2880-soc + + - description: Boards with Ralink RT3050 SoC + items: + - const: ralink,rt3050-soc + + - description: Boards with Ralink RT3052 SoC + items: + - enum: + - ralink,rt3052-eval-board + - const: ralink,rt3052-soc + + - description: Boards with Ralink RT3350 SoC + items: + - const: ralink,rt3350-soc + + - description: Boards with Ralink RT3352 SoC + items: + - const: ralink,rt3352-soc + + - description: Boards with Ralink RT3383 SoC + items: + - enum: + - ralink,rt3883-eval-board + - const: ralink,rt3383-soc + + - description: Boards with Ralink RT5350 SoC + items: + - const: ralink,rt5350-soc + + - description: Boards with Mediatek/Ralink MT7620A SoC + items: + - enum: + - ralink,mt7620a-eval-board + - const: ralink,mt7620a-soc + + - description: Boards with Mediatek/Ralink MT7620N SoC + items: + - const: ralink,mt7620n-soc + + - description: Boards with Mediatek/Ralink MT7628A SoC + items: + - enum: + - onion,omega2+ + - vocore,vocore2 + - const: ralink,mt7628a-soc + + - description: Boards with Mediatek/Ralink MT7688A SoC + items: + - enum: + - gardena,smart-gateway-mt7688 + - onion,omega2+ + - const: ralink,mt7628a-soc + + - description: Boards with Mediatek/Ralink MT7621 SoC + items: + - enum: + - gnubee,gb-pc1 + - gnubee,gb-pc2 + - const: mediatek,mt7621-soc + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml index 37a5fe7b26dc..de6f076e0ece 100644 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml @@ -88,6 +88,12 @@ properties: description: For this device it is strongly suggested to include arasan,soc-ctl-syscon. + - items: + - const: intel,thunderbay-sdhci-5.1 # Intel Thunder Bay eMMC PHY + - const: arasan,sdhci-5.1 + description: + For this device it is strongly suggested to include + clock-output-names and '#clock-cells'. reg: maxItems: 1 @@ -153,7 +159,6 @@ properties: The MIO bank number in which the command and data lines are configured. dependencies: - clock-output-names: [ '#clock-cells' ] '#clock-cells': [ clock-output-names ] required: @@ -301,3 +306,22 @@ examples: <&scmi_clk KEEM_BAY_PSS_SD0>; arasan,soc-ctl-syscon = <&sd0_phy_syscon>; }; + + - | + #define EMMC_XIN_CLK + #define EMMC_AXI_CLK + #define TBH_PSS_EMMC_RST_N + mmc@80420000 { + compatible = "intel,thunderbay-sdhci-5.1", "arasan,sdhci-5.1"; + interrupts = <GIC_SPI 714 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x80420000 0x400>; + clocks = <&scmi_clk EMMC_XIN_CLK>, + <&scmi_clk EMMC_AXI_CLK>; + clock-names = "clk_xin", "clk_ahb"; + phys = <&emmc_phy>; + phy-names = "phy_arasan"; + assigned-clocks = <&scmi_clk EMMC_XIN_CLK>; + clock-output-names = "emmc_cardclock"; + resets = <&rst_pss1 TBH_PSS_EMMC_RST_N>; + #clock-cells = <0x0>; + }; diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml index af7442f73881..4207fed62dfe 100644 --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml @@ -17,6 +17,7 @@ properties: compatible: items: - enum: + - microchip,mpfs-sd4hc - socionext,uniphier-sd4hc - const: cdns,sd4hc diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index a3412f221104..19621a2f8beb 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -34,6 +34,7 @@ properties: - fsl,imx6ull-usdhc - fsl,imx7d-usdhc - fsl,imx7ulp-usdhc + - nxp,s32g2-usdhc - items: - enum: - fsl,imx8mm-usdhc diff --git a/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml b/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml index 546480f41141..01d5c6da0eeb 100644 --- a/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml @@ -61,7 +61,7 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/jz4780-cgu.h> + #include <dt-bindings/clock/ingenic,jz4780-cgu.h> #include <dt-bindings/dma/jz4780-dma.h> mmc0: mmc@13450000 { compatible = "ingenic,jz4780-mmc"; diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.txt b/Documentation/devicetree/bindings/mmc/mmc-card.txt deleted file mode 100644 index 8d2d71758907..000000000000 --- a/Documentation/devicetree/bindings/mmc/mmc-card.txt +++ /dev/null @@ -1,30 +0,0 @@ -mmc-card / eMMC bindings ------------------------- - -This documents describes the devicetree bindings for a mmc-host controller -child node describing a mmc-card / an eMMC, see "Use of Function subnodes" -in mmc.txt - -Required properties: --compatible : Must be "mmc-card" --reg : Must be <0> - -Optional properties: --broken-hpi : Use this to indicate that the mmc-card has a broken hpi - implementation, and that hpi should not be used - -Example: - -&mmc2 { - pinctrl-names = "default"; - pinctrl-0 = <&mmc2_pins_a>; - vmmc-supply = <®_vcc3v3>; - bus-width = <8>; - non-removable; - - mmccard: mmccard@0 { - reg = <0>; - compatible = "mmc-card"; - broken-hpi; - }; -}; diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml new file mode 100644 index 000000000000..b17d454442b3 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mmc-card.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MMC Card / eMMC Generic Device Tree Bindings + +maintainers: + - Ulf Hansson <ulf.hansson@linaro.org> + +description: | + This documents describes the devicetree bindings for a mmc-host controller + child node describing a mmc-card / an eMMC. + +properties: + compatible: + const: mmc-card + + reg: + const: 0 + + broken-hpi: + $ref: /schemas/types.yaml#/definitions/flag + description: + Use this to indicate that the mmc-card has a broken hpi + implementation, and that hpi should not be used. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + mmc { + #address-cells = <1>; + #size-cells = <0>; + + card@0 { + compatible = "mmc-card"; + reg = <0>; + broken-hpi; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml index 25ac8e200970..513f3c8758aa 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml @@ -333,12 +333,6 @@ patternProperties: subnode describes. A value of 0 denotes the memory SD function, values from 1 to 7 denote the SDIO functions. - broken-hpi: - $ref: /schemas/types.yaml#/definitions/flag - description: - Use this to indicate that the mmc-card has a broken hpi - implementation, and that hpi should not be used. - required: - reg diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index e866e985549e..82768a807294 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -119,6 +119,18 @@ properties: If present, HS400 command responses are sampled on rising edges. If not present, HS400 command responses are sampled on falling edges. + mediatek,hs400-ds-dly3: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Gear of the third delay line for DS for input data latch in data + pad macro, there are 32 stages from 0 to 31. + For different corner IC, the time is different about one step, it is + about 100ps. + The value is confirmed by doing scan and calibration to find a best + value with corner IC and it is valid only for HS400 mode. + minimum: 0 + maximum: 31 + mediatek,latch-ck: $ref: /schemas/types.yaml#/definitions/uint32 description: diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt index 365c3fc122ea..50841e2843fc 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -13,6 +13,7 @@ Required properties: string is added to support this change - "qcom,sdhci-msm-v5". full compatible strings with SoC and version: "qcom,apq8084-sdhci", "qcom,sdhci-msm-v4" + "qcom,msm8226-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8974-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8916-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8992-sdhci", "qcom,sdhci-msm-v4" diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt index aeb615ef672a..f91e341e6b36 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt @@ -5,7 +5,11 @@ Refer to mmc.txt for standard MMC bindings. For UHS devices which require tuning, the device tree should have a "cpu_thermal" node which maps to the appropriate thermal zone. This is used to get the temperature of the zone during tuning. Required properties: -- compatible: Should be "ti,dra7-sdhci" for DRA7 and DRA72 controllers +- compatible: Should be "ti,omap2430-sdhci" for omap2430 controllers + Should be "ti,omap3-sdhci" for omap3 controllers + Should be "ti,omap4-sdhci" for omap4 and ti81 controllers + Should be "ti,omap5-sdhci" for omap5 controllers + Should be "ti,dra7-sdhci" for DRA7 and DRA72 controllers Should be "ti,k2g-sdhci" for K2G Should be "ti,am335-sdhci" for am335x controllers Should be "ti,am437-sdhci" for am437x controllers @@ -24,6 +28,9 @@ Optional properties: DMA specifiers listed in dmas. The string naming is to be "tx" and "rx" for TX and RX DMA requests, respectively. +Deprecated properties: +- ti,non-removable: Compatible with the generic non-removable property + Example: mmc1: mmc@4809c000 { compatible = "ti,dra7-sdhci"; diff --git a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml index e6c9a2f77cc7..f300ced4cdf3 100644 --- a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml @@ -20,9 +20,7 @@ properties: - snps,dwcmshc-sdhci reg: - minItems: 1 - items: - - description: Offset and length of the register set for the device + maxItems: 1 interrupts: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt deleted file mode 100644 index c459f169a904..000000000000 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ /dev/null @@ -1,147 +0,0 @@ -Device tree bindings for GPMC connected NANDs - -GPMC connected NAND (found on OMAP boards) are represented as child nodes of -the GPMC controller with a name of "nand". - -All timing relevant properties as well as generic gpmc child properties are -explained in a separate documents - please refer to -Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt - -For NAND specific properties such as ECC modes or bus width, please refer to -Documentation/devicetree/bindings/mtd/nand-controller.yaml - - -Required properties: - - - compatible: "ti,omap2-nand" - - reg: range id (CS number), base offset and length of the - NAND I/O space - - interrupts: Two interrupt specifiers, one for fifoevent, one for termcount. - -Optional properties: - - - nand-bus-width: Set this numeric value to 16 if the hardware - is wired that way. If not specified, a bus - width of 8 is assumed. - - - ti,nand-ecc-opt: A string setting the ECC layout to use. One of: - "sw" 1-bit Hamming ecc code via software - "hw" <deprecated> use "ham1" instead - "hw-romcode" <deprecated> use "ham1" instead - "ham1" 1-bit Hamming ecc code - "bch4" 4-bit BCH ecc code - "bch8" 8-bit BCH ecc code - "bch16" 16-bit BCH ECC code - Refer below "How to select correct ECC scheme for your device ?" - - - ti,nand-xfer-type: A string setting the data transfer type. One of: - - "prefetch-polled" Prefetch polled mode (default) - "polled" Polled mode, without prefetch - "prefetch-dma" Prefetch enabled DMA mode - "prefetch-irq" Prefetch enabled irq mode - - - elm_id: <deprecated> use "ti,elm-id" instead - - ti,elm-id: Specifies phandle of the ELM devicetree node. - ELM is an on-chip hardware engine on TI SoC which is used for - locating ECC errors for BCHx algorithms. SoC devices which have - ELM hardware engines should specify this device node in .dtsi - Using ELM for ECC error correction frees some CPU cycles. - - rb-gpios: GPIO specifier for the ready/busy# pin. - -For inline partition table parsing (optional): - - - #address-cells: should be set to 1 - - #size-cells: should be set to 1 - -Example for an AM33xx board: - - gpmc: gpmc@50000000 { - compatible = "ti,am3352-gpmc"; - ti,hwmods = "gpmc"; - reg = <0x50000000 0x36c>; - interrupts = <100>; - gpmc,num-cs = <8>; - gpmc,num-waitpins = <2>; - #address-cells = <2>; - #size-cells = <1>; - ranges = <0 0 0x08000000 0x1000000>; /* CS0 space, 16MB */ - elm_id = <&elm>; - interrupt-controller; - #interrupt-cells = <2>; - - nand@0,0 { - compatible = "ti,omap2-nand"; - reg = <0 0 4>; /* CS0, offset 0, NAND I/O window 4 */ - interrupt-parent = <&gpmc>; - interrupts = <0 IRQ_TYPE_NONE>, <1 IRQ_TYPE NONE>; - nand-bus-width = <16>; - ti,nand-ecc-opt = "bch8"; - ti,nand-xfer-type = "polled"; - rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */ - - gpmc,sync-clk-ps = <0>; - gpmc,cs-on-ns = <0>; - gpmc,cs-rd-off-ns = <44>; - gpmc,cs-wr-off-ns = <44>; - gpmc,adv-on-ns = <6>; - gpmc,adv-rd-off-ns = <34>; - gpmc,adv-wr-off-ns = <44>; - gpmc,we-off-ns = <40>; - gpmc,oe-off-ns = <54>; - gpmc,access-ns = <64>; - gpmc,rd-cycle-ns = <82>; - gpmc,wr-cycle-ns = <82>; - gpmc,wr-access-ns = <40>; - gpmc,wr-data-mux-bus-ns = <0>; - - #address-cells = <1>; - #size-cells = <1>; - - /* partitions go here */ - }; - }; - -How to select correct ECC scheme for your device ? --------------------------------------------------- -Higher ECC scheme usually means better protection against bit-flips and -increased system lifetime. However, selection of ECC scheme is dependent -on various other factors also like; - -(1) support of built in hardware engines. - Some legacy OMAP SoC do not have ELM harware engine, so those SoC cannot - support ecc-schemes with hardware error-correction (BCHx_HW). However - such SoC can use ecc-schemes with software library for error-correction - (BCHx_HW_DETECTION_SW). The error correction capability with software - library remains equivalent to their hardware counter-part, but there is - slight CPU penalty when too many bit-flips are detected during reads. - -(2) Device parameters like OOBSIZE. - Other factor which governs the selection of ecc-scheme is oob-size. - Higher ECC schemes require more OOB/Spare area to store ECC syndrome, - so the device should have enough free bytes available its OOB/Spare - area to accommodate ECC for entire page. In general following expression - helps in determining if given device can accommodate ECC syndrome: - "2 + (PAGESIZE / 512) * ECC_BYTES" <= OOBSIZE" - where - OOBSIZE number of bytes in OOB/spare area - PAGESIZE number of bytes in main-area of device page - ECC_BYTES number of ECC bytes generated to protect - 512 bytes of data, which is: - '3' for HAM1_xx ecc schemes - '7' for BCH4_xx ecc schemes - '14' for BCH8_xx ecc schemes - '26' for BCH16_xx ecc schemes - - Example(a): For a device with PAGESIZE = 2048 and OOBSIZE = 64 and - trying to use BCH16 (ECC_BYTES=26) ecc-scheme. - Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B - which is greater than capacity of NAND device (OOBSIZE=64) - Hence, BCH16 cannot be supported on given device. But it can - probably use lower ecc-schemes like BCH8. - - Example(b): For a device with PAGESIZE = 2048 and OOBSIZE = 128 and - trying to use BCH16 (ECC_BYTES=26) ecc-scheme. - Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B - which can be accommodated in the OOB/Spare area of this device - (OOBSIZE=128). So this device can use BCH16 ecc-scheme. diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt deleted file mode 100644 index 2133be0d52f2..000000000000 --- a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt +++ /dev/null @@ -1,98 +0,0 @@ -Device tree bindings for NOR flash connect to TI GPMC - -NOR flash connected to the TI GPMC (found on OMAP boards) are represented as -child nodes of the GPMC controller with a name of "nor". - -All timing relevant properties as well as generic GPMC child properties are -explained in a separate documents. Please refer to -Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt - -Required properties: -- bank-width: Width of NOR flash in bytes. GPMC supports 8-bit and - 16-bit devices and so must be either 1 or 2 bytes. -- compatible: Documentation/devicetree/bindings/mtd/mtd-physmap.yaml -- gpmc,cs-on-ns: Chip-select assertion time -- gpmc,cs-rd-off-ns: Chip-select de-assertion time for reads -- gpmc,cs-wr-off-ns: Chip-select de-assertion time for writes -- gpmc,oe-on-ns: Output-enable assertion time -- gpmc,oe-off-ns: Output-enable de-assertion time -- gpmc,we-on-ns Write-enable assertion time -- gpmc,we-off-ns: Write-enable de-assertion time -- gpmc,access-ns: Start cycle to first data capture (read access) -- gpmc,rd-cycle-ns: Total read cycle time -- gpmc,wr-cycle-ns: Total write cycle time -- linux,mtd-name: Documentation/devicetree/bindings/mtd/mtd-physmap.yaml -- reg: Chip-select, base address (relative to chip-select) - and size of NOR flash. Note that base address will be - typically 0 as this is the start of the chip-select. - -Optional properties: -- gpmc,XXX Additional GPMC timings and settings parameters. See - Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt - -Optional properties for partition table parsing: -- #address-cells: should be set to 1 -- #size-cells: should be set to 1 - -Example: - -gpmc: gpmc@6e000000 { - compatible = "ti,omap3430-gpmc", "simple-bus"; - ti,hwmods = "gpmc"; - reg = <0x6e000000 0x1000>; - interrupts = <20>; - gpmc,num-cs = <8>; - gpmc,num-waitpins = <4>; - #address-cells = <2>; - #size-cells = <1>; - - ranges = <0 0 0x10000000 0x08000000>; - - nor@0,0 { - compatible = "cfi-flash"; - linux,mtd-name= "intel,pf48f6000m0y1be"; - #address-cells = <1>; - #size-cells = <1>; - reg = <0 0 0x08000000>; - bank-width = <2>; - - gpmc,mux-add-data; - gpmc,cs-on-ns = <0>; - gpmc,cs-rd-off-ns = <186>; - gpmc,cs-wr-off-ns = <186>; - gpmc,adv-on-ns = <12>; - gpmc,adv-rd-off-ns = <48>; - gpmc,adv-wr-off-ns = <48>; - gpmc,oe-on-ns = <54>; - gpmc,oe-off-ns = <168>; - gpmc,we-on-ns = <54>; - gpmc,we-off-ns = <168>; - gpmc,rd-cycle-ns = <186>; - gpmc,wr-cycle-ns = <186>; - gpmc,access-ns = <114>; - gpmc,page-burst-access-ns = <6>; - gpmc,bus-turnaround-ns = <12>; - gpmc,cycle2cycle-delay-ns = <18>; - gpmc,wr-data-mux-bus-ns = <90>; - gpmc,wr-access-ns = <186>; - gpmc,cycle2cycle-samecsen; - gpmc,cycle2cycle-diffcsen; - - partition@0 { - label = "bootloader-nor"; - reg = <0 0x40000>; - }; - partition@40000 { - label = "params-nor"; - reg = <0x40000 0x40000>; - }; - partition@80000 { - label = "kernel-nor"; - reg = <0x80000 0x200000>; - }; - partition@280000 { - label = "filesystem-nor"; - reg = <0x240000 0x7d80000>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt deleted file mode 100644 index e9f01a963a0a..000000000000 --- a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt +++ /dev/null @@ -1,48 +0,0 @@ -Device tree bindings for GPMC connected OneNANDs - -GPMC connected OneNAND (found on OMAP boards) are represented as child nodes of -the GPMC controller with a name of "onenand". - -All timing relevant properties as well as generic gpmc child properties are -explained in a separate documents - please refer to -Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt - -Required properties: - - - compatible: "ti,omap2-onenand" - - reg: The CS line the peripheral is connected to - - gpmc,device-width: Width of the ONENAND device connected to the GPMC - in bytes. Must be 1 or 2. - -Optional properties: - - - int-gpios: GPIO specifier for the INT pin. - -For inline partition table parsing (optional): - - - #address-cells: should be set to 1 - - #size-cells: should be set to 1 - -Example for an OMAP3430 board: - - gpmc: gpmc@6e000000 { - compatible = "ti,omap3430-gpmc"; - ti,hwmods = "gpmc"; - reg = <0x6e000000 0x1000000>; - interrupts = <20>; - gpmc,num-cs = <8>; - gpmc,num-waitpins = <4>; - #address-cells = <2>; - #size-cells = <1>; - - onenand@0 { - compatible = "ti,omap2-onenand"; - reg = <0 0 0>; /* CS0, offset 0 */ - gpmc,device-width = <2>; - - #address-cells = <1>; - #size-cells = <1>; - - /* partitions go here */ - }; - }; diff --git a/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml b/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml index 89aa3ceda592..9de8ef6e59ca 100644 --- a/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml +++ b/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml @@ -55,7 +55,7 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/jz4780-cgu.h> + #include <dt-bindings/clock/ingenic,jz4780-cgu.h> memory-controller@13410000 { compatible = "ingenic,jz4780-nemc"; reg = <0x13410000 0x10000>; diff --git a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml index 29c5ef24ac6a..eab8ea3da1fa 100644 --- a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics Flexible Memory Controller 2 (FMC2) Bindings maintainers: - - Christophe Kerello <christophe.kerello@st.com> + - Christophe Kerello <christophe.kerello@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml b/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml new file mode 100644 index 000000000000..beb26b9bcfb2 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml @@ -0,0 +1,121 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/ti,gpmc-nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments GPMC NAND Flash controller. + +maintainers: + - Tony Lindgren <tony@atomide.com> + - Roger Quadros <rogerq@kernel.org> + +description: + GPMC NAND controller/Flash is represented as a child of the + GPMC controller node. + +properties: + compatible: + const: ti,omap2-nand + + reg: + maxItems: 1 + + interrupts: + items: + - description: Interrupt for fifoevent + - description: Interrupt for termcount + + "#address-cells": true + + "#size-cells": true + + ti,nand-ecc-opt: + description: Desired ECC algorithm + $ref: /schemas/types.yaml#/definitions/string + enum: [sw, ham1, bch4, bch8, bch16] + + ti,nand-xfer-type: + description: Data transfer method between controller and chip. + $ref: /schemas/types.yaml#/definitions/string + enum: [prefetch-polled, polled, prefetch-dma, prefetch-irq] + default: prefetch-polled + + ti,elm-id: + description: + phandle to the ELM (Error Location Module). + $ref: /schemas/types.yaml#/definitions/phandle + + nand-bus-width: + description: + Bus width to the NAND chip + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16] + default: 8 + +patternProperties: + "@[0-9a-f]+$": + $ref: "/schemas/mtd/partitions/partition.yaml" + +allOf: + - $ref: "/schemas/memory-controllers/ti,gpmc-child.yaml" + +required: + - compatible + - reg + - ti,nand-ecc-opt + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/gpio/gpio.h> + + gpmc: memory-controller@50000000 { + compatible = "ti,am3352-gpmc"; + dmas = <&edma 52 0>; + dma-names = "rxtx"; + clocks = <&l3s_gclk>; + clock-names = "fck"; + reg = <0x50000000 0x2000>; + interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>; + gpmc,num-cs = <7>; + gpmc,num-waitpins = <2>; + #address-cells = <2>; + #size-cells = <1>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-controller; + #gpio-cells = <2>; + + ranges = <0 0 0x08000000 0x01000000>; /* CS0 space. Min partition = 16MB */ + nand@0,0 { + compatible = "ti,omap2-nand"; + reg = <0 0 4>; /* device IO registers */ + interrupt-parent = <&gpmc>; + interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */ + <1 IRQ_TYPE_NONE>; /* termcount */ + ti,nand-xfer-type = "prefetch-dma"; + ti,nand-ecc-opt = "bch16"; + ti,elm-id = <&elm>; + #address-cells = <1>; + #size-cells = <1>; + + /* NAND generic properties */ + nand-bus-width = <8>; + rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */ + + /* GPMC properties*/ + gpmc,device-width = <1>; + + partition@0 { + label = "NAND.SPL"; + reg = <0x00000000 0x00040000>; + }; + partition@1 { + label = "NAND.SPL.backup1"; + reg = <0x00040000 0x00040000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml b/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml new file mode 100644 index 000000000000..a953f7397c40 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/ti,gpmc-onenand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OneNAND over Texas Instruments GPMC bus. + +maintainers: + - Tony Lindgren <tony@atomide.com> + - Roger Quadros <rogerq@kernel.org> + +description: + GPMC connected OneNAND (found on OMAP boards) are represented + as child nodes of the GPMC controller. + +properties: + compatible: + const: ti,omap2-onenand + + reg: + items: + - description: | + Chip Select number, register offset and size of + OneNAND register window. + + "#address-cells": true + + "#size-cells": true + + int-gpios: + description: GPIO specifier for the INT pin. + +patternProperties: + "@[0-9a-f]+$": + $ref: "/schemas/mtd/partitions/partition.yaml" + +allOf: + - $ref: "/schemas/memory-controllers/ti,gpmc-child.yaml" + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +unevaluatedProperties: false + +examples: + - | + gpmc: memory-controller@6e000000 { + compatible = "ti,omap3430-gpmc"; + reg = <0x6e000000 0x02d0>; + interrupts = <20>; + gpmc,num-cs = <8>; + gpmc,num-waitpins = <4>; + clocks = <&l3s_clkctrl>; + clock-names = "fck"; + #address-cells = <2>; + #size-cells = <1>; + + ranges = <0 0 0x01000000 0x01000000>, /* 16 MB for OneNAND */ + <1 0 0x02000000 0x01000000>; /* 16 MB for smc91c96 */ + + onenand@0,0 { + compatible = "ti,omap2-onenand"; + reg = <0 0 0x20000>; /* CS0, offset 0, IO size 128K */ + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "bootloader"; + reg = <0x00000000 0x00100000>; + }; + + partition@100000 { + label = "config"; + reg = <0x00100000 0x002c0000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml index 9eb4bb529ad5..407586bc366b 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml @@ -15,7 +15,7 @@ properties: oneOf: - const: allwinner,sun8i-a83t-emac - const: allwinner,sun8i-h3-emac - - const: allwinner,sun8i-r40-emac + - const: allwinner,sun8i-r40-gmac - const: allwinner,sun8i-v3s-emac - const: allwinner,sun50i-a64-emac - items: @@ -93,7 +93,7 @@ allOf: compatible: contains: enum: - - allwinner,sun8i-r40-emac + - allwinner,sun8i-r40-gmac then: properties: diff --git a/Documentation/devicetree/bindings/net/asix,ax88796c.yaml b/Documentation/devicetree/bindings/net/asix,ax88796c.yaml new file mode 100644 index 000000000000..699ebf452479 --- /dev/null +++ b/Documentation/devicetree/bindings/net/asix,ax88796c.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/asix,ax88796c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASIX AX88796C SPI Ethernet Adapter + +maintainers: + - Łukasz Stelmach <l.stelmach@samsung.com> + +description: | + ASIX AX88796C is an Ethernet controller with a built in PHY. This + describes SPI mode of the chip. + + The node for this driver must be a child node of an SPI controller, + hence all mandatory properties described in + ../spi/spi-controller.yaml must be specified. + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + const: asix,ax88796c + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 40000000 + + interrupts: + maxItems: 1 + + reset-gpios: + description: + A GPIO line handling reset of the chip. As the line is active low, + it should be marked GPIO_ACTIVE_LOW. + maxItems: 1 + + local-mac-address: true + + mac-address: true + +required: + - compatible + - reg + - spi-max-frequency + - interrupts + - reset-gpios + +additionalProperties: false + +examples: + # Artik5 eval board + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + ethernet@0 { + compatible = "asix,ax88796c"; + reg = <0x0>; + local-mac-address = [00 00 00 00 00 00]; /* Filled in by a bootloader */ + interrupt-parent = <&gpx2>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + spi-max-frequency = <40000000>; + reset-gpios = <&gpe0 2 GPIO_ACTIVE_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/brcm,bcmgenet.txt b/Documentation/devicetree/bindings/net/brcm,bcmgenet.txt index 33a0d67e4ce5..0b5994fba35f 100644 --- a/Documentation/devicetree/bindings/net/brcm,bcmgenet.txt +++ b/Documentation/devicetree/bindings/net/brcm,bcmgenet.txt @@ -2,7 +2,8 @@ Required properties: - compatible: should contain one of "brcm,genet-v1", "brcm,genet-v2", - "brcm,genet-v3", "brcm,genet-v4", "brcm,genet-v5", "brcm,bcm2711-genet-v5". + "brcm,genet-v3", "brcm,genet-v4", "brcm,genet-v5", "brcm,bcm2711-genet-v5" or + "brcm,bcm7712-genet-v5". - reg: address and length of the register set for the device - interrupts and/or interrupts-extended: must be two cells, the first cell is the general purpose interrupt line, while the second cell is the diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml index fbdc2083bec4..5aac094fd217 100644 --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml @@ -50,16 +50,29 @@ properties: by interrupts and "host-wakeup" interrupt-names clocks: + minItems: 1 maxItems: 2 description: 1 or 2 clocks as defined in clock-names below, in that order clock-names: description: Names of the 1 to 2 supplied clocks - items: + oneOf: + - const: extclk + deprecated: true + description: Deprecated in favor of txco + - const: txco + description: > + external reference clock (not a standalone crystal) + - const: lpo - - const: extclk + description: > + external low power 32.768 kHz clock + + - items: + - const: txco + - const: lpo vbat-supply: description: phandle to regulator supply for VBAT diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml index 16aa192c118e..2ad7f79ad371 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml @@ -46,6 +46,9 @@ patternProperties: type: object description: Ethernet switch ports + allOf: + - $ref: "http://devicetree.org/schemas/net/ethernet-controller.yaml#" + properties: reg: description: Port number @@ -73,11 +76,14 @@ patternProperties: dsa-tag-protocol: description: Instead of the default, the switch will use this tag protocol if - possible. Useful when a device supports multiple protcols and + possible. Useful when a device supports multiple protocols and the default is incompatible with the Ethernet device. enum: - dsa - edsa + - ocelot + - ocelot-8021q + - seville phy-handle: true @@ -91,6 +97,10 @@ patternProperties: managed: true + rx-internal-delay-ps: true + + tx-internal-delay-ps: true + required: - reg diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt b/Documentation/devicetree/bindings/net/dsa/marvell.txt index 30c11fea491b..2363b412410c 100644 --- a/Documentation/devicetree/bindings/net/dsa/marvell.txt +++ b/Documentation/devicetree/bindings/net/dsa/marvell.txt @@ -83,7 +83,7 @@ Example: #interrupt-cells = <2>; switch0: switch@0 { - compatible = "marvell,mv88e6390"; + compatible = "marvell,mv88e6190"; reg = <0>; reset-gpios = <&gpio5 1 GPIO_ACTIVE_LOW>; diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml index f978f8719d8e..24cd733c11d1 100644 --- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml @@ -74,10 +74,42 @@ properties: - compatible - reg +patternProperties: + "^(ethernet-)?ports$": + patternProperties: + "^(ethernet-)?port@[0-9]+$": + allOf: + - if: + properties: + phy-mode: + contains: + enum: + - rgmii + - rgmii-rxid + - rgmii-txid + - rgmii-id + then: + properties: + rx-internal-delay-ps: + $ref: "#/$defs/internal-delay-ps" + tx-internal-delay-ps: + $ref: "#/$defs/internal-delay-ps" + required: - compatible - reg +$defs: + internal-delay-ps: + description: + Disable tunable delay lines using 0 ps, or enable them and select + the phase between 1640 ps (73.8 degree shift at 1Gbps) and 2260 ps + (101.7 degree shift) in increments of 0.9 degrees (20 ps). + enum: + [0, 1640, 1660, 1680, 1700, 1720, 1740, 1760, 1780, 1800, 1820, 1840, + 1860, 1880, 1900, 1920, 1940, 1960, 1980, 2000, 2020, 2040, 2060, 2080, + 2100, 2120, 2140, 2160, 2180, 2200, 2220, 2240, 2260] + unevaluatedProperties: false examples: @@ -97,29 +129,40 @@ examples: port@0 { phy-handle = <&rgmii_phy6>; phy-mode = "rgmii-id"; + rx-internal-delay-ps = <0>; + tx-internal-delay-ps = <0>; reg = <0>; }; port@1 { phy-handle = <&rgmii_phy3>; phy-mode = "rgmii-id"; + rx-internal-delay-ps = <0>; + tx-internal-delay-ps = <0>; reg = <1>; }; port@2 { phy-handle = <&rgmii_phy4>; phy-mode = "rgmii-id"; + rx-internal-delay-ps = <0>; + tx-internal-delay-ps = <0>; reg = <2>; }; port@3 { + phy-handle = <&rgmii_phy4>; phy-mode = "rgmii-id"; + rx-internal-delay-ps = <0>; + tx-internal-delay-ps = <0>; reg = <3>; }; port@4 { ethernet = <&enet2>; phy-mode = "rgmii"; + rx-internal-delay-ps = <0>; + tx-internal-delay-ps = <0>; reg = <4>; fixed-link { diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.txt b/Documentation/devicetree/bindings/net/dsa/qca8k.txt deleted file mode 100644 index 8c73f67c43ca..000000000000 --- a/Documentation/devicetree/bindings/net/dsa/qca8k.txt +++ /dev/null @@ -1,215 +0,0 @@ -* Qualcomm Atheros QCA8xxx switch family - -Required properties: - -- compatible: should be one of: - "qca,qca8327" - "qca,qca8334" - "qca,qca8337" - -- #size-cells: must be 0 -- #address-cells: must be 1 - -Optional properties: - -- reset-gpios: GPIO to be used to reset the whole device - -Subnodes: - -The integrated switch subnode should be specified according to the binding -described in dsa/dsa.txt. If the QCA8K switch is connect to a SoC's external -mdio-bus each subnode describing a port needs to have a valid phandle -referencing the internal PHY it is connected to. This is because there's no -N:N mapping of port and PHY id. -To declare the internal mdio-bus configuration, declare a mdio node in the -switch node and declare the phandle for the port referencing the internal -PHY is connected to. In this config a internal mdio-bus is registered and -the mdio MASTER is used as communication. - -Don't use mixed external and internal mdio-bus configurations, as this is -not supported by the hardware. - -The CPU port of this switch is always port 0. - -A CPU port node has the following optional node: - -- fixed-link : Fixed-link subnode describing a link to a non-MDIO - managed entity. See - Documentation/devicetree/bindings/net/fixed-link.txt - for details. - -For QCA8K the 'fixed-link' sub-node supports only the following properties: - -- 'speed' (integer, mandatory), to indicate the link speed. Accepted - values are 10, 100 and 1000 -- 'full-duplex' (boolean, optional), to indicate that full duplex is - used. When absent, half duplex is assumed. - -Examples: - -for the external mdio-bus configuration: - - &mdio0 { - phy_port1: phy@0 { - reg = <0>; - }; - - phy_port2: phy@1 { - reg = <1>; - }; - - phy_port3: phy@2 { - reg = <2>; - }; - - phy_port4: phy@3 { - reg = <3>; - }; - - phy_port5: phy@4 { - reg = <4>; - }; - - switch@10 { - compatible = "qca,qca8337"; - #address-cells = <1>; - #size-cells = <0>; - - reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>; - reg = <0x10>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - label = "cpu"; - ethernet = <&gmac1>; - phy-mode = "rgmii"; - fixed-link { - speed = 1000; - full-duplex; - }; - }; - - port@1 { - reg = <1>; - label = "lan1"; - phy-handle = <&phy_port1>; - }; - - port@2 { - reg = <2>; - label = "lan2"; - phy-handle = <&phy_port2>; - }; - - port@3 { - reg = <3>; - label = "lan3"; - phy-handle = <&phy_port3>; - }; - - port@4 { - reg = <4>; - label = "lan4"; - phy-handle = <&phy_port4>; - }; - - port@5 { - reg = <5>; - label = "wan"; - phy-handle = <&phy_port5>; - }; - }; - }; - }; - -for the internal master mdio-bus configuration: - - &mdio0 { - switch@10 { - compatible = "qca,qca8337"; - #address-cells = <1>; - #size-cells = <0>; - - reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>; - reg = <0x10>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - label = "cpu"; - ethernet = <&gmac1>; - phy-mode = "rgmii"; - fixed-link { - speed = 1000; - full-duplex; - }; - }; - - port@1 { - reg = <1>; - label = "lan1"; - phy-mode = "internal"; - phy-handle = <&phy_port1>; - }; - - port@2 { - reg = <2>; - label = "lan2"; - phy-mode = "internal"; - phy-handle = <&phy_port2>; - }; - - port@3 { - reg = <3>; - label = "lan3"; - phy-mode = "internal"; - phy-handle = <&phy_port3>; - }; - - port@4 { - reg = <4>; - label = "lan4"; - phy-mode = "internal"; - phy-handle = <&phy_port4>; - }; - - port@5 { - reg = <5>; - label = "wan"; - phy-mode = "internal"; - phy-handle = <&phy_port5>; - }; - }; - - mdio { - #address-cells = <1>; - #size-cells = <0>; - - phy_port1: phy@0 { - reg = <0>; - }; - - phy_port2: phy@1 { - reg = <1>; - }; - - phy_port3: phy@2 { - reg = <2>; - }; - - phy_port4: phy@3 { - reg = <3>; - }; - - phy_port5: phy@4 { - reg = <4>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml new file mode 100644 index 000000000000..48de0ace265d --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml @@ -0,0 +1,362 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/qca8k.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Atheros QCA83xx switch family + +maintainers: + - John Crispin <john@phrozen.org> + +description: + If the QCA8K switch is connect to an SoC's external mdio-bus, each subnode + describing a port needs to have a valid phandle referencing the internal PHY + it is connected to. This is because there is no N:N mapping of port and PHY + ID. To declare the internal mdio-bus configuration, declare an MDIO node in + the switch node and declare the phandle for the port, referencing the internal + PHY it is connected to. In this config, an internal mdio-bus is registered and + the MDIO master is used for communication. Mixed external and internal + mdio-bus configurations are not supported by the hardware. + +properties: + compatible: + oneOf: + - enum: + - qca,qca8327 + - qca,qca8328 + - qca,qca8334 + - qca,qca8337 + description: | + qca,qca8328: referenced as AR8328(N)-AK1(A/B) QFN 176 pin package + qca,qca8327: referenced as AR8327(N)-AL1A DR-QFN 148 pin package + qca,qca8334: referenced as QCA8334-AL3C QFN 88 pin package + qca,qca8337: referenced as QCA8337N-AL3(B/C) DR-QFN 148 pin package + + reg: + maxItems: 1 + + reset-gpios: + description: + GPIO to be used to reset the whole device + maxItems: 1 + + qca,ignore-power-on-sel: + $ref: /schemas/types.yaml#/definitions/flag + description: + Ignore power-on pin strapping to configure LED open-drain or EEPROM + presence. This is needed for devices with incorrect configuration or when + the OEM has decided not to use pin strapping and falls back to SW regs. + + qca,led-open-drain: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set LEDs to open-drain mode. This requires the qca,ignore-power-on-sel to + be set, otherwise the driver will fail at probe. This is required if the + OEM does not use pin strapping to set this mode and prefers to set it + using SW regs. The pin strappings related to LED open-drain mode are + B68 on the QCA832x and B49 on the QCA833x. + + mdio: + type: object + description: Qca8k switch have an internal mdio to access switch port. + If this is not present, the legacy mapping is used and the + internal mdio access is used. + With the legacy mapping the reg corresponding to the internal + mdio is the switch reg with an offset of -1. + + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + patternProperties: + "^(ethernet-)?phy@[0-4]$": + type: object + + allOf: + - $ref: "http://devicetree.org/schemas/net/mdio.yaml#" + + properties: + reg: + maxItems: 1 + + required: + - reg + +patternProperties: + "^(ethernet-)?ports$": + type: object + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + patternProperties: + "^(ethernet-)?port@[0-6]$": + type: object + description: Ethernet switch ports + + properties: + reg: + description: Port number + + label: + description: + Describes the label associated with this port, which will become + the netdev name + $ref: /schemas/types.yaml#/definitions/string + + link: + description: + Should be a list of phandles to other switch's DSA port. This + port is used as the outgoing port towards the phandle ports. The + full routing information must be given, not just the one hop + routes to neighbouring switches + $ref: /schemas/types.yaml#/definitions/phandle-array + + ethernet: + description: + Should be a phandle to a valid Ethernet device node. This host + device is what the switch port is connected to + $ref: /schemas/types.yaml#/definitions/phandle + + phy-handle: true + + phy-mode: true + + fixed-link: true + + mac-address: true + + sfp: true + + qca,sgmii-rxclk-falling-edge: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set the receive clock phase to falling edge. Mostly commonly used on + the QCA8327 with CPU port 0 set to SGMII. + + qca,sgmii-txclk-falling-edge: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set the transmit clock phase to falling edge. + + qca,sgmii-enable-pll: + $ref: /schemas/types.yaml#/definitions/flag + description: + For SGMII CPU port, explicitly enable PLL, TX and RX chain along with + Signal Detection. On the QCA8327 this should not be enabled, otherwise + the SGMII port will not initialize. When used on the QCA8337, revision 3 + or greater, a warning will be displayed. When the CPU port is set to + SGMII on the QCA8337, it is advised to set this unless a communication + issue is observed. + + required: + - reg + + additionalProperties: false + +oneOf: + - required: + - ports + - required: + - ethernet-ports + +required: + - compatible + - reg + +additionalProperties: true + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + external_phy_port1: ethernet-phy@0 { + reg = <0>; + }; + + external_phy_port2: ethernet-phy@1 { + reg = <1>; + }; + + external_phy_port3: ethernet-phy@2 { + reg = <2>; + }; + + external_phy_port4: ethernet-phy@3 { + reg = <3>; + }; + + external_phy_port5: ethernet-phy@4 { + reg = <4>; + }; + + switch@10 { + compatible = "qca,qca8337"; + #address-cells = <1>; + #size-cells = <0>; + reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>; + reg = <0x10>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "cpu"; + ethernet = <&gmac1>; + phy-mode = "rgmii"; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + + port@1 { + reg = <1>; + label = "lan1"; + phy-handle = <&external_phy_port1>; + }; + + port@2 { + reg = <2>; + label = "lan2"; + phy-handle = <&external_phy_port2>; + }; + + port@3 { + reg = <3>; + label = "lan3"; + phy-handle = <&external_phy_port3>; + }; + + port@4 { + reg = <4>; + label = "lan4"; + phy-handle = <&external_phy_port4>; + }; + + port@5 { + reg = <5>; + label = "wan"; + phy-handle = <&external_phy_port5>; + }; + }; + }; + }; + - | + #include <dt-bindings/gpio/gpio.h> + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + switch@10 { + compatible = "qca,qca8337"; + #address-cells = <1>; + #size-cells = <0>; + reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>; + reg = <0x10>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "cpu"; + ethernet = <&gmac1>; + phy-mode = "rgmii"; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + + port@1 { + reg = <1>; + label = "lan1"; + phy-mode = "internal"; + phy-handle = <&internal_phy_port1>; + }; + + port@2 { + reg = <2>; + label = "lan2"; + phy-mode = "internal"; + phy-handle = <&internal_phy_port2>; + }; + + port@3 { + reg = <3>; + label = "lan3"; + phy-mode = "internal"; + phy-handle = <&internal_phy_port3>; + }; + + port@4 { + reg = <4>; + label = "lan4"; + phy-mode = "internal"; + phy-handle = <&internal_phy_port4>; + }; + + port@5 { + reg = <5>; + label = "wan"; + phy-mode = "internal"; + phy-handle = <&internal_phy_port5>; + }; + + port@6 { + reg = <0>; + label = "cpu"; + ethernet = <&gmac1>; + phy-mode = "sgmii"; + + qca,sgmii-rxclk-falling-edge; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + internal_phy_port1: ethernet-phy@0 { + reg = <0>; + }; + + internal_phy_port2: ethernet-phy@1 { + reg = <1>; + }; + + internal_phy_port3: ethernet-phy@2 { + reg = <2>; + }; + + internal_phy_port4: ethernet-phy@3 { + reg = <3>; + }; + + internal_phy_port5: ethernet-phy@4 { + reg = <4>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt index b6ae8541bd55..7959ec237983 100644 --- a/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt +++ b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt @@ -9,6 +9,7 @@ SMI-based Realtek devices. Required properties: - compatible: must be exactly one of: + "realtek,rtl8365mb" (4+1 ports) "realtek,rtl8366" "realtek,rtl8366rb" (4+1 ports) "realtek,rtl8366s" (4+1 ports) @@ -62,6 +63,8 @@ and subnodes of DSA switches. Examples: +An example for the RTL8366RB: + switch { compatible = "realtek,rtl8366rb"; /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */ @@ -151,3 +154,87 @@ switch { }; }; }; + +An example for the RTL8365MB-VC: + +switch { + compatible = "realtek,rtl8365mb"; + mdc-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>; + mdio-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>; + + switch_intc: interrupt-controller { + interrupt-parent = <&gpio5>; + interrupts = <1 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + port@0 { + reg = <0>; + label = "swp0"; + phy-handle = <ðphy0>; + }; + port@1 { + reg = <1>; + label = "swp1"; + phy-handle = <ðphy1>; + }; + port@2 { + reg = <2>; + label = "swp2"; + phy-handle = <ðphy2>; + }; + port@3 { + reg = <3>; + label = "swp3"; + phy-handle = <ðphy3>; + }; + port@6 { + reg = <6>; + label = "cpu"; + ethernet = <&fec1>; + phy-mode = "rgmii"; + tx-internal-delay-ps = <2000>; + rx-internal-delay-ps = <2000>; + + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + }; + + mdio { + compatible = "realtek,smi-mdio"; + #address-cells = <1>; + #size-cells = <0>; + + ethphy0: phy@0 { + reg = <0>; + interrupt-parent = <&switch_intc>; + interrupts = <0>; + }; + ethphy1: phy@1 { + reg = <1>; + interrupt-parent = <&switch_intc>; + interrupts = <1>; + }; + ethphy2: phy@2 { + reg = <2>; + interrupt-parent = <&switch_intc>; + interrupts = <2>; + }; + ethphy3: phy@3 { + reg = <3>; + interrupt-parent = <&switch_intc>; + interrupts = <3>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt deleted file mode 100644 index 32821066a85b..000000000000 --- a/Documentation/devicetree/bindings/net/gpmc-eth.txt +++ /dev/null @@ -1,97 +0,0 @@ -Device tree bindings for Ethernet chip connected to TI GPMC - -Besides being used to interface with external memory devices, the -General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices -such as ethernet controllers to processors using the TI GPMC as a data bus. - -Ethernet controllers connected to TI GPMC are represented as child nodes of -the GPMC controller with an "ethernet" name. - -All timing relevant properties as well as generic GPMC child properties are -explained in a separate documents. Please refer to -Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt - -For the properties relevant to the ethernet controller connected to the GPMC -refer to the binding documentation of the device. For example, the documentation -for the SMSC 911x is Documentation/devicetree/bindings/net/smsc,lan9115.yaml - -Child nodes need to specify the GPMC bus address width using the "bank-width" -property but is possible that an ethernet controller also has a property to -specify the I/O registers address width. Even when the GPMC has a maximum 16-bit -address width, it supports devices with 32-bit word registers. -For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an -OMAP2+ board, "bank-width = <2>;" and "reg-io-width = <4>;". - -Required properties: -- bank-width: Address width of the device in bytes. GPMC supports 8-bit - and 16-bit devices and so must be either 1 or 2 bytes. -- compatible: Compatible string property for the ethernet child device. -- gpmc,cs-on-ns: Chip-select assertion time -- gpmc,cs-rd-off-ns: Chip-select de-assertion time for reads -- gpmc,cs-wr-off-ns: Chip-select de-assertion time for writes -- gpmc,oe-on-ns: Output-enable assertion time -- gpmc,oe-off-ns: Output-enable de-assertion time -- gpmc,we-on-ns: Write-enable assertion time -- gpmc,we-off-ns: Write-enable de-assertion time -- gpmc,access-ns: Start cycle to first data capture (read access) -- gpmc,rd-cycle-ns: Total read cycle time -- gpmc,wr-cycle-ns: Total write cycle time -- reg: Chip-select, base address (relative to chip-select) - and size of the memory mapped for the device. - Note that base address will be typically 0 as this - is the start of the chip-select. - -Optional properties: -- gpmc,XXX Additional GPMC timings and settings parameters. See - Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt - -Example: - -gpmc: gpmc@6e000000 { - compatible = "ti,omap3430-gpmc"; - ti,hwmods = "gpmc"; - reg = <0x6e000000 0x1000>; - interrupts = <20>; - gpmc,num-cs = <8>; - gpmc,num-waitpins = <4>; - #address-cells = <2>; - #size-cells = <1>; - - ranges = <5 0 0x2c000000 0x1000000>; - - ethernet@5,0 { - compatible = "smsc,lan9221", "smsc,lan9115"; - reg = <5 0 0xff>; - bank-width = <2>; - - gpmc,mux-add-data; - gpmc,cs-on-ns = <0>; - gpmc,cs-rd-off-ns = <186>; - gpmc,cs-wr-off-ns = <186>; - gpmc,adv-on-ns = <12>; - gpmc,adv-rd-off-ns = <48>; - gpmc,adv-wr-off-ns = <48>; - gpmc,oe-on-ns = <54>; - gpmc,oe-off-ns = <168>; - gpmc,we-on-ns = <54>; - gpmc,we-off-ns = <168>; - gpmc,rd-cycle-ns = <186>; - gpmc,wr-cycle-ns = <186>; - gpmc,access-ns = <114>; - gpmc,page-burst-access-ns = <6>; - gpmc,bus-turnaround-ns = <12>; - gpmc,cycle2cycle-delay-ns = <18>; - gpmc,wr-data-mux-bus-ns = <90>; - gpmc,wr-access-ns = <186>; - gpmc,cycle2cycle-samecsen; - gpmc,cycle2cycle-diffcsen; - - interrupt-parent = <&gpio6>; - interrupts = <16>; - vmmc-supply = <&vddvario>; - vmmc_aux-supply = <&vdd33a>; - reg-io-width = <4>; - - smsc,save-mac-address; - }; -}; diff --git a/Documentation/devicetree/bindings/net/ingenic,mac.yaml b/Documentation/devicetree/bindings/net/ingenic,mac.yaml index d08a88125a5c..8e52b2e683b8 100644 --- a/Documentation/devicetree/bindings/net/ingenic,mac.yaml +++ b/Documentation/devicetree/bindings/net/ingenic,mac.yaml @@ -58,7 +58,7 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/x1000-cgu.h> + #include <dt-bindings/clock/ingenic,x1000-cgu.h> mac: ethernet@134b0000 { compatible = "ingenic,x1000-mac"; diff --git a/Documentation/devicetree/bindings/net/lantiq,etop-xway.yaml b/Documentation/devicetree/bindings/net/lantiq,etop-xway.yaml new file mode 100644 index 000000000000..437502c5ca96 --- /dev/null +++ b/Documentation/devicetree/bindings/net/lantiq,etop-xway.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/lantiq,etop-xway.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Lantiq Xway ETOP Ethernet driver + +maintainers: + - John Crispin <john@phrozen.org> + +properties: + $nodename: + pattern: "^ethernet@[0-9a-f]+$" + + compatible: + const: lantiq,etop-xway + + reg: + maxItems: 1 + + interrupts: + items: + - description: TX interrupt + - description: RX interrupt + + interrupt-names: + items: + - const: tx + - const: rx + + lantiq,tx-burst-length: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + TX programmable burst length. + enum: [2, 4, 8] + + lantiq,rx-burst-length: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + RX programmable burst length. + enum: [2, 4, 8] + + phy-mode: true + +required: + - compatible + - reg + - interrupt-parent + - interrupts + - interrupt-names + - lantiq,tx-burst-length + - lantiq,rx-burst-length + - phy-mode + +additionalProperties: false + +examples: + - | + ethernet@e180000 { + compatible = "lantiq,etop-xway"; + reg = <0xe180000 0x40000>; + interrupt-parent = <&icu0>; + interrupts = <73>, <78>; + interrupt-names = "tx", "rx"; + lantiq,tx-burst-length = <8>; + lantiq,rx-burst-length = <8>; + phy-mode = "rmii"; + }; diff --git a/Documentation/devicetree/bindings/net/lantiq,xrx200-net.txt b/Documentation/devicetree/bindings/net/lantiq,xrx200-net.txt deleted file mode 100644 index 5ff5e68bbbb6..000000000000 --- a/Documentation/devicetree/bindings/net/lantiq,xrx200-net.txt +++ /dev/null @@ -1,21 +0,0 @@ -Lantiq xRX200 GSWIP PMAC Ethernet driver -================================== - -Required properties: - -- compatible : "lantiq,xrx200-net" for the PMAC of the embedded - : GSWIP in the xXR200 -- reg : memory range of the PMAC core inside of the GSWIP core -- interrupts : TX and RX DMA interrupts. Use interrupt-names "tx" for - : the TX interrupt and "rx" for the RX interrupt. - -Example: - -ethernet@e10b308 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "lantiq,xrx200-net"; - reg = <0xe10b308 0xcf8>; - interrupts = <73>, <72>; - interrupt-names = "tx", "rx"; -}; diff --git a/Documentation/devicetree/bindings/net/lantiq,xrx200-net.yaml b/Documentation/devicetree/bindings/net/lantiq,xrx200-net.yaml new file mode 100644 index 000000000000..7bc074a42369 --- /dev/null +++ b/Documentation/devicetree/bindings/net/lantiq,xrx200-net.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/lantiq,xrx200-net.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Lantiq xRX200 GSWIP PMAC Ethernet driver + +maintainers: + - Hauke Mehrtens <hauke@hauke-m.de> + +properties: + $nodename: + pattern: "^ethernet@[0-9a-f]+$" + + compatible: + const: lantiq,xrx200-net + + reg: + maxItems: 1 + + interrupts: + items: + - description: TX interrupt + - description: RX interrupt + + interrupt-names: + items: + - const: tx + - const: rx + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +required: + - compatible + - reg + - interrupt-parent + - interrupts + - interrupt-names + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + ethernet@e10b308 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "lantiq,xrx200-net"; + reg = <0xe10b308 0xcf8>; + interrupt-parent = <&icu0>; + interrupts = <73>, <72>; + interrupt-names = "tx", "rx"; + }; diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index af9df2f01a1c..a1b06fd1962e 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -30,6 +30,10 @@ Required properties: Optional elements: 'tsu_clk' - clocks: Phandles to input clocks. +Optional properties: +- mdio: node containing PHY children. If this node is not present, then PHYs + will be direct children. + The MAC address will be determined using the optional properties defined in ethernet.txt. diff --git a/Documentation/devicetree/bindings/net/marvell-bluetooth.txt b/Documentation/devicetree/bindings/net/marvell-bluetooth.txt deleted file mode 100644 index 0e2842296032..000000000000 --- a/Documentation/devicetree/bindings/net/marvell-bluetooth.txt +++ /dev/null @@ -1,25 +0,0 @@ -Marvell Bluetooth Chips ------------------------ - -This documents the binding structure and common properties for serial -attached Marvell Bluetooth devices. The following chips are included in -this binding: - -* Marvell 88W8897 Bluetooth devices - -Required properties: - - compatible: should be: - "mrvl,88w8897" - -Optional properties: -None so far - -Example: - -&serial0 { - compatible = "ns16550a"; - ... - bluetooth { - compatible = "mrvl,88w8897"; - }; -}; diff --git a/Documentation/devicetree/bindings/net/marvell-bluetooth.yaml b/Documentation/devicetree/bindings/net/marvell-bluetooth.yaml new file mode 100644 index 000000000000..309ef21a1e37 --- /dev/null +++ b/Documentation/devicetree/bindings/net/marvell-bluetooth.yaml @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/net/marvell-bluetooth.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Marvell Bluetooth chips + +description: | + This documents the binding structure and common properties for serial + attached Marvell Bluetooth devices. + +maintainers: + - Rob Herring <robh@kernel.org> + +properties: + compatible: + const: mrvl,88w8897 + +required: + - compatible + +additionalProperties: false + +examples: + - | + serial { + bluetooth { + compatible = "mrvl,88w8897"; + }; + }; diff --git a/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml new file mode 100644 index 000000000000..15a45db3899a --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml @@ -0,0 +1,170 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nfc/marvell,nci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell International Ltd. NCI NFC controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + enum: + - marvell,nfc-i2c + - marvell,nfc-spi + - marvell,nfc-uart + + hci-muxed: + type: boolean + description: | + Specifies that the chip is muxing NCI over HCI frames + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + reset-n-io: + $ref: "/schemas/types.yaml#/definitions/phandle-array" + maxItems: 1 + description: | + Output GPIO pin used to reset the chip (active low) + + i2c-int-falling: + type: boolean + description: | + For I2C type of connection. Specifies that the chip read event shall be + trigged on falling edge. + + i2c-int-rising: + type: boolean + description: | + For I2C type of connection. Specifies that the chip read event shall be + trigged on rising edge. + + break-control: + type: boolean + description: | + For UART type of connection. Specifies that the chip needs specific break + management. + + flow-control: + type: boolean + description: | + For UART type of connection. Specifies that the chip is using RTS/CTS. + + spi-cpha: true + spi-cpol: true + spi-max-frequency: true + +required: + - compatible + +allOf: + - if: + properties: + compatible: + contains: + const: marvell,nfc-i2c + then: + properties: + break-control: false + flow-control: false + spi-cpha: false + spi-cpol: false + spi-max-frequency: false + required: + - reg + + - if: + properties: + compatible: + contains: + const: marvell,nfc-spi + then: + properties: + break-control: false + flow-control: false + i2c-int-falling: false + i2c-int-rising: false + required: + - reg + + - if: + properties: + compatible: + contains: + const: marvell,nfc-uart + then: + properties: + i2c-int-falling: false + i2c-int-rising: false + interrupts: false + spi-cpha: false + spi-cpol: false + spi-max-frequency: false + reg: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + nfc@8 { + compatible = "marvell,nfc-i2c"; + reg = <0x8>; + + interrupt-parent = <&gpio3>; + interrupts = <21 IRQ_TYPE_EDGE_RISING>; + + i2c-int-rising; + + reset-n-io = <&gpio3 19 GPIO_ACTIVE_HIGH>; + }; + }; + + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + nfc@0 { + compatible = "marvell,nfc-spi"; + reg = <0>; + + spi-max-frequency = <3000000>; + spi-cpha; + spi-cpol; + + interrupt-parent = <&gpio1>; + interrupts = <17 IRQ_TYPE_EDGE_RISING>; + + reset-n-io = <&gpio3 19 GPIO_ACTIVE_HIGH>; + }; + }; + + - | + #include <dt-bindings/gpio/gpio.h> + + uart { + nfc { + compatible = "marvell,nfc-uart"; + + reset-n-io = <&gpio3 16 GPIO_ACTIVE_HIGH>; + + hci-muxed; + flow-control; + }; + }; diff --git a/Documentation/devicetree/bindings/net/nfc/nfcmrvl.txt b/Documentation/devicetree/bindings/net/nfc/nfcmrvl.txt deleted file mode 100644 index c9b35251bb20..000000000000 --- a/Documentation/devicetree/bindings/net/nfc/nfcmrvl.txt +++ /dev/null @@ -1,84 +0,0 @@ -* Marvell International Ltd. NCI NFC Controller - -Required properties: -- compatible: Should be: - - "marvell,nfc-uart" or "mrvl,nfc-uart" for UART devices - - "marvell,nfc-i2c" for I2C devices - - "marvell,nfc-spi" for SPI devices - -Optional SoC specific properties: -- pinctrl-names: Contains only one value - "default". -- pintctrl-0: Specifies the pin control groups used for this controller. -- reset-n-io: Output GPIO pin used to reset the chip (active low). -- hci-muxed: Specifies that the chip is muxing NCI over HCI frames. - -Optional UART-based chip specific properties: -- flow-control: Specifies that the chip is using RTS/CTS. -- break-control: Specifies that the chip needs specific break management. - -Optional I2C-based chip specific properties: -- i2c-int-falling: Specifies that the chip read event shall be trigged on - falling edge. -- i2c-int-rising: Specifies that the chip read event shall be trigged on - rising edge. - -Example (for ARM-based BeagleBoard Black with 88W8887 on UART5): - -&uart5 { - - nfcmrvluart: nfcmrvluart@5 { - compatible = "marvell,nfc-uart"; - - reset-n-io = <&gpio3 16 0>; - - hci-muxed; - flow-control; - } -}; - - -Example (for ARM-based BeagleBoard Black with 88W8887 on I2C1): - -&i2c1 { - clock-frequency = <400000>; - - nfcmrvli2c0: i2c@1 { - compatible = "marvell,nfc-i2c"; - - reg = <0x8>; - - /* I2C INT configuration */ - interrupt-parent = <&gpio3>; - interrupts = <21 0>; - - /* I2C INT trigger configuration */ - i2c-int-rising; - - /* Reset IO */ - reset-n-io = <&gpio3 19 0>; - }; -}; - - -Example (for ARM-based BeagleBoard Black on SPI0): - -&spi0 { - - mrvlnfcspi0: spi@0 { - compatible = "marvell,nfc-spi"; - - reg = <0>; - - /* SPI Bus configuration */ - spi-max-frequency = <3000000>; - spi-cpha; - spi-cpol; - - /* SPI INT configuration */ - interrupt-parent = <&gpio1>; - interrupts = <17 0>; - - /* Reset IO */ - reset-n-io = <&gpio3 19 0>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml b/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml new file mode 100644 index 000000000000..7465aea2e1c0 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nfc/nxp,nci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Semiconductors NCI NFC controller + +maintainers: + - Charles Gorand <charles.gorand@effinnov.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + oneOf: + - const: nxp,nxp-nci-i2c + - items: + - const: nxp,pn547 + - const: nxp,nxp-nci-i2c + + enable-gpios: + description: Output GPIO pin used for enabling/disabling the controller + + firmware-gpios: + description: Output GPIO pin used to enter firmware download mode + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - enable-gpios + - interrupts + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + nfc@29 { + compatible = "nxp,nxp-nci-i2c"; + + reg = <0x29>; + + interrupt-parent = <&gpio1>; + interrupts = <29 IRQ_TYPE_LEVEL_HIGH>; + + enable-gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>; + firmware-gpios = <&gpio0 31 GPIO_ACTIVE_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml b/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml new file mode 100644 index 000000000000..d8ba5a18db98 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nfc/nxp,pn532.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Semiconductors PN532 NFC controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + oneOf: + - const: nxp,pn532 + - description: Deprecated bindings + enum: + - nxp,pn532-i2c + - nxp,pn533-i2c + deprecated: true + + interrupts: + description: Required if connected via I2C + maxItems: 1 + + reg: + description: Required if connected via I2C + maxItems: 1 + +required: + - compatible + +dependencies: + interrupts: [ 'reg' ] + +additionalProperties: false + +examples: + # PN532 on I2C bus + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + nfc@24 { + compatible = "nxp,pn532"; + + reg = <0x24>; + + interrupt-parent = <&gpio1>; + interrupts = <17 IRQ_TYPE_LEVEL_HIGH>; + }; + }; + + # PN532 connected via UART + - | + serial@49042000 { + reg = <0x49042000 0x400>; + + nfc { + compatible = "nxp,pn532"; + }; + }; diff --git a/Documentation/devicetree/bindings/net/nfc/nxp,pn544.yaml b/Documentation/devicetree/bindings/net/nfc/nxp,pn544.yaml new file mode 100644 index 000000000000..d520414de463 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/nxp,pn544.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nfc/nxp,pn544.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Semiconductors PN544 NFC Controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + const: nxp,pn544-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + enable-gpios: + description: Output GPIO pin used for enabling/disabling the PN544 + maxItems: 1 + + firmware-gpios: + description: Output GPIO pin used to enter firmware download mode + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - enable-gpios + - firmware-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + nfc@28 { + compatible = "nxp,pn544-i2c"; + reg = <0x28>; + + interrupt-parent = <&gpio1>; + interrupts = <17 IRQ_TYPE_LEVEL_HIGH>; + + enable-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>; + firmware-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/nfc/nxp-nci.txt b/Documentation/devicetree/bindings/net/nfc/nxp-nci.txt deleted file mode 100644 index 285a37c2f189..000000000000 --- a/Documentation/devicetree/bindings/net/nfc/nxp-nci.txt +++ /dev/null @@ -1,33 +0,0 @@ -* NXP Semiconductors NXP NCI NFC Controllers - -Required properties: -- compatible: Should be "nxp,nxp-nci-i2c". -- clock-frequency: I²C work frequency. -- reg: address on the bus -- interrupts: GPIO interrupt to which the chip is connected -- enable-gpios: Output GPIO pin used for enabling/disabling the chip - -Optional SoC Specific Properties: -- pinctrl-names: Contains only one value - "default". -- pintctrl-0: Specifies the pin control groups used for this controller. -- firmware-gpios: Output GPIO pin used to enter firmware download mode - -Example (for ARM-based BeagleBone with NPC100 NFC controller on I2C2): - -&i2c2 { - - - npc100: npc100@29 { - - compatible = "nxp,nxp-nci-i2c"; - - reg = <0x29>; - clock-frequency = <100000>; - - interrupt-parent = <&gpio1>; - interrupts = <29 IRQ_TYPE_LEVEL_HIGH>; - - enable-gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>; - firmware-gpios = <&gpio0 31 GPIO_ACTIVE_HIGH>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/nfc/pn532.txt b/Documentation/devicetree/bindings/net/nfc/pn532.txt deleted file mode 100644 index a5507dc499bc..000000000000 --- a/Documentation/devicetree/bindings/net/nfc/pn532.txt +++ /dev/null @@ -1,46 +0,0 @@ -* NXP Semiconductors PN532 NFC Controller - -Required properties: -- compatible: Should be - - "nxp,pn532" Place a node with this inside the devicetree node of the bus - where the NFC chip is connected to. - Currently the kernel has phy bindings for uart and i2c. - - "nxp,pn532-i2c" (DEPRECATED) only works for the i2c binding. - - "nxp,pn533-i2c" (DEPRECATED) only works for the i2c binding. - -Required properties if connected on i2c: -- clock-frequency: I²C work frequency. -- reg: for the I²C bus address. This is fixed at 0x24 for the PN532. -- interrupts: GPIO interrupt to which the chip is connected - -Optional SoC Specific Properties: -- pinctrl-names: Contains only one value - "default". -- pintctrl-0: Specifies the pin control groups used for this controller. - -Example (for ARM-based BeagleBone with PN532 on I2C2): - -&i2c2 { - - - pn532: nfc@24 { - - compatible = "nxp,pn532"; - - reg = <0x24>; - clock-frequency = <400000>; - - interrupt-parent = <&gpio1>; - interrupts = <17 IRQ_TYPE_EDGE_FALLING>; - - }; -}; - -Example (for PN532 connected via uart): - -uart4: serial@49042000 { - compatible = "ti,omap3-uart"; - - pn532: nfc { - compatible = "nxp,pn532"; - }; -}; diff --git a/Documentation/devicetree/bindings/net/nfc/pn544.txt b/Documentation/devicetree/bindings/net/nfc/pn544.txt deleted file mode 100644 index 2bd82562ce8e..000000000000 --- a/Documentation/devicetree/bindings/net/nfc/pn544.txt +++ /dev/null @@ -1,33 +0,0 @@ -* NXP Semiconductors PN544 NFC Controller - -Required properties: -- compatible: Should be "nxp,pn544-i2c". -- clock-frequency: I²C work frequency. -- reg: address on the bus -- interrupts: GPIO interrupt to which the chip is connected -- enable-gpios: Output GPIO pin used for enabling/disabling the PN544 -- firmware-gpios: Output GPIO pin used to enter firmware download mode - -Optional SoC Specific Properties: -- pinctrl-names: Contains only one value - "default". -- pintctrl-0: Specifies the pin control groups used for this controller. - -Example (for ARM-based BeagleBone with PN544 on I2C2): - -&i2c2 { - - - pn544: pn544@28 { - - compatible = "nxp,pn544-i2c"; - - reg = <0x28>; - clock-frequency = <400000>; - - interrupt-parent = <&gpio1>; - interrupts = <17 IRQ_TYPE_LEVEL_HIGH>; - - enable-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>; - firmware-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml b/Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml new file mode 100644 index 000000000000..a6a1bc788d29 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/st,st-nci.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nfc/st,st-nci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics ST NCI NFC controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + enum: + - st,st21nfcb-i2c + - st,st21nfcb-spi + - st,st21nfcc-i2c + + reset-gpios: + description: Output GPIO pin used for resetting the controller + + ese-present: + type: boolean + description: | + Specifies that an ese is physically connected to the controller + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + spi-max-frequency: true + + uicc-present: + type: boolean + description: | + Specifies that the uicc swp signal can be physically connected to the + controller + +required: + - compatible + - interrupts + - reg + - reset-gpios + +if: + properties: + compatible: + contains: + enum: + - st,st21nfcb-i2c + - st,st21nfcc-i2c +then: + properties: + spi-max-frequency: false +else: + required: + - spi-max-frequency + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + nfc@8 { + compatible = "st,st21nfcb-i2c"; + reg = <0x08>; + + interrupt-parent = <&gpio5>; + interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; + reset-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>; + + ese-present; + uicc-present; + }; + }; + + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + nfc@0 { + compatible = "st,st21nfcb-spi"; + reg = <0>; + + spi-max-frequency = <4000000>; + + interrupt-parent = <&gpio5>; + interrupts = <2 IRQ_TYPE_EDGE_RISING>; + reset-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>; + + ese-present; + uicc-present; + }; + }; diff --git a/Documentation/devicetree/bindings/net/nfc/st,st21nfca.yaml b/Documentation/devicetree/bindings/net/nfc/st,st21nfca.yaml new file mode 100644 index 000000000000..4356eacde8aa --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/st,st21nfca.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nfc/st,st21nfca.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics SAS ST21NFCA NFC controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + const: st,st21nfca-i2c + + enable-gpios: + description: Output GPIO pin used for enabling/disabling the controller + + ese-present: + type: boolean + description: | + Specifies that an ese is physically connected to the controller + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + uicc-present: + type: boolean + description: | + Specifies that the uicc swp signal can be physically connected to the + controller + +required: + - compatible + - enable-gpios + - interrupts + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + nfc@1 { + compatible = "st,st21nfca-i2c"; + reg = <0x1>; + + interrupt-parent = <&gpio5>; + interrupts = <2 IRQ_TYPE_LEVEL_LOW>; + enable-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>; + + ese-present; + uicc-present; + }; + }; diff --git a/Documentation/devicetree/bindings/net/nfc/st,st95hf.yaml b/Documentation/devicetree/bindings/net/nfc/st,st95hf.yaml new file mode 100644 index 000000000000..d3bca376039e --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/st,st95hf.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nfc/st,st95hf.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics ST95HF NFC controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + const: st,st95hf + + enable-gpio: + description: Output GPIO pin used for enabling/disabling the controller + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + st95hfvin-supply: + description: ST95HF transceiver's Vin regulator supply + + spi-max-frequency: true + +required: + - compatible + - enable-gpio + - interrupts + - reg + - spi-max-frequency + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + nfc@0{ + compatible = "st,st95hf"; + reg = <0>; + + spi-max-frequency = <1000000>; + enable-gpio = <&pio4 GPIO_ACTIVE_HIGH>; + interrupt-parent = <&pio0>; + interrupts = <7 IRQ_TYPE_EDGE_FALLING>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/nfc/st-nci-i2c.txt b/Documentation/devicetree/bindings/net/nfc/st-nci-i2c.txt deleted file mode 100644 index baa8f8133d19..000000000000 --- a/Documentation/devicetree/bindings/net/nfc/st-nci-i2c.txt +++ /dev/null @@ -1,38 +0,0 @@ -* STMicroelectronics SAS. ST NCI NFC Controller - -Required properties: -- compatible: Should be "st,st21nfcb-i2c" or "st,st21nfcc-i2c". -- clock-frequency: I²C work frequency. -- reg: address on the bus -- interrupts: GPIO interrupt to which the chip is connected -- reset-gpios: Output GPIO pin used to reset the ST21NFCB - -Optional SoC Specific Properties: -- pinctrl-names: Contains only one value - "default". -- pintctrl-0: Specifies the pin control groups used for this controller. -- ese-present: Specifies that an ese is physically connected to the nfc -controller. -- uicc-present: Specifies that the uicc swp signal can be physically -connected to the nfc controller. - -Example (for ARM-based BeagleBoard xM with ST21NFCB on I2C2): - -&i2c2 { - - - st21nfcb: st21nfcb@8 { - - compatible = "st,st21nfcb-i2c"; - - reg = <0x08>; - clock-frequency = <400000>; - - interrupt-parent = <&gpio5>; - interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; - - reset-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>; - - ese-present; - uicc-present; - }; -}; diff --git a/Documentation/devicetree/bindings/net/nfc/st-nci-spi.txt b/Documentation/devicetree/bindings/net/nfc/st-nci-spi.txt deleted file mode 100644 index d33343330b94..000000000000 --- a/Documentation/devicetree/bindings/net/nfc/st-nci-spi.txt +++ /dev/null @@ -1,36 +0,0 @@ -* STMicroelectronics SAS. ST NCI NFC Controller - -Required properties: -- compatible: Should be "st,st21nfcb-spi" -- spi-max-frequency: Maximum SPI frequency (<= 4000000). -- interrupts: GPIO interrupt to which the chip is connected -- reset-gpios: Output GPIO pin used to reset the ST21NFCB - -Optional SoC Specific Properties: -- pinctrl-names: Contains only one value - "default". -- pintctrl-0: Specifies the pin control groups used for this controller. -- ese-present: Specifies that an ese is physically connected to the nfc -controller. -- uicc-present: Specifies that the uicc swp signal can be physically -connected to the nfc controller. - -Example (for ARM-based BeagleBoard xM with ST21NFCB on SPI4): - -&mcspi4 { - - - st21nfcb: st21nfcb@0 { - - compatible = "st,st21nfcb-spi"; - - clock-frequency = <4000000>; - - interrupt-parent = <&gpio5>; - interrupts = <2 IRQ_TYPE_EDGE_RISING>; - - reset-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>; - - ese-present; - uicc-present; - }; -}; diff --git a/Documentation/devicetree/bindings/net/nfc/st21nfca.txt b/Documentation/devicetree/bindings/net/nfc/st21nfca.txt deleted file mode 100644 index b8bd90f80e12..000000000000 --- a/Documentation/devicetree/bindings/net/nfc/st21nfca.txt +++ /dev/null @@ -1,37 +0,0 @@ -* STMicroelectronics SAS. ST21NFCA NFC Controller - -Required properties: -- compatible: Should be "st,st21nfca-i2c". -- clock-frequency: I²C work frequency. -- reg: address on the bus -- enable-gpios: Output GPIO pin used for enabling/disabling the ST21NFCA - -Optional SoC Specific Properties: -- pinctrl-names: Contains only one value - "default". -- pintctrl-0: Specifies the pin control groups used for this controller. -- ese-present: Specifies that an ese is physically connected to the nfc -controller. -- uicc-present: Specifies that the uicc swp signal can be physically -connected to the nfc controller. - -Example (for ARM-based BeagleBoard xM with ST21NFCA on I2C2): - -&i2c2 { - - - st21nfca: st21nfca@1 { - - compatible = "st,st21nfca-i2c"; - - reg = <0x01>; - clock-frequency = <400000>; - - interrupt-parent = <&gpio5>; - interrupts = <2 IRQ_TYPE_LEVEL_LOW>; - - enable-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>; - - ese-present; - uicc-present; - }; -}; diff --git a/Documentation/devicetree/bindings/net/nfc/st95hf.txt b/Documentation/devicetree/bindings/net/nfc/st95hf.txt deleted file mode 100644 index 3f373a1e20ff..000000000000 --- a/Documentation/devicetree/bindings/net/nfc/st95hf.txt +++ /dev/null @@ -1,45 +0,0 @@ -* STMicroelectronics : NFC Transceiver ST95HF - -ST NFC Transceiver is required to attach with SPI bus. -ST95HF node should be defined in DT as SPI slave device of SPI -master with which ST95HF transceiver is physically connected. -The properties defined below are required to be the part of DT -to include ST95HF transceiver into the platform. - -Required properties: -=================== -- reg: Address of SPI slave "ST95HF transceiver" on SPI master bus. - -- compatible: should be "st,st95hf" for ST95HF NFC transceiver - -- spi-max-frequency: Max. operating SPI frequency for ST95HF - transceiver. - -- enable-gpio: GPIO line to enable ST95HF transceiver. - -- interrupts : Standard way to define ST95HF transceiver's out - interrupt. - -Optional property: -================= -- st95hfvin-supply : This is an optional property. It contains a - phandle to ST95HF transceiver's regulator supply node in DT. - -Example: -======= -spi@9840000 { - reg = <0x9840000 0x110>; - #address-cells = <1>; - #size-cells = <0>; - cs-gpios = <&pio0 4>; - - st95hf@0{ - reg = <0>; - compatible = "st,st95hf"; - spi-max-frequency = <1000000>; - enable-gpio = <&pio4 0>; - interrupt-parent = <&pio0>; - interrupts = <7 IRQ_TYPE_EDGE_FALLING>; - }; - -}; diff --git a/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml b/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml new file mode 100644 index 000000000000..40da2ac98978 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nfc/ti,trf7970a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments TRF7970A RFID/NFC/15693 Transceiver + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Mark Greer <mgreer@animalcreek.com> + +properties: + compatible: + const: ti,trf7970a + + autosuspend-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Specify autosuspend delay in milliseconds. + + clock-frequency: + description: | + Set to specify that the input frequency to the trf7970a is 13560000Hz or + 27120000Hz + + en2-rf-quirk: + type: boolean + description: | + Specify that the trf7970a being used has the "EN2 RF" erratum + + interrupts: + maxItems: 1 + + irq-status-read-quirk: + type: boolean + description: | + Specify that the trf7970a being used has the "IRQ Status Read" erratum + + reg: + maxItems: 1 + + spi-max-frequency: true + + ti,enable-gpios: + minItems: 1 + maxItems: 2 + description: | + One or two GPIO entries used for 'EN' and 'EN2' pins on the TRF7970A. EN2 + is optional. + + vdd-io-supply: + description: | + Regulator specifying voltage for VDD-IO + + vin-supply: + description: | + Regulator for supply voltage to VIN pin + +required: + - compatible + - interrupts + - reg + - spi-max-frequency + - ti,enable-gpios + - vin-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + nfc@0 { + compatible = "ti,trf7970a"; + reg = <0>; + + pinctrl-names = "default"; + pinctrl-0 = <&trf7970a_default>; + spi-max-frequency = <2000000>; + interrupt-parent = <&gpio2>; + interrupts = <14 0>; + + ti,enable-gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>, + <&gpio2 5 GPIO_ACTIVE_HIGH>; + vin-supply = <&ldo3_reg>; + vdd-io-supply = <&ldo2_reg>; + autosuspend-delay = <30000>; + irq-status-read-quirk; + en2-rf-quirk; + clock-frequency = <27120000>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt deleted file mode 100644 index ba1934b950e5..000000000000 --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt +++ /dev/null @@ -1,43 +0,0 @@ -* Texas Instruments TRF7970A RFID/NFC/15693 Transceiver - -Required properties: -- compatible: Should be "ti,trf7970a". -- spi-max-frequency: Maximum SPI frequency (<= 2000000). -- interrupts: A single interrupt specifier. -- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the - TRF7970A. EN2 is optional. -- vin-supply: Regulator for supply voltage to VIN pin - -Optional SoC Specific Properties: -- pinctrl-names: Contains only one value - "default". -- pintctrl-0: Specifies the pin control groups used for this controller. -- autosuspend-delay: Specify autosuspend delay in milliseconds. -- irq-status-read-quirk: Specify that the trf7970a being used has the - "IRQ Status Read" erratum. -- en2-rf-quirk: Specify that the trf7970a being used has the "EN2 RF" - erratum. -- vdd-io-supply: Regulator specifying voltage for vdd-io -- clock-frequency: Set to specify that the input frequency to the trf7970a is 13560000Hz or 27120000Hz - -Example (for ARM-based BeagleBone with TRF7970A on SPI1): - -&spi1 { - - nfc@0 { - compatible = "ti,trf7970a"; - reg = <0>; - pinctrl-names = "default"; - pinctrl-0 = <&trf7970a_default>; - spi-max-frequency = <2000000>; - interrupt-parent = <&gpio2>; - interrupts = <14 0>; - ti,enable-gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>, - <&gpio2 5 GPIO_ACTIVE_HIGH>; - vin-supply = <&ldo3_reg>; - vdd-io-supply = <&ldo2_reg>; - autosuspend-delay = <30000>; - irq-status-read-quirk; - en2-rf-quirk; - clock-frequency = <27120000>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml index 5629b2e4ccf8..ee4afe361fac 100644 --- a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml +++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml @@ -34,7 +34,6 @@ properties: clocks: minItems: 3 - maxItems: 5 items: - description: MAC host clock - description: MAC apb clock diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index b8a0b392b24e..b86edf67ce62 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -64,7 +64,8 @@ properties: - const: gsi iommus: - maxItems: 1 + minItems: 1 + maxItems: 2 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml b/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml index 948677ade6d1..d7748dd33199 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml @@ -51,6 +51,9 @@ examples: switch@10 { compatible = "qca,qca8337"; reg = <0x10>; - /* ... */ + + ports { + /* ... */ + }; }; }; diff --git a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml index 0634e69dd9a6..157d606bf9cb 100644 --- a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml @@ -34,6 +34,8 @@ properties: maxItems: 1 description: GPIO specifier, used to wakeup the host processor + max-speed: true + required: - compatible diff --git a/Documentation/devicetree/bindings/net/renesas,ether.yaml b/Documentation/devicetree/bindings/net/renesas,ether.yaml index c101a1ec846e..06b38c9bc6ec 100644 --- a/Documentation/devicetree/bindings/net/renesas,ether.yaml +++ b/Documentation/devicetree/bindings/net/renesas,ether.yaml @@ -100,15 +100,18 @@ additionalProperties: false examples: # Lager board - | - #include <dt-bindings/clock/r8a7790-clock.h> - #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/r8a7790-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7790-sysc.h> + #include <dt-bindings/gpio/gpio.h> ethernet@ee700000 { compatible = "renesas,ether-r8a7790", "renesas,rcar-gen2-ether"; reg = <0xee700000 0x400>; - interrupt-parent = <&gic>; - interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp8_clks R8A7790_CLK_ETHER>; + interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 813>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 813>; phy-mode = "rmii"; phy-handle = <&phy1>; renesas,ether-link-active-low; @@ -116,8 +119,12 @@ examples: #size-cells = <0>; phy1: ethernet-phy@1 { + compatible = "ethernet-phy-id0022.1537", + "ethernet-phy-ieee802.3-c22"; reg = <1>; interrupt-parent = <&irqc0>; interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + micrel,led-mode = <1>; + reset-gpios = <&gpio5 31 GPIO_ACTIVE_LOW>; }; }; diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml index 4c927d2c17d3..bda821065a2b 100644 --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml @@ -287,6 +287,7 @@ examples: "ch13", "ch14", "ch15", "ch16", "ch17", "ch18", "ch19", "ch20", "ch21", "ch22", "ch23", "ch24"; clocks = <&cpg CPG_MOD 812>; + clock-names = "fck"; iommus = <&ipmmu_ds0 16>; power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; resets = <&cpg 812>; @@ -298,6 +299,8 @@ examples: #size-cells = <0>; phy0: ethernet-phy@0 { + compatible = "ethernet-phy-id0022.1622", + "ethernet-phy-ieee802.3-c22"; rxc-skew-ps = <1500>; reg = <0>; interrupt-parent = <&gpio2>; diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 42689b7d03a2..7ae70dc27f78 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Synopsys DesignWare MAC Device Tree Bindings maintainers: - - Alexandre Torgue <alexandre.torgue@st.com> + - Alexandre Torgue <alexandre.torgue@foss.st.com> - Giuseppe Cavallaro <peppe.cavallaro@st.com> - Jose Abreu <joabreu@synopsys.com> @@ -21,6 +21,7 @@ select: contains: enum: - snps,dwmac + - snps,dwmac-3.40a - snps,dwmac-3.50a - snps,dwmac-3.610 - snps,dwmac-3.70a @@ -49,7 +50,7 @@ properties: - allwinner,sun7i-a20-gmac - allwinner,sun8i-a83t-emac - allwinner,sun8i-h3-emac - - allwinner,sun8i-r40-emac + - allwinner,sun8i-r40-gmac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac - loongson,ls2k-dwmac @@ -76,6 +77,7 @@ properties: - rockchip,rk3399-gmac - rockchip,rv1108-gmac - snps,dwmac + - snps,dwmac-3.40a - snps,dwmac-3.50a - snps,dwmac-3.610 - snps,dwmac-3.70a @@ -316,7 +318,7 @@ allOf: - allwinner,sun7i-a20-gmac - allwinner,sun8i-a83t-emac - allwinner,sun8i-h3-emac - - allwinner,sun8i-r40-emac + - allwinner,sun8i-r40-gmac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac - ingenic,jz4775-mac @@ -364,7 +366,7 @@ allOf: - allwinner,sun7i-a20-gmac - allwinner,sun8i-a83t-emac - allwinner,sun8i-h3-emac - - allwinner,sun8i-r40-emac + - allwinner,sun8i-r40-gmac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac - loongson,ls2k-dwmac diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml index 8a03a24a2019..6bc61c42418f 100644 --- a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml @@ -24,6 +24,7 @@ properties: - socionext,uniphier-ld11-ave4 - socionext,uniphier-ld20-ave4 - socionext,uniphier-pxs3-ave4 + - socionext,uniphier-nx1-ave4 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index d3f05d5934d5..577f4e284425 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -8,8 +8,8 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: STMicroelectronics STM32 / MCU DWMAC glue layer controller maintainers: - - Alexandre Torgue <alexandre.torgue@st.com> - - Christophe Roullier <christophe.roullier@st.com> + - Alexandre Torgue <alexandre.torgue@foss.st.com> + - Christophe Roullier <christophe.roullier@foss.st.com> description: This file documents platform glue layer for stmmac. diff --git a/Documentation/devicetree/bindings/net/ti,bluetooth.yaml b/Documentation/devicetree/bindings/net/ti,bluetooth.yaml new file mode 100644 index 000000000000..81616f9fb493 --- /dev/null +++ b/Documentation/devicetree/bindings/net/ti,bluetooth.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/ti,bluetooth.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments Bluetooth Chips + +maintainers: + - David Lechner <david@lechnology.com> + +description: | + This documents the binding structure and common properties for serial + attached TI Bluetooth devices. The following chips are included in this + binding: + + * TI CC256x Bluetooth devices + * TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices + + TI WiLink devices have a UART interface for providing Bluetooth, FM radio, + and GPS over what's called "shared transport". The shared transport is + standard BT HCI protocol with additional channels for the other functions. + + TI WiLink devices also have a separate WiFi interface as described in + wireless/ti,wlcore.yaml. + + This bindings follows the UART slave device binding in ../serial/serial.yaml. + +properties: + compatible: + enum: + - ti,cc2560 + - ti,wl1271-st + - ti,wl1273-st + - ti,wl1281-st + - ti,wl1283-st + - ti,wl1285-st + - ti,wl1801-st + - ti,wl1805-st + - ti,wl1807-st + - ti,wl1831-st + - ti,wl1835-st + - ti,wl1837-st + + enable-gpios: + maxItems: 1 + + vio-supply: + description: Vio input supply (1.8V) + + vbat-supply: + description: Vbat input supply (2.9-4.8V) + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ext_clock + + max-speed: + default: 3000000 + + nvmem-cells: + maxItems: 1 + description: + Nvmem data cell that contains a 6 byte BD address with the most + significant byte first (big-endian). + + nvmem-cell-names: + items: + - const: bd-address + +required: + - compatible + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + serial { + bluetooth { + compatible = "ti,wl1835-st"; + enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>; + clocks = <&clk32k_wl18xx>; + clock-names = "ext_clock"; + nvmem-cells = <&bd_address>; + nvmem-cell-names = "bd-address"; + }; + }; diff --git a/Documentation/devicetree/bindings/net/ti-bluetooth.txt b/Documentation/devicetree/bindings/net/ti-bluetooth.txt deleted file mode 100644 index f48c17b38f58..000000000000 --- a/Documentation/devicetree/bindings/net/ti-bluetooth.txt +++ /dev/null @@ -1,60 +0,0 @@ -Texas Instruments Bluetooth Chips ---------------------------------- - -This documents the binding structure and common properties for serial -attached TI Bluetooth devices. The following chips are included in this -binding: - -* TI CC256x Bluetooth devices -* TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices - -TI WiLink devices have a UART interface for providing Bluetooth, FM radio, -and GPS over what's called "shared transport". The shared transport is -standard BT HCI protocol with additional channels for the other functions. - -TI WiLink devices also have a separate WiFi interface as described in -wireless/ti,wlcore.txt. - -This bindings follows the UART slave device binding in ../serial/serial.yaml. - -Required properties: - - compatible: should be one of the following: - "ti,cc2560" - "ti,wl1271-st" - "ti,wl1273-st" - "ti,wl1281-st" - "ti,wl1283-st" - "ti,wl1285-st" - "ti,wl1801-st" - "ti,wl1805-st" - "ti,wl1807-st" - "ti,wl1831-st" - "ti,wl1835-st" - "ti,wl1837-st" - -Optional properties: - - enable-gpios : GPIO signal controlling enabling of BT. Active high. - - vio-supply : Vio input supply (1.8V) - - vbat-supply : Vbat input supply (2.9-4.8V) - - clocks : Must contain an entry, for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names : Must include the following entry: - "ext_clock" (External clock provided to the TI combo chip). - - nvmem-cells: phandle to nvmem data cell that contains a 6 byte BD address - with the most significant byte first (big-endian). - - nvmem-cell-names: "bd-address" (required when nvmem-cells is specified) - -Example: - -&serial0 { - compatible = "ns16550a"; - ... - bluetooth { - compatible = "ti,wl1835-st"; - enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>; - clocks = <&clk32k_wl18xx>; - clock-names = "ext_clock"; - nvmem-cells = <&bd_address>; - nvmem-cell-names = "bd-address"; - }; -}; diff --git a/Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt b/Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt deleted file mode 100644 index 6830c4786f8a..000000000000 --- a/Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt +++ /dev/null @@ -1,30 +0,0 @@ -Espressif ESP8089 wireless SDIO devices - -This node provides properties for controlling the ESP8089 wireless device. -The node is expected to be specified as a child node to the SDIO controller -that connects the device to the system. - -Required properties: - - - compatible : Should be "esp,esp8089". - -Optional properties: - - esp,crystal-26M-en: Integer value for the crystal_26M_en firmware parameter - -Example: - -&mmc1 { - #address-cells = <1>; - #size-cells = <0>; - - vmmc-supply = <®_dldo1>; - mmc-pwrseq = <&wifi_pwrseq>; - bus-width = <4>; - non-removable; - - esp8089: sdio_wifi@1 { - compatible = "esp,esp8089"; - reg = <1>; - esp,crystal-26M-en = <2>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml b/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml new file mode 100644 index 000000000000..284ef45add99 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/wireless/esp,esp8089.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Espressif ESP8089 Device Tree Bindings + +maintainers: + - Hans de Goede <hdegoede@redhat.com> + +properties: + compatible: + const: esp,esp8089 + + reg: + maxItems: 1 + + esp,crystal-26M-en: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + Value for the crystal_26M_en firmware parameter + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + mmc { + #address-cells = <1>; + #size-cells = <0>; + + wifi@1 { + compatible = "esp,esp8089"; + reg = <1>; + esp,crystal-26M-en = <2>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml index 3e2c2e43175e..1489d3c1cd6e 100644 --- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml @@ -47,6 +47,11 @@ properties: ieee80211-freq-limit: true + mediatek,eeprom-data: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + EEPROM data embedded as array. + mediatek,mtd-eeprom: $ref: /schemas/types.yaml#/definitions/phandle-array description: diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt deleted file mode 100644 index aaaeeb5f935b..000000000000 --- a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt +++ /dev/null @@ -1,48 +0,0 @@ -* Qualcomm Atheros ath9k wireless devices - -This node provides properties for configuring the ath9k wireless device. The -node is expected to be specified as a child node of the PCI controller to -which the wireless chip is connected. - -Required properties: -- compatible: For PCI and PCIe devices this should be an identifier following - the format as defined in "PCI Bus Binding to Open Firmware" - Revision 2.1. One of the possible formats is "pciVVVV,DDDD" - where VVVV is the PCI vendor ID and DDDD is PCI device ID. - Typically QCA's PCI vendor ID 168c is used while the PCI device - ID depends on the chipset - see the following (possibly - incomplete) list: - - 0023 for AR5416 - - 0024 for AR5418 - - 0027 for AR9160 - - 0029 for AR9220 and AR9223 - - 002a for AR9280 and AR9283 - - 002b for AR9285 - - 002c for AR2427 - - 002d for AR9227 - - 002e for AR9287 - - 0030 for AR9380, AR9381 and AR9382 - - 0032 for AR9485 - - 0033 for AR9580 and AR9590 - - 0034 for AR9462 - - 0036 for AR9565 - - 0037 for AR9485 -- reg: Address and length of the register set for the device. - -Optional properties: -- qca,no-eeprom: Indicates that there is no physical EEPROM connected to the - ath9k wireless chip (in this case the calibration / - EEPROM data will be loaded from userspace using the - kernel firmware loader). - -The MAC address will be determined using the optional properties defined in -net/ethernet.txt. - -In this example, the node is defined as child node of the PCI controller: -&pci0 { - wifi@168c,002d { - compatible = "pci168c,002d"; - reg = <0x7000 0 0 0 0x1000>; - qca,no-eeprom; - }; -}; diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml new file mode 100644 index 000000000000..8cd0adbf7021 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/wireless/qca,ath9k.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Atheros ath9k wireless devices Generic Binding + +maintainers: + - Kalle Valo <kvalo@codeaurora.org> + +description: | + This node provides properties for configuring the ath9k wireless device. + The node is expected to be specified as a child node of the PCI controller + to which the wireless chip is connected. + +allOf: + - $ref: ieee80211.yaml# + +properties: + compatible: + enum: + - pci168c,0023 # AR5416 + - pci168c,0024 # AR5418 + - pci168c,0027 # AR9160 + - pci168c,0029 # AR9220 and AR9223 + - pci168c,002a # AR9280 and AR9283 + - pci168c,002b # AR9285 + - pci168c,002c # AR2427 - 802.11n bonded out + - pci168c,002d # AR9227 + - pci168c,002e # AR9287 + - pci168c,0030 # AR9380, AR9381 and AR9382 + - pci168c,0032 # AR9485 + - pci168c,0033 # AR9580 and AR9590 + - pci168c,0034 # AR9462 + - pci168c,0036 # AR9565 + - pci168c,0037 # AR1111 and AR9485 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + ieee80211-freq-limit: true + + qca,no-eeprom: + $ref: /schemas/types.yaml#/definitions/flag + description: + Indicates that there is no physical EEPROM connected + + nvmem-cells: + items: + - description: Reference to an nvmem node for the MAC address + - description: Reference to an nvmem node for calibration data + + nvmem-cell-names: + items: + - const: mac-address + - const: calibration + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + pcie0 { + #address-cells = <3>; + #size-cells = <2>; + wifi@0,0 { + compatible = "pci168c,002d"; + reg = <0 0 0 0 0>; + interrupts = <3>; + qca,no-eeprom; + }; + }; + - | + pci0 { + #address-cells = <3>; + #size-cells = <2>; + wifi@0,11 { + compatible = "pci168c,0029"; + reg = <0x8800 0 0 0 0>; + nvmem-cells = <&macaddr_art_c>, <&cal_art_1000>; + nvmem-cell-names = "mac-address", "calibration"; + }; + }; diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt deleted file mode 100644 index cb5c9e1569ca..000000000000 --- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt +++ /dev/null @@ -1,57 +0,0 @@ -* Texas Instruments wl12xx/wl18xx wireless lan controller - -The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This -document describes the binding for the SPI connected chip. - -Required properties: -- compatible : Should be one of the following: - * "ti,wl1271" - * "ti,wl1273" - * "ti,wl1281" - * "ti,wl1283" - * "ti,wl1801" - * "ti,wl1805" - * "ti,wl1807" - * "ti,wl1831" - * "ti,wl1835" - * "ti,wl1837" -- reg : Chip select address of device -- spi-max-frequency : Maximum SPI clocking speed of device in Hz -- interrupts : Should contain parameters for 1 interrupt line. -- vwlan-supply : Point the node of the regulator that powers/enable the - wl12xx/wl18xx chip - -Optional properties: -- ref-clock-frequency : Reference clock frequency (should be set for wl12xx) -- clock-xtal : boolean, clock is generated from XTAL - -- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt - for optional SPI connection related properties, - -Examples: - -For wl12xx family: -&spi1 { - wlcore: wlcore@1 { - compatible = "ti,wl1271"; - reg = <1>; - spi-max-frequency = <48000000>; - interrupt-parent = <&gpio3>; - interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; - vwlan-supply = <&vwlan_fixed>; - clock-xtal; - ref-clock-frequency = <38400000>; - }; -}; - -For wl18xx family: -&spi0 { - wlcore: wlcore@0 { - compatible = "ti,wl1835"; - reg = <0>; - spi-max-frequency = <48000000>; - interrupt-parent = <&gpio0>; - interrupts = <27 IRQ_TYPE_EDGE_RISING>; - vwlan-supply = <&vwlan_fixed>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt deleted file mode 100644 index 9306c4dadd46..000000000000 --- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt +++ /dev/null @@ -1,45 +0,0 @@ -TI Wilink 6/7/8 (wl12xx/wl18xx) SDIO devices - -This node provides properties for controlling the wilink wireless device. The -node is expected to be specified as a child node to the SDIO controller that -connects the device to the system. - -Required properties: - - compatible: should be one of the following: - * "ti,wl1271" - * "ti,wl1273" - * "ti,wl1281" - * "ti,wl1283" - * "ti,wl1285" - * "ti,wl1801" - * "ti,wl1805" - * "ti,wl1807" - * "ti,wl1831" - * "ti,wl1835" - * "ti,wl1837" - - interrupts : specifies attributes for the out-of-band interrupt. - -Optional properties: - - ref-clock-frequency : ref clock frequency in Hz - - tcxo-clock-frequency : tcxo clock frequency in Hz - -Note: the *-clock-frequency properties assume internal clocks. In case of external -clock, new bindings (for parsing the clock nodes) have to be added. - -Example: - -&mmc3 { - vmmc-supply = <&wlan_en_reg>; - bus-width = <4>; - cap-power-off-card; - keep-power-in-suspend; - - #address-cells = <1>; - #size-cells = <0>; - wlcore: wlcore@2 { - compatible = "ti,wl1835"; - reg = <2>; - interrupt-parent = <&gpio0>; - interrupts = <19 IRQ_TYPE_LEVEL_HIGH>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml new file mode 100644 index 000000000000..8dd164d10290 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml @@ -0,0 +1,134 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/wireless/ti,wlcore.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments Wilink 6/7/8 (wl12xx/wl18xx) Wireless LAN Controller + +maintainers: + - Tony Lindgren <tony@atomide.com> + +description: + The wl12xx/wl18xx chips can be connected via SPI or via SDIO. + Note that the *-clock-frequency properties assume internal clocks. In case + of external clocks, new bindings (for parsing the clock nodes) have to be + added. + +properties: + compatible: + enum: + - ti,wl1271 + - ti,wl1273 + - ti,wl1281 + - ti,wl1283 + - ti,wl1285 + - ti,wl1801 + - ti,wl1805 + - ti,wl1807 + - ti,wl1831 + - ti,wl1835 + - ti,wl1837 + + reg: + maxItems: 1 + description: + This is required when connected via SPI, and optional when connected via + SDIO. + + spi-max-frequency: true + + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + items: + - const: irq + - const: wakeup + + vwlan-supply: + description: + Points to the node of the regulator that powers/enable the wl12xx/wl18xx + chip. This is required when connected via SPI. + + + ref-clock-frequency: + description: Reference clock frequency. + + tcxo-clock-frequency: + description: TCXO clock frequency. + + clock-xtal: + $ref: /schemas/types.yaml#/definitions/flag + description: Indicates that the clock is generated from XTAL. + +required: + - compatible + - interrupts + +if: + properties: + compatible: + contains: + enum: + - ti,wl1271 + - ti,wl1273 + - ti,wl1281 + - ti,wl1283 +then: + required: + - ref-clock-frequency + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + // For wl12xx family: + spi1 { + #address-cells = <1>; + #size-cells = <0>; + + wlcore1: wlcore@1 { + compatible = "ti,wl1271"; + reg = <1>; + spi-max-frequency = <48000000>; + interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; + vwlan-supply = <&vwlan_fixed>; + clock-xtal; + ref-clock-frequency = <38400000>; + }; + }; + + // For wl18xx family: + spi2 { + #address-cells = <1>; + #size-cells = <0>; + + wlcore2: wlcore@0 { + compatible = "ti,wl1835"; + reg = <0>; + spi-max-frequency = <48000000>; + interrupts = <27 IRQ_TYPE_EDGE_RISING>; + vwlan-supply = <&vwlan_fixed>; + }; + }; + + // SDIO example: + mmc3 { + vmmc-supply = <&wlan_en_reg>; + bus-width = <4>; + cap-power-off-card; + keep-power-in-suspend; + + #address-cells = <1>; + #size-cells = <0>; + + wlcore3: wlcore@2 { + compatible = "ti,wl1835"; + reg = <2>; + interrupts = <19 IRQ_TYPE_LEVEL_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/numa.txt b/Documentation/devicetree/bindings/numa.txt index 21b35053ca5a..42f282c2f3cc 100644 --- a/Documentation/devicetree/bindings/numa.txt +++ b/Documentation/devicetree/bindings/numa.txt @@ -103,7 +103,51 @@ Example: }; ============================================================================== -4 - Example dts +4 - Empty memory nodes +============================================================================== + +Empty memory nodes, which no memory resides in, are allowed. There are no +device nodes for these empty memory nodes. However, the NUMA node IDs and +distance maps are still valid and memory may be added into them through +hotplug afterwards. + +Example: + + memory@0 { + device_type = "memory"; + reg = <0x0 0x0 0x0 0x80000000>; + numa-node-id = <0>; + }; + + memory@80000000 { + device_type = "memory"; + reg = <0x0 0x80000000 0x0 0x80000000>; + numa-node-id = <1>; + }; + + /* Empty memory node 2 and 3 */ + distance-map { + compatible = "numa-distance-map-v1"; + distance-matrix = <0 0 10>, + <0 1 20>, + <0 2 40>, + <0 3 20>, + <1 0 20>, + <1 1 10>, + <1 2 20>, + <1 3 40>, + <2 0 40>, + <2 1 20>, + <2 2 10>, + <2 3 20>, + <3 0 20>, + <3 1 40>, + <3 2 20>, + <3 3 10>; + }; + +============================================================================== +5 - Example dts ============================================================================== Dual socket system consists of 2 boards connected through ccn bus and diff --git a/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml b/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml index 1485d3fbabfd..bf84768228f5 100644 --- a/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml +++ b/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml @@ -33,7 +33,7 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/jz4780-cgu.h> + #include <dt-bindings/clock/ingenic,jz4780-cgu.h> efuse@134100d0 { compatible = "ingenic,jz4780-efuse"; diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml index 0b80ce22a2f8..a48c8fa56bce 100644 --- a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml +++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml @@ -13,7 +13,7 @@ description: | internal vref (VREFIN_CAL), unique device ID... maintainers: - - Fabrice Gasnier <fabrice.gasnier@st.com> + - Fabrice Gasnier <fabrice.gasnier@foss.st.com> allOf: - $ref: "nvmem.yaml#" diff --git a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml index ae3ae4d39843..15a76bcd6d42 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml @@ -33,7 +33,7 @@ properties: type: boolean patternProperties: - '^opp-?[0-9]+$': + '^opp(-?[0-9]+)*$': type: object description: One or more OPP nodes describing voltage-current-frequency combinations. diff --git a/Documentation/devicetree/bindings/pci/apple,pcie.yaml b/Documentation/devicetree/bindings/pci/apple,pcie.yaml new file mode 100644 index 000000000000..ef1d424ec299 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/apple,pcie.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/apple,pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple PCIe host controller + +maintainers: + - Mark Kettenis <kettenis@openbsd.org> + +description: | + The Apple PCIe host controller is a PCIe host controller with + multiple root ports present in Apple ARM SoC platforms, including + various iPhone and iPad devices and the "Apple Silicon" Macs. + The controller incorporates Synopsys DesigWare PCIe logic to + implements its root ports. But the ATU found on most DesignWare + PCIe host bridges is absent. + + All root ports share a single ECAM space, but separate GPIOs are + used to take the PCI devices on those ports out of reset. Therefore + the standard "reset-gpios" and "max-link-speed" properties appear on + the child nodes that represent the PCI bridges that correspond to + the individual root ports. + + MSIs are handled by the PCIe controller and translated into regular + interrupts. A range of 32 MSIs is provided. These 32 MSIs can be + distributed over the root ports as the OS sees fit by programming + the PCIe controller's port registers. + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + - $ref: /schemas/interrupt-controller/msi-controller.yaml# + +properties: + compatible: + items: + - const: apple,t8103-pcie + - const: apple,pcie + + reg: + minItems: 3 + maxItems: 5 + + reg-names: + minItems: 3 + items: + - const: config + - const: rc + - const: port0 + - const: port1 + - const: port2 + + ranges: + minItems: 2 + maxItems: 2 + + interrupts: + description: + Interrupt specifiers, one for each root port. + minItems: 1 + maxItems: 3 + + msi-parent: true + + msi-ranges: + maxItems: 1 + + iommu-map: true + iommu-map-mask: true + +required: + - compatible + - reg + - reg-names + - bus-range + - interrupts + - msi-controller + - msi-parent + - msi-ranges + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/apple-aic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pcie0: pcie@690000000 { + compatible = "apple,t8103-pcie", "apple,pcie"; + device_type = "pci"; + + reg = <0x6 0x90000000 0x0 0x1000000>, + <0x6 0x80000000 0x0 0x100000>, + <0x6 0x81000000 0x0 0x4000>, + <0x6 0x82000000 0x0 0x4000>, + <0x6 0x83000000 0x0 0x4000>; + reg-names = "config", "rc", "port0", "port1", "port2"; + + interrupt-parent = <&aic>; + interrupts = <AIC_IRQ 695 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 698 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 701 IRQ_TYPE_LEVEL_HIGH>; + + msi-controller; + msi-parent = <&pcie0>; + msi-ranges = <&aic AIC_IRQ 704 IRQ_TYPE_EDGE_RISING 32>; + + iommu-map = <0x100 &dart0 1 1>, + <0x200 &dart1 1 1>, + <0x300 &dart2 1 1>; + iommu-map-mask = <0xff00>; + + bus-range = <0 3>; + #address-cells = <3>; + #size-cells = <2>; + ranges = <0x43000000 0x6 0xa0000000 0x6 0xa0000000 0x0 0x20000000>, + <0x02000000 0x0 0xc0000000 0x6 0xc0000000 0x0 0x40000000>; + + power-domains = <&ps_apcie>, <&ps_apcie_gp>, <&ps_pcie_ref>; + pinctrl-0 = <&pcie_pins>; + pinctrl-names = "default"; + + pci@0,0 { + device_type = "pci"; + reg = <0x0 0x0 0x0 0x0 0x0>; + reset-gpios = <&pinctrl_ap 152 0>; + max-link-speed = <2>; + + #address-cells = <3>; + #size-cells = <2>; + ranges; + }; + + pci@1,0 { + device_type = "pci"; + reg = <0x800 0x0 0x0 0x0 0x0>; + reset-gpios = <&pinctrl_ap 153 0>; + max-link-speed = <2>; + + #address-cells = <3>; + #size-cells = <2>; + ranges; + }; + + pci@2,0 { + device_type = "pci"; + reg = <0x1000 0x0 0x0 0x0 0x0>; + reset-gpios = <&pinctrl_ap 33 0>; + max-link-speed = <1>; + + #address-cells = <3>; + #size-cells = <2>; + ranges; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml index b9589a0daa5c..1fe102743f82 100644 --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml @@ -88,6 +88,7 @@ required: allOf: - $ref: /schemas/pci/pci-bus.yaml# + - $ref: /schemas/interrupt-controller/msi-controller.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml index 2911e565b260..acea1cd444fd 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml @@ -41,7 +41,6 @@ properties: - description: builtin MSI controller. interrupt-names: - minItems: 1 items: - const: msi diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml new file mode 100644 index 000000000000..044fa967bc8b --- /dev/null +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml @@ -0,0 +1,142 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/mediatek,mt7621-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek MT7621 PCIe controller + +maintainers: + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +description: |+ + MediaTek MT7621 PCIe subsys supports a single Root Complex (RC) + with 3 Root Ports. Each Root Port supports a Gen1 1-lane Link + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + +properties: + compatible: + const: mediatek,mt7621-pci + + reg: + items: + - description: host-pci bridge registers + - description: pcie port 0 RC control registers + - description: pcie port 1 RC control registers + - description: pcie port 2 RC control registers + + ranges: + maxItems: 2 + +patternProperties: + 'pcie@[0-2],0': + type: object + $ref: /schemas/pci/pci-bus.yaml# + + properties: + resets: + maxItems: 1 + + clocks: + maxItems: 1 + + phys: + maxItems: 1 + + required: + - "#interrupt-cells" + - interrupt-map-mask + - interrupt-map + - resets + - clocks + - phys + - phy-names + - ranges + + unevaluatedProperties: false + +required: + - compatible + - reg + - ranges + - "#interrupt-cells" + - interrupt-map-mask + - interrupt-map + - reset-gpios + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/mips-gic.h> + + pcie: pcie@1e140000 { + compatible = "mediatek,mt7621-pci"; + reg = <0x1e140000 0x100>, + <0x1e142000 0x100>, + <0x1e143000 0x100>, + <0x1e144000 0x100>; + + #address-cells = <3>; + #size-cells = <2>; + pinctrl-names = "default"; + pinctrl-0 = <&pcie_pins>; + device_type = "pci"; + ranges = <0x02000000 0 0x60000000 0x60000000 0 0x10000000>, /* pci memory */ + <0x01000000 0 0x1e160000 0x1e160000 0 0x00010000>; /* io space */ + #interrupt-cells = <1>; + interrupt-map-mask = <0xF800 0 0 0>; + interrupt-map = <0x0000 0 0 0 &gic GIC_SHARED 4 IRQ_TYPE_LEVEL_HIGH>, + <0x0800 0 0 0 &gic GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>, + <0x1000 0 0 0 &gic GIC_SHARED 25 IRQ_TYPE_LEVEL_HIGH>; + reset-gpios = <&gpio 19 GPIO_ACTIVE_LOW>; + + pcie@0,0 { + reg = <0x0000 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SHARED 4 IRQ_TYPE_LEVEL_HIGH>; + resets = <&rstctrl 24>; + clocks = <&clkctrl 24>; + phys = <&pcie0_phy 1>; + phy-names = "pcie-phy0"; + ranges; + }; + + pcie@1,0 { + reg = <0x0800 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>; + resets = <&rstctrl 25>; + clocks = <&clkctrl 25>; + phys = <&pcie0_phy 1>; + phy-names = "pcie-phy1"; + ranges; + }; + + pcie@2,0 { + reg = <0x1000 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SHARED 25 IRQ_TYPE_LEVEL_HIGH>; + resets = <&rstctrl 26>; + clocks = <&clkctrl 26>; + phys = <&pcie2_phy 0>; + phy-names = "pcie-phy2"; + ranges; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml index fb95c276a986..7b0776457178 100644 --- a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml @@ -11,6 +11,7 @@ maintainers: allOf: - $ref: /schemas/pci/pci-bus.yaml# + - $ref: /schemas/interrupt-controller/msi-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt index 6a99d2aa8075..8e4f9bfb316d 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt @@ -197,7 +197,7 @@ Tegra194 RC mode: Tegra194 EP mode: ----------------- - pcie_ep@141a0000 { + pcie-ep@141a0000 { compatible = "nvidia,tegra194-pcie-ep", "snps,dw-pcie-ep"; power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8A>; reg = <0x00 0x141a0000 0x0 0x00020000 /* appl registers (128K) */ diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml new file mode 100644 index 000000000000..3d23599e5e91 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml @@ -0,0 +1,158 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/qcom,pcie-ep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm PCIe Endpoint Controller binding + +maintainers: + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> + +allOf: + - $ref: "pci-ep.yaml#" + +properties: + compatible: + const: qcom,sdx55-pcie-ep + + reg: + items: + - description: Qualcomm-specific PARF configuration registers + - description: DesignWare PCIe registers + - description: External local bus interface registers + - description: Address Translation Unit (ATU) registers + - description: Memory region used to map remote RC address space + - description: BAR memory region + + reg-names: + items: + - const: parf + - const: dbi + - const: elbi + - const: atu + - const: addr_space + - const: mmio + + clocks: + items: + - description: PCIe Auxiliary clock + - description: PCIe CFG AHB clock + - description: PCIe Master AXI clock + - description: PCIe Slave AXI clock + - description: PCIe Slave Q2A AXI clock + - description: PCIe Sleep clock + - description: PCIe Reference clock + + clock-names: + items: + - const: aux + - const: cfg + - const: bus_master + - const: bus_slave + - const: slave_q2a + - const: sleep + - const: ref + + qcom,perst-regs: + description: Reference to a syscon representing TCSR followed by the two + offsets within syscon for Perst enable and Perst separation + enable registers + $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + minItems: 3 + maxItems: 3 + + interrupts: + items: + - description: PCIe Global interrupt + - description: PCIe Doorbell interrupt + + interrupt-names: + items: + - const: global + - const: doorbell + + reset-gpios: + description: GPIO used as PERST# input signal + maxItems: 1 + + wake-gpios: + description: GPIO used as WAKE# output signal + maxItems: 1 + + resets: + maxItems: 1 + + reset-names: + const: core + + power-domains: + maxItems: 1 + + phys: + maxItems: 1 + + phy-names: + const: pciephy + + num-lanes: + default: 2 + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - qcom,perst-regs + - interrupts + - interrupt-names + - reset-gpios + - resets + - reset-names + - power-domains + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sdx55.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + pcie_ep: pcie-ep@40000000 { + compatible = "qcom,sdx55-pcie-ep"; + reg = <0x01c00000 0x3000>, + <0x40000000 0xf1d>, + <0x40000f20 0xc8>, + <0x40001000 0x1000>, + <0x40002000 0x1000>, + <0x01c03000 0x3000>; + reg-names = "parf", "dbi", "elbi", "atu", "addr_space", + "mmio"; + + clocks = <&gcc GCC_PCIE_AUX_CLK>, + <&gcc GCC_PCIE_CFG_AHB_CLK>, + <&gcc GCC_PCIE_MSTR_AXI_CLK>, + <&gcc GCC_PCIE_SLV_AXI_CLK>, + <&gcc GCC_PCIE_SLV_Q2A_AXI_CLK>, + <&gcc GCC_PCIE_SLEEP_CLK>, + <&gcc GCC_PCIE_0_CLKREF_CLK>; + clock-names = "aux", "cfg", "bus_master", "bus_slave", + "slave_q2a", "sleep", "ref"; + + qcom,perst-regs = <&tcsr 0xb258 0xb270>; + + interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "global", "doorbell"; + reset-gpios = <&tlmm 57 GPIO_ACTIVE_LOW>; + wake-gpios = <&tlmm 53 GPIO_ACTIVE_LOW>; + resets = <&gcc GCC_PCIE_BCR>; + reset-names = "core"; + power-domains = <&gcc PCIE_GDSC>; + phys = <&pcie0_lane>; + phy-names = "pciephy"; + max-link-speed = <3>; + num-lanes = <2>; + }; diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt index 3f646875f8c2..a0ae024c2d0c 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt @@ -12,6 +12,7 @@ - "qcom,pcie-ipq4019" for ipq4019 - "qcom,pcie-ipq8074" for ipq8074 - "qcom,pcie-qcs404" for qcs404 + - "qcom,pcie-sc8180x" for sc8180x - "qcom,pcie-sdm845" for sdm845 - "qcom,pcie-sm8250" for sm8250 - "qcom,pcie-ipq6018" for ipq6018 @@ -156,7 +157,7 @@ - "pipe" PIPE clock - clock-names: - Usage: required for sm8250 + Usage: required for sc8180x and sm8250 Value type: <stringlist> Definition: Should contain the following entries - "aux" Auxiliary clock @@ -245,7 +246,7 @@ - "ahb" AHB reset - reset-names: - Usage: required for sdm845 and sm8250 + Usage: required for sc8180x, sdm845 and sm8250 Value type: <stringlist> Definition: Should contain the following entries - "pci" PCIe core reset diff --git a/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml b/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml index 295840cf612f..32a3b7665ff5 100644 --- a/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml +++ b/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml @@ -19,6 +19,7 @@ properties: - renesas,r8a774b1-pcie-ep # RZ/G2N - renesas,r8a774c0-pcie-ep # RZ/G2E - renesas,r8a774e1-pcie-ep # RZ/G2H + - renesas,r8a7795-pcie-ep # R-Car H3 - const: renesas,rcar-gen3-pcie-ep # R-Car Gen3 and RZ/G2 reg: diff --git a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml new file mode 100644 index 000000000000..142bbe577763 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml @@ -0,0 +1,141 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/rockchip-dw-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DesignWare based PCIe controller on Rockchip SoCs + +maintainers: + - Shawn Lin <shawn.lin@rock-chips.com> + - Simon Xue <xxm@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +description: |+ + RK3568 SoC PCIe host controller is based on the Synopsys DesignWare + PCIe IP and thus inherits all the common properties defined in + designware-pcie.txt. + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + +# We need a select here so we don't match all nodes with 'snps,dw-pcie' +select: + properties: + compatible: + contains: + const: rockchip,rk3568-pcie + required: + - compatible + +properties: + compatible: + items: + - const: rockchip,rk3568-pcie + - const: snps,dw-pcie + + reg: + items: + - description: Data Bus Interface (DBI) registers + - description: Rockchip designed configuration registers + - description: Config registers + + reg-names: + items: + - const: dbi + - const: apb + - const: config + + clocks: + items: + - description: AHB clock for PCIe master + - description: AHB clock for PCIe slave + - description: AHB clock for PCIe dbi + - description: APB clock for PCIe + - description: Auxiliary clock for PCIe + + clock-names: + items: + - const: aclk_mst + - const: aclk_slv + - const: aclk_dbi + - const: pclk + - const: aux + + msi-map: true + + num-lanes: true + + phys: + maxItems: 1 + + phy-names: + const: pcie-phy + + power-domains: + maxItems: 1 + + ranges: + maxItems: 2 + + resets: + maxItems: 1 + + reset-names: + const: pipe + + vpcie3v3-supply: true + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - msi-map + - num-lanes + - phys + - phy-names + - power-domains + - resets + - reset-names + +unevaluatedProperties: false + +examples: + - | + + bus { + #address-cells = <2>; + #size-cells = <2>; + + pcie3x2: pcie@fe280000 { + compatible = "rockchip,rk3568-pcie", "snps,dw-pcie"; + reg = <0x3 0xc0800000 0x0 0x390000>, + <0x0 0xfe280000 0x0 0x10000>, + <0x3 0x80000000 0x0 0x100000>; + reg-names = "dbi", "apb", "config"; + bus-range = <0x20 0x2f>; + clocks = <&cru 143>, <&cru 144>, + <&cru 145>, <&cru 146>, + <&cru 147>; + clock-names = "aclk_mst", "aclk_slv", + "aclk_dbi", "pclk", + "aux"; + device_type = "pci"; + linux,pci-domain = <2>; + max-link-speed = <2>; + msi-map = <0x2000 &its 0x2000 0x1000>; + num-lanes = <2>; + phys = <&pcie30phy>; + phy-names = "pcie-phy"; + power-domains = <&power 15>; + ranges = <0x81000000 0x0 0x80800000 0x3 0x80800000 0x0 0x100000>, + <0x83000000 0x0 0x80900000 0x3 0x80900000 0x0 0x3f700000>; + resets = <&cru 193>; + reset-names = "pipe"; + #address-cells = <3>; + #size-cells = <2>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml index 05b4dcd80019..426101530a21 100644 --- a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml @@ -18,13 +18,21 @@ properties: const: brcm,ns-usb2-phy reg: - items: - - description: iomem address range of DMU (Device Management Unit) + anyOf: + - maxItems: 1 + description: PHY control register + - maxItems: 1 + description: iomem address range of DMU (Device Management Unit) + deprecated: true reg-names: items: - const: dmu + brcm,syscon-clkset: + description: phandle to syscon for clkset register + $ref: /schemas/types.yaml#/definitions/phandle + clocks: items: - description: USB PHY reference clock @@ -39,20 +47,25 @@ properties: required: - compatible - reg - - reg-names - clocks - clock-names - "#phy-cells" +oneOf: + - required: + - brcm,syscon-clkset + - required: + - reg-names + additionalProperties: false examples: - | #include <dt-bindings/clock/bcm-nsp.h> - phy@1800c000 { + phy@1800c164 { compatible = "brcm,ns-usb2-phy"; - reg = <0x1800c000 0x1000>; - reg-names = "dmu"; + reg = <0x1800c164 0x4>; + brcm,syscon-clkset = <&clkset>; clocks = <&genpll BCM_NSP_GENPLL_USB_PHY_REF_CLK>; clock-names = "phy-ref-clk"; #phy-cells = <0>; diff --git a/Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml b/Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml index 0fd93d71fe5a..5cab21648632 100644 --- a/Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml +++ b/Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml @@ -46,7 +46,7 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/jz4770-cgu.h> + #include <dt-bindings/clock/ingenic,jz4770-cgu.h> otg_phy: usb-phy@3c { compatible = "ingenic,jz4770-phy"; reg = <0x3c 0x10>; diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.txt deleted file mode 100644 index 1aa6f2674af5..000000000000 --- a/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.txt +++ /dev/null @@ -1,74 +0,0 @@ -Tegra SOC USB PHY - -The device node for Tegra SOC USB PHY: - -Required properties : - - compatible : For Tegra20, must contain "nvidia,tegra20-usb-phy". - For Tegra30, must contain "nvidia,tegra30-usb-phy". Otherwise, must contain - "nvidia,<chip>-usb-phy" plus at least one of the above, where <chip> is - tegra114, tegra124, tegra132, or tegra210. - - reg : Defines the following set of registers, in the order listed: - - The PHY's own register set. - Always present. - - The register set of the PHY containing the UTMI pad control registers. - Present if-and-only-if phy_type == utmi. - - phy_type : Should be one of "utmi", "ulpi" or "hsic". - - clocks : Defines the clocks listed in the clock-names property. - - clock-names : The following clock names must be present: - - reg: The clock needed to access the PHY's own registers. This is the - associated EHCI controller's clock. Always present. - - pll_u: PLL_U. Always present. - - timer: The timeout clock (clk_m). Present if phy_type == utmi. - - utmi-pads: The clock needed to access the UTMI pad control registers. - Present if phy_type == utmi. - - ulpi-link: The clock Tegra provides to the ULPI PHY (usually pad DAP_MCLK2 - with pad group aka "nvidia,pins" cdev2 and pin mux option config aka - "nvidia,function" pllp_out4). - Present if phy_type == ulpi, and ULPI link mode is in use. - - resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names : Must include the following entries: - - usb: The PHY's own reset signal. - - utmi-pads: The reset of the PHY containing the chip-wide UTMI pad control - registers. Required even if phy_type == ulpi. - -Required properties for phy_type == ulpi: - - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. - -Required PHY timing params for utmi phy, for all chips: - - nvidia,hssync-start-delay : Number of 480 Mhz clock cycles to wait before - start of sync launches RxActive - - nvidia,elastic-limit : Variable FIFO Depth of elastic input store - - nvidia,idle-wait-delay : Number of 480 Mhz clock cycles of idle to wait - before declare IDLE. - - nvidia,term-range-adj : Range adjusment on terminations - - Either one of the following for HS driver output control: - - nvidia,xcvr-setup : integer, uses the provided value. - - nvidia,xcvr-setup-use-fuses : boolean, indicates that the value is read - from the on-chip fuses - If both are provided, nvidia,xcvr-setup-use-fuses takes precedence. - - nvidia,xcvr-lsfslew : LS falling slew rate control. - - nvidia,xcvr-lsrslew : LS rising slew rate control. - -Required PHY timing params for utmi phy, only on Tegra30 and above: - - nvidia,xcvr-hsslew : HS slew rate control. - - nvidia,hssquelch-level : HS squelch detector level. - - nvidia,hsdiscon-level : HS disconnect detector level. - -Optional properties: - - nvidia,has-legacy-mode : boolean indicates whether this controller can - operate in legacy mode (as APX 2500 / 2600). In legacy mode some - registers are accessed through the APB_MISC base address instead of - the USB controller. - - nvidia,is-wired : boolean. Indicates whether we can do certain kind of power - optimizations for the devices that are always connected. e.g. modem. - - dr_mode : dual role mode. Indicates the working mode for the PHY. Can be - "host", "peripheral", or "otg". Defaults to "host" if not defined. - host means this is a host controller - peripheral means it is device controller - otg means it can operate as either ("on the go") - - nvidia,has-utmi-pad-registers : boolean indicates whether this controller - contains the UTMI pad control registers common to all USB controllers. - -VBUS control (required for dr_mode == otg, optional for dr_mode == host): - - vbus-supply: regulator for VBUS diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.yaml new file mode 100644 index 000000000000..dfde0eaf66e1 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.yaml @@ -0,0 +1,373 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/nvidia,tegra20-usb-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra USB PHY + +maintainers: + - Dmitry Osipenko <digetx@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - nvidia,tegra124-usb-phy + - nvidia,tegra114-usb-phy + - enum: + - nvidia,tegra30-usb-phy + - items: + - enum: + - nvidia,tegra30-usb-phy + - nvidia,tegra20-usb-phy + + reg: + minItems: 1 + maxItems: 2 + description: | + PHY0 and PHY2 share power and ground, PHY0 contains shared registers. + PHY0 and PHY2 must specify two register sets, where the first set is + PHY own registers and the second set is the PHY0 registers. + + clocks: + anyOf: + - items: + - description: Registers clock + - description: Main PHY clock + + - items: + - description: Registers clock + - description: Main PHY clock + - description: ULPI PHY clock + + - items: + - description: Registers clock + - description: Main PHY clock + - description: UTMI pads control registers clock + + - items: + - description: Registers clock + - description: Main PHY clock + - description: UTMI timeout clock + - description: UTMI pads control registers clock + + clock-names: + oneOf: + - items: + - const: reg + - const: pll_u + + - items: + - const: reg + - const: pll_u + - const: ulpi-link + + - items: + - const: reg + - const: pll_u + - const: utmi-pads + + - items: + - const: reg + - const: pll_u + - const: timer + - const: utmi-pads + + interrupts: + maxItems: 1 + + resets: + oneOf: + - maxItems: 1 + description: PHY reset + + - items: + - description: PHY reset + - description: UTMI pads reset + + reset-names: + oneOf: + - const: usb + + - items: + - const: usb + - const: utmi-pads + + "#phy-cells": + const: 0 + + phy_type: + $ref: /schemas/types.yaml#/definitions/string + enum: [utmi, ulpi, hsic] + + dr_mode: + $ref: /schemas/types.yaml#/definitions/string + enum: [host, peripheral, otg] + default: host + + vbus-supply: + description: Regulator controlling USB VBUS. + + nvidia,has-legacy-mode: + description: | + Indicates whether this controller can operate in legacy mode + (as APX 2500 / 2600). In legacy mode some registers are accessed + through the APB_MISC base address instead of the USB controller. + type: boolean + + nvidia,is-wired: + description: | + Indicates whether we can do certain kind of power optimizations for + the devices that are always connected. e.g. modem. + type: boolean + + nvidia,has-utmi-pad-registers: + description: | + Indicates whether this controller contains the UTMI pad control + registers common to all USB controllers. + type: boolean + + nvidia,hssync-start-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: | + Number of 480 MHz clock cycles to wait before start of sync launches + RxActive. + + nvidia,elastic-limit: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Variable FIFO Depth of elastic input store. + + nvidia,idle-wait-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: | + Number of 480 MHz clock cycles of idle to wait before declare IDLE. + + nvidia,term-range-adj: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Range adjustment on terminations. + + nvidia,xcvr-setup: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 127 + description: Input of XCVR cell, HS driver output control. + + nvidia,xcvr-setup-use-fuses: + description: Indicates that the value is read from the on-chip fuses. + type: boolean + + nvidia,xcvr-lsfslew: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + description: LS falling slew rate control. + + nvidia,xcvr-lsrslew: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + description: LS rising slew rate control. + + nvidia,xcvr-hsslew: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 511 + description: HS slew rate control. + + nvidia,hssquelch-level: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + description: HS squelch detector level. + + nvidia,hsdiscon-level: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + description: HS disconnect detector level. + + nvidia,phy-reset-gpio: + maxItems: 1 + description: GPIO used to reset the PHY. + + nvidia,pmc: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: Phandle to Power Management controller. + - description: USB controller ID. + description: + Phandle to Power Management controller. + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - "#phy-cells" + - phy_type + +additionalProperties: false + +allOf: + - if: + properties: + phy_type: + const: utmi + + then: + properties: + reg: + minItems: 2 + maxItems: 2 + + resets: + maxItems: 2 + + reset-names: + maxItems: 2 + + required: + - nvidia,hssync-start-delay + - nvidia,elastic-limit + - nvidia,idle-wait-delay + - nvidia,term-range-adj + - nvidia,xcvr-lsfslew + - nvidia,xcvr-lsrslew + + anyOf: + - required: ["nvidia,xcvr-setup"] + - required: ["nvidia,xcvr-setup-use-fuses"] + + if: + properties: + compatible: + contains: + const: nvidia,tegra30-usb-phy + + then: + properties: + clocks: + maxItems: 3 + + clock-names: + items: + - const: reg + - const: pll_u + - const: utmi-pads + + required: + - nvidia,xcvr-hsslew + - nvidia,hssquelch-level + - nvidia,hsdiscon-level + + else: + properties: + clocks: + maxItems: 4 + + clock-names: + items: + - const: reg + - const: pll_u + - const: timer + - const: utmi-pads + + - if: + properties: + phy_type: + const: ulpi + + then: + properties: + reg: + minItems: 1 + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + minItems: 2 + maxItems: 3 + + oneOf: + - items: + - const: reg + - const: pll_u + + - items: + - const: reg + - const: pll_u + - const: ulpi-link + + resets: + minItems: 1 + maxItems: 2 + + reset-names: + minItems: 1 + maxItems: 2 + +examples: + - | + #include <dt-bindings/clock/tegra124-car.h> + + usb-phy@7d008000 { + compatible = "nvidia,tegra124-usb-phy", "nvidia,tegra30-usb-phy"; + reg = <0x7d008000 0x4000>, + <0x7d000000 0x4000>; + interrupts = <0 97 4>; + phy_type = "utmi"; + clocks = <&tegra_car TEGRA124_CLK_USB3>, + <&tegra_car TEGRA124_CLK_PLL_U>, + <&tegra_car TEGRA124_CLK_USBD>; + clock-names = "reg", "pll_u", "utmi-pads"; + resets = <&tegra_car 59>, <&tegra_car 22>; + reset-names = "usb", "utmi-pads"; + #phy-cells = <0>; + nvidia,hssync-start-delay = <0>; + nvidia,idle-wait-delay = <17>; + nvidia,elastic-limit = <16>; + nvidia,term-range-adj = <6>; + nvidia,xcvr-setup = <9>; + nvidia,xcvr-lsfslew = <0>; + nvidia,xcvr-lsrslew = <3>; + nvidia,hssquelch-level = <2>; + nvidia,hsdiscon-level = <5>; + nvidia,xcvr-hsslew = <12>; + nvidia,pmc = <&tegra_pmc 2>; + }; + + - | + #include <dt-bindings/clock/tegra20-car.h> + + usb-phy@c5004000 { + compatible = "nvidia,tegra20-usb-phy"; + reg = <0xc5004000 0x4000>; + interrupts = <0 21 4>; + phy_type = "ulpi"; + clocks = <&tegra_car TEGRA20_CLK_USB2>, + <&tegra_car TEGRA20_CLK_PLL_U>, + <&tegra_car TEGRA20_CLK_CDEV2>; + clock-names = "reg", "pll_u", "ulpi-link"; + resets = <&tegra_car 58>, <&tegra_car 22>; + reset-names = "usb", "utmi-pads"; + #phy-cells = <0>; + nvidia,pmc = <&tegra_pmc 1>; + }; diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml index 3329f1d33a4f..267b695215b6 100644 --- a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml +++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml @@ -24,7 +24,7 @@ description: |_ UTMI switch_______| OTG controller maintainers: - - Amelie Delaunay <amelie.delaunay@st.com> + - Amelie Delaunay <amelie.delaunay@foss.st.com> properties: compatible: @@ -81,6 +81,119 @@ patternProperties: properties: vbus-supply: true + # It can be necessary to adjust the PHY settings to compensate parasitics, which can be due + # to USB connector/receptacle, routing, ESD protection component,... Here is the list of + # all optional parameters to tune the interface of the PHY (HS for High-Speed, FS for Full- + # Speed, LS for Low-Speed) + + st,current-boost-microamp: + description: Current boosting in uA + enum: [ 1000, 2000 ] + + st,no-lsfs-fb-cap: + description: Disables the LS/FS feedback capacitor + type: boolean + + st,decrease-hs-slew-rate: + description: Decreases the HS driver slew rate by 10% + type: boolean + + st,tune-hs-dc-level: + description: | + Tunes the HS driver DC level + - <0> normal level + - <1> increases the level by 5 to 7 mV + - <2> increases the level by 10 to 14 mV + - <3> decreases the level by 5 to 7 mV + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + default: 0 + + st,enable-fs-rftime-tuning: + description: Enables the FS rise/fall tuning option + type: boolean + + st,enable-hs-rftime-reduction: + description: Enables the HS rise/fall reduction feature + type: boolean + + st,trim-hs-current: + description: | + Controls HS driver current trimming for choke compensation + - <0> = 18.87 mA target current / nominal + 0% + - <1> = 19.165 mA target current / nominal + 1.56% + - <2> = 19.46 mA target current / nominal + 3.12% + - <3> = 19.755 mA target current / nominal + 4.68% + - <4> = 20.05 mA target current / nominal + 6.24% + - <5> = 20.345 mA target current / nominal + 7.8% + - <6> = 20.64 mA target current / nominal + 9.36% + - <7> = 20.935 mA target current / nominal + 10.92% + - <8> = 21.23 mA target current / nominal + 12.48% + - <9> = 21.525 mA target current / nominal + 14.04% + - <10> = 21.82 mA target current / nominal + 15.6% + - <11> = 22.115 mA target current / nominal + 17.16% + - <12> = 22.458 mA target current / nominal + 19.01% + - <13> = 22.755 mA target current / nominal + 20.58% + - <14> = 23.052 mA target current / nominal + 22.16% + - <15> = 23.348 mA target current / nominal + 23.73% + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + default: 0 + + st,trim-hs-impedance: + description: | + Controls HS driver impedance tuning for choke compensation + - <0> = no impedance offset + - <1> = reduce the impedance by 2 ohms + - <2> = reduce the impedance by 4 ohms + - <3> = reduce the impedance by 6 ohms + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + default: 0 + + st,tune-squelch-level: + description: | + Tunes the squelch DC threshold value + - <0> = no shift in threshold + - <1> = threshold shift by +7 mV + - <2> = threshold shift by -5 mV + - <3> = threshold shift by +14 mV + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + default: 0 + + st,enable-hs-rx-gain-eq: + description: Enables the HS Rx gain equalizer + type: boolean + + st,tune-hs-rx-offset: + description: | + Adjusts the HS Rx offset + - <0> = no offset + - <1> = offset of +5 mV + - <2> = offset of +10 mV + - <3> = offset of -5 mV + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + default: 0 + + st,no-hs-ftime-ctrl: + description: Disables the HS fall time control of single ended signals during pre-emphasis + type: boolean + + st,no-lsfs-sc: + description: Disables the short circuit protection in LS/FS driver + type: boolean + + st,enable-hs-tx-staggering: + description: Enables the basic staggering in HS Tx mode + type: boolean + allOf: - if: properties: @@ -137,6 +250,14 @@ examples: reg = <0>; phy-supply = <&vdd_usb>; #phy-cells = <0>; + st,tune-hs-dc-level = <2>; + st,enable-fs-rftime-tuning; + st,enable-hs-rftime-reduction; + st,trim-hs-current = <15>; + st,trim-hs-impedance = <1>; + st,tune-squelch-level = <3>; + st,tune-hs-rx-offset = <2>; + st,no-lsfs-sc; connector { compatible = "usb-a-connector"; vbus-supply = <&vbus_sw>; @@ -147,6 +268,14 @@ examples: reg = <1>; phy-supply = <&vdd_usb>; #phy-cells = <1>; + st,tune-hs-dc-level = <2>; + st,enable-fs-rftime-tuning; + st,enable-hs-rftime-reduction; + st,trim-hs-current = <15>; + st,trim-hs-impedance = <1>; + st,tune-squelch-level = <3>; + st,tune-hs-rx-offset = <2>; + st,no-lsfs-sc; }; }; ... diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index 75be5650a198..630ceaf915e2 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: Qualcomm QMP PHY controller maintainers: - - Manu Gautam <mgautam@codeaurora.org> + - Vinod Koul <vkoul@kernel.org> description: QMP phy controller supports physical layer functionality for a number of @@ -27,6 +27,7 @@ properties: - qcom,msm8998-qmp-pcie-phy - qcom,msm8998-qmp-ufs-phy - qcom,msm8998-qmp-usb3-phy + - qcom,qcm2290-qmp-usb3-phy - qcom,sc7180-qmp-usb3-phy - qcom,sc8180x-qmp-pcie-phy - qcom,sc8180x-qmp-ufs-phy @@ -116,8 +117,6 @@ required: - clock-names - resets - reset-names - - vdda-phy-supply - - vdda-pll-supply additionalProperties: false @@ -150,6 +149,9 @@ allOf: items: - const: phy - const: common + required: + - vdda-phy-supply + - vdda-pll-supply - if: properties: compatible: @@ -176,6 +178,9 @@ allOf: items: - const: phy - const: common + required: + - vdda-phy-supply + - vdda-pll-supply - if: properties: compatible: @@ -204,6 +209,9 @@ allOf: - const: phy - const: common - const: cfg + required: + - vdda-phy-supply + - vdda-pll-supply - if: properties: compatible: @@ -233,6 +241,9 @@ allOf: items: - const: phy - const: common + required: + - vdda-phy-supply + - vdda-pll-supply - if: properties: compatible: @@ -253,6 +264,9 @@ allOf: reset-names: items: - const: ufsphy + required: + - vdda-phy-supply + - vdda-pll-supply - if: properties: compatible: @@ -278,34 +292,16 @@ allOf: reset-names: items: - const: ufsphy - - if: - properties: - compatible: - contains: - enum: - - qcom,ipq8074-qmp-pcie-phy - then: - properties: - clocks: - items: - - description: pipe clk. - clock-names: - items: - - const: pipe_clk - resets: - items: - - description: reset of phy block. - - description: phy common block reset. - reset-names: - items: - - const: phy - - const: common + required: + - vdda-phy-supply + - vdda-pll-supply - if: properties: compatible: contains: enum: - qcom,ipq6018-qmp-pcie-phy + - qcom,ipq8074-qmp-pcie-phy then: properties: clocks: @@ -356,6 +352,9 @@ allOf: reset-names: items: - const: phy + required: + - vdda-phy-supply + - vdda-pll-supply - if: properties: compatible: @@ -387,6 +386,9 @@ allOf: items: - const: phy - const: common + required: + - vdda-phy-supply + - vdda-pll-supply - if: properties: compatible: @@ -414,6 +416,38 @@ allOf: items: - const: phy - const: common + required: + - vdda-phy-supply + - vdda-pll-supply + - if: + properties: + compatible: + contains: + enum: + - qcom,qcm2290-qmp-usb3-phy + then: + properties: + clocks: + items: + - description: Phy config clock. + - description: 19.2 MHz ref clk. + - description: Phy common block aux clock. + clock-names: + items: + - const: cfg_ahb + - const: ref + - const: com_aux + resets: + items: + - description: phy_phy reset. + - description: reset of phy block. + reset-names: + items: + - const: phy_phy + - const: phy + required: + - vdda-phy-supply + - vdda-pll-supply examples: - | diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index ec9ccaaba098..aa2e409a1a09 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -21,6 +21,7 @@ properties: - qcom,ipq8074-qusb2-phy - qcom,msm8996-qusb2-phy - qcom,msm8998-qusb2-phy + - qcom,qcm2290-qusb2-phy - qcom,sdm660-qusb2-phy - qcom,ipq6018-qusb2-phy - qcom,sm4250-qusb2-phy @@ -50,6 +51,10 @@ properties: - const: ref - const: iface + vdd-supply: + description: + Phandle to 0.9V regulator supply to PHY digital circuit. + vdda-pll-supply: description: Phandle to 1.8V regulator supply to PHY refclk pll block. @@ -156,6 +161,7 @@ required: - "#phy-cells" - clocks - clock-names + - vdd-supply - vdda-pll-supply - vdda-phy-dpdm-supply - resets @@ -174,6 +180,7 @@ examples: <&gcc GCC_RX1_USB2_CLKREF_CLK>; clock-names = "cfg_ahb", "ref"; + vdd-supply = <&pm8994_l28>; vdda-pll-supply = <&pm8994_l12>; vdda-phy-dpdm-supply = <&pm8994_l24>; diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.yaml index f0fc8275dcd0..499d55131aa8 100644 --- a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.yaml @@ -11,13 +11,10 @@ maintainers: properties: compatible: - oneOf: - - const: rockchip,rk3288-usb-phy - - items: - - enum: - - rockchip,rk3066a-usb-phy - - rockchip,rk3188-usb-phy - - const: rockchip,rk3288-usb-phy + enum: + - rockchip,rk3066a-usb-phy + - rockchip,rk3188-usb-phy + - rockchip,rk3288-usb-phy "#address-cells": const: 1 diff --git a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml index d50571affd1f..07b00de79755 100644 --- a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml @@ -34,6 +34,10 @@ properties: gpio-ranges: maxItems: 1 + apple,npins: + $ref: /schemas/types.yaml#/definitions/uint32 + description: The number of pins in this GPIO controller. + interrupts: description: One interrupt for each of the (up to 7) interrupt groups supported by the controller sorted by interrupt group @@ -43,6 +47,9 @@ properties: interrupt-controller: true + '#interrupt-cells': + const: 2 + patternProperties: '-pins$': type: object @@ -66,6 +73,7 @@ required: - gpio-controller - '#gpio-cells' - gpio-ranges + - apple,npins additionalProperties: false @@ -86,8 +94,10 @@ examples: gpio-controller; #gpio-cells = <2>; gpio-ranges = <&pinctrl 0 0 212>; + apple,npins = <212>; interrupt-controller; + #interrupt-cells = <2>; interrupt-parent = <&aic>; interrupts = <AIC_IRQ 16 IRQ_TYPE_LEVEL_HIGH>, <AIC_IRQ 17 IRQ_TYPE_LEVEL_HIGH>, diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml index 470aff599c27..fc39e3e9f71c 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml @@ -17,9 +17,6 @@ description: A list of pins varies across chipsets so few bindings are available. - Node of the pinmux must be nested in the CRU (Central Resource Unit) "syscon" - node. - properties: compatible: enum: @@ -27,10 +24,11 @@ properties: - brcm,bcm4709-pinmux - brcm,bcm53012-pinmux - offset: - description: offset of pin registers in the CRU block + reg: maxItems: 1 - $ref: /schemas/types.yaml#/definitions/uint32-array + + reg-names: + const: cru_gpio_control patternProperties: '-pins$': @@ -72,23 +70,20 @@ allOf: uart1_grp ] required: - - offset + - reg + - reg-names additionalProperties: false examples: - | - cru@1800c100 { - compatible = "syscon", "simple-mfd"; - reg = <0x1800c100 0x1a4>; - - pinctrl { - compatible = "brcm,bcm4708-pinmux"; - offset = <0xc0>; - - spi-pins { - function = "spi"; - groups = "spi_grp"; - }; + pin-controller@1800c1c0 { + compatible = "brcm,bcm4708-pinmux"; + reg = <0x1800c1c0 0x24>; + reg-names = "cru_gpio_control"; + + spi-pins { + function = "spi"; + groups = "spi_grp"; }; }; diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml new file mode 100644 index 000000000000..7602b11e8bce --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml @@ -0,0 +1,363 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7986-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT7986 Pin Controller Device Tree Bindings + +maintainers: + - Sean Wang <sean.wang@kernel.org> + +description: |+ + The MediaTek's MT7986 Pin controller is used to control SoC pins. + +properties: + compatible: + enum: + - mediatek,mt7986a-pinctrl + - mediatek,mt7986b-pinctrl + + reg: + minItems: 8 + maxItems: 8 + + reg-names: + items: + - const: gpio + - const: iocfg_rt + - const: iocfg_rb + - const: iocfg_lt + - const: iocfg_lb + - const: iocfg_tr + - const: iocfg_tl + - const: eint + + gpio-controller: true + + "#gpio-cells": + const: 2 + description: | + Number of cells in GPIO specifier. Since the generic GPIO + binding is used, the amount of cells must be specified as 2. See the below + mentioned gpio binding representation for description of particular cells. + + gpio-ranges: + minItems: 1 + maxItems: 5 + description: | + GPIO valid number range. + + interrupt-controller: true + + interrupts: + maxItems: 1 + + "#interrupt-cells": + const: 2 + +required: + - compatible + - reg + - reg-names + - gpio-controller + - "#gpio-cells" + +patternProperties: + '-pins$': + type: object + additionalProperties: false + + patternProperties: + '.*mux.*': + type: object + additionalProperties: false + description: | + pinmux configuration nodes. + + The following table shows the effective values of "group", "function" + properties and chip pinout pins + + groups function pins (in pin#) + --------------------------------------------------------------------- + "watchdog" "watchdog" 0 + "wifi_led" "led" 1, 2 + "i2c" "i2c" 3, 4 + "uart1_0" "uart" 7, 8, 9, 10 + "pcie_clk" "pcie" 9 + "pcie_wake" "pcie" 10 + "spi1_0" "spi" 11, 12, 13, 14 + "pwm1_1" "pwm" 20, + "pwm0" "pwm" 21, + "pwm1_0" "pwm" 22, + "snfi" "flash" 23, 24, 25, 26, 27, 28 + "spi1_2" "spi" 29, 30, 31, 32 + "emmc_45" "emmc" 22, 23, 24, 25, 26, 27, 28, 29, 30, + 31, 32 + "spi1_1" "spi" 23, 24, 25, 26 + "uart1_2" "uart" 29, 30, 31, 32 + "uart1_1" "uart" 23, 24, 25, 26 + "uart2_0" "uart" 29, 30, 31, 32 + "spi0" "spi" 33, 34, 35, 36 + "spi0_wp_hold" "spi" 37, 38 + "uart1_3_rx_tx" "uart" 35, 36 + "uart1_3_cts_rts" "uart" 37, 38 + "uart2_1" "uart" 33, 34, 35, 36 + "spi1_3" "spi" 33, 34, 35, 36 + "uart0" "uart" 39, 40 + "pcie_pereset" "pcie" 41 + "uart1" "uart" 42, 43, 44, 45 + "uart2" "uart" 46, 47, 48, 49 + "emmc_51" "emmc" 50, 51, 52, 53, 54, 55, 56, 57, 57, + 59, 60, 61 + "pcm" "audio" 62, 63, 64, 65 + "i2s" "audio" 62, 63, 64, 65 + "switch_int" "eth" 66 + "mdc_mdio" "eth" 67 + + $ref: "/schemas/pinctrl/pinmux-node.yaml" + properties: + function: + description: | + A string containing the name of the function to mux to the group. + There is no "audio", "pcie" functions on mt7986b, you can only use + those functions on mt7986a. + enum: [audio, emmc, eth, i2c, led, flash, pcie, pwm, spi, uart, + watchdog, wifi] + groups: + description: | + An array of strings. Each string contains the name of a group. + There is no "pcie_pereset", "uart1", "uart2" "emmc_51", "pcm", + and "i2s" groups on mt7986b, you can only use those groups on + mt7986a. + required: + - function + - groups + + allOf: + - if: + properties: + function: + const: audio + then: + properties: + groups: + enum: [pcm, i2s] + - if: + properties: + function: + const: emmc + then: + properties: + groups: + enum: [emmc, emmc_rst] + - if: + properties: + function: + const: eth + then: + properties: + groups: + enum: [switch_int, mdc_mdio] + - if: + properties: + function: + const: i2c + then: + properties: + groups: + enum: [i2c] + - if: + properties: + function: + const: led + then: + properties: + groups: + enum: [wifi_led] + - if: + properties: + function: + const: flash + then: + properties: + groups: + enum: [snfi] + - if: + properties: + function: + const: pcie + then: + properties: + groups: + enum: [pcie_clk, pcie_wake, pcie_pereset] + - if: + properties: + function: + const: pwm + then: + properties: + groups: + enum: [pwm0, pwm1_0, pwm1_1] + - if: + properties: + function: + const: spi + then: + properties: + groups: + enum: [spi0, spi0_wp_hold, spi1_0, spi1_1, spi1_2, spi1_3] + - if: + properties: + function: + const: uart + then: + properties: + groups: + enum: [uart1_0, uart1_1, uart1_2, uart1_3_rx_tx, + uart1_3_cts_rts, uart2_0, uart2_1, uart0, uart1, uart2] + - if: + properties: + function: + const: watchdog + then: + properties: + groups: + enum: [watchdog] + - if: + properties: + function: + const: wifi + then: + properties: + groups: + enum: [wf_2g, wf_5g, wf_dbdc] + '.*conf.*': + type: object + additionalProperties: false + description: | + pinconf configuration nodes. + $ref: "/schemas/pinctrl/pincfg-node.yaml" + + properties: + pins: + description: | + An array of strings. Each string contains the name of a pin. + There is no PIN 41 to PIN 65 above on mt7686b, you can only use + those pins on mt7986a. + enum: [SYS_WATCHDOG, WF2G_LED, WF5G_LED, I2C_SCL, I2C_SDA, GPIO_0, + GPIO_1, GPIO_2, GPIO_3, GPIO_4, GPIO_5, GPIO_6, GPIO_7, + GPIO_8, GPIO_9, GPIO_10, GPIO_11, GPIO_12, GPIO_13, GPIO_14, + GPIO_15, PWM0, PWM1, SPI0_CLK, SPI0_MOSI, SPI0_MISO, SPI0_CS, + SPI0_HOLD, SPI0_WP, SPI1_CLK, SPI1_MOSI, SPI1_MISO, SPI1_CS, + SPI2_CLK, SPI2_MOSI, SPI2_MISO, SPI2_CS, SPI2_HOLD, SPI2_WP, + UART0_RXD, UART0_TXD, PCIE_PERESET_N, UART1_RXD, UART1_TXD, + UART1_CTS, UART1_RTS, UART2_RXD, UART2_TXD, UART2_CTS, + UART2_RTS, EMMC_DATA_0, EMMC_DATA_1, EMMC_DATA_2, + EMMC_DATA_3, EMMC_DATA_4, EMMC_DATA_5, EMMC_DATA_6, + EMMC_DATA_7, EMMC_CMD, EMMC_CK, EMMC_DSL, EMMC_RSTB, PCM_DTX, + PCM_DRX, PCM_CLK, PCM_FS, MT7531_INT, SMI_MDC, SMI_MDIO, + WF0_DIG_RESETB, WF0_CBA_RESETB, WF0_XO_REQ, WF0_TOP_CLK, + WF0_TOP_DATA, WF0_HB1, WF0_HB2, WF0_HB3, WF0_HB4, WF0_HB0, + WF0_HB0_B, WF0_HB5, WF0_HB6, WF0_HB7, WF0_HB8, WF0_HB9, + WF0_HB10, WF1_DIG_RESETB, WF1_CBA_RESETB, WF1_XO_REQ, + WF1_TOP_CLK, WF1_TOP_DATA, WF1_HB1, WF1_HB2, WF1_HB3, + WF1_HB4, WF1_HB0, WF1_HB0_B, WF1_HB5, WF1_HB6, WF1_HB7, + WF1_HB8] + + bias-disable: true + + bias-pull-up: true + + bias-pull-down: true + + input-enable: true + + input-disable: true + + output-enable: true + + output-low: true + + output-high: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + + mediatek,pull-up-adv: + description: | + Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3' + Pull up setings for 2 pull resistors, R0 and R1. Valid arguments + are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + mediatek,pull-down-adv: + description: | + Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3' + Pull down setings for 2 pull resistors, R0 and R1. Valid arguments + are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + required: + - pins + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + pio: pinctrl@1001f000 { + compatible = "mediatek,mt7986a-pinctrl"; + reg = <0 0x1001f000 0 0x1000>, + <0 0x11c30000 0 0x1000>, + <0 0x11c40000 0 0x1000>, + <0 0x11e20000 0 0x1000>, + <0 0x11e30000 0 0x1000>, + <0 0x11f00000 0 0x1000>, + <0 0x11f10000 0 0x1000>, + <0 0x1000b000 0 0x1000>; + reg-names = "gpio", "iocfg_rt", "iocfg_rb", "iocfg_lt", + "iocfg_lb", "iocfg_tr", "iocfg_tl", "eint"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pio 0 0 100>; + interrupt-controller; + interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>; + interrupt-parent = <&gic>; + #interrupt-cells = <2>; + + uart1_pins: uart1-pins { + mux { + function = "uart"; + groups = "uart1"; + }; + }; + + uart2_pins: uart2-pins { + mux { + function = "uart"; + groups = "uart2"; + }; + }; + + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml index 4fe35e650909..cb554084bdf1 100644 --- a/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml @@ -68,6 +68,13 @@ properties: clock, and larger than zero. default: 12500000 + resets: + maxItems: 1 + + reset-names: + items: + - const: switch + patternProperties: "^gpio@[0-1]$": type: object diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml index e17a399e0904..5e2bb2bf3a55 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml @@ -49,6 +49,12 @@ properties: description: The interrupt outputs to sysirq. maxItems: 1 + mediatek,rsel_resistance_in_si_unit: + type: boolean + description: | + Identifying i2c pins pull up/down type which is RSEL. It can support + RSEL define or si unit value(ohm) to set different resistance. + #PIN CONFIGURATION NODES patternProperties: '-pins$': @@ -82,9 +88,85 @@ patternProperties: drive-strength: enum: [2, 4, 6, 8, 10, 12, 14, 16] - bias-pull-down: true + bias-pull-down: + description: | + For pull down type is normal, it don't need add RSEL & R1R0 define + and resistance value. + For pull down type is PUPD/R0/R1 type, it can add R1R0 define to + set different resistance. It can support "MTK_PUPD_SET_R1R0_00" & + "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & "MTK_PUPD_SET_R1R0_11" + define in mt8195. + For pull down type is RSEL, it can add RSEL define & resistance value(ohm) + to set different resistance by identifying property "mediatek,rsel_resistance_in_si_unit". + It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" + & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" & "MTK_PULL_SET_RSEL_100" + & "MTK_PULL_SET_RSEL_101" & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" + define in mt8195. It can also support resistance value(ohm) "75000" & "5000" in mt8195. + oneOf: + - enum: [100, 101, 102, 103] + - description: mt8195 pull down PUPD/R0/R1 type define value. + - enum: [200, 201, 202, 203, 204, 205, 206, 207] + - description: mt8195 pull down RSEL type define value. + - enum: [75000, 5000] + - description: mt8195 pull down RSEL type si unit value(ohm). + + An example of using RSEL define: + pincontroller { + i2c0_pin { + pinmux = <PINMUX_GPIO8__FUNC_SDA0>; + bias-pull-down = <MTK_PULL_SET_RSEL_001>; + }; + }; + An example of using si unit resistance value(ohm): + &pio { + mediatek,rsel_resistance_in_si_unit; + } + pincontroller { + i2c0_pin { + pinmux = <PINMUX_GPIO8__FUNC_SDA0>; + bias-pull-down = <75000>; + }; + }; - bias-pull-up: true + bias-pull-up: + description: | + For pull up type is normal, it don't need add RSEL & R1R0 define + and resistance value. + For pull up type is PUPD/R0/R1 type, it can add R1R0 define to + set different resistance. It can support "MTK_PUPD_SET_R1R0_00" & + "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & "MTK_PUPD_SET_R1R0_11" + define in mt8195. + For pull up type is RSEL, it can add RSEL define & resistance value(ohm) + to set different resistance by identifying property "mediatek,rsel_resistance_in_si_unit". + It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" + & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" & "MTK_PULL_SET_RSEL_100" + & "MTK_PULL_SET_RSEL_101" & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" + define in mt8195. It can also support resistance value(ohm) + "1000" & "1500" & "2000" & "3000" & "4000" & "5000" & "10000" & "75000" in mt8195. + oneOf: + - enum: [100, 101, 102, 103] + - description: mt8195 pull up PUPD/R0/R1 type define value. + - enum: [200, 201, 202, 203, 204, 205, 206, 207] + - description: mt8195 pull up RSEL type define value. + - enum: [1000, 1500, 2000, 3000, 4000, 5000, 10000, 75000] + - description: mt8195 pull up RSEL type si unit value(ohm). + An example of using RSEL define: + pincontroller { + i2c0_pin { + pinmux = <PINMUX_GPIO8__FUNC_SDA0>; + bias-pull-up = <MTK_PULL_SET_RSEL_001>; + }; + }; + An example of using si unit resistance value(ohm): + &pio { + mediatek,rsel_resistance_in_si_unit; + } + pincontroller { + i2c0_pin { + pinmux = <PINMUX_GPIO8__FUNC_SDA0>; + bias-pull-up = <1000>; + }; + }; bias-disable: true diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index 9bd01db37dcd..8952b4cc1262 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -21,6 +21,7 @@ properties: - qcom,pm660l-gpio - qcom,pm6150-gpio - qcom,pm6150l-gpio + - qcom,pm6350-gpio - qcom,pm7325-gpio - qcom,pm8005-gpio - qcom,pm8008-gpio @@ -103,6 +104,7 @@ $defs: this subnode. Valid pins are - gpio1-gpio10 for pm6150 - gpio1-gpio12 for pm6150l + - gpio1-gpio9 for pm6350 - gpio1-gpio10 for pm7325 - gpio1-gpio4 for pm8005 - gpio1-gpio2 for pm8008 @@ -170,6 +172,8 @@ $defs: input-enable: true output-high: true output-low: true + output-enable: true + output-disable: true power-source: true qcom,drive-strength: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt deleted file mode 100644 index 5363d44cbb74..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt +++ /dev/null @@ -1,187 +0,0 @@ -Qualcomm PMIC Multi-Purpose Pin (MPP) block - -This binding describes the MPP block(s) found in the 8xxx series -of PMIC's from Qualcomm. - -- compatible: - Usage: required - Value type: <string> - Definition: Should contain one of: - "qcom,pm8018-mpp", - "qcom,pm8019-mpp", - "qcom,pm8038-mpp", - "qcom,pm8058-mpp", - "qcom,pm8821-mpp", - "qcom,pm8841-mpp", - "qcom,pm8916-mpp", - "qcom,pm8917-mpp", - "qcom,pm8921-mpp", - "qcom,pm8941-mpp", - "qcom,pm8950-mpp", - "qcom,pmi8950-mpp", - "qcom,pm8994-mpp", - "qcom,pma8084-mpp", - "qcom,pmi8994-mpp", - - And must contain either "qcom,spmi-mpp" or "qcom,ssbi-mpp" - if the device is on an spmi bus or an ssbi bus respectively. - -- reg: - Usage: required - Value type: <prop-encoded-array> - Definition: Register base of the MPP block and length. - -- interrupts: - Usage: required - Value type: <prop-encoded-array> - Definition: Must contain an array of encoded interrupt specifiers for - each available MPP - -- gpio-controller: - Usage: required - Value type: <none> - Definition: Mark the device node as a GPIO controller - -- #gpio-cells: - Usage: required - Value type: <u32> - Definition: Must be 2; - the first cell will be used to define MPP number and the - second denotes the flags for this MPP - -Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for -a general description of GPIO and interrupt bindings. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices, including the meaning of the -phrase "pin configuration node". - -The pin configuration nodes act as a container for an arbitrary number of -subnodes. Each of these subnodes represents some desired configuration for a -pin or a list of pins. This configuration can include the -mux function to select on those pin(s), and various pin configuration -parameters, as listed below. - -SUBNODES: - -The name of each subnode is not important; all subnodes should be enumerated -and processed purely based on their content. - -Each subnode only affects those parameters that are explicitly listed. In -other words, a subnode that lists a mux function but no pin configuration -parameters implies no information about any pin configuration parameters. -Similarly, a pin subnode that describes a pullup parameter implies no -information about e.g. the mux function. - -The following generic properties as defined in pinctrl-bindings.txt are valid -to specify in a pin configuration subnode: - -- pins: - Usage: required - Value type: <string-array> - Definition: List of MPP pins affected by the properties specified in - this subnode. Valid pins are: - mpp1-mpp4 for pm8841 - mpp1-mpp4 for pm8916 - mpp1-mpp8 for pm8941 - mpp1-mpp4 for pm8950 - mpp1-mpp4 for pmi8950 - mpp1-mpp4 for pma8084 - -- function: - Usage: required - Value type: <string> - Definition: Specify the alternative function to be configured for the - specified pins. Valid values are: - "digital", - "analog", - "sink" - -- bias-disable: - Usage: optional - Value type: <none> - Definition: The specified pins should be configured as no pull. - -- bias-pull-up: - Usage: optional - Value type: <u32> - Definition: The specified pins should be configured as pull up. - Valid values are 600, 10000 and 30000 in bidirectional mode - only, i.e. when operating in qcom,analog-mode and input and - outputs are enabled. The hardware ignores the configuration - when operating in other modes. - -- bias-high-impedance: - Usage: optional - Value type: <none> - Definition: The specified pins will put in high-Z mode and disabled. - -- input-enable: - Usage: optional - Value type: <none> - Definition: The specified pins are put in input mode, i.e. their input - buffer is enabled - -- output-high: - Usage: optional - Value type: <none> - Definition: The specified pins are configured in output mode, driven - high. - -- output-low: - Usage: optional - Value type: <none> - Definition: The specified pins are configured in output mode, driven - low. - -- power-source: - Usage: optional - Value type: <u32> - Definition: Selects the power source for the specified pins. Valid power - sources are defined in <dt-bindings/pinctrl/qcom,pmic-mpp.h> - -- qcom,analog-level: - Usage: optional - Value type: <u32> - Definition: Selects the source for analog output. Valued values are - defined in <dt-binding/pinctrl/qcom,pmic-mpp.h> - PMIC_MPP_AOUT_LVL_* - -- qcom,dtest: - Usage: optional - Value type: <u32> - Definition: Selects which dtest rail to be routed in the various functions. - Valid values are 1-4 - -- qcom,amux-route: - Usage: optional - Value type: <u32> - Definition: Selects the source for analog input. Valid values are - defined in <dt-bindings/pinctrl/qcom,pmic-mpp.h> - PMIC_MPP_AMUX_ROUTE_CH5, PMIC_MPP_AMUX_ROUTE_CH6... -- qcom,paired: - Usage: optional - Value type: <none> - Definition: Indicates that the pin should be operating in paired mode. - -Example: - - mpps@a000 { - compatible = "qcom,pm8841-mpp", "qcom,spmi-mpp"; - reg = <0xa000>; - gpio-controller; - #gpio-cells = <2>; - interrupts = <4 0xa0 0 0>, <4 0xa1 0 0>, <4 0xa2 0 0>, <4 0xa3 0 0>; - - pinctrl-names = "default"; - pinctrl-0 = <&pm8841_default>; - - pm8841_default: default { - gpio { - pins = "mpp1", "mpp2", "mpp3", "mpp4"; - function = "digital"; - input-enable; - power-source = <PM8841_MPP_S3>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml new file mode 100644 index 000000000000..35c846f59979 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml @@ -0,0 +1,188 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,pmic-mpp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm PMIC Multi-Purpose Pin (MPP) block + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + This binding describes the MPP block(s) found in the 8xxx series of + PMIC's from Qualcomm. + +properties: + compatible: + items: + - enum: + - qcom,pm8018-mpp + - qcom,pm8019-mpp + - qcom,pm8038-mpp + - qcom,pm8058-mpp + - qcom,pm8821-mpp + - qcom,pm8841-mpp + - qcom,pm8916-mpp + - qcom,pm8917-mpp + - qcom,pm8921-mpp + - qcom,pm8941-mpp + - qcom,pm8950-mpp + - qcom,pmi8950-mpp + - qcom,pm8994-mpp + - qcom,pma8084-mpp + - qcom,pmi8994-mpp + + - enum: + - qcom,spmi-mpp + - qcom,ssbi-mpp + + reg: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + gpio-controller: true + gpio-line-names: true + + gpio-ranges: + maxItems: 1 + + '#gpio-cells': + const: 2 + description: + The first cell will be used to define gpio number and the + second denotes the flags for this gpio + +additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + - interrupt-controller + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-pmic-mpp-state" + - patternProperties: + "mpp": + $ref: "#/$defs/qcom-pmic-mpp-state" + additionalProperties: false + +$defs: + qcom-pmic-mpp-state: + type: object + allOf: + - $ref: "pinmux-node.yaml" + - $ref: "pincfg-node.yaml" + properties: + pins: + description: + List of gpio pins affected by the properties specified in + this subnode. Valid pins are + - mpp1-mpp4 for pm8841 + - mpp1-mpp4 for pm8916 + - mpp1-mpp8 for pm8941 + - mpp1-mpp4 for pm8950 + - mpp1-mpp4 for pmi8950 + - mpp1-mpp4 for pma8084 + + items: + pattern: "^mpp([0-9]+)$" + + function: + items: + - enum: + - digital + - analog + - sink + + bias-disable: true + bias-pull-up: true + bias-high-impedance: true + input-enable: true + output-high: true + output-low: true + power-source: true + + qcom,analog-level: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Selects the source for analog output. Valued values are defined in + <dt-binding/pinctrl/qcom,pmic-mpp.h> PMIC_MPP_AOUT_LVL_* + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + qcom,atest: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Selects ATEST rail to route to GPIO when it's + configured in analog-pass-through mode. + enum: [1, 2, 3, 4] + + qcom,dtest: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Selects DTEST rail to route to GPIO when it's + configured as digital input. + enum: [1, 2, 3, 4] + + qcom,amux-route: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Selects the source for analog input. Valid values are defined in + <dt-bindings/pinctrl/qcom,pmic-mpp.h> PMIC_MPP_AMUX_ROUTE_CH5, + PMIC_MPP_AMUX_ROUTE_CH6... + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + qcom,paired: + - description: + Indicates that the pin should be operating in paired mode. + + required: + - pins + - function + + additionalProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/qcom,pmic-mpp.h> + + pm8841_mpp: mpps@a000 { + compatible = "qcom,pm8841-mpp", "qcom,spmi-mpp"; + reg = <0xa000 0>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pm8841_mpp 0 0 4>; + gpio-line-names = "VDD_PX_BIAS", "WLAN_LED_CTRL", + "BT_LED_CTRL", "GPIO-F"; + interrupt-controller; + #interrupt-cells = <2>; + + pinctrl-names = "default"; + pinctrl-0 = <&pm8841_default>; + + mpp1-state { + pins = "mpp1"; + function = "digital"; + input-enable; + power-source = <PM8841_MPP_S3>; + }; + + default-state { + gpio-mpp { + pins = "mpp1", "mpp2", "mpp3", "mpp4"; + function = "digital"; + input-enable; + power-source = <PM8841_MPP_S3>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml new file mode 100644 index 000000000000..13f338619d77 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml @@ -0,0 +1,165 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,qcm2290-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. QCM2290 TLMM block + +maintainers: + - Shawn Guo <shawn.guo@linaro.org> + +description: + This binding describes the Top Level Mode Multiplexer block found in the + QCM2290 platform. + +properties: + compatible: + const: qcom,qcm2290-tlmm + + reg: + maxItems: 1 + + interrupts: + description: Specifies the TLMM summary IRQ + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + description: + Specifies the PIN numbers and Flags, as defined in defined in + include/dt-bindings/interrupt-controller/irq.h + const: 2 + + gpio-controller: true + + '#gpio-cells': + description: Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h + const: 2 + + gpio-ranges: + maxItems: 1 + + wakeup-parent: + maxItems: 1 + +#PIN CONFIGURATION NODES +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-qcm2290-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-qcm2290-tlmm-state" + +'$defs': + qcom-qcm2290-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-1][0-9]|12[0-6])$" + - enum: [ sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data, + sdc2_clk, sdc2_cmd, sdc2_data ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ adsp_ext, agera_pll, atest, cam_mclk, cci_async, cci_i2c, + cci_timer0, cci_timer1, cci_timer2, cci_timer3, char_exec, + cri_trng, cri_trng0, cri_trng1, dac_calib, dbg_out, ddr_bist, + ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, gcc_gp1, gcc_gp2, + gcc_gp3, gpio, gp_pdm0, gp_pdm1, gp_pdm2, gsm0_tx, gsm1_tx, + jitter_bist, mdp_vsync, mdp_vsync_out_0, mdp_vsync_out_1, + mpm_pwr, mss_lte, m_voc, nav_gpio, pa_indicator, pbs0, pbs1, + pbs2, pbs3, pbs4, pbs5, pbs6, pbs7, pbs8, pbs9, pbs10, pbs11, + pbs12, pbs13, pbs14, pbs15, pbs_out, phase_flag, pll_bist, + pll_bypassnl, pll_reset, prng_rosc, pwm_0, pwm_1, pwm_2, pwm_3, + pwm_4, pwm_5, pwm_6, pwm_7, pwm_8, pwm_9, qdss_cti, qdss_gpio, + qup0, qup1, qup2, qup3, qup4, qup5, sdc1_tb, sdc2_tb, sd_write, + ssbi_wtr1, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm, + uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, + uim2_data, uim2_present, uim2_reset, usb_phy, vfr_1, + vsense_trigger, wlan1_adc0, wlan1_adc1 ] + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + default: 2 + description: + Selects the drive strength for the specified pins, in mA. + + bias-pull-down: true + + bias-pull-up: true + + bias-disable: true + + output-high: true + + output-low: true + + required: + - pins + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - '#interrupt-cells' + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + tlmm: pinctrl@500000 { + compatible = "qcom,qcm2290-tlmm"; + reg = <0x500000 0x300000>; + interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-ranges = <&tlmm 0 0 127>; + + sdc2_on_state: sdc2-on-state { + clk { + pins = "sdc2_clk"; + bias-disable; + drive-strength = <16>; + }; + + cmd { + pins = "sdc2_cmd"; + bias-pull-up; + drive-strength = <10>; + }; + + data { + pins = "sdc2_data"; + bias-pull-up; + drive-strength = <10>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-pinctrl.yaml new file mode 100644 index 000000000000..554992a681f3 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-pinctrl.yaml @@ -0,0 +1,148 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm6350-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. SM6350 TLMM block + +maintainers: + - Konrad Dybcio <konrad.dybcio@somainline.org> + +description: | + This binding describes the Top Level Mode Multiplexer (TLMM) block found + in the SM6350 platform. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,sm6350-tlmm + + reg: + maxItems: 1 + + interrupts: true + interrupt-controller: true + '#interrupt-cells': true + gpio-controller: true + gpio-reserved-ranges: true + '#gpio-cells': true + gpio-ranges: true + wakeup-parent: true + +required: + - compatible + - reg + +additionalProperties: false + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-sm6350-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-sm6350-tlmm-state" + +$defs: + qcom-sm6350-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|15[0-7])$" + - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ adsp_ext, agera_pll, atest_char, atest_char0, atest_char1, atest_char2, + atest_char3, atest_tsens, atest_tsens2, atest_usb1, atest_usb10, atest_usb11, + atest_usb12, atest_usb13, atest_usb2, atest_usb20, atest_usb21, atest_usb22, + atest_usb23, audio_ref, btfm_slimbus, cam_mclk0, cam_mclk1, cam_mclk2, cam_mclk3, + cam_mclk4, cci_async, cci_i2c, cci_timer0, cci_timer1, cci_timer2, cci_timer3, + cci_timer4, cri_trng, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, + dp_hot, edp_lcd, gcc_gp1, gcc_gp2, gcc_gp3, gp_pdm0, gp_pdm1, gp_pdm2, gpio, + gps_tx, ibi_i3c, jitter_bist, ldo_en, ldo_update, lpass_ext, m_voc, mclk, + mdp_vsync, mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s_0, mi2s_1, mi2s_2, + mss_lte, nav_gpio, nav_pps, pa_indicator, pcie0_clk, phase_flag0, phase_flag1, + phase_flag10, phase_flag11, phase_flag12, phase_flag13, phase_flag14, phase_flag15, + phase_flag16, phase_flag17, phase_flag18, phase_flag19, phase_flag2, phase_flag20, + phase_flag21, phase_flag22, phase_flag23, phase_flag24, phase_flag25, phase_flag26, + phase_flag27, phase_flag28, phase_flag29, phase_flag3, phase_flag30, phase_flag31, + phase_flag4, phase_flag5, phase_flag6, phase_flag7, phase_flag8, phase_flag9, + pll_bist, pll_bypassnl, pll_reset, prng_rosc, qdss_cti, qdss_gpio, qdss_gpio0, + qdss_gpio1, qdss_gpio10, qdss_gpio11, qdss_gpio12, qdss_gpio13, qdss_gpio14, + qdss_gpio15, qdss_gpio2, qdss_gpio3, qdss_gpio4, qdss_gpio5, qdss_gpio6, + qdss_gpio7, qdss_gpio8, qdss_gpio9, qlink0_enable, qlink0_request, qlink0_wmss, + qlink1_enable, qlink1_request, qlink1_wmss, qup00, qup01, qup02, qup10, qup11, + qup12, qup13_f1, qup13_f2, qup14, rffe0_clk, rffe0_data, rffe1_clk, rffe1_data, + rffe2_clk, rffe2_data, rffe3_clk, rffe3_data, rffe4_clk, rffe4_data, sd_write, + sdc1_tb, sdc2_tb, sp_cmu, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm1, + tsense_pwm2, uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data, + uim2_present, uim2_reset, usb_phy, vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1, + wlan2_adc0, wlan2_adc1, ] + + + bias-disable: true + bias-pull-down: true + bias-pull-up: true + drive-strength: true + input-enable: true + output-high: true + output-low: true + + required: + - pins + - function + + additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + pinctrl@f100000 { + compatible = "qcom,sm6350-tlmm"; + reg = <0x0f100000 0x300000>; + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-ranges = <&tlmm 0 0 157>; + + gpio-wo-subnode-state { + pins = "gpio1"; + function = "gpio"; + }; + + uart-w-subnodes-state { + rx { + pins = "gpio25"; + function = "qup13_f2"; + bias-disable; + }; + + tx { + pins = "gpio26"; + function = "qup13_f2"; + bias-disable; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt deleted file mode 100644 index 84c4111293bd..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt +++ /dev/null @@ -1,114 +0,0 @@ -* Rockchip Pinmux Controller - -The Rockchip Pinmux Controller, enables the IC -to share one PAD to several functional blocks. The sharing is done by -multiplexing the PAD input/output signals. For each PAD there are several -muxing options with option 0 being the use as a GPIO. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices, including the meaning of the -phrase "pin configuration node". - -The Rockchip pin configuration node is a node of a group of pins which can be -used for a specific device or function. This node represents both mux and -config of the pins in that group. The 'pins' selects the function mode(also -named pin mode) this pin can work on and the 'config' configures various pad -settings such as pull-up, etc. - -The pins are grouped into up to 5 individual pin banks which need to be -defined as gpio sub-nodes of the pinmux controller. - -Required properties for iomux controller: - - compatible: should be - "rockchip,px30-pinctrl": for Rockchip PX30 - "rockchip,rv1108-pinctrl": for Rockchip RV1108 - "rockchip,rk2928-pinctrl": for Rockchip RK2928 - "rockchip,rk3066a-pinctrl": for Rockchip RK3066a - "rockchip,rk3066b-pinctrl": for Rockchip RK3066b - "rockchip,rk3128-pinctrl": for Rockchip RK3128 - "rockchip,rk3188-pinctrl": for Rockchip RK3188 - "rockchip,rk3228-pinctrl": for Rockchip RK3228 - "rockchip,rk3288-pinctrl": for Rockchip RK3288 - "rockchip,rk3308-pinctrl": for Rockchip RK3308 - "rockchip,rk3328-pinctrl": for Rockchip RK3328 - "rockchip,rk3368-pinctrl": for Rockchip RK3368 - "rockchip,rk3399-pinctrl": for Rockchip RK3399 - "rockchip,rk3568-pinctrl": for Rockchip RK3568 - - - rockchip,grf: phandle referencing a syscon providing the - "general register files" - -Optional properties for iomux controller: - - rockchip,pmu: phandle referencing a syscon providing the pmu registers - as some SoCs carry parts of the iomux controller registers there. - Required for at least rk3188 and rk3288. On the rk3368 this should - point to the PMUGRF syscon. - -Deprecated properties for iomux controller: - - reg: first element is the general register space of the iomux controller - It should be large enough to contain also separate pull registers. - second element is the separate pull register space of the rk3188. - Use rockchip,grf and rockchip,pmu described above instead. - -Required properties for gpio sub nodes: -See rockchip,gpio-bank.yaml - -Required properties for pin configuration node: - - rockchip,pins: 3 integers array, represents a group of pins mux and config - setting. The format is rockchip,pins = <PIN_BANK PIN_BANK_IDX MUX &phandle>. - The MUX 0 means gpio and MUX 1 to N mean the specific device function. - The phandle of a node containing the generic pinconfig options - to use, as described in pinctrl-bindings.txt in this directory. - -Examples: - -#include <dt-bindings/pinctrl/rockchip.h> - -... - -pinctrl@20008000 { - compatible = "rockchip,rk3066a-pinctrl"; - rockchip,grf = <&grf>; - - #address-cells = <1>; - #size-cells = <1>; - ranges; - - gpio0: gpio0@20034000 { - compatible = "rockchip,gpio-bank"; - reg = <0x20034000 0x100>; - interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clk_gates8 9>; - - gpio-controller; - #gpio-cells = <2>; - - interrupt-controller; - #interrupt-cells = <2>; - }; - - ... - - pcfg_pull_default: pcfg_pull_default { - bias-pull-pin-default - }; - - uart2 { - uart2_xfer: uart2-xfer { - rockchip,pins = <1 RK_PB0 1 &pcfg_pull_default>, - <1 RK_PB1 1 &pcfg_pull_default>; - }; - }; -}; - -uart2: serial@20064000 { - compatible = "snps,dw-apb-uart"; - reg = <0x20064000 0x400>; - interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>; - reg-shift = <2>; - reg-io-width = <1>; - clocks = <&mux_uart2>; - - pinctrl-names = "default"; - pinctrl-0 = <&uart2_xfer>; -}; diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml new file mode 100644 index 000000000000..07c0a98ef9c6 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/rockchip,pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip Pinmux Controller + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +description: | + The Rockchip Pinmux Controller enables the IC to share one PAD + to several functional blocks. The sharing is done by multiplexing + the PAD input/output signals. For each PAD there are several muxing + options with option 0 being used as a GPIO. + + Please refer to pinctrl-bindings.txt in this directory for details of the + common pinctrl bindings used by client devices, including the meaning of the + phrase "pin configuration node". + + The Rockchip pin configuration node is a node of a group of pins which can be + used for a specific device or function. This node represents both mux and + config of the pins in that group. The 'pins' selects the function mode + (also named pin mode) this pin can work on and the 'config' configures + various pad settings such as pull-up, etc. + + The pins are grouped into up to 9 individual pin banks which need to be + defined as gpio sub-nodes of the pinmux controller. + +properties: + compatible: + enum: + - rockchip,px30-pinctrl + - rockchip,rk2928-pinctrl + - rockchip,rk3066a-pinctrl + - rockchip,rk3066b-pinctrl + - rockchip,rk3128-pinctrl + - rockchip,rk3188-pinctrl + - rockchip,rk3228-pinctrl + - rockchip,rk3288-pinctrl + - rockchip,rk3308-pinctrl + - rockchip,rk3328-pinctrl + - rockchip,rk3368-pinctrl + - rockchip,rk3399-pinctrl + - rockchip,rk3568-pinctrl + - rockchip,rv1108-pinctrl + + rockchip,grf: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: + The phandle of the syscon node for the GRF registers. + + rockchip,pmu: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: + The phandle of the syscon node for the PMU registers, + as some SoCs carry parts of the iomux controller registers there. + Required for at least rk3188 and rk3288. On the rk3368 this should + point to the PMUGRF syscon. + + "#address-cells": + enum: [1, 2] + + "#size-cells": + enum: [1, 2] + + ranges: true + +required: + - compatible + - rockchip,grf + - "#address-cells" + - "#size-cells" + - ranges + +patternProperties: + "gpio@[0-9a-f]+$": + type: object + + $ref: "/schemas/gpio/rockchip,gpio-bank.yaml#" + + unevaluatedProperties: false + + "pcfg-[a-z0-9-]+$": + type: object + properties: + bias-disable: true + + bias-pull-down: true + + bias-pull-pin-default: true + + bias-pull-up: true + + drive-strength: + minimum: 0 + maximum: 20 + + input-enable: true + + input-schmitt-enable: true + + output-high: true + + output-low: true + + additionalProperties: false + +additionalProperties: + type: object + additionalProperties: + type: object + properties: + rockchip,pins: + $ref: "/schemas/types.yaml#/definitions/uint32-matrix" + minItems: 1 + items: + items: + - minimum: 0 + maximum: 8 + description: + Pin bank. + - minimum: 0 + maximum: 31 + description: + Pin bank index. + - minimum: 0 + maximum: 6 + description: + Mux 0 means GPIO and mux 1 to N means + the specific device function. + - description: + The phandle of a node contains the generic pinconfig options + to use as described in pinctrl-bindings.txt. + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/pinctrl/rockchip.h> + + pinctrl: pinctrl { + compatible = "rockchip,rk3066a-pinctrl"; + rockchip,grf = <&grf>; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + gpio0: gpio@20034000 { + compatible = "rockchip,gpio-bank"; + reg = <0x20034000 0x100>; + interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk_gates8 9>; + + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + pcfg_pull_default: pcfg-pull-default { + bias-pull-pin-default; + }; + + uart2 { + uart2_xfer: uart2-xfer { + rockchip,pins = <1 RK_PB0 1 &pcfg_pull_default>, + <1 RK_PB1 1 &pcfg_pull_default>; + }; + }; + }; + + uart2: serial@20064000 { + compatible = "snps,dw-apb-uart"; + reg = <0x20064000 0x400>; + interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mux_uart2>; + pinctrl-0 = <&uart2_xfer>; + pinctrl-names = "default"; + reg-io-width = <1>; + reg-shift = <2>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index e7a1b1880375..b8b475967ff9 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -23,6 +23,7 @@ Required Properties: - "samsung,exynos5433-pinctrl": for Exynos5433 compatible pin-controller. - "samsung,exynos7-pinctrl": for Exynos7 compatible pin-controller. - "samsung,exynos850-pinctrl": for Exynos850 compatible pin-controller. + - "samsung,exynosautov9-pinctrl": for ExynosAutov9 compatible pin-controller. - reg: Base address of the pin controller hardware module and length of the address space it occupies. diff --git a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml index 502480a19f49..a804d9bc1602 100644 --- a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml @@ -24,6 +24,7 @@ properties: - socionext,uniphier-ld11-pinctrl - socionext,uniphier-ld20-pinctrl - socionext,uniphier-pxs3-pinctrl + - socionext,uniphier-nx1-pinctrl required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml index dfee6d38a701..ac88e01ec430 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STM32 GPIO and Pin Mux/Config controller maintainers: - - Alexandre TORGUE <alexandre.torgue@st.com> + - Alexandre TORGUE <alexandre.torgue@foss.st.com> description: | STMicroelectronics's STM32 MCUs intregrate a GPIO and Pin mux/config hardware diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index 239f37881cae..e810480e3eb7 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -19,6 +19,7 @@ properties: - qcom,mdm9607-rpmpd - qcom,msm8916-rpmpd - qcom,msm8939-rpmpd + - qcom,msm8953-rpmpd - qcom,msm8976-rpmpd - qcom,msm8994-rpmpd - qcom,msm8996-rpmpd @@ -31,6 +32,7 @@ properties: - qcom,sdm845-rpmhpd - qcom,sdx55-rpmhpd - qcom,sm6115-rpmpd + - qcom,sm6350-rpmhpd - qcom,sm8150-rpmhpd - qcom,sm8250-rpmhpd - qcom,sm8350-rpmhpd diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml index f792d06db413..ffb344987a7b 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml @@ -62,7 +62,7 @@ required: - compatible - reg -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/power/supply/samsung,battery.yaml b/Documentation/devicetree/bindings/power/supply/samsung,battery.yaml new file mode 100644 index 000000000000..40292d581b10 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/samsung,battery.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/samsung,battery.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung SDI Batteries + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + Samsung SDI (Samsung Digital Interface) batteries are all different versions + of lithium ion chemistry devices used for mobile phones, laptops and other + portable electronics. The batteries are adapted to a specific product and + the physical restrictions make it impossible to use another battery with the + product, so product device trees can specify these batteries. Operating + systems should determine hardware characteristics of the batteries from the + compatible string. + +properties: + compatible: + oneOf: + - const: samsung,eb-l1m7flu + description: 3.8V 1500 mAh battery used in Samsung GT-I8190 + - const: samsung,eb425161la + description: 3.8V 1500 mAh battery used in Samsung SGH-T599 and SGH-I407 + - const: samsung,eb425161lu + description: 3.8V 1500 mAh battery used in Samsung GT-I8160 + - const: samsung,eb485159lu + description: 3.8V 1700 mAh battery used in Samsung GT-S7710 + - const: samsung,eb535151vu + description: 3.8V 1500 mAh battery used in Samsung GT-I9070 + - const: samsung,eb585157lu + description: 3.8V 2000 mAh battery used in Samsung GT-I8530 + +required: + - compatible + +additionalProperties: false + +examples: + - | + power { + #address-cells = <1>; + #size-cells = <0>; + + battery: battery { + compatible = "samsung,eb425161la"; + }; + + charger@11 { + reg = <0x11>; + monitored-battery = <&battery>; + }; + }; diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-btemp.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-btemp.yaml index 2f57aa5a5f4e..4b8a00cec39c 100644 --- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-btemp.yaml +++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-btemp.yaml @@ -17,10 +17,14 @@ properties: compatible: const: stericsson,ab8500-btemp - battery: + monitored-battery: $ref: /schemas/types.yaml#/definitions/phandle description: phandle to battery node + battery: + $ref: /schemas/types.yaml#/definitions/phandle + deprecated: true + interrupts: maxItems: 5 @@ -42,7 +46,7 @@ properties: required: - compatible - - battery + - monitored-battery - interrupts - interrupt-names - io-channels @@ -56,7 +60,7 @@ examples: pmic { battery-temperature { compatible = "stericsson,ab8500-btemp"; - battery = <&ab8500_battery>; + monitored-battery = <&battery>; interrupts = <20 IRQ_TYPE_LEVEL_HIGH>, <80 IRQ_TYPE_LEVEL_HIGH>, <83 IRQ_TYPE_LEVEL_HIGH>, diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-chargalg.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-chargalg.yaml index 0897231c2f6e..6799224f7fb4 100644 --- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-chargalg.yaml +++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-chargalg.yaml @@ -17,13 +17,17 @@ properties: compatible: const: stericsson,ab8500-chargalg - battery: + monitored-battery: $ref: /schemas/types.yaml#/definitions/phandle description: phandle to battery node + battery: + $ref: /schemas/types.yaml#/definitions/phandle + deprecated: true + required: - compatible - - battery + - monitored-battery additionalProperties: false @@ -32,6 +36,6 @@ examples: pmic { charging-algorithm { compatible = "stericsson,ab8500-chargalg"; - battery = <&ab8500_battery>; + monitored-battery = <&ab8500_battery>; }; }; diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-charger.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-charger.yaml index e13305afea69..9518eb7289d0 100644 --- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-charger.yaml @@ -17,10 +17,14 @@ properties: compatible: const: stericsson,ab8500-charger - battery: + monitored-battery: $ref: /schemas/types.yaml#/definitions/phandle description: phandle to battery node + battery: + $ref: /schemas/types.yaml#/definitions/phandle + deprecated: true + vddadc-supply: description: Supply for USB and Main charger @@ -66,7 +70,7 @@ properties: required: - compatible - - battery + - monitored-battery - vddadc-supply - interrupts - interrupt-names @@ -81,7 +85,7 @@ examples: pmic { charger { compatible = "stericsson,ab8500-charger"; - battery = <&ab8500_battery>; + monitored-battery = <&battery>; vddadc-supply = <&ab8500_ldo_tvout_reg>; interrupts = <10 IRQ_TYPE_LEVEL_HIGH>, <11 IRQ_TYPE_LEVEL_HIGH>, diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml index db342e5ac0d1..54ac42a9d354 100644 --- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml +++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml @@ -17,10 +17,14 @@ properties: compatible: const: stericsson,ab8500-fg - battery: + monitored-battery: $ref: /schemas/types.yaml#/definitions/phandle description: phandle to battery node + battery: + $ref: /schemas/types.yaml#/definitions/phandle + deprecated: true + interrupts: maxItems: 5 @@ -41,7 +45,7 @@ properties: required: - compatible - - battery + - monitored-battery - interrupts - interrupt-names - io-channels @@ -55,7 +59,7 @@ examples: pmic { fuel-gauge { compatible = "stericsson,ab8500-fg"; - battery = <&ab8500_battery>; + monitored-battery = <&battery>; interrupts = <24 IRQ_TYPE_LEVEL_HIGH>, <8 IRQ_TYPE_LEVEL_HIGH>, <28 IRQ_TYPE_LEVEL_HIGH>, diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml index 81ccb2110162..1f5c6384182e 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml @@ -35,9 +35,11 @@ properties: - renesas,tpu-r8a7794 # R-Car E2 - renesas,tpu-r8a7795 # R-Car H3 - renesas,tpu-r8a7796 # R-Car M3-W + - renesas,tpu-r8a77961 # R-Car M3-W+ - renesas,tpu-r8a77965 # R-Car M3-N - renesas,tpu-r8a77970 # R-Car V3M - renesas,tpu-r8a77980 # R-Car V3H + - renesas,tpu-r8a779a0 # R-Car V3U - const: renesas,tpu reg: diff --git a/Documentation/devicetree/bindings/regulator/max77686.txt b/Documentation/devicetree/bindings/regulator/max77686.txt index e9f7578ca09a..ff3d2dec8c4b 100644 --- a/Documentation/devicetree/bindings/regulator/max77686.txt +++ b/Documentation/devicetree/bindings/regulator/max77686.txt @@ -43,7 +43,7 @@ Example: max77686: pmic@9 { compatible = "maxim,max77686"; interrupt-parent = <&wakeup_eint>; - interrupts = <26 IRQ_TYPE_NONE>; + interrupts = <26 IRQ_TYPE_LEVEL_LOW>; reg = <0x09>; voltage-regulators { diff --git a/Documentation/devicetree/bindings/regulator/max8952.txt b/Documentation/devicetree/bindings/regulator/max8952.txt deleted file mode 100644 index 866fcdd0f4eb..000000000000 --- a/Documentation/devicetree/bindings/regulator/max8952.txt +++ /dev/null @@ -1,52 +0,0 @@ -Maxim MAX8952 voltage regulator - -Required properties: -- compatible: must be equal to "maxim,max8952" -- reg: I2C slave address, usually 0x60 -- max8952,dvs-mode-microvolt: array of 4 integer values defining DVS voltages - in microvolts. All values must be from range <770000, 1400000> -- any required generic properties defined in regulator.txt - -Optional properties: -- max8952,vid-gpios: array of two GPIO pins used for DVS voltage selection -- max8952,en-gpio: GPIO used to control enable status of regulator -- max8952,default-mode: index of default DVS voltage, from <0, 3> range -- max8952,sync-freq: sync frequency, must be one of following values: - - 0: 26 MHz - - 1: 13 MHz - - 2: 19.2 MHz - Defaults to 26 MHz if not specified. -- max8952,ramp-speed: voltage ramp speed, must be one of following values: - - 0: 32mV/us - - 1: 16mV/us - - 2: 8mV/us - - 3: 4mV/us - - 4: 2mV/us - - 5: 1mV/us - - 6: 0.5mV/us - - 7: 0.25mV/us - Defaults to 32mV/us if not specified. -- any available generic properties defined in regulator.txt - -Example: - - vdd_arm_reg: pmic@60 { - compatible = "maxim,max8952"; - reg = <0x60>; - - /* max8952-specific properties */ - max8952,vid-gpios = <&gpx0 3 0>, <&gpx0 4 0>; - max8952,en-gpio = <&gpx0 1 0>; - max8952,default-mode = <0>; - max8952,dvs-mode-microvolt = <1250000>, <1200000>, - <1050000>, <950000>; - max8952,sync-freq = <0>; - max8952,ramp-speed = <0>; - - /* generic regulator properties */ - regulator-name = "vdd_arm"; - regulator-min-microvolt = <770000>; - regulator-max-microvolt = <1400000>; - regulator-always-on; - regulator-boot-on; - }; diff --git a/Documentation/devicetree/bindings/regulator/max8973-regulator.txt b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt deleted file mode 100644 index c2c68fcc1b41..000000000000 --- a/Documentation/devicetree/bindings/regulator/max8973-regulator.txt +++ /dev/null @@ -1,52 +0,0 @@ -* Maxim MAX8973 Voltage Regulator - -Required properties: - -- compatible: must be one of following: - "maxim,max8973" - "maxim,max77621". -- reg: the i2c slave address of the regulator. It should be 0x1b. - -Any standard regulator properties can be used to configure the single max8973 -DCDC. - -Optional properties: - --maxim,externally-enable: boolean, externally control the regulator output - enable/disable. --maxim,enable-gpio: GPIO for enable control. If the valid GPIO is provided - then externally enable control will be considered. --maxim,dvs-gpio: GPIO which is connected to DVS pin of device. --maxim,dvs-default-state: Default state of GPIO during initialisation. - 1 for HIGH and 0 for LOW. --maxim,enable-remote-sense: boolean, enable reote sense. --maxim,enable-falling-slew-rate: boolean, enable falling slew rate. --maxim,enable-active-discharge: boolean: enable active discharge. --maxim,enable-frequency-shift: boolean, enable 9% frequency shift. --maxim,enable-bias-control: boolean, enable bias control. By enabling this - startup delay can be reduce to 20us from 220us. --maxim,enable-etr: boolean, enable Enhanced Transient Response. --maxim,enable-high-etr-sensitivity: boolean, Enhanced transient response - circuit is enabled and set for high sensitivity. If this - property is available then etr will be enable default. - -Enhanced transient response (ETR) will affect the configuration of CKADV. - --junction-warn-millicelsius: u32, junction warning temperature threshold - in millicelsius. If die temperature crosses this level then - device generates the warning interrupts. - -Please note that thermal functionality is only supported on MAX77621. The -supported threshold warning temperature for MAX77621 are 120 degC and 140 degC. - -Example: - - max8973@1b { - compatible = "maxim,max8973"; - reg = <0x1b>; - - regulator-min-microvolt = <935000>; - regulator-max-microvolt = <1200000>; - regulator-boot-on; - regulator-always-on; - }; diff --git a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt deleted file mode 100644 index b53c5e2b335f..000000000000 --- a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt +++ /dev/null @@ -1,145 +0,0 @@ -* Maxim MAX8997 Voltage and Current Regulator - -The Maxim MAX8997 is a multi-function device which includes voltage and -current regulators, rtc, charger controller and other sub-blocks. It is -interfaced to the host controller using a i2c interface. Each sub-block is -addressed by the host system using different i2c slave address. This document -describes the bindings for 'pmic' sub-block of max8997. - -Required properties: -- compatible: Should be "maxim,max8997-pmic". -- reg: Specifies the i2c slave address of the pmic block. It should be 0x66. - -- max8997,pmic-buck1-dvs-voltage: A set of 8 voltage values in micro-volt (uV) - units for buck1 when changing voltage using gpio dvs. Refer to [1] below - for additional information. - -- max8997,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV) - units for buck2 when changing voltage using gpio dvs. Refer to [1] below - for additional information. - -- max8997,pmic-buck5-dvs-voltage: A set of 8 voltage values in micro-volt (uV) - units for buck5 when changing voltage using gpio dvs. Refer to [1] below - for additional information. - -[1] If none of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional - property is specified, the 'max8997,pmic-buck[1/2/5]-dvs-voltage' - property should specify atleast one voltage level (which would be a - safe operating voltage). - - If either of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional - property is specified, then all the eight voltage values for the - 'max8997,pmic-buck[1/2/5]-dvs-voltage' should be specified. - -Optional properties: -- interrupts: Interrupt specifiers for two interrupt sources. - - First interrupt specifier is for 'irq1' interrupt. - - Second interrupt specifier is for 'alert' interrupt. -- charger-supply: regulator node for charging current. -- max8997,pmic-buck1-uses-gpio-dvs: 'buck1' can be controlled by gpio dvs. -- max8997,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs. -- max8997,pmic-buck5-uses-gpio-dvs: 'buck5' can be controlled by gpio dvs. - -Additional properties required if either of the optional properties are used: -- max8997,pmic-ignore-gpiodvs-side-effect: When GPIO-DVS mode is used for - multiple bucks, changing the voltage value of one of the bucks may affect - that of another buck, which is the side effect of the change (set_voltage). - Use this property to ignore such side effects and change the voltage. - -- max8997,pmic-buck125-default-dvs-idx: Default voltage setting selected from - the possible 8 options selectable by the dvs gpios. The value of this - property should be between 0 and 7. If not specified or if out of range, the - default value of this property is set to 0. - -- max8997,pmic-buck125-dvs-gpios: GPIO specifiers for three host gpio's used - for dvs. The format of the gpio specifier depends in the gpio controller. - -Regulators: The regulators of max8997 that have to be instantiated should be -included in a sub-node named 'regulators'. Regulator nodes included in this -sub-node should be of the format as listed below. - - regulator_name { - standard regulator bindings here - }; - -The following are the names of the regulators that the max8997 pmic block -supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number -as per the datasheet of max8997. - - - LDOn - - valid values for n are 1 to 18 and 21 - - Example: LDO0, LD01, LDO2, LDO21 - - BUCKn - - valid values for n are 1 to 7. - - Example: BUCK1, BUCK2, BUCK3, BUCK7 - - - ENVICHG: Battery Charging Current Monitor Output. This is a fixed - voltage type regulator - - - ESAFEOUT1: (ldo19) - - ESAFEOUT2: (ld020) - - - CHARGER_CV: main battery charger voltage control - - CHARGER: main battery charger current control - - CHARGER_TOPOFF: end of charge current threshold level - -The bindings inside the regulator nodes use the standard regulator bindings -which are documented elsewhere. - -Example: - - max8997_pmic@66 { - compatible = "maxim,max8997-pmic"; - interrupt-parent = <&wakeup_eint>; - reg = <0x66>; - interrupts = <4 0>, <3 0>; - - max8997,pmic-buck1-uses-gpio-dvs; - max8997,pmic-buck2-uses-gpio-dvs; - max8997,pmic-buck5-uses-gpio-dvs; - - max8997,pmic-ignore-gpiodvs-side-effect; - max8997,pmic-buck125-default-dvs-idx = <0>; - - max8997,pmic-buck125-dvs-gpios = <&gpx0 0 1 0 0>, /* SET1 */ - <&gpx0 1 1 0 0>, /* SET2 */ - <&gpx0 2 1 0 0>; /* SET3 */ - - max8997,pmic-buck1-dvs-voltage = <1350000>, <1300000>, - <1250000>, <1200000>, - <1150000>, <1100000>, - <1000000>, <950000>; - - max8997,pmic-buck2-dvs-voltage = <1100000>, <1100000>, - <1100000>, <1100000>, - <1000000>, <1000000>, - <1000000>, <1000000>; - - max8997,pmic-buck5-dvs-voltage = <1200000>, <1200000>, - <1200000>, <1200000>, - <1200000>, <1200000>, - <1200000>, <1200000>; - - regulators { - ldo1_reg: LDO1 { - regulator-name = "VDD_ABB_3.3V"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - ldo2_reg: LDO2 { - regulator-name = "VDD_ALIVE_1.1V"; - regulator-min-microvolt = <1100000>; - regulator-max-microvolt = <1100000>; - regulator-always-on; - }; - - buck1_reg: BUCK1 { - regulator-name = "VDD_ARM_1.2V"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/maxim,max8952.yaml b/Documentation/devicetree/bindings/regulator/maxim,max8952.yaml new file mode 100644 index 000000000000..e4e8c58f6046 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max8952.yaml @@ -0,0 +1,109 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max8952.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX8952 voltage regulator + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + const: maxim,max8952 + + max8952,default-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + description: | + index of default DVS voltage + + max8952,dvs-mode-microvolt: + minItems: 4 + maxItems: 4 + items: + minimum: 770000 + maximum: 1400000 + description: | + Array of 4 integer values defining DVS voltages in microvolts. All values + must be from range <770000, 1400000>. + + max8952,en-gpio: + maxItems: 1 + description: | + GPIO used to control enable status of regulator + + max8952,ramp-speed: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5, 6, 7] + default: 0 + description: | + Voltage ramp speed, values map to: + - 0: 32mV/us + - 1: 16mV/us + - 2: 8mV/us + - 3: 4mV/us + - 4: 2mV/us + - 5: 1mV/us + - 6: 0.5mV/us + - 7: 0.25mV/us + Defaults to 32mV/us if not specified. + + max8952,sync-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + default: 0 + description: | + Sync frequency, values map to: + - 0: 26 MHz + - 1: 13 MHz + - 2: 19.2 MHz + Defaults to 26 MHz if not specified. + + max8952,vid-gpios: + minItems: 2 + maxItems: 2 + description: | + Array of two GPIO pins used for DVS voltage selection + + reg: + maxItems: 1 + +required: + - compatible + - max8952,dvs-mode-microvolt + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@60 { + compatible = "maxim,max8952"; + reg = <0x60>; + + max8952,vid-gpios = <&gpx0 3 GPIO_ACTIVE_HIGH>, + <&gpx0 4 GPIO_ACTIVE_HIGH>; + max8952,default-mode = <0>; + max8952,dvs-mode-microvolt = <1250000>, <1200000>, + <1050000>, <950000>; + max8952,sync-freq = <0>; + max8952,ramp-speed = <0>; + + regulator-name = "VARM_1.2V_C210"; + regulator-min-microvolt = <770000>; + regulator-max-microvolt = <1400000>; + regulator-always-on; + regulator-boot-on; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml b/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml new file mode 100644 index 000000000000..54522827265b --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml @@ -0,0 +1,139 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max8973.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX8973/MAX77621 voltage regulator + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + enum: + - maxim,max8973 + - maxim,max77621 + + junction-warn-millicelsius: + description: | + Junction warning temperature threshold in millicelsius. If die + temperature crosses this level then device generates the warning + interrupts. + Please note that thermal functionality is only supported on MAX77621. The + supported threshold warning temperature for MAX77621 are 120 degC and 140 + degC. + + maxim,dvs-gpio: + maxItems: 1 + description: | + GPIO which is connected to DVS pin of device. + + maxim,dvs-default-state: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: | + Default state of GPIO during initialisation. + 1 for HIGH and 0 for LOW. + + maxim,externally-enable: + type: boolean + description: | + Externally control the regulator output enable/disable. + + maxim,enable-gpio: + maxItems: 1 + description: | + GPIO for enable control. If the valid GPIO is provided then externally + enable control will be considered. + + maxim,enable-remote-sense: + type: boolean + description: Enable remote sense. + + maxim,enable-falling-slew-rate: + type: boolean + description: Enable falling slew rate. + + maxim,enable-active-discharge: + type: boolean + description: Eable active discharge. + + maxim,enable-frequency-shift: + type: boolean + description: Enable 9% frequency shift. + + maxim,enable-bias-control: + type: boolean + description: | + Enable bias control which can reduce the startup delay to 20us from 220us. + + maxim,enable-etr: + type: boolean + description: Enable Enhanced Transient Response. + + maxim,enable-high-etr-sensitivity: + type: boolean + description: | + Enhanced transient response circuit is enabled and set for high + sensitivity. If this property is available then etr will be enable + default. + Enhanced transient response (ETR) will affect the configuration of CKADV. + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@1b { + compatible = "maxim,max8973"; + reg = <0x1b>; + + regulator-min-microvolt = <935000>; + regulator-max-microvolt = <1200000>; + regulator-boot-on; + regulator-always-on; + }; + }; + + - | + #include <dt-bindings/gpio/tegra-gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@1b { + compatible = "maxim,max77621"; + reg = <0x1b>; + interrupt-parent = <&gpio>; + interrupts = <TEGRA_GPIO(Y, 1) IRQ_TYPE_LEVEL_LOW>; + + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1231250>; + regulator-name = "PPVAR_CPU"; + regulator-ramp-delay = <12500>; + maxim,dvs-default-state = <1>; + maxim,enable-active-discharge; + maxim,enable-bias-control; + maxim,enable-etr; + maxim,enable-gpio = <&pmic 5 GPIO_ACTIVE_HIGH>; + maxim,externally-enable; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/maxim,max8997.yaml b/Documentation/devicetree/bindings/regulator/maxim,max8997.yaml new file mode 100644 index 000000000000..d5a44ca3df04 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max8997.yaml @@ -0,0 +1,445 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max8997.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX8997 Power Management IC + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + The Maxim MAX8997 is a Power Management IC which includes voltage and current + regulators, charger controller with fuel gauge, RTC, clock outputs, haptic + motor driver, flash LED driver and Micro-USB Interface Controller. + + The binding here is not complete and describes only regulator and charger + controller parts. + +properties: + compatible: + const: maxim,max8997-pmic + + charger-supply: + description: | + Regulator node for charging current. + + interrupts: + items: + - description: irq1 interrupt + - description: alert interrupt + + max8997,pmic-buck1-dvs-voltage: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + description: | + A set of 8 voltage values in micro-volt (uV) units for buck1 when + changing voltage using GPIO DVS. + If none of max8997,pmic-buck[1/2/5]-uses-gpio-dvs optional property is + specified, the max8997,pmic-buck[1/2/5]-dvs-voltage property should + specify at least one voltage level (which would be a safe operating + voltage). + + max8997,pmic-buck2-dvs-voltage: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + description: | + A set of 8 voltage values in micro-volt (uV) units for buck2 when + changing voltage using GPIO DVS. + If none of max8997,pmic-buck[1/2/5]-uses-gpio-dvs optional property is + specified, the max8997,pmic-buck[1/2/5]-dvs-voltage property should + specify at least one voltage level (which would be a safe operating + voltage). + + max8997,pmic-buck5-dvs-voltage: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + description: | + A set of 8 voltage values in micro-volt (uV) units for buck5 when + changing voltage using GPIO DVS. + If none of max8997,pmic-buck[1/2/5]-uses-gpio-dvs optional property is + specified, the max8997,pmic-buck[1/2/5]-dvs-voltage property should + specify at least one voltage level (which would be a safe operating + voltage). + + max8997,pmic-buck1-uses-gpio-dvs: + type: boolean + description: | + buck1 can be controlled by GPIO DVS. + + max8997,pmic-buck2-uses-gpio-dvs: + type: boolean + description: | + buck2 can be controlled by GPIO DVS. + + max8997,pmic-buck5-uses-gpio-dvs: + type: boolean + description: | + buck5 can be controlled by GPIO DVS. + + max8997,pmic-buck125-default-dvs-idx: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + default: 0 + description: | + Default voltage setting selected from the possible 8 options selectable + by the dvs gpios. The value of this property should be between 0 and 7. + If not specified or if out of range, the default value of this property + is set to 0. + + max8997,pmic-buck125-dvs-gpios: + minItems: 3 + maxItems: 3 + description: | + GPIO specifiers for three host gpio's used for DVS. + + max8997,pmic-ignore-gpiodvs-side-effect: + type: boolean + description: | + When GPIO-DVS mode is used for multiple bucks, changing the voltage value + of one of the bucks may affect that of another buck, which is the side + effect of the change (set_voltage). Use this property to ignore such + side effects and change the voltage. + + reg: + maxItems: 1 + + regulators: + type: object + description: + List of child nodes that specify the regulators. + + patternProperties: + # 1-18 and 21 LDOs + "^LDO([1-9]|1[0-8]|21)$": + type: object + $ref: regulator.yaml# + description: + Properties for single LDO regulator. + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + # 7 bucks + "^BUCK[1-7]$": + type: object + $ref: regulator.yaml# + description: + Properties for single BUCK regulator. + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + "^EN32KHZ_[AC]P$": + type: object + $ref: regulator.yaml# + description: + 32768 Hz clock output (modelled as regulator) + + properties: + regulator-name: true + regulator-always-on: true + regulator-boot-on: true + + required: + - regulator-name + + additionalProperties: false + + properties: + CHARGER: + type: object + $ref: regulator.yaml# + description: main battery charger current control + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + CHARGER_CV: + type: object + $ref: regulator.yaml# + description: main battery charger voltage control + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + CHARGER_TOPOFF: + type: object + $ref: regulator.yaml# + description: end of charge current threshold level + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + ENVICHG: + type: object + $ref: regulator.yaml# + description: | + Battery Charging Current Monitor Output. This is a fixed voltage type + regulator + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + ESAFEOUT1: + type: object + $ref: regulator.yaml# + description: LDO19 + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + + ESAFEOUT2: + type: object + $ref: regulator.yaml# + description: LDO20 + + properties: + regulator-name: true + + required: + - regulator-name + + unevaluatedProperties: false + +required: + - compatible + - max8997,pmic-buck1-dvs-voltage + - max8997,pmic-buck2-dvs-voltage + - max8997,pmic-buck5-dvs-voltage + - reg + - regulators + +dependencies: + max8997,pmic-buck1-uses-gpio-dvs: [ 'max8997,pmic-buck125-dvs-gpios' ] + max8997,pmic-buck2-uses-gpio-dvs: [ 'max8997,pmic-buck125-dvs-gpios' ] + max8997,pmic-buck5-uses-gpio-dvs: [ 'max8997,pmic-buck125-dvs-gpios' ] + +additionalProperties: false + +if: + anyOf: + - required: + - max8997,pmic-buck1-uses-gpio-dvs + - required: + - max8997,pmic-buck2-uses-gpio-dvs + - required: + - max8997,pmic-buck5-uses-gpio-dvs +then: + properties: + max8997,pmic-buck1-dvs-voltage: + minItems: 8 + maxItems: 8 + max8997,pmic-buck2-dvs-voltage: + minItems: 8 + maxItems: 8 + max8997,pmic-buck5-dvs-voltage: + minItems: 8 + maxItems: 8 + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "maxim,max8997-pmic"; + reg = <0x66>; + + interrupts-extended = <&gpx0 7 IRQ_TYPE_LEVEL_LOW>, + <&gpx2 3 IRQ_TYPE_EDGE_FALLING>; + + max8997,pmic-buck1-uses-gpio-dvs; + max8997,pmic-buck2-uses-gpio-dvs; + max8997,pmic-buck5-uses-gpio-dvs; + + max8997,pmic-ignore-gpiodvs-side-effect; + max8997,pmic-buck125-default-dvs-idx = <0>; + + max8997,pmic-buck125-dvs-gpios = <&gpx0 5 GPIO_ACTIVE_HIGH>, + <&gpx0 6 GPIO_ACTIVE_HIGH>, + <&gpl0 0 GPIO_ACTIVE_HIGH>; + + max8997,pmic-buck1-dvs-voltage = <1350000>, <1300000>, + <1250000>, <1200000>, + <1150000>, <1100000>, + <1000000>, <950000>; + + max8997,pmic-buck2-dvs-voltage = <1100000>, <1000000>, + <950000>, <900000>, + <1100000>, <1000000>, + <950000>, <900000>; + + max8997,pmic-buck5-dvs-voltage = <1200000>, <1200000>, + <1200000>, <1200000>, + <1200000>, <1200000>, + <1200000>, <1200000>; + + pinctrl-0 = <&max8997_irq>, <&otg_gp>, <&usb_sel>; + pinctrl-names = "default"; + + charger-supply = <&charger_reg>; + + regulators { + LDO1 { + regulator-name = "VADC_3.3V_C210"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + + LDO2 { + regulator-name = "VALIVE_1.1V_C210"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-always-on; + }; + + BUCK1 { + regulator-name = "VARM_1.2V_C210"; + regulator-min-microvolt = <65000>; + regulator-max-microvolt = <2225000>; + regulator-always-on; + }; + + // ... + + BUCK7 { + regulator-name = "VCC_SUB_2.0V"; + regulator-min-microvolt = <2000000>; + regulator-max-microvolt = <2000000>; + regulator-always-on; + }; + + ESAFEOUT1 { + regulator-name = "SAFEOUT1"; + }; + + ESAFEOUT2 { + regulator-name = "SAFEOUT2"; + regulator-boot-on; + }; + + EN32KHZ_AP { + regulator-name = "EN32KHZ_AP"; + regulator-always-on; + }; + + EN32KHZ_CP { + regulator-name = "EN32KHZ_CP"; + regulator-always-on; + }; + + CHARGER { + regulator-name = "CHARGER"; + regulator-min-microamp = <200000>; + regulator-max-microamp = <950000>; + }; + + CHARGER_CV { + regulator-name = "CHARGER_CV"; + regulator-min-microvolt = <4200000>; + regulator-max-microvolt = <4200000>; + regulator-always-on; + }; + + CHARGER_TOPOFF { + regulator-name = "CHARGER_TOPOFF"; + regulator-min-microamp = <200000>; + regulator-max-microamp = <200000>; + regulator-always-on; + }; + }; + }; + }; + + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "maxim,max8997-pmic"; + reg = <0x66>; + + interrupt-parent = <&gpx0>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>, + <3 IRQ_TYPE_EDGE_FALLING>; + pinctrl-names = "default"; + pinctrl-0 = <&max8997_irq>; + + max8997,pmic-buck1-dvs-voltage = <1350000>; + max8997,pmic-buck2-dvs-voltage = <1100000>; + max8997,pmic-buck5-dvs-voltage = <1200000>; + + regulators { + LDO1 { + regulator-name = "VDD_ABB_3.3V"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + + // ... + + BUCK1 { + regulator-name = "VDD_ARM_1.2V"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + regulator-boot-on; + }; + + // ... + + EN32KHZ_AP { + regulator-name = "EN32KHZ_AP"; + regulator-always-on; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml index 34de38377aa6..b959504e0ea4 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml @@ -35,6 +35,7 @@ description: | PMIC. Supported regulator node names are For PM6150, smps1 - smps5, ldo1 - ldo19 For PM6150L, smps1 - smps8, ldo1 - ldo11, bob + For PM6350, smps1 - smps5, ldo1 - ldo22 For PM7325, smps1 - smps8, ldo1 - ldo19 For PM8005, smps1 - smps4 For PM8009, smps1 - smps2, ldo1 - ldo7 @@ -52,6 +53,7 @@ properties: enum: - qcom,pm6150-rpmh-regulators - qcom,pm6150l-rpmh-regulators + - qcom,pm6350-rpmh-regulators - qcom,pm7325-rpmh-regulators - qcom,pm8005-rpmh-regulators - qcom,pm8009-rpmh-regulators diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml index 83b53579f463..f052e03be402 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml @@ -65,6 +65,9 @@ description: For pms405, s1, s2, s3, s4, s5, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13 + For pm2250, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, + l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22 + maintainers: - Kathiravan T <kathirav@codeaurora.org> @@ -86,6 +89,7 @@ properties: - qcom,rpm-pmi8994-regulators - qcom,rpm-pmi8998-regulators - qcom,rpm-pms405-regulators + - qcom,rpm-pm2250-regulators patternProperties: ".*-supply$": diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.txt b/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.txt deleted file mode 100644 index bae3c7f838cf..000000000000 --- a/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.txt +++ /dev/null @@ -1,79 +0,0 @@ -Binding for Samsung S2MPA01 regulator block -=========================================== - -This is a part of device tree bindings for S2M family multi-function devices. -More information can be found in bindings/mfd/sec-core.txt file. - -The S2MPA01 device provide buck and LDO regulators. - -To register these with regulator framework instantiate under main device node -a sub-node named "regulators" with more sub-nodes for each regulator using the -common regulator binding documented in: - - Documentation/devicetree/bindings/regulator/regulator.txt - - -Names of regulators supported by S2MPA01 device: - - LDOn - - valid values for n are 1 to 26 - - Example: LDO1, LD02, LDO26 - - BUCKn - - valid values for n are 1 to 10. - - Example: BUCK1, BUCK2, BUCK9 -Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number -as per the datasheet of device. - - -Optional properties of buck regulator nodes under "regulators" sub-node: - - regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500 - (default), 25000, or 50000. May be 0 for disabling the ramp delay on - BUCK{1,2,3,4}. - - In the absence of the regulator-ramp-delay property, the default ramp - delay will be used. - - Note: Some bucks share the ramp rate setting i.e. same ramp value - will be set for a particular group of bucks so provide the same - regulator-ramp-delay value for them. - Groups sharing ramp rate: - - buck{1,6}, - - buck{2,4}, - - buck{8,9,10}. - -Example: - - s2mpa01_pmic@66 { - compatible = "samsung,s2mpa01-pmic"; - reg = <0x66>; - - regulators { - ldo1_reg: LDO1 { - regulator-name = "VDD_ALIVE"; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1000000>; - }; - - ldo2_reg: LDO2 { - regulator-name = "VDDQ_MMC2"; - regulator-min-microvolt = <2800000>; - regulator-max-microvolt = <2800000>; - regulator-always-on; - }; - - buck1_reg: BUCK1 { - regulator-name = "vdd_mif"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - }; - - buck2_reg: BUCK2 { - regulator-name = "vdd_arm"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - regulator-ramp-delay = <50000>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.yaml new file mode 100644 index 000000000000..0627dec513da --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mpa01.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s2mpa01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPA01 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPA01 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml for + additional information and example. + +patternProperties: + # 26 LDOs + "^LDO([1-9]|1[0-9]|2[0-6])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + required: + - regulator-name + + # 10 bucks + "^BUCK([1-9]|10)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + properties: + regulator-ramp-delay: + enum: [0, 6250, 12500, 25000, 50000] + default: 12500 + description: | + May be 0 for disabling the ramp delay on BUCK{1,2,3,4}. + + In the absence of the regulator-ramp-delay property, the default ramp + delay will be used. + + Note: Some bucks share the ramp rate setting i.e. same ramp value + will be set for a particular group of bucks so provide the same + regulator-ramp-delay value for them. + Groups sharing ramp rate: + * buck{1,6}, + * buck{2,4}, + * buck{8,9,10}. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps11.txt b/Documentation/devicetree/bindings/regulator/samsung,s2mps11.txt deleted file mode 100644 index 27a48bf1b185..000000000000 --- a/Documentation/devicetree/bindings/regulator/samsung,s2mps11.txt +++ /dev/null @@ -1,102 +0,0 @@ -Binding for Samsung S2M family regulator block -============================================== - -This is a part of device tree bindings for S2M family multi-function devices. -More information can be found in bindings/mfd/sec-core.txt file. - -The S2MPS11/13/14/15 and S2MPU02 devices provide buck and LDO regulators. - -To register these with regulator framework instantiate under main device node -a sub-node named "regulators" with more sub-nodes for each regulator using the -common regulator binding documented in: - - Documentation/devicetree/bindings/regulator/regulator.txt - - -Names of regulators supported by different devices: - - LDOn - - valid values for n are: - - S2MPS11: 1 to 38 - - S2MPS13: 1 to 40 - - S2MPS14: 1 to 25 - - S2MPS15: 1 to 27 - - S2MPU02: 1 to 28 - - Example: LDO1, LDO2, LDO28 - - BUCKn - - valid values for n are: - - S2MPS11: 1 to 10 - - S2MPS13: 1 to 10 - - S2MPS14: 1 to 5 - - S2MPS15: 1 to 10 - - S2MPU02: 1 to 7 - - Example: BUCK1, BUCK2, BUCK9 -Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number -as per the datasheet of device. - - -Optional properties of the nodes under "regulators" sub-node: - - regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500, - 25000 (default) or 50000. - - Additionally S2MPS11 supports disabling ramp delay for BUCK{2,3,4,6} - by setting it to <0>. - - Note: On S2MPS11 some bucks share the ramp rate setting i.e. same ramp value - will be set for a particular group of bucks so provide the same - regulator-ramp-delay value for them. - Groups sharing ramp rate: - - buck{1,6}, - - buck{3,4}, - - buck{7,8,10}. - - - samsung,ext-control-gpios: On S2MPS14 the LDO10, LDO11 and LDO12 can be - configured to external control over GPIO. To turn this feature on this - property must be added to the regulator sub-node: - - samsung,ext-control-gpios: GPIO specifier for one GPIO - controlling this regulator (enable/disable) - Example: - LDO12 { - regulator-name = "V_EMMC_2.8V"; - regulator-min-microvolt = <2800000>; - regulator-max-microvolt = <2800000>; - samsung,ext-control-gpios = <&gpk0 2 0>; - }; - - -Example: - - s2mps11_pmic@66 { - compatible = "samsung,s2mps11-pmic"; - reg = <0x66>; - - regulators { - ldo1_reg: LDO1 { - regulator-name = "VDD_ABB_3.3V"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - ldo2_reg: LDO2 { - regulator-name = "VDD_ALIVE_1.1V"; - regulator-min-microvolt = <1100000>; - regulator-max-microvolt = <1100000>; - regulator-always-on; - }; - - buck1_reg: BUCK1 { - regulator-name = "vdd_mif"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - }; - - buck2_reg: BUCK2 { - regulator-name = "vdd_arm"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - regulator-ramp-delay = <50000>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mps11.yaml new file mode 100644 index 000000000000..e3b780715f44 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mps11.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s2mps11.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPS11 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPS11 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for + additional information and example. + +patternProperties: + # 38 LDOs + "^LDO([1-9]|[1-2][0-9]|3[0-8])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + required: + - regulator-name + + # 10 bucks + "^BUCK([1-9]|10)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps13.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mps13.yaml new file mode 100644 index 000000000000..579d77aefc3f --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mps13.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s2mps13.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPS13 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPS13 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for + additional information and example. + +patternProperties: + # 40 LDOs + "^LDO([1-9]|[1-3][0-9]|40)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + required: + - regulator-name + + # 10 bucks + "^BUCK([1-9]|10)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml new file mode 100644 index 000000000000..fdea290b3e94 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s2mps14.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPS14 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPS14 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for + additional information and example. + +patternProperties: + # 25 LDOs + "^LDO([1-9]|[1][0-9]|2[0-5])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + required: + - regulator-name + + # 5 bucks + "^BUCK[1-5]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps15.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mps15.yaml new file mode 100644 index 000000000000..b3a883c94628 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mps15.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s2mps15.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPS15 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPS15 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for + additional information and example. + +patternProperties: + # 27 LDOs + "^LDO([1-9]|[1][0-9]|2[0-7])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + required: + - regulator-name + + # 10 bucks + "^BUCK([1-9]|10)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mpu02.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mpu02.yaml new file mode 100644 index 000000000000..0ded6953e3b6 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mpu02.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s2mpu02.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPU02 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPU02 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for + additional information and example. + +patternProperties: + # 28 LDOs + "^LDO([1-9]|1[0-9]|2[0-8])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + required: + - regulator-name + + # 7 bucks + "^BUCK[1-7]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/samsung,s5m8767.txt b/Documentation/devicetree/bindings/regulator/samsung,s5m8767.txt deleted file mode 100644 index 093edda0c8df..000000000000 --- a/Documentation/devicetree/bindings/regulator/samsung,s5m8767.txt +++ /dev/null @@ -1,145 +0,0 @@ -Binding for Samsung S5M8767 regulator block -=========================================== - -This is a part of device tree bindings for S5M family multi-function devices. -More information can be found in bindings/mfd/sec-core.txt file. - -The S5M8767 device provide buck and LDO regulators. - -To register these with regulator framework instantiate under main device node -a sub-node named "regulators" with more sub-nodes for each regulator using the -common regulator binding documented in: - - Documentation/devicetree/bindings/regulator/regulator.txt - - -Required properties of the main device node (the parent!): - - s5m8767,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV) - units for buck2 when changing voltage using gpio dvs. Refer to [1] below - for additional information. - - - s5m8767,pmic-buck3-dvs-voltage: A set of 8 voltage values in micro-volt (uV) - units for buck3 when changing voltage using gpio dvs. Refer to [1] below - for additional information. - - - s5m8767,pmic-buck4-dvs-voltage: A set of 8 voltage values in micro-volt (uV) - units for buck4 when changing voltage using gpio dvs. Refer to [1] below - for additional information. - - - s5m8767,pmic-buck-ds-gpios: GPIO specifiers for three host gpio's used - for selecting GPIO DVS lines. It is one-to-one mapped to dvs gpio lines. - - [1] If none of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional - property is specified, the 's5m8767,pmic-buck[2/3/4]-dvs-voltage' - property should specify atleast one voltage level (which would be a - safe operating voltage). - - If either of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional - property is specified, then all the eight voltage values for the - 's5m8767,pmic-buck[2/3/4]-dvs-voltage' should be specified. - -Optional properties of the main device node (the parent!): - - s5m8767,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs. - - s5m8767,pmic-buck3-uses-gpio-dvs: 'buck3' can be controlled by gpio dvs. - - s5m8767,pmic-buck4-uses-gpio-dvs: 'buck4' can be controlled by gpio dvs. - -Additional properties required if either of the optional properties are used: - - - s5m8767,pmic-buck234-default-dvs-idx: Default voltage setting selected from - the possible 8 options selectable by the dvs gpios. The value of this - property should be between 0 and 7. If not specified or if out of range, the - default value of this property is set to 0. - - - s5m8767,pmic-buck-dvs-gpios: GPIO specifiers for three host gpio's used - for dvs. The format of the gpio specifier depends in the gpio controller. - - -Names of regulators supported by S5M8767 device: - - LDOn - - valid values for n are 1 to 28 - - Example: LDO1, LDO2, LDO28 - - BUCKn - - valid values for n are 1 to 9. - - Example: BUCK1, BUCK2, BUCK9 -Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number -as per the datasheet of device. - - -Optional properties of the nodes under "regulators" sub-node: - - op_mode: describes the different operating modes of the LDO's with - power mode change in SOC. The different possible values are, - 0 - always off mode - 1 - on in normal mode - 2 - low power mode - 3 - suspend mode - - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one - GPIO controlling this regulator - (enable/disable); This is valid only - for buck9. - -Example: - - s5m8767_pmic@66 { - compatible = "samsung,s5m8767-pmic"; - reg = <0x66>; - - s5m8767,pmic-buck2-uses-gpio-dvs; - s5m8767,pmic-buck3-uses-gpio-dvs; - s5m8767,pmic-buck4-uses-gpio-dvs; - - s5m8767,pmic-buck-default-dvs-idx = <0>; - - s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 0>, /* DVS1 */ - <&gpx0 1 0>, /* DVS2 */ - <&gpx0 2 0>; /* DVS3 */ - - s5m8767,pmic-buck-ds-gpios = <&gpx2 3 0>, /* SET1 */ - <&gpx2 4 0>, /* SET2 */ - <&gpx2 5 0>; /* SET3 */ - - s5m8767,pmic-buck2-dvs-voltage = <1350000>, <1300000>, - <1250000>, <1200000>, - <1150000>, <1100000>, - <1000000>, <950000>; - - s5m8767,pmic-buck3-dvs-voltage = <1100000>, <1100000>, - <1100000>, <1100000>, - <1000000>, <1000000>, - <1000000>, <1000000>; - - s5m8767,pmic-buck4-dvs-voltage = <1200000>, <1200000>, - <1200000>, <1200000>, - <1200000>, <1200000>, - <1200000>, <1200000>; - - regulators { - ldo1_reg: LDO1 { - regulator-name = "VDD_ABB_3.3V"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - op_mode = <1>; /* Normal Mode */ - }; - - ldo2_reg: LDO2 { - regulator-name = "VDD_ALIVE_1.1V"; - regulator-min-microvolt = <1100000>; - regulator-max-microvolt = <1100000>; - regulator-always-on; - }; - - buck1_reg: BUCK1 { - regulator-name = "VDD_MIF_1.2V"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-always-on; - regulator-boot-on; - }; - - vemmc_reg: BUCK9 { - regulator-name = "VMEM_VDD_2.8V"; - regulator-min-microvolt = <2800000>; - regulator-max-microvolt = <2800000>; - op_mode = <3>; /* Standby Mode */ - s5m8767,pmic-ext-control-gpios = <&gpk0 2 0>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml b/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml new file mode 100644 index 000000000000..80a63d47790a --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s5m8767.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5M8767 Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S5M8767 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml for + additional information and example. + +patternProperties: + # 28 LDOs + "^LDO([1-9]|1[0-9]|2[0-8])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + properties: + op_mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 1 + description: | + Describes the different operating modes of the LDO's with power mode + change in SOC. The different possible values are: + 0 - always off mode + 1 - on in normal mode + 2 - low power mode + 3 - suspend mode + + required: + - regulator-name + + # 8 bucks + "^BUCK[1-8]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + required: + - regulator-name + + # 9 buck + "^BUCK9$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single BUCK regulator. + + properties: + s5m8767,pmic-ext-control-gpios: + maxItems: 1 + description: | + GPIO specifier for one GPIO controlling this regulator on/off. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml b/Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml new file mode 100644 index 000000000000..a52a67c869b5 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/silergy,sy8106a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silergy SY8106A Voltage Regulator Device Tree Bindings + +maintainers: + - Ondrej Jirman <megous@megous.com> + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + const: silergy,sy8106a + + reg: + maxItems: 1 + + silergy,fixed-microvolt: + description: > + The voltage when I2C regulating is disabled (set by external resistor + like a fixed voltage) + +required: + - compatible + - reg + - silergy,fixed-microvolt + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@65 { + compatible = "silergy,sy8106a"; + reg = <0x65>; + regulator-name = "sy8106a-vdd"; + silergy,fixed-microvolt = <1200000>; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1400000>; + regulator-boot-on; + regulator-always-on; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml index 861d5f3c79e8..1218f21ba320 100644 --- a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml @@ -27,6 +27,7 @@ properties: - socionext,uniphier-pxs2-usb3-regulator - socionext,uniphier-ld20-usb3-regulator - socionext,uniphier-pxs3-usb3-regulator + - socionext,uniphier-nx1-usb3-regulator reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml index 9f1c70381b82..df0191b1ceba 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 booster for ADC analog input switches bindings maintainers: - - Fabrice Gasnier <fabrice.gasnier@st.com> + - Fabrice Gasnier <fabrice.gasnier@foss.st.com> description: | Some STM32 devices embed a 3.3V booster supplied by Vdda, that can be used diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml index 3cd4a254e4cb..836d4156d54c 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml @@ -12,7 +12,7 @@ description: | components through the dedicated VREF+ pin. maintainers: - - Fabrice Gasnier <fabrice.gasnier@st.com> + - Fabrice Gasnier <fabrice.gasnier@foss.st.com> allOf: - $ref: "regulator.yaml#" diff --git a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml index e6322bc3e447..bd07b9c81570 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STM32MP1 PWR voltage regulators maintainers: - - Pascal Paillet <p.paillet@st.com> + - Pascal Paillet <p.paillet@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt b/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt deleted file mode 100644 index 39a8ca73f572..000000000000 --- a/Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt +++ /dev/null @@ -1,23 +0,0 @@ -SY8106A Voltage regulator - -Required properties: -- compatible: Must be "silergy,sy8106a" -- reg: I2C slave address - must be <0x65> -- silergy,fixed-microvolt - the voltage when I2C regulating is disabled (set - by external resistor like a fixed voltage) - -Any property defined as part of the core regulator binding, defined in -./regulator.txt, can also be used. - -Example: - - sy8106a { - compatible = "silergy,sy8106a"; - reg = <0x65>; - regulator-name = "sy8106a-vdd"; - silergy,fixed-microvolt = <1200000>; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1400000>; - regulator-boot-on; - regulator-always-on; - }; diff --git a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml new file mode 100644 index 000000000000..d892d29a656b --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/remoteproc/amlogic,meson-mx-ao-arc.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson AO ARC Remote Processor bindings + +description: + Amlogic Meson6, Meson8, Meson8b and Meson8m2 SoCs embed an ARC core + controller for always-on operations, typically used for managing + system suspend. Meson6 and older use a ARC core based on the ARCv1 + ISA, while Meson8, Meson8b and Meson8m2 use an ARC EM4 (ARCv2 ISA) + core. + +maintainers: + - Martin Blumenstingl <martin.blumenstingl@googlemail.com> + +properties: + compatible: + items: + - enum: + - amlogic,meson8-ao-arc + - amlogic,meson8b-ao-arc + - const: amlogic,meson-mx-ao-arc + + firmware-name: + $ref: /schemas/types.yaml#/definitions/string + description: + The name of the firmware which should be loaded for this remote + processor. + + reg: + description: + Address ranges of the remap and CPU control addresses for the + remote processor. + minItems: 2 + + reg-names: + items: + - const: remap + - const: cpu + + resets: + minItems: 1 + + clocks: + minItems: 1 + + sram: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandles to a reserved SRAM region which is used as the memory of + the ARC core. The region should be defined as child nodes of the + AHB SRAM node as per the generic bindings in + Documentation/devicetree/bindings/sram/sram.yaml + + amlogic,secbus2: + $ref: /schemas/types.yaml#/definitions/phandle + description: + A phandle to the SECBUS2 region which contains some configuration + bits of this remote processor + +required: + - compatible + - reg + - reg-names + - resets + - clocks + - sram + - amlogic,secbus2 + +additionalProperties: false + +examples: + - | + remoteproc@1c { + compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc"; + reg = <0x1c 0x8>, <0x38 0x8>; + reg-names = "remap", "cpu"; + resets = <&media_cpu_reset>; + clocks = <&media_cpu_clock>; + sram = <&ahb_sram_ao_arc>; + amlogic,secbus2 = <&secbus2>; + }; + +... diff --git a/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml b/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml index d0aa91bbf5e5..aaaaabad46ea 100644 --- a/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml @@ -58,7 +58,7 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/jz4770-cgu.h> + #include <dt-bindings/clock/ingenic,jz4770-cgu.h> vpu: video-decoder@132a0000 { compatible = "ingenic,jz4770-vpu-rproc"; diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt deleted file mode 100644 index 3f5f78764b60..000000000000 --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt +++ /dev/null @@ -1,36 +0,0 @@ -Mediatek SCP Bindings ----------------------------------------- - -This binding provides support for ARM Cortex M4 Co-processor found on some -Mediatek SoCs. - -Required properties: -- compatible Should be "mediatek,mt8183-scp" -- reg Should contain the address ranges for memory regions: - SRAM, CFG, and L1TCM. -- reg-names Contains the corresponding names for the memory regions: - "sram", "cfg", and "l1tcm". -- clocks Clock for co-processor (See: ../clock/clock-bindings.txt) -- clock-names Contains the corresponding name for the clock. This - should be named "main". - -Subnodes --------- - -Subnodes of the SCP represent rpmsg devices. The names of the devices are not -important. The properties of these nodes are defined by the individual bindings -for the rpmsg devices - but must contain the following property: - -- mtk,rpmsg-name Contains the name for the rpmsg device. Used to match - the subnode to rpmsg device announced by SCP. - -Example: - - scp: scp@10500000 { - compatible = "mediatek,mt8183-scp"; - reg = <0 0x10500000 0 0x80000>, - <0 0x105c0000 0 0x5000>; - reg-names = "sram", "cfg"; - clocks = <&infracfg CLK_INFRA_SCPSYS>; - clock-names = "main"; - }; diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml new file mode 100644 index 000000000000..d21a25ee96e6 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/mtk,scp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek SCP Bindings + +maintainers: + - Tinghan Shen <tinghan.shen@mediatek.com> + +description: + This binding provides support for ARM Cortex M4 Co-processor found on some + Mediatek SoCs. + +properties: + compatible: + enum: + - mediatek,mt8183-scp + - mediatek,mt8192-scp + - mediatek,mt8195-scp + + reg: + description: + Should contain the address ranges for memory regions SRAM, CFG, and + L1TCM. + maxItems: 3 + + reg-names: + items: + - const: sram + - const: cfg + - const: l1tcm + + clocks: + description: + Clock for co-processor (see ../clock/clock-bindings.txt). + Required by mt8183 and mt8192. + maxItems: 1 + + clock-names: + const: main + +required: + - compatible + - reg + - reg-names + +if: + properties: + compatible: + enum: + - mediatek,mt8183-scp + - mediatek,mt8192-scp +then: + required: + - clocks + - clock-names + +additionalProperties: + type: object + description: + Subnodes of the SCP represent rpmsg devices. The names of the devices + are not important. The properties of these nodes are defined by the + individual bindings for the rpmsg devices. + properties: + mediatek,rpmsg-name: + $ref: /schemas/types.yaml#/definitions/string-array + description: + Contains the name for the rpmsg device. Used to match + the subnode to rpmsg device announced by SCP. + + required: + - mediatek,rpmsg-name + +examples: + - | + #include <dt-bindings/clock/mt8183-clk.h> + + scp@10500000 { + compatible = "mediatek,mt8183-scp"; + reg = <0x10500000 0x80000>, + <0x10700000 0x8000>, + <0x10720000 0xe0000>; + reg-names = "sram", "cfg", "l1tcm"; + clocks = <&infracfg CLK_INFRA_SCPSYS>; + clock-names = "main"; + + cros_ec { + mediatek,rpmsg-name = "cros-ec-rpmsg"; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index 0c112f3264a9..63e06d93bca3 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -25,6 +25,7 @@ properties: - qcom,qcs404-cdsp-pas - qcom,qcs404-wcss-pas - qcom,sc7180-mpss-pas + - qcom,sc7280-mpss-pas - qcom,sc8180x-adsp-pas - qcom,sc8180x-cdsp-pas - qcom,sc8180x-mpss-pas @@ -93,6 +94,10 @@ properties: maxItems: 1 description: Reference to the reserved-memory for the Hexagon core + qcom,qmp: + $ref: /schemas/types.yaml#/definitions/phandle + description: Reference to the AOSS side-channel message RAM. + qcom,smem-states: $ref: /schemas/types.yaml#/definitions/phandle-array description: States used by the AP to signal the Hexagon core @@ -147,6 +152,7 @@ allOf: - qcom,msm8998-adsp-pas - qcom,qcs404-adsp-pas - qcom,qcs404-wcss-pas + - qcom,sc7280-mpss-pas - qcom,sc8180x-adsp-pas - qcom,sc8180x-cdsp-pas - qcom,sc8180x-mpss-pas @@ -292,6 +298,7 @@ allOf: contains: enum: - qcom,sc7180-mpss-pas + - qcom,sc7280-mpss-pas - qcom,sc8180x-mpss-pas - qcom,sdx55-mpss-pas - qcom,sm8150-mpss-pas @@ -369,13 +376,11 @@ allOf: properties: power-domains: items: - - description: Load State power domain - description: CX power domain - description: MX power domain - description: MSS power domain power-domain-names: items: - - const: load_state - const: cx - const: mx - const: mss @@ -391,43 +396,21 @@ allOf: properties: power-domains: items: - - description: Load State power domain - description: CX power domain - power-domain-names: - items: - - const: load_state - - const: cx - if: properties: compatible: contains: enum: + - qcom,sc7280-mpss-pas + - qcom,sdx55-mpss-pas - qcom,sm8150-mpss-pas - qcom,sm8350-mpss-pas then: properties: power-domains: items: - - description: Load State power domain - - description: CX power domain - - description: MSS power domain - power-domain-names: - items: - - const: load_state - - const: cx - - const: mss - - - if: - properties: - compatible: - contains: - enum: - - qcom,sdx55-mpss-pas - then: - properties: - power-domains: - items: - description: CX power domain - description: MSS power domain power-domain-names: @@ -451,12 +434,10 @@ allOf: properties: power-domains: items: - - description: Load State power domain - description: LCX power domain - description: LMX power domain power-domain-names: items: - - const: load_state - const: lcx - const: lmx @@ -470,12 +451,10 @@ allOf: properties: power-domains: items: - - description: Load State power domain - description: CX power domain - description: MXC power domain power-domain-names: items: - - const: load_state - const: cx - const: mxc @@ -500,6 +479,7 @@ allOf: contains: enum: - qcom,sc7180-mpss-pas + - qcom,sc7280-mpss-pas then: properties: resets: @@ -511,6 +491,25 @@ allOf: - const: mss_restart - const: pdc_reset + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8974-adsp-pil + - qcom,msm8996-adsp-pil + - qcom,msm8996-slpi-pil + - qcom,msm8998-adsp-pas + - qcom,msm8998-slpi-pas + - qcom,qcs404-adsp-pas + - qcom,qcs404-cdsp-pas + - qcom,qcs404-wcss-pas + - qcom,sdm660-adsp-pas + - qcom,sdx55-mpss-pas + then: + properties: + qcom,qmp: false + examples: - | #include <dt-bindings/clock/qcom,rpmcc.h> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 69c49c7b2cff..8f1507052afd 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -15,6 +15,7 @@ on the Qualcomm Hexagon core. "qcom,msm8996-mss-pil" "qcom,msm8998-mss-pil" "qcom,sc7180-mss-pil" + "qcom,sc7280-mss-pil" "qcom,sdm845-mss-pil" - reg: @@ -47,6 +48,7 @@ on the Qualcomm Hexagon core. qcom,msm8996-mss-pil: qcom,msm8998-mss-pil: qcom,sc7180-mss-pil: + qcom,sc7280-mss-pil: qcom,sdm845-mss-pil: must be "wdog", "fatal", "ready", "handover", "stop-ack", "shutdown-ack" @@ -87,6 +89,8 @@ on the Qualcomm Hexagon core. qcom,sc7180-mss-pil: must be "iface", "bus", "xo", "snoc_axi", "mnoc_axi", "nav" + qcom,sc7280-mss-pil: + must be "iface", "xo", "snoc_axi", "offline", "pka" qcom,sdm845-mss-pil: must be "iface", "bus", "mem", "xo", "gpll0_mss", "snoc_axi", "mnoc_axi", "prng" @@ -98,7 +102,7 @@ on the Qualcomm Hexagon core. reference to the list of 3 reset-controllers for the wcss sub-system reference to the list of 2 reset-controllers for the modem - sub-system on SC7180, SDM845 SoCs + sub-system on SC7180, SC7280, SDM845 SoCs - reset-names: Usage: required @@ -107,7 +111,7 @@ on the Qualcomm Hexagon core. must be "wcss_aon_reset", "wcss_reset", "wcss_q6_reset" for the wcss sub-system must be "mss_restart", "pdc_reset" for the modem - sub-system on SC7180, SDM845 SoCs + sub-system on SC7180, SC7280, SDM845 SoCs For devices where the mba and mpss sub-nodes are not specified, mba/mpss region should be referenced as follows: @@ -173,8 +177,16 @@ For the compatible string below the following supplies are required: qcom,msm8998-mss-pil: must be "cx", "mx" qcom,sc7180-mss-pil: + must be "cx", "mx", "mss" + qcom,sc7280-mss-pil: + must be "cx", "mss" qcom,sdm845-mss-pil: - must be "cx", "mx", "mss", "load_state" + must be "cx", "mx", "mss" + +- qcom,qmp: + Usage: optional + Value type: <phandle> + Definition: reference to the AOSS side-channel message RAM. - qcom,smem-states: Usage: required @@ -193,6 +205,9 @@ For the compatible string below the following supplies are required: Definition: a phandle reference to a syscon representing TCSR followed by the three offsets within syscon for q6, modem and nc halt registers. + a phandle reference to a syscon representing TCSR followed + by the four offsets within syscon for q6, modem, nc and vq6 + halt registers on SC7280 SoCs. For the compatible strings below the following phandle references are required: "qcom,sc7180-mss-pil" @@ -203,6 +218,24 @@ For the compatible strings below the following phandle references are required: by the offset within syscon for conn_box_spare0 register used by the modem sub-system running on SC7180 SoC. +For the compatible strings below the following phandle references are required: + "qcom,sc7280-mss-pil" +- qcom,ext-regs: + Usage: required + Value type: <prop-encoded-array> + Definition: two phandle references to syscons representing TCSR_REG and + TCSR register space followed by the two offsets within the syscon + to force_clk_en/rscc_disable and axim1_clk_off/crypto_clk_off + registers respectively. + +- qcom,qaccept-regs: + Usage: required + Value type: <prop-encoded-array> + Definition: a phandle reference to a syscon representing TCSR followed + by the three offsets within syscon for mdm, cx and axi + qaccept registers used by the modem sub-system running on + SC7280 SoC. + The Hexagon node must contain iommus property as described in ../iommu/iommu.txt on platforms which do not have TrustZone. diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index 1e6225677e00..b587c97c282b 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -11,8 +11,8 @@ description: boots firmwares on the ST32MP family chipset. maintainers: - - Fabien Dessenne <fabien.dessenne@st.com> - - Arnaud Pouliquen <arnaud.pouliquen@st.com> + - Fabien Dessenne <fabien.dessenne@foss.st.com> + - Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml index 6070456a7b67..5ec6505ac408 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml @@ -133,9 +133,7 @@ unevaluatedProperties: false examples: - | - / { - model = "Texas Instruments K3 J721E SoC"; - compatible = "ti,j721e"; + soc { #address-cells = <2>; #size-cells = <2>; diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml index 130fbaacc4b1..eeef255c4045 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml @@ -230,9 +230,7 @@ additionalProperties: false examples: - | - / { - model = "Texas Instruments K3 AM654 SoC"; - compatible = "ti,am654-evm", "ti,am654"; + soc { #address-cells = <2>; #size-cells = <2>; diff --git a/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml b/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml new file mode 100644 index 000000000000..83dfe499a259 --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reserved-memory/memory-region.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Reserved Memory Region Device Tree Binding + +maintainers: + - devicetree-spec@vger.kernel.org + +description: | + Regions in the /reserved-memory node may be referenced by other device + nodes by adding a memory-region property to the device node. + +select: true + +properties: + memory-region: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: > + Phandle to a /reserved-memory child node assigned to the device. + + memory-region-names: + $ref: /schemas/types.yaml#/definitions/string-array + description: > + A list of names, one for each corresponding entry in the + memory-region property + +additionalProperties: true + +examples: + - | + fb0: video@12300000 { + /* ... */ + reg = <0x12300000 0x1000>; + memory-region = <&display_reserved>; + }; + +... diff --git a/Documentation/devicetree/bindings/reserved-memory/ramoops.txt b/Documentation/devicetree/bindings/reserved-memory/ramoops.txt deleted file mode 100644 index b571ef6dab0f..000000000000 --- a/Documentation/devicetree/bindings/reserved-memory/ramoops.txt +++ /dev/null @@ -1,66 +0,0 @@ -Ramoops oops/panic logger -========================= - -ramoops provides persistent RAM storage for oops and panics, so they can be -recovered after a reboot. This is a child-node of "/reserved-memory", and -is named "ramoops" after the backend, rather than "pstore" which is the -subsystem. - -Parts of this storage may be set aside for other persistent log buffers, such -as kernel log messages, or for optional ECC error-correction data. The total -size of these optional buffers must fit in the reserved region. - -Any remaining space will be used for a circular buffer of oops and panic -records. These records have a configurable size, with a size of 0 indicating -that they should be disabled. - -At least one of "record-size", "console-size", "ftrace-size", or "pmsg-size" -must be set non-zero, but are otherwise optional as listed below. - - -Required properties: - -- compatible: must be "ramoops" - -- reg: region of memory that is preserved between reboots - - -Optional properties: - -- ecc-size: enables ECC support and specifies ECC buffer size in bytes - (defaults to 0: no ECC) - -- record-size: maximum size in bytes of each kmsg dump. - (defaults to 0: disabled) - -- console-size: size in bytes of log buffer reserved for kernel messages - (defaults to 0: disabled) - -- ftrace-size: size in bytes of log buffer reserved for function tracing and - profiling (defaults to 0: disabled) - -- pmsg-size: size in bytes of log buffer reserved for userspace messages - (defaults to 0: disabled) - -- mem-type: if present, sets the type of mapping is to be used to map the - reserved region. mem-type: 0 = write-combined (default), 1 = unbuffered, - 2 = cached. - -- unbuffered: deprecated, use mem_type instead. If present, and mem_type is - not specified, it is equivalent to mem_type = 1 and uses unbuffered mappings - to map the reserved region (defaults to buffered mappings mem_type = 0). If - both are specified -- "mem_type" overrides "unbuffered". - -- max-reason: if present, sets maximum type of kmsg dump reasons to store - (defaults to 2: log Oopses and Panics). This can be set to INT_MAX to - store all kmsg dumps. See include/linux/kmsg_dump.h KMSG_DUMP_* for other - kmsg dump reason values. Setting this to 0 (KMSG_DUMP_UNDEF), means the - reason filtering will be controlled by the printk.always_kmsg_dump boot - param: if unset, it will be KMSG_DUMP_OOPS, otherwise KMSG_DUMP_MAX. - -- no-dump-oops: deprecated, use max_reason instead. If present, and - max_reason is not specified, it is equivalent to max_reason = 1 - (KMSG_DUMP_PANIC). - -- flags: if present, pass ramoops behavioral flags (defaults to 0, - see include/linux/pstore_ram.h RAMOOPS_FLAG_* for flag values). diff --git a/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml b/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml new file mode 100644 index 000000000000..f4c351a69542 --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml @@ -0,0 +1,145 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/reserved-memory/ramoops.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Ramoops oops/panic logger + +description: | + ramoops provides persistent RAM storage for oops and panics, so they can be + recovered after a reboot. This is a child-node of "/reserved-memory", and + is named "ramoops" after the backend, rather than "pstore" which is the + subsystem. + + Parts of this storage may be set aside for other persistent log buffers, such + as kernel log messages, or for optional ECC error-correction data. The total + size of these optional buffers must fit in the reserved region. + + Any remaining space will be used for a circular buffer of oops and panic + records. These records have a configurable size, with a size of 0 indicating + that they should be disabled. + + At least one of "record-size", "console-size", "ftrace-size", or "pmsg-size" + must be set non-zero, but are otherwise optional as listed below. + +maintainers: + - Kees Cook <keescook@chromium.org> + +allOf: + - $ref: "reserved-memory.yaml" + +properties: + compatible: + const: ramoops + + reg: + description: region of memory that is preserved between reboots + + ecc-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: enables ECC support and specifies ECC buffer size in bytes + default: 0 # no ECC + + record-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: maximum size in bytes of each kmsg dump + default: 0 + + console-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: size in bytes of log buffer reserved for kernel messages + default: 0 + + ftrace-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: size in bytes of log buffer reserved for function tracing and profiling + default: 0 + + pmsg-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: size in bytes of log buffer reserved for userspace messages + default: 0 + + mem-type: + $ref: /schemas/types.yaml#/definitions/uint32 + description: if present, sets the type of mapping is to be used to map the reserved region. + default: 0 + oneOf: + - const: 0 + description: write-combined + - const: 1 + description: unbuffered + - const: 2 + description: cached + + max-reason: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 2 # log oopses and panics + maximum: 0x7fffffff + description: | + If present, sets maximum type of kmsg dump reasons to store. + This can be set to INT_MAX to store all kmsg dumps. + See include/linux/kmsg_dump.h KMSG_DUMP_* for other kmsg dump reason values. + Setting this to 0 (KMSG_DUMP_UNDEF), means the reason filtering will be + controlled by the printk.always_kmsg_dump boot param. + If unset, it will be 2 (KMSG_DUMP_OOPS), otherwise 5 (KMSG_DUMP_MAX). + + flags: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + description: | + If present, pass ramoops behavioral flags + (see include/linux/pstore_ram.h RAMOOPS_FLAG_* for flag values). + + no-dump-oops: + deprecated: true + type: boolean + description: | + Use max_reason instead. If present, and max_reason is not specified, + it is equivalent to max_reason = 1 (KMSG_DUMP_PANIC). + + unbuffered: + deprecated: true + type: boolean + description: | + Use mem_type instead. If present, and mem_type is not specified, + it is equivalent to mem_type = 1 and uses unbuffered mappings to map + the reserved region (defaults to buffered mappings mem_type = 0). + If both are specified -- "mem_type" overrides "unbuffered". + +unevaluatedProperties: false + +required: + - compatible + - reg + +anyOf: + - required: [record-size] + - required: [console-size] + - required: [ftrace-size] + - required: [pmsg-size] + +examples: + - | + / { + compatible = "foo"; + model = "foo"; + #address-cells = <1>; + #size-cells = <1>; + + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + ramoops@bfdf0000 { + compatible = "ramoops"; + reg = <0xbfdf0000 0x10000>; /* 64kB */ + console-size = <0x8000>; /* 32kB */ + record-size = <0x400>; /* 1kB */ + ecc-size = <16>; + }; + }; + }; + diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt index 39b5f4c5a511..1810701a8509 100644 --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt @@ -1,171 +1 @@ -*** Reserved memory regions *** - -Reserved memory is specified as a node under the /reserved-memory node. -The operating system shall exclude reserved memory from normal usage -one can create child nodes describing particular reserved (excluded from -normal use) memory regions. Such memory regions are usually designed for -the special usage by various device drivers. - -Parameters for each memory region can be encoded into the device tree -with the following nodes: - -/reserved-memory node ---------------------- -#address-cells, #size-cells (required) - standard definition - - Should use the same values as the root node -ranges (required) - standard definition - - Should be empty - -/reserved-memory/ child nodes ------------------------------ -Each child of the reserved-memory node specifies one or more regions of -reserved memory. Each child node may either use a 'reg' property to -specify a specific range of reserved memory, or a 'size' property with -optional constraints to request a dynamically allocated block of memory. - -Following the generic-names recommended practice, node names should -reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit -address (@<address>) should be appended to the name if the node is a -static allocation. - -Properties: -Requires either a) or b) below. -a) static allocation - reg (required) - standard definition -b) dynamic allocation - size (required) - length based on parent's #size-cells - - Size in bytes of memory to reserve. - alignment (optional) - length based on parent's #size-cells - - Address boundary for alignment of allocation. - alloc-ranges (optional) - prop-encoded-array (address, length pairs). - - Specifies regions of memory that are - acceptable to allocate from. - -If both reg and size are present, then the reg property takes precedence -and size is ignored. - -Additional properties: -compatible (optional) - standard definition - - may contain the following strings: - - shared-dma-pool: This indicates a region of memory meant to be - used as a shared pool of DMA buffers for a set of devices. It can - be used by an operating system to instantiate the necessary pool - management subsystem if necessary. - - restricted-dma-pool: This indicates a region of memory meant to be - used as a pool of restricted DMA buffers for a set of devices. The - memory region would be the only region accessible to those devices. - When using this, the no-map and reusable properties must not be set, - so the operating system can create a virtual mapping that will be used - for synchronization. The main purpose for restricted DMA is to - mitigate the lack of DMA access control on systems without an IOMMU, - which could result in the DMA accessing the system memory at - unexpected times and/or unexpected addresses, possibly leading to data - leakage or corruption. The feature on its own provides a basic level - of protection against the DMA overwriting buffer contents at - unexpected times. However, to protect against general data leakage and - system memory corruption, the system needs to provide way to lock down - the memory access, e.g., MPU. Note that since coherent allocation - needs remapping, one must set up another device coherent pool by - shared-dma-pool and use dma_alloc_from_dev_coherent instead for atomic - coherent allocation. - - vendor specific string in the form <vendor>,[<device>-]<usage> -no-map (optional) - empty property - - Indicates the operating system must not create a virtual mapping - of the region as part of its standard mapping of system memory, - nor permit speculative access to it under any circumstances other - than under the control of the device driver using the region. -reusable (optional) - empty property - - The operating system can use the memory in this region with the - limitation that the device driver(s) owning the region need to be - able to reclaim it back. Typically that means that the operating - system can use that region to store volatile or cached data that - can be otherwise regenerated or migrated elsewhere. - -A node must not carry both the no-map and the reusable property as these are -logically contradictory. - -Linux implementation note: -- If a "linux,cma-default" property is present, then Linux will use the - region for the default pool of the contiguous memory allocator. - -- If a "linux,dma-default" property is present, then Linux will use the - region for the default pool of the consistent DMA allocator. - -Device node references to reserved memory ------------------------------------------ -Regions in the /reserved-memory node may be referenced by other device -nodes by adding a memory-region property to the device node. - -memory-region (optional) - phandle, specifier pairs to children of /reserved-memory -memory-region-names (optional) - a list of names, one for each corresponding - entry in the memory-region property - -Example -------- -This example defines 4 contiguous regions for Linux kernel: -one default of all device drivers (named linux,cma@72000000 and 64MiB in size), -one dedicated to the framebuffer device (named framebuffer@78000000, 8MiB), -one for multimedia processing (named multimedia-memory@77000000, 64MiB), and -one for restricted dma pool (named restricted_dma_reserved@0x50000000, 64MiB). - -/ { - #address-cells = <1>; - #size-cells = <1>; - - memory { - reg = <0x40000000 0x40000000>; - }; - - reserved-memory { - #address-cells = <1>; - #size-cells = <1>; - ranges; - - /* global autoconfigured region for contiguous allocations */ - linux,cma { - compatible = "shared-dma-pool"; - reusable; - size = <0x4000000>; - alignment = <0x2000>; - linux,cma-default; - }; - - display_reserved: framebuffer@78000000 { - reg = <0x78000000 0x800000>; - }; - - multimedia_reserved: multimedia@77000000 { - compatible = "acme,multimedia-memory"; - reg = <0x77000000 0x4000000>; - }; - - restricted_dma_reserved: restricted_dma_reserved { - compatible = "restricted-dma-pool"; - reg = <0x50000000 0x4000000>; - }; - }; - - /* ... */ - - fb0: video@12300000 { - memory-region = <&display_reserved>; - /* ... */ - }; - - scaler: scaler@12500000 { - memory-region = <&multimedia_reserved>; - /* ... */ - }; - - codec: codec@12600000 { - memory-region = <&multimedia_reserved>; - /* ... */ - }; - - pcie_device: pcie_device@0,0 { - reg = <0x83010000 0x0 0x00000000 0x0 0x00100000 - 0x83010000 0x0 0x00100000 0x0 0x00100000>; - memory-region = <&restricted_dma_reserved>; - /* ... */ - }; -}; +This file has been moved to reserved-memory.yaml. diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml new file mode 100644 index 000000000000..7a0744052ff6 --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: /reserved-memory Child Node Common Device Tree Bindings + +maintainers: + - devicetree-spec@vger.kernel.org + +description: > + Reserved memory is specified as a node under the /reserved-memory node. The + operating system shall exclude reserved memory from normal usage one can + create child nodes describing particular reserved (excluded from normal use) + memory regions. Such memory regions are usually designed for the special + usage by various device drivers. + + Each child of the reserved-memory node specifies one or more regions + of reserved memory. Each child node may either use a 'reg' property to + specify a specific range of reserved memory, or a 'size' property with + optional constraints to request a dynamically allocated block of + memory. + + Following the generic-names recommended practice, node names should + reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). + Unit address (@<address>) should be appended to the name if the node + is a static allocation. + +properties: + reg: true + + size: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 2 + description: > + Length based on parent's \#size-cells. Size in bytes of memory to + reserve. + + alignment: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 2 + description: > + Length based on parent's \#size-cells. Address boundary for + alignment of allocation. + + alloc-ranges: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: > + Address and Length pairs. Specifies regions of memory that are + acceptable to allocate from. + + no-map: + type: boolean + description: > + Indicates the operating system must not create a virtual mapping + of the region as part of its standard mapping of system memory, + nor permit speculative access to it under any circumstances other + than under the control of the device driver using the region. + + reusable: + type: boolean + description: > + The operating system can use the memory in this region with the + limitation that the device driver(s) owning the region need to be + able to reclaim it back. Typically that means that the operating + system can use that region to store volatile or cached data that + can be otherwise regenerated or migrated elsewhere. + +allOf: + - if: + required: + - no-map + + then: + not: + required: + - reusable + + - if: + required: + - reusable + + then: + not: + required: + - no-map + +oneOf: + - required: + - reg + + - required: + - size + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml b/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml new file mode 100644 index 000000000000..a4bf757d6881 --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reserved-memory/shared-dma-pool.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: /reserved-memory DMA pool node bindings + +maintainers: + - devicetree-spec@vger.kernel.org + +allOf: + - $ref: "reserved-memory.yaml" + +properties: + compatible: + oneOf: + - const: shared-dma-pool + description: > + This indicates a region of memory meant to be used as a shared + pool of DMA buffers for a set of devices. It can be used by an + operating system to instantiate the necessary pool management + subsystem if necessary. + + - const: restricted-dma-pool + description: > + This indicates a region of memory meant to be used as a pool + of restricted DMA buffers for a set of devices. The memory + region would be the only region accessible to those devices. + When using this, the no-map and reusable properties must not + be set, so the operating system can create a virtual mapping + that will be used for synchronization. The main purpose for + restricted DMA is to mitigate the lack of DMA access control + on systems without an IOMMU, which could result in the DMA + accessing the system memory at unexpected times and/or + unexpected addresses, possibly leading to data leakage or + corruption. The feature on its own provides a basic level of + protection against the DMA overwriting buffer contents at + unexpected times. However, to protect against general data + leakage and system memory corruption, the system needs to + provide way to lock down the memory access, e.g., MPU. Note + that since coherent allocation needs remapping, one must set + up another device coherent pool by shared-dma-pool and use + dma_alloc_from_dev_coherent instead for atomic coherent + allocation. + + linux,cma-default: + type: boolean + description: > + If this property is present, then Linux will use the region for + the default pool of the contiguous memory allocator. + + linux,dma-default: + type: boolean + description: > + If this property is present, then Linux will use the region for + the default pool of the consistent DMA allocator. + +unevaluatedProperties: false + +examples: + - | + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + /* global autoconfigured region for contiguous allocations */ + linux,cma { + compatible = "shared-dma-pool"; + reusable; + size = <0x4000000>; + alignment = <0x2000>; + linux,cma-default; + }; + + display_reserved: framebuffer@78000000 { + reg = <0x78000000 0x800000>; + }; + + restricted_dma_reserved: restricted-dma-pool@50000000 { + compatible = "restricted-dma-pool"; + reg = <0x50000000 0x4000000>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/reset/microchip,rst.yaml b/Documentation/devicetree/bindings/reset/microchip,rst.yaml index 370579aeeca1..578bfa529b16 100644 --- a/Documentation/devicetree/bindings/reset/microchip,rst.yaml +++ b/Documentation/devicetree/bindings/reset/microchip,rst.yaml @@ -20,7 +20,9 @@ properties: pattern: "^reset-controller@[0-9a-f]+$" compatible: - const: microchip,sparx5-switch-reset + enum: + - microchip,sparx5-switch-reset + - microchip,lan966x-switch-reset reg: items: diff --git a/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml b/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml index 29e4a900cad7..bfbd3e9b4186 100644 --- a/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml +++ b/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml @@ -23,6 +23,7 @@ properties: - socionext,uniphier-pxs2-usb3-reset - socionext,uniphier-ld20-usb3-reset - socionext,uniphier-pxs3-usb3-reset + - socionext,uniphier-nx1-usb3-reset - socionext,uniphier-pro4-ahci-reset - socionext,uniphier-pxs2-ahci-reset - socionext,uniphier-pxs3-ahci-reset diff --git a/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml index 4c9b0ebf6869..377a7d242323 100644 --- a/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml +++ b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml @@ -23,6 +23,7 @@ properties: - socionext,uniphier-ld11-reset - socionext,uniphier-ld20-reset - socionext,uniphier-pxs3-reset + - socionext,uniphier-nx1-reset - description: Media I/O (MIO) reset, SD reset enum: - socionext,uniphier-ld4-mio-reset @@ -34,6 +35,7 @@ properties: - socionext,uniphier-ld11-sd-reset - socionext,uniphier-ld20-sd-reset - socionext,uniphier-pxs3-sd-reset + - socionext,uniphier-nx1-sd-reset - description: Peripheral reset enum: - socionext,uniphier-ld4-peri-reset @@ -44,6 +46,7 @@ properties: - socionext,uniphier-ld11-peri-reset - socionext,uniphier-ld20-peri-reset - socionext,uniphier-pxs3-peri-reset + - socionext,uniphier-nx1-peri-reset - description: Analog signal amplifier reset enum: - socionext,uniphier-ld11-adamv-reset diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index e534f6a7cfa1..aa5fb64d57eb 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -31,9 +31,7 @@ properties: - sifive,bullet0 - sifive,e5 - sifive,e7 - - sifive,e51 - sifive,e71 - - sifive,u54-mc - sifive,u74-mc - sifive,u54 - sifive,u74 @@ -41,6 +39,12 @@ properties: - sifive,u7 - canaan,k210 - const: riscv + - items: + - enum: + - sifive,e51 + - sifive,u54-mc + - const: sifive,rocket0 + - const: riscv - const: riscv # Simulator only description: Identifies that the hart uses the RISC-V instruction set diff --git a/Documentation/devicetree/bindings/rng/ingenic,trng.yaml b/Documentation/devicetree/bindings/rng/ingenic,trng.yaml index 808f247c8421..044d9a065650 100644 --- a/Documentation/devicetree/bindings/rng/ingenic,trng.yaml +++ b/Documentation/devicetree/bindings/rng/ingenic,trng.yaml @@ -32,7 +32,7 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/x1830-cgu.h> + #include <dt-bindings/clock/ingenic,x1830-cgu.h> dtrng: trng@10072000 { compatible = "ingenic,x1830-dtrng"; diff --git a/Documentation/devicetree/bindings/rng/omap_rng.txt b/Documentation/devicetree/bindings/rng/omap_rng.txt deleted file mode 100644 index ea434ce50f36..000000000000 --- a/Documentation/devicetree/bindings/rng/omap_rng.txt +++ /dev/null @@ -1,38 +0,0 @@ -OMAP SoC and Inside-Secure HWRNG Module - -Required properties: - -- compatible : Should contain entries for this and backward compatible - RNG versions: - - "ti,omap2-rng" for OMAP2. - - "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX. - - "inside-secure,safexcel-eip76" for SoCs with EIP76 IP block - Note that these two versions are incompatible. -- ti,hwmods: Name of the hwmod associated with the RNG module -- reg : Offset and length of the register set for the module -- interrupts : the interrupt number for the RNG module. - Used for "ti,omap4-rng" and "inside-secure,safexcel-eip76" -- clocks: the trng clock source. Only mandatory for the - "inside-secure,safexcel-eip76" compatible, the second clock is - needed for the Armada 7K/8K SoCs -- clock-names: mandatory if there is a second clock, in this case the - name must be "core" for the first clock and "reg" for the second - one - - -Example: -/* AM335x */ -rng: rng@48310000 { - compatible = "ti,omap4-rng"; - ti,hwmods = "rng"; - reg = <0x48310000 0x2000>; - interrupts = <111>; -}; - -/* SafeXcel IP-76 */ -trng: rng@f2760000 { - compatible = "inside-secure,safexcel-eip76"; - reg = <0xf2760000 0x7d>; - interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpm_syscon0 1 25>; -}; diff --git a/Documentation/devicetree/bindings/rng/omap_rng.yaml b/Documentation/devicetree/bindings/rng/omap_rng.yaml new file mode 100644 index 000000000000..010188cdbec8 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/omap_rng.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/omap_rng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OMAP SoC and Inside-Secure HWRNG Module + +maintainers: + - Jayesh Choudhary <j-choudhary@ti.com> + +properties: + compatible: + enum: + - ti,omap2-rng + - ti,omap4-rng + - inside-secure,safexcel-eip76 + + ti,hwmods: + const: rng + deprecated: true + description: Name of the hwmod associated with the RNG module + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + items: + - description: EIP150 gatable clock + - description: Main gatable clock + + clock-names: + minItems: 1 + items: + - const: core + - const: reg + + +allOf: + - if: + properties: + compatible: + contains: + enum: + - ti,omap4-rng + - inside-secure,safexcel-eip76 + + then: + required: + - interrupts + + - if: + properties: + compatible: + contains: + enum: + - inside-secure,safexcel-eip76 + + then: + required: + - clocks + + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + /* AM335x */ + rng: rng@48310000 { + compatible = "ti,omap4-rng"; + ti,hwmods = "rng"; + reg = <0x48310000 0x2000>; + interrupts = <111>; + }; + - | + /* SafeXcel IP-76 */ + trng: rng@f2760000 { + compatible = "inside-secure,safexcel-eip76"; + reg = <0xf2760000 0x7d>; + interrupts = <0 59 4>; + clocks = <&cpm_syscon0 1 25>; + }; + +... diff --git a/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml b/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml index 82bb2e97e889..9a6e4eaf4d3c 100644 --- a/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml +++ b/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml @@ -11,7 +11,7 @@ description: | IP and is fully separated from other crypto functions. maintainers: - - Lionel Debieve <lionel.debieve@st.com> + - Lionel Debieve <lionel.debieve@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml b/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml index 60e93e86ad9d..b235b2441997 100644 --- a/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml @@ -72,7 +72,7 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/jz4740-cgu.h> + #include <dt-bindings/clock/ingenic,jz4740-cgu.h> rtc_dev: rtc@10003000 { compatible = "ingenic,jz4740-rtc"; reg = <0x10003000 0x40>; diff --git a/Documentation/devicetree/bindings/rtc/mstar,msc313-rtc.yaml b/Documentation/devicetree/bindings/rtc/mstar,msc313-rtc.yaml new file mode 100644 index 000000000000..114199cf4d28 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/mstar,msc313-rtc.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/mstar,msc313-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mstar MSC313e RTC Device Tree Bindings + +allOf: + - $ref: "rtc.yaml#" + +maintainers: + - Daniel Palmer <daniel@0x0f.com> + - Romain Perier <romain.perier@gmail.com> + +properties: + compatible: + enum: + - mstar,msc313-rtc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + start-year: true + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + rtc@2400 { + compatible = "mstar,msc313-rtc"; + reg = <0x2400 0x40>; + clocks = <&xtal_div2>; + interrupts-extended = <&intc_irq GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; + }; +... diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt index 627bb533eff7..6439682c9319 100644 --- a/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt @@ -13,10 +13,19 @@ Optional property: expressed in femto Farad (fF). Valid values are 7000 and 12500. Default value (if no value is specified) is 7000fF. +Optional child node: +- clock: Provide this if the square wave pin is used as boot-enabled fixed clock. + Example: pcf85063: rtc@51 { compatible = "nxp,pcf85063"; reg = <0x51>; quartz-load-femtofarads = <12500>; + + clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + }; }; diff --git a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml index 5456604b1c14..2359f541b770 100644 --- a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 Real Time Clock Bindings maintainers: - - Gabriel Fernandez <gabriel.fernandez@st.com> + - Gabriel Fernandez <gabriel.fernandez@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/serial/8250_omap.yaml b/Documentation/devicetree/bindings/serial/8250_omap.yaml index 70ca61688bb9..7b34ec8fa90e 100644 --- a/Documentation/devicetree/bindings/serial/8250_omap.yaml +++ b/Documentation/devicetree/bindings/serial/8250_omap.yaml @@ -86,7 +86,7 @@ required: - reg - interrupts -additionalProperties: false +unevaluatedProperties: false if: properties: diff --git a/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt b/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt deleted file mode 100644 index 8b2b0460259a..000000000000 --- a/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt +++ /dev/null @@ -1,36 +0,0 @@ -* BCM63xx UART - -Required properties: - -- compatible: "brcm,bcm6345-uart" - -- reg: The base address of the UART register bank. - -- interrupts: A single interrupt specifier. - -- clocks: Clock driving the hardware; used to figure out the baud rate - divisor. - - -Optional properties: - -- clock-names: Should be "refclk". - -Example: - - uart0: serial@14e00520 { - compatible = "brcm,bcm6345-uart"; - reg = <0x14e00520 0x18>; - interrupt-parent = <&periph_intc>; - interrupts = <2>; - clocks = <&periph_clk>; - clock-names = "refclk"; - }; - - clocks { - periph_clk: periph_clk@0 { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <54000000>; - }; - }; diff --git a/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.yaml b/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.yaml new file mode 100644 index 000000000000..a22285c43f80 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/brcm,bcm6345-uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: BCM63xx UART + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +allOf: + - $ref: serial.yaml# + +properties: + compatible: + const: brcm,bcm6345-uart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: refclk + +unevaluatedProperties: false + +required: + - reg + - interrupts + - clocks + +examples: + - | + serial@14e00520 { + compatible = "brcm,bcm6345-uart"; + reg = <0x14e00520 0x18>; + interrupt-parent = <&periph_intc>; + interrupts = <2>; + clocks = <&periph_clk>; + clock-names = "refclk"; + }; diff --git a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.txt b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.txt deleted file mode 100644 index f1bbe0826be5..000000000000 --- a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.txt +++ /dev/null @@ -1,22 +0,0 @@ -* Freescale LINFlexD UART - -The LINFlexD controller implements several LIN protocol versions, as well as -support for full-duplex UART communication through 8-bit and 9-bit frames. - -See chapter 47 ("LINFlexD") in the reference manual[1]. - -Required properties: -- compatible : - - "fsl,s32v234-linflexuart" for LINFlexD configured in UART mode, which - is compatible with the one integrated on S32V234 SoC -- reg : Address and length of the register set for the device -- interrupts : Should contain uart interrupt - -Example: -uart0: serial@40053000 { - compatible = "fsl,s32v234-linflexuart"; - reg = <0x0 0x40053000 0x0 0x1000>; - interrupts = <0 59 4>; -}; - -[1] https://www.nxp.com/webapp/Download?colCode=S32V234RM diff --git a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml new file mode 100644 index 000000000000..8b643bae3c7b --- /dev/null +++ b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/fsl,s32-linflexuart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale LINFlexD UART + +description: | + The LINFlexD controller implements several LIN protocol versions, as well + as support for full-duplex UART communication through 8-bit and 9-bit + frames. See chapter 47 ("LINFlexD") in the reference manual + https://www.nxp.com/webapp/Download?colCode=S32V234RM. + +maintainers: + - Chester Lin <clin@suse.com> + +allOf: + - $ref: "serial.yaml" + +properties: + compatible: + oneOf: + - const: fsl,s32v234-linflexuart + - items: + - const: nxp,s32g2-linflexuart + - const: fsl,s32v234-linflexuart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + serial@40053000 { + compatible = "fsl,s32v234-linflexuart"; + reg = <0x40053000 0x1000>; + interrupts = <0 59 4>; + }; diff --git a/Documentation/devicetree/bindings/serial/ingenic,uart.yaml b/Documentation/devicetree/bindings/serial/ingenic,uart.yaml index b432d4dff730..9ca7a18ecd8b 100644 --- a/Documentation/devicetree/bindings/serial/ingenic,uart.yaml +++ b/Documentation/devicetree/bindings/serial/ingenic,uart.yaml @@ -71,7 +71,7 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/jz4780-cgu.h> + #include <dt-bindings/clock/ingenic,jz4780-cgu.h> #include <dt-bindings/dma/jz4780-dma.h> #include <dt-bindings/gpio/gpio.h> serial@10032000 { diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml index f064e5b76cf1..2940afb874b3 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml @@ -26,6 +26,7 @@ properties: - samsung,s3c6400-uart - samsung,s5pv210-uart - samsung,exynos4210-uart + - samsung,exynos850-uart reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.yaml b/Documentation/devicetree/bindings/serial/sprd-uart.yaml index 09f6283f3cae..a444bebd2c1a 100644 --- a/Documentation/devicetree/bindings/serial/sprd-uart.yaml +++ b/Documentation/devicetree/bindings/serial/sprd-uart.yaml @@ -19,6 +19,7 @@ properties: - enum: - sprd,sc9860-uart - sprd,sc9863a-uart + - sprd,ums512-uart - const: sprd,sc9836-uart - const: sprd,sc9836-uart diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml index f50f4ca893a0..333dc42722d2 100644 --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml @@ -5,7 +5,7 @@ $id: http://devicetree.org/schemas/serial/st,stm32-uart.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# maintainers: - - Erwan Le Ray <erwan.leray@st.com> + - Erwan Le Ray <erwan.leray@foss.st.com> title: STMicroelectronics STM32 USART bindings diff --git a/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.txt b/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.txt deleted file mode 100644 index c37deb44dead..000000000000 --- a/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.txt +++ /dev/null @@ -1,23 +0,0 @@ -Xilinx Axi Uartlite controller Device Tree Bindings ---------------------------------------------------------- - -Required properties: -- compatible : Can be either of - "xlnx,xps-uartlite-1.00.a" - "xlnx,opb-uartlite-1.00.b" -- reg : Physical base address and size of the Axi Uartlite - registers map. -- interrupts : Should contain the UART controller interrupt. - -Optional properties: -- port-number : Set Uart port number -- clock-names : Should be "s_axi_aclk" -- clocks : Input clock specifier. Refer to common clock bindings. - -Example: -serial@800c0000 { - compatible = "xlnx,xps-uartlite-1.00.a"; - reg = <0x0 0x800c0000 0x10000>; - interrupts = <0x0 0x6e 0x1>; - port-number = <0>; -}; diff --git a/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.yaml b/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.yaml new file mode 100644 index 000000000000..f7617b88c7c3 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/xlnx,opb-uartlite.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Axi Uartlite + +maintainers: + - Peter Korsgaard <jacmet@sunsite.dk> + +properties: + compatible: + contains: + enum: + - xlnx,xps-uartlite-1.00.a + - xlnx,opb-uartlite-1.00.b + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + port-number: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Set Uart port number + + clocks: + maxItems: 1 + + clock-names: + const: s_axi_aclk + + current-speed: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The fixed baud rate that the device was configured for. + + xlnx,data-bits: + enum: [5, 6, 7, 8] + description: + The fixed number of data bits that the device was configured for. + + xlnx,use-parity: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: + Whether parity checking was enabled when the device was configured. + + xlnx,odd-parity: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: + Whether odd parity was configured. + +required: + - compatible + - reg + - interrupts + - current-speed + - xlnx,data-bits + - xlnx,use-parity + +allOf: + - $ref: /schemas/serial.yaml# + - if: + properties: + xlnx,use-parity: + contains: + const: 1 + then: + required: + - xlnx,odd-parity + +unevaluatedProperties: false + +examples: + - | + serial@800c0000 { + compatible = "xlnx,xps-uartlite-1.00.a"; + reg = <0x800c0000 0x10000>; + interrupts = <0x0 0x6e 0x1>; + port-number = <0>; + current-speed = <115200>; + xlnx,data-bits = <8>; + xlnx,use-parity = <0>; + }; +... diff --git a/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml b/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml new file mode 100644 index 000000000000..6876407124dc --- /dev/null +++ b/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# # Copyright (c) 2018 Google LLC +# # Copyright (c) 2021 Aspeed Technology Inc. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/aspeed/uart-routing.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Aspeed UART Routing Controller + +maintainers: + - Oskar Senft <osk@google.com> + - Chia-Wei Wang <chiawei_wang@aspeedtech.com> + +description: + The Aspeed UART routing control allow to dynamically route the inputs for + the built-in UARTS and physical serial I/O ports. + + This allows, for example, to connect the output of UART to another UART. + This can be used to enable Host <-> BMC communication via UARTs, e.g. to + allow access to the Host's serial console. + + This driver is for the BMC side. The sysfs files allow the BMC userspace + which owns the system configuration policy, to configure how UARTs and + physical serial I/O ports are routed. + +properties: + compatible: + items: + - enum: + - aspeed,ast2400-uart-routing + - aspeed,ast2500-uart-routing + - aspeed,ast2600-uart-routing + reg: + maxItems: 1 + +required: + - compatible + +additionalProperties: false + +examples: + - | + lpc: lpc@1e789000 { + compatible = "aspeed,ast2600-lpc-v2", "simple-mfd", "syscon"; + reg = <0x1e789000 0x1000>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x1e789000 0x1000>; + + uart_routing: uart-routing@98 { + compatible = "aspeed,ast2600-uart-routing"; + reg = <0x98 0x8>; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml new file mode 100644 index 000000000000..ecd86cfb3da4 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml @@ -0,0 +1,94 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8MM DISP blk-ctrl + +maintainers: + - Lucas Stach <l.stach@pengutronix.de> + +description: + The i.MX8MM DISP blk-ctrl is a top-level peripheral providing access to + the NoC and ensuring proper power sequencing of the display and MIPI CSI + peripherals located in the DISP domain of the SoC. + +properties: + compatible: + items: + - const: fsl,imx8mm-disp-blk-ctrl + - const: syscon + + reg: + maxItems: 1 + + '#power-domain-cells': + const: 1 + + power-domains: + minItems: 5 + maxItems: 5 + + power-domain-names: + items: + - const: bus + - const: csi-bridge + - const: lcdif + - const: mipi-dsi + - const: mipi-csi + + clocks: + minItems: 10 + maxItems: 10 + + clock-names: + items: + - const: csi-bridge-axi + - const: csi-bridge-apb + - const: csi-bridge-core + - const: lcdif-axi + - const: lcdif-apb + - const: lcdif-pix + - const: dsi-pclk + - const: dsi-ref + - const: csi-aclk + - const: csi-pclk + +required: + - compatible + - reg + - power-domains + - power-domain-names + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mm-clock.h> + #include <dt-bindings/power/imx8mm-power.h> + + disp_blk_ctl: blk_ctrl@32e28000 { + compatible = "fsl,imx8mm-disp-blk-ctrl", "syscon"; + reg = <0x32e28000 0x100>; + power-domains = <&pgc_dispmix>, <&pgc_dispmix>, <&pgc_dispmix>, + <&pgc_mipi>, <&pgc_mipi>; + power-domain-names = "bus", "csi-bridge", "lcdif", + "mipi-dsi", "mipi-csi"; + clocks = <&clk IMX8MM_CLK_DISP_AXI_ROOT>, + <&clk IMX8MM_CLK_DISP_APB_ROOT>, + <&clk IMX8MM_CLK_CSI1_ROOT>, + <&clk IMX8MM_CLK_DISP_AXI_ROOT>, + <&clk IMX8MM_CLK_DISP_APB_ROOT>, + <&clk IMX8MM_CLK_DISP_ROOT>, + <&clk IMX8MM_CLK_DSI_CORE>, + <&clk IMX8MM_CLK_DSI_PHY_REF>, + <&clk IMX8MM_CLK_CSI1_CORE>, + <&clk IMX8MM_CLK_CSI1_PHY_REF>; + clock-names = "csi-bridge-axi", "csi-bridge-apb", "csi-bridge-core", + "lcdif-axi", "lcdif-apb", "lcdif-pix", "dsi-pclk", + "dsi-ref", "csi-aclk", "csi-pclk"; + #power-domain-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml new file mode 100644 index 000000000000..26487daa64d9 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8MM VPU blk-ctrl + +maintainers: + - Lucas Stach <l.stach@pengutronix.de> + +description: + The i.MX8MM VPU blk-ctrl is a top-level peripheral providing access to + the NoC and ensuring proper power sequencing of the VPU peripherals + located in the VPU domain of the SoC. + +properties: + compatible: + items: + - const: fsl,imx8mm-vpu-blk-ctrl + - const: syscon + + reg: + maxItems: 1 + + '#power-domain-cells': + const: 1 + + power-domains: + minItems: 4 + maxItems: 4 + + power-domain-names: + items: + - const: bus + - const: g1 + - const: g2 + - const: h1 + + clocks: + minItems: 3 + maxItems: 3 + + clock-names: + items: + - const: g1 + - const: g2 + - const: h1 + +required: + - compatible + - reg + - power-domains + - power-domain-names + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mm-clock.h> + #include <dt-bindings/power/imx8mm-power.h> + + vpu_blk_ctrl: blk-ctrl@38330000 { + compatible = "fsl,imx8mm-vpu-blk-ctrl", "syscon"; + reg = <0x38330000 0x100>; + power-domains = <&pgc_vpumix>, <&pgc_vpu_g1>, + <&pgc_vpu_g2>, <&pgc_vpu_h1>; + power-domain-names = "bus", "g1", "g2", "h1"; + clocks = <&clk IMX8MM_CLK_VPU_G1_ROOT>, + <&clk IMX8MM_CLK_VPU_G2_ROOT>, + <&clk IMX8MM_CLK_VPU_H1_ROOT>; + clock-names = "g1", "g2", "h1"; + #power-domain-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml index 93e4b737ee1b..e2e173dfada7 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml @@ -19,8 +19,7 @@ description: The AOSS side channel exposes control over a set of resources, used to control a set of debug related clocks and to affect the low power state of resources - related to the secondary subsystems. These resources are exposed as a set of - power-domains. + related to the secondary subsystems. properties: compatible: @@ -30,6 +29,7 @@ properties: - qcom,sc7280-aoss-qmp - qcom,sc8180x-aoss-qmp - qcom,sdm845-aoss-qmp + - qcom,sm6350-aoss-qmp - qcom,sm8150-aoss-qmp - qcom,sm8250-aoss-qmp - qcom,sm8350-aoss-qmp @@ -57,13 +57,6 @@ properties: description: The single clock represents the QDSS clock. - "#power-domain-cells": - const: 1 - description: | - The provided power-domains are: - CDSP state (0), LPASS state (1), modem state (2), SLPI - state (3), SPSS state (4) and Venus state (5). - required: - compatible - reg @@ -101,7 +94,6 @@ examples: mboxes = <&apss_shared 0>; #clock-cells = <0>; - #power-domain-cells = <1>; cx_cdev: cx { #cooling-cells = <2>; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt deleted file mode 100644 index 2e2f6dc351c0..000000000000 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt +++ /dev/null @@ -1,134 +0,0 @@ -Qualcomm APR (Asynchronous Packet Router) binding - -This binding describes the Qualcomm APR. APR is a IPC protocol for -communication between Application processor and QDSP. APR is mainly -used for audio/voice services on the QDSP. - -- compatible: - Usage: required - Value type: <stringlist> - Definition: must be "qcom,apr-v<VERSION-NUMBER>", example "qcom,apr-v2" - -- qcom,apr-domain - Usage: required - Value type: <u32> - Definition: Destination processor ID. - Possible values are : - 1 - APR simulator - 2 - PC - 3 - MODEM - 4 - ADSP - 5 - APPS - 6 - MODEM2 - 7 - APPS2 - -= APR SERVICES -Each subnode of the APR node represents service tied to this apr. The name -of the nodes are not important. The properties of these nodes are defined -by the individual bindings for the specific service -- All APR services MUST contain the following property: - -- reg - Usage: required - Value type: <u32> - Definition: APR Service ID - Possible values are : - 3 - DSP Core Service - 4 - Audio Front End Service. - 5 - Voice Stream Manager Service. - 6 - Voice processing manager. - 7 - Audio Stream Manager Service. - 8 - Audio Device Manager Service. - 9 - Multimode voice manager. - 10 - Core voice stream. - 11 - Core voice processor. - 12 - Ultrasound stream manager. - 13 - Listen stream manager. - -- qcom,protection-domain - Usage: optional - Value type: <stringlist> - Definition: Must list the protection domain service name and path - that the particular apr service has a dependency on. - Possible values are : - "avs/audio", "msm/adsp/audio_pd". - "kernel/elf_loader", "msm/modem/wlan_pd". - "tms/servreg", "msm/adsp/audio_pd". - "tms/servreg", "msm/modem/wlan_pd". - "tms/servreg", "msm/slpi/sensor_pd". - -= EXAMPLE -The following example represents a QDSP based sound card on a MSM8996 device -which uses apr as communication between Apps and QDSP. - - apr { - compatible = "qcom,apr-v2"; - qcom,apr-domain = <APR_DOMAIN_ADSP>; - - apr-service@3 { - compatible = "qcom,q6core"; - reg = <APR_SVC_ADSP_CORE>; - }; - - apr-service@4 { - compatible = "qcom,q6afe"; - reg = <APR_SVC_AFE>; - - dais { - #sound-dai-cells = <1>; - dai@1 { - reg = <HDMI_RX>; - }; - }; - }; - - apr-service@7 { - compatible = "qcom,q6asm"; - reg = <APR_SVC_ASM>; - ... - }; - - apr-service@8 { - compatible = "qcom,q6adm"; - reg = <APR_SVC_ADM>; - ... - }; - }; - -= EXAMPLE 2 -The following example represents a QDSP based sound card with protection domain -dependencies specified. Here some of the apr services are dependent on services -running on protection domain hosted on ADSP/SLPI remote processors while others -have no such dependency. - - apr { - compatible = "qcom,apr-v2"; - qcom,glink-channels = "apr_audio_svc"; - qcom,apr-domain = <APR_DOMAIN_ADSP>; - - apr-service@3 { - compatible = "qcom,q6core"; - reg = <APR_SVC_ADSP_CORE>; - }; - - q6afe: apr-service@4 { - compatible = "qcom,q6afe"; - reg = <APR_SVC_AFE>; - qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd"; - ... - }; - - q6asm: apr-service@7 { - compatible = "qcom,q6asm"; - reg = <APR_SVC_ASM>; - qcom,protection-domain = "tms/servreg", "msm/slpi/sensor_pd"; - ... - }; - - q6adm: apr-service@8 { - compatible = "qcom,q6adm"; - reg = <APR_SVC_ADM>; - qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd"; - ... - }; - }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml new file mode 100644 index 000000000000..028c5d105adb --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml @@ -0,0 +1,177 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/qcom/qcom,apr.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm APR/GPR (Asynchronous/Generic Packet Router) binding + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + This binding describes the Qualcomm APR/GPR, APR/GPR is a IPC protocol for + communication between Application processor and QDSP. APR/GPR is mainly + used for audio/voice services on the QDSP. + +properties: + compatible: + enum: + - qcom,apr-v2 + - qcom,gpr + + qcom,apr-domain: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 3, 4, 5, 6, 7] + description: + Selects the processor domain for apr + 1 = APR simulator + 2 = PC Domain + 3 = Modem Domain + 4 = ADSP Domain + 5 = Application processor Domain + 6 = Modem2 Domain + 7 = Application Processor2 Domain + deprecated: true + + qcom,domain: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 7 + description: + Selects the processor domain for apr + 1 = APR simulator + 2 = PC Domain + 3 = Modem Domain + 4 = ADSP Domain + 5 = Application processor Domain + 6 = Modem2 Domain + 7 = Application Processor2 Domain + Selects the processor domain for gpr + 1 = Modem Domain + 2 = Audio DSP Domain + 3 = Application Processor Domain + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +#APR/GPR Services +patternProperties: + "^service@[1-9a-d]$": + type: object + description: + APR/GPR node's client devices use subnodes for desired static port services. + + properties: + compatible: + enum: + - qcom,q6core + - qcom,q6asm + - qcom,q6afe + - qcom,q6adm + - qcom,q6apm + - qcom,q6prm + + reg: + minimum: 1 + maximum: 13 + description: + APR Service ID + 3 = DSP Core Service + 4 = Audio Front End Service. + 5 = Voice Stream Manager Service. + 6 = Voice processing manager. + 7 = Audio Stream Manager Service. + 8 = Audio Device Manager Service. + 9 = Multimode voice manager. + 10 = Core voice stream. + 11 = Core voice processor. + 12 = Ultrasound stream manager. + 13 = Listen stream manager. + GPR Service ID + 1 = Audio Process Manager Service + 2 = Proxy Resource Manager Service. + 3 = AMDB Service. + 4 = Voice processing manager. + + qcom,protection-domain: + $ref: /schemas/types.yaml#/definitions/string-array + description: protection domain service name and path for apr service + possible values are + "avs/audio", "msm/adsp/audio_pd". + "kernel/elf_loader", "msm/modem/wlan_pd". + "tms/servreg", "msm/adsp/audio_pd". + "tms/servreg", "msm/modem/wlan_pd". + "tms/servreg", "msm/slpi/sensor_pd". + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + patternProperties: + "^.*@[0-9a-f]+$": + type: object + description: + Service based devices like clock controllers or digital audio interfaces. + + additionalProperties: false + +required: + - compatible + - qcom,domain + +additionalProperties: false + +examples: + - | + #include <dt-bindings/soc/qcom,apr.h> + apr { + compatible = "qcom,apr-v2"; + qcom,domain = <APR_DOMAIN_ADSP>; + #address-cells = <1>; + #size-cells = <0>; + + q6core: service@3 { + compatible = "qcom,q6core"; + reg = <APR_SVC_ADSP_CORE>; + qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd"; + }; + + q6afe: service@4 { + compatible = "qcom,q6afe"; + reg = <APR_SVC_AFE>; + qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd"; + }; + + q6asm: service@7 { + compatible = "qcom,q6asm"; + reg = <APR_SVC_ASM>; + qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd"; + }; + + q6adm: service@8 { + compatible = "qcom,q6adm"; + reg = <APR_SVC_ADM>; + qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd"; + }; + }; + + - | + #include <dt-bindings/soc/qcom,gpr.h> + gpr { + compatible = "qcom,gpr"; + qcom,domain = <GPR_DOMAIN_ID_ADSP>; + #address-cells = <1>; + #size-cells = <0>; + + service@1 { + compatible = "qcom,q6apm"; + reg = <GPR_APM_MODULE_IID>; + qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd"; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index cc3fe5ed7421..b32457c2fc0b 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -34,6 +34,7 @@ properties: - qcom,rpm-ipq6018 - qcom,rpm-msm8226 - qcom,rpm-msm8916 + - qcom,rpm-msm8953 - qcom,rpm-msm8974 - qcom,rpm-msm8976 - qcom,rpm-msm8996 @@ -41,6 +42,7 @@ properties: - qcom,rpm-sdm660 - qcom,rpm-sm6115 - qcom,rpm-sm6125 + - qcom,rpm-qcm2290 - qcom,rpm-qcs404 qcom,smd-channels: @@ -57,6 +59,7 @@ if: - qcom,rpm-apq8084 - qcom,rpm-msm8916 - qcom,rpm-msm8974 + - qcom,rpm-msm8953 then: required: - qcom,smd-channels diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smem.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.yaml index f7e17713b3d8..4149cf2b66be 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smem.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.yaml @@ -10,14 +10,18 @@ maintainers: - Andy Gross <agross@kernel.org> - Bjorn Andersson <bjorn.andersson@linaro.org> -description: | - This binding describes the Qualcomm Shared Memory Manager, used to share data - between various subsystems and OSes in Qualcomm platforms. +description: + This binding describes the Qualcomm Shared Memory Manager, a region of + reserved-memory used to share data between various subsystems and OSes in + Qualcomm platforms. properties: compatible: const: qcom,smem + reg: + maxItems: 1 + memory-region: maxItems: 1 description: handle to memory reservation for main SMEM memory region. @@ -29,11 +33,19 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle description: handle to RPM message memory resource + no-map: true + required: - compatible - - memory-region - hwlocks +oneOf: + - required: + - reg + - no-map + - required: + - memory-region + additionalProperties: false examples: @@ -43,6 +55,20 @@ examples: #size-cells = <1>; ranges; + smem@fa00000 { + compatible = "qcom,smem"; + reg = <0xfa00000 0x200000>; + no-map; + + hwlocks = <&tcsr_mutex 3>; + }; + }; + - | + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + smem_region: smem@fa00000 { reg = <0xfa00000 0x200000>; no-map; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml new file mode 100644 index 000000000000..07d2d5398345 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/qcom/qcom,spm.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Subsystem Power Manager binding + +maintainers: + - Andy Gross <agross@kernel.org> + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: | + This binding describes the Qualcomm Subsystem Power Manager, used to control + the peripheral logic surrounding the application cores in Qualcomm platforms. + +properties: + compatible: + items: + - enum: + - qcom,sdm660-gold-saw2-v4.1-l2 + - qcom,sdm660-silver-saw2-v4.1-l2 + - qcom,msm8998-gold-saw2-v4.1-l2 + - qcom,msm8998-silver-saw2-v4.1-l2 + - qcom,msm8916-saw2-v3.0-cpu + - qcom,msm8226-saw2-v2.1-cpu + - qcom,msm8974-saw2-v2.1-cpu + - qcom,apq8084-saw2-v2.1-cpu + - qcom,apq8064-saw2-v1.1-cpu + - const: qcom,saw2 + + reg: + description: Base address and size of the SPM register region + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + + /* Example 1: SoC using SAW2 and kpss-acc-v2 CPUIdle */ + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + compatible = "qcom,kryo"; + device_type = "cpu"; + enable-method = "qcom,kpss-acc-v2"; + qcom,saw = <&saw0>; + reg = <0x0>; + operating-points-v2 = <&cpu_opp_table>; + }; + }; + + saw0: power-manager@f9089000 { + compatible = "qcom,msm8974-saw2-v2.1-cpu", "qcom,saw2"; + reg = <0xf9089000 0x1000>; + }; + + - | + + /* + * Example 2: New-gen multi cluster SoC using SAW only for L2; + * This does not require any cpuidle driver, nor any cpu phandle. + */ + power-manager@17812000 { + compatible = "qcom,msm8998-gold-saw2-v4.1-l2", "qcom,saw2"; + reg = <0x17812000 0x1000>; + }; + + power-manager@17912000 { + compatible = "qcom,msm8998-silver-saw2-v4.1-l2", "qcom,saw2"; + reg = <0x17912000 0x1000>; + }; + +... diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml new file mode 100644 index 000000000000..99dff7d73b7e --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom-stats.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. (QTI) Stats bindings + +maintainers: + - Maulik Shah <mkshah@codeaurora.org> + +description: + Always On Processor/Resource Power Manager maintains statistics of the SoC + sleep modes involving powering down of the rails and oscillator clock. + + Statistics includes SoC sleep mode type, number of times low power mode were + entered, time of last entry, time of last exit and accumulated sleep duration. + +properties: + compatible: + enum: + - qcom,rpmh-stats + - qcom,rpm-stats + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + # Example of rpmh sleep stats + - | + sram@c3f0000 { + compatible = "qcom,rpmh-stats"; + reg = <0x0c3f0000 0x400>; + }; + # Example of rpm sleep stats + - | + sram@4690000 { + compatible = "qcom,rpm-stats"; + reg = <0x04690000 0x10000>; + }; +... diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml index 39b66e9ce3e3..7d48ea094c66 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml @@ -21,6 +21,9 @@ properties: - const: allwinner,sun8i-a83t-i2s - const: allwinner,sun8i-h3-i2s - items: + - const: allwinner,sun8i-r40-i2s + - const: allwinner,sun8i-h3-i2s + - items: - const: allwinner,sun8i-v3-i2s - const: allwinner,sun8i-h3-i2s - const: allwinner,sun50i-a64-codec-i2s diff --git a/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml b/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml index c7613ea728d4..db7b04da0b39 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml @@ -34,6 +34,10 @@ properties: resets: maxItems: 1 + AVDD-supply: + description: + Analogue power supply. + required: - "#sound-dai-cells" - compatible @@ -41,6 +45,7 @@ required: - clocks - clock-names - resets + - AVDD-supply additionalProperties: false @@ -56,4 +61,5 @@ examples: clocks = <&clkc CLKID_AUDIO_CODEC>; clock-names = "pclk"; resets = <&reset RESET_AUDIO_CODEC>; + AVDD-supply = <&vddao_1v8>; }; diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml b/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml new file mode 100644 index 000000000000..f7e94b1e0e4b --- /dev/null +++ b/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/audio-graph-card2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Audio Graph Card2 Device Tree Bindings + +maintainers: + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> + +properties: + compatible: + enum: + - audio-graph-card2 + links: + $ref: /schemas/types.yaml#/definitions/phandle-array + label: + maxItems: 1 + routing: + description: | + A list of the connections between audio components. + Each entry is a pair of strings, the first being the + connection's sink, the second being the connection's source. + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + multi: + description: Multi-CPU/Codec node + dpcm: + description: DPCM node + codec2codec: + description: Codec to Codec node + +required: + - compatible + - links + +additionalProperties: false + +examples: + - | + sound { + compatible = "audio-graph-card2"; + + links = <&cpu_port>; + }; + + cpu { + compatible = "cpu-driver"; + + cpu_port: port { cpu_ep: endpoint { remote-endpoint = <&codec_ep>; }; }; + }; + + codec { + compatible = "codec-driver"; + + port { codec_ep: endpoint { remote-endpoint = <&cpu_ep>; }; }; + }; diff --git a/Documentation/devicetree/bindings/sound/bt-sco.txt b/Documentation/devicetree/bindings/sound/bt-sco.txt deleted file mode 100644 index 641edf75e184..000000000000 --- a/Documentation/devicetree/bindings/sound/bt-sco.txt +++ /dev/null @@ -1,13 +0,0 @@ -Bluetooth-SCO audio CODEC - -This device support generic Bluetooth SCO link. - -Required properties: - - - compatible : "delta,dfbmcs320" or "linux,bt-sco" - -Example: - -codec: bt_sco { - compatible = "delta,dfbmcs320"; -}; diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml new file mode 100644 index 000000000000..3235702ce402 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml @@ -0,0 +1,157 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/cirrus,cs35l41.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic CS35L41 Speaker Amplifier + +maintainers: + - david.rhodes@cirrus.com + +description: | + CS35L41 is a boosted mono Class D amplifier with DSP + speaker protection and equalization + +properties: + compatible: + enum: + - cirrus,cs35l40 + - cirrus,cs35l41 + + reg: + maxItems: 1 + + '#sound-dai-cells': + description: + The first cell indicating the audio interface. + const: 1 + + reset-gpios: + maxItems: 1 + + VA-supply: + description: voltage regulator phandle for the VA supply + + VP-supply: + description: voltage regulator phandle for the VP supply + + cirrus,boost-peak-milliamp: + description: + Boost-converter peak current limit in mA. + Configures the peak current by monitoring the current through the boost FET. + Range starts at 1600 mA and goes to a maximum of 4500 mA with increments + of 50 mA. See section 4.3.6 of the datasheet for details. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 1600 + maximum: 4500 + default: 4500 + + cirrus,boost-ind-nanohenry: + description: + Boost inductor value, expressed in nH. Valid + values include 1000, 1200, 1500 and 2200. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 1000 + maximum: 2200 + + cirrus,boost-cap-microfarad: + description: + Total equivalent boost capacitance on the VBST + and VAMP pins, derated at 11 volts DC. The value must be rounded to the + nearest integer and expressed in uF. + $ref: "/schemas/types.yaml#/definitions/uint32" + + cirrus,asp-sdout-hiz: + description: + Audio serial port SDOUT Hi-Z control. Sets the Hi-Z + configuration for SDOUT pin of amplifier. + 0 = Logic 0 during unused slots, and while all transmit channels disabled + 1 = Hi-Z during unused slots but logic 0 while all transmit channels disabled + 2 = (Default) Logic 0 during unused slots, but Hi-Z while all transmit channels disabled + 3 = Hi-Z during unused slots and while all transmit channels disabled + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 3 + default: 2 + + cirrus,gpio1-polarity-invert: + description: + Boolean which specifies whether the GPIO1 + level is inverted. If this property is not present the level is not inverted. + type: boolean + + cirrus,gpio1-output-enable: + description: + Boolean which specifies whether the GPIO1 pin + is configured as an output. If this property is not present the + pin will be configured as an input. + type: boolean + + cirrus,gpio1-src-select: + description: + Configures the function of the GPIO1 pin. + Note that the options are different from the GPIO2 pin + 0 = High Impedance (Default) + 1 = GPIO + 2 = Sync + 3 = MCLK input + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 3 + + cirrus,gpio2-polarity-invert: + description: + Boolean which specifies whether the GPIO2 + level is inverted. If this property is not present the level is not inverted. + type: boolean + + cirrus,gpio2-output-enable: + description: + Boolean which specifies whether the GPIO2 pin + is configured as an output. If this property is not present the + pin will be configured as an input. + type: boolean + + cirrus,gpio2-src-select: + description: + Configures the function of the GPIO2 pin. + Note that the options are different from the GPIO1 pin. + 0 = High Impedance (Default) + 1 = GPIO + 2 = Open Drain INTB + 3 = MCLK input + 4 = Push-pull INTB (active low) + 5 = Push-pull INT (active high) + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 5 + +required: + - compatible + - reg + - "#sound-dai-cells" + - cirrus,boost-peak-milliamp + - cirrus,boost-ind-nanohenry + - cirrus,boost-cap-microfarad + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + cs35l41: cs35l41@2 { + #sound-dai-cells = <1>; + compatible = "cirrus,cs35l41"; + reg = <2>; + VA-supply = <&dummy_vreg>; + VP-supply = <&dummy_vreg>; + reset-gpios = <&gpio 110 0>; + cirrus,boost-peak-milliamp = <4500>; + cirrus,boost-ind-nanohenry = <1000>; + cirrus,boost-cap-microfarad = <15>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml index 0d87e2c86a42..963a871e74da 100644 --- a/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml +++ b/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: CS42L51 audio codec DT bindings maintainers: - - Olivier Moysan <olivier.moysan@st.com> + - Olivier Moysan <olivier.moysan@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/sound/cs42l42.txt b/Documentation/devicetree/bindings/sound/cs42l42.txt index 5d416fdaf023..3b7705623980 100644 --- a/Documentation/devicetree/bindings/sound/cs42l42.txt +++ b/Documentation/devicetree/bindings/sound/cs42l42.txt @@ -19,13 +19,14 @@ Optional properties: (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for further information relating to interrupt properties) - - cirrus,ts-inv : Boolean property. For jacks that invert the tip sense - polarity. Normal jacks will short tip sense pin to HS1 when headphones are - plugged in and leave tip sense floating when not plugged in. Inverting jacks - short tip sense when unplugged and float when plugged in. + - cirrus,ts-inv : Boolean property. Sets the behaviour of the jack plug + detect switch. - 0 = (Default) Non-inverted - 1 = Inverted + 0 = (Default) Shorted to tip when unplugged, open when plugged. + This is "inverted tip sense (ITS)" in the datasheet. + + 1 = Open when unplugged, shorted to tip when plugged. + This is "normal tip sense (TS)" in the datasheet. - cirrus,ts-dbnc-rise : Debounce the rising edge of TIP_SENSE_PLUG. With no debounce, the tip sense pin might be noisy on a plug event. diff --git a/Documentation/devicetree/bindings/sound/ingenic,aic.yaml b/Documentation/devicetree/bindings/sound/ingenic,aic.yaml index cdc0fdaab30a..d607325f2f15 100644 --- a/Documentation/devicetree/bindings/sound/ingenic,aic.yaml +++ b/Documentation/devicetree/bindings/sound/ingenic,aic.yaml @@ -71,7 +71,7 @@ required: examples: - | - #include <dt-bindings/clock/jz4740-cgu.h> + #include <dt-bindings/clock/ingenic,jz4740-cgu.h> aic: audio-controller@10020000 { compatible = "ingenic,jz4740-i2s"; reg = <0x10020000 0x38>; diff --git a/Documentation/devicetree/bindings/sound/ingenic,codec.yaml b/Documentation/devicetree/bindings/sound/ingenic,codec.yaml index 97d5f3819b27..48aae54dd643 100644 --- a/Documentation/devicetree/bindings/sound/ingenic,codec.yaml +++ b/Documentation/devicetree/bindings/sound/ingenic,codec.yaml @@ -48,7 +48,7 @@ required: examples: - | - #include <dt-bindings/clock/jz4740-cgu.h> + #include <dt-bindings/clock/ingenic,jz4740-cgu.h> codec: audio-codec@10020080 { compatible = "ingenic,jz4740-codec"; reg = <0x10020080 0x8>; diff --git a/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml b/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml new file mode 100644 index 000000000000..e3a1f485f664 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/linux,bt-sco.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bluetooth SCO Audio Codec Device Tree Bindings + +maintainers: + - Mark Brown <broonie@kernel.org> + +properties: + '#sound-dai-cells': + enum: + - 0 + + # For Wideband PCM + - 1 + + compatible: + enum: + - delta,dfbmcs320 + - linux,bt-sco + +required: + - '#sound-dai-cells' + - compatible + +additionalProperties: false + +examples: + - | + codec { + #sound-dai-cells = <0>; + compatible = "linux,bt-sco"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml b/Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml new file mode 100644 index 000000000000..c6b070e1d014 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml @@ -0,0 +1,32 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/linux,spdif-dit.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Dummy SPDIF Transmitter Device Tree Bindings + +maintainers: + - Mark Brown <broonie@kernel.org> + +properties: + compatible: + const: linux,spdif-dit + + "#sound-dai-cells": + const: 0 + +required: + - "#sound-dai-cells" + - compatible + +additionalProperties: false + +examples: + - | + spdif-out { + #sound-dai-cells = <0>; + compatible = "linux,spdif-dit"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/max9892x.txt b/Documentation/devicetree/bindings/sound/max9892x.txt index f6171591ddc6..98cb9ba5b328 100644 --- a/Documentation/devicetree/bindings/sound/max9892x.txt +++ b/Documentation/devicetree/bindings/sound/max9892x.txt @@ -30,6 +30,9 @@ Required properties: - reg : the I2C address of the device for I2C +Optional properties: + - reset-gpios : GPIO to reset the device + Example: codec: max98927@3a { diff --git a/Documentation/devicetree/bindings/sound/maxim,max98520.yaml b/Documentation/devicetree/bindings/sound/maxim,max98520.yaml new file mode 100644 index 000000000000..b6509cb2c8e0 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/maxim,max98520.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/maxim,max98520.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim Integrated MAX98520 Speaker Amplifier Driver + +maintainers: + - George Song <george.song@maximintegrated.com> + +properties: + compatible: + const: maxim,max98520 + + reg: + maxItems: 1 + description: I2C address of the device. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + max98520: amplifier@38 { + compatible = "maxim,max98520"; + reg = <0x38>; + }; + }; + diff --git a/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml new file mode 100644 index 000000000000..7a25bc9b8060 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mt8192-afe-pcm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek AFE PCM controller for mt8192 + +maintainers: + - Jiaxin Yu <jiaxin.yu@mediatek.com> + - Shane Chien <shane.chien@mediatek.com> + +properties: + compatible: + const: mediatek,mt8192-audio + + interrupts: + maxItems: 1 + + resets: + maxItems: 1 + + reset-names: + const: audiosys + + mediatek,apmixedsys: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of the mediatek apmixedsys controller + + mediatek,infracfg: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of the mediatek infracfg controller + + mediatek,topckgen: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of the mediatek topckgen controller + + power-domains: + maxItems: 1 + + clocks: + items: + - description: AFE clock + - description: ADDA DAC clock + - description: ADDA DAC pre-distortion clock + - description: audio infra sys clock + - description: audio infra 26M clock + + clock-names: + items: + - const: aud_afe_clk + - const: aud_dac_clk + - const: aud_dac_predis_clk + - const: aud_infra_clk + - const: aud_infra_26m_clk + +required: + - compatible + - interrupts + - resets + - reset-names + - mediatek,apmixedsys + - mediatek,infracfg + - mediatek,topckgen + - power-domains + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8192-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/power/mt8192-power.h> + #include <dt-bindings/reset/mt8192-resets.h> + + afe: mt8192-afe-pcm { + compatible = "mediatek,mt8192-audio"; + interrupts = <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>; + resets = <&watchdog MT8192_TOPRGU_AUDIO_SW_RST>; + reset-names = "audiosys"; + mediatek,apmixedsys = <&apmixedsys>; + mediatek,infracfg = <&infracfg>; + mediatek,topckgen = <&topckgen>; + power-domains = <&scpsys MT8192_POWER_DOMAIN_AUDIO>; + clocks = <&audsys CLK_AUD_AFE>, + <&audsys CLK_AUD_DAC>, + <&audsys CLK_AUD_DAC_PREDIS>, + <&infracfg CLK_INFRA_AUDIO>, + <&infracfg CLK_INFRA_AUDIO_26M_B>; + clock-names = "aud_afe_clk", + "aud_dac_clk", + "aud_dac_predis_clk", + "aud_infra_clk", + "aud_infra_26m_clk"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1011-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1011-rt5682.yaml new file mode 100644 index 000000000000..d354c30d3377 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1011-rt5682.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mt8195-mt6359-rt1011-rt5682.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT8195 with MT6359, RT1011 and RT5682 ASoC sound card driver + +maintainers: + - Trevor Wu <trevor.wu@mediatek.com> + +description: + This binding describes the MT8195 sound card with RT1011 and RT5682. + +properties: + compatible: + const: mediatek,mt8195_mt6359_rt1011_rt5682 + + mediatek,platform: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of MT8195 ASoC platform. + + mediatek,dptx-codec: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of MT8195 Display Port Tx codec node. + + mediatek,hdmi-codec: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of MT8195 HDMI codec node. + +additionalProperties: false + +required: + - compatible + - mediatek,platform + +examples: + - | + + sound: mt8195-sound { + compatible = "mediatek,mt8195_mt6359_rt1011_rt5682"; + mediatek,platform = <&afe>; + pinctrl-names = "default"; + pinctrl-0 = <&aud_pins_default>; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/name-prefix.txt b/Documentation/devicetree/bindings/sound/name-prefix.txt deleted file mode 100644 index 645775908657..000000000000 --- a/Documentation/devicetree/bindings/sound/name-prefix.txt +++ /dev/null @@ -1,24 +0,0 @@ -Name prefix: - -Card implementing the routing property define the connection between -audio components as list of string pair. Component using the same -sink/source names may use the name prefix property to prepend the -name of their sinks/sources with the provided string. - -Optional name prefix property: -- sound-name-prefix : string using as prefix for the sink/source names of - the component. - -Example: Two instances of the same component. - -amp0: analog-amplifier@0 { - compatible = "simple-audio-amplifier"; - enable-gpios = <&gpio GPIOH_3 0>; - sound-name-prefix = "FRONT"; -}; - -amp1: analog-amplifier@1 { - compatible = "simple-audio-amplifier"; - enable-gpios = <&gpio GPIOH_4 0>; - sound-name-prefix = "BACK"; -}; diff --git a/Documentation/devicetree/bindings/sound/name-prefix.yaml b/Documentation/devicetree/bindings/sound/name-prefix.yaml new file mode 100644 index 000000000000..2fe57f87ac52 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/name-prefix.yaml @@ -0,0 +1,21 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/name-prefix.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Component sound name prefix + +maintainers: + - Jerome Brunet <jbrunet@baylibre.com> + +properties: + sound-name-prefix: + $ref: /schemas/types.yaml#/definitions/string + description: | + Card implementing the routing property define the connection between + audio components as list of string pair. Component using the same + sink/source names may use this property to prepend the name of their + sinks/sources with the provided string. + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/sound/nau8821.txt b/Documentation/devicetree/bindings/sound/nau8821.txt new file mode 100644 index 000000000000..6c3baf7a5f21 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nau8821.txt @@ -0,0 +1,55 @@ +Nuvoton NAU88L21 audio codec + +This device supports I2C only. + +Required properties: + - compatible : Must be "nuvoton,nau8821" + + - reg : the I2C address of the device. This is either 0x1B (CSB=0) or 0x54 (CSB=1). + +Optional properties: + - nuvoton,jkdet-enable: Enable jack detection via JKDET pin. + - nuvoton,jkdet-pull-enable: Enable JKDET pin pull. If set - pin pull enabled, + otherwise pin in high impedance state. + - nuvoton,jkdet-pull-up: Pull-up JKDET pin. If set then JKDET pin is pull up, otherwise pull down. + - nuvoton,jkdet-polarity: JKDET pin polarity. 0 - active high, 1 - active low. + + - nuvoton,vref-impedance: VREF Impedance selection + 0 - Open + 1 - 25 kOhm + 2 - 125 kOhm + 3 - 2.5 kOhm + + - nuvoton,micbias-voltage: Micbias voltage level. + 0 - VDDA + 1 - VDDA + 2 - VDDA * 1.1 + 3 - VDDA * 1.2 + 4 - VDDA * 1.3 + 5 - VDDA * 1.4 + 6 - VDDA * 1.53 + 7 - VDDA * 1.53 + + - nuvoton,jack-insert-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms + - nuvoton,jack-eject-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms + + - nuvoton,dmic-clk-threshold: the ADC threshold of DMIC clock. + + +Example: + + headset: nau8821@1b { + compatible = "nuvoton,nau8821"; + reg = <0x1b>; + interrupt-parent = <&gpio>; + interrupts = <23 IRQ_TYPE_LEVEL_LOW>; + nuvoton,jkdet-enable; + nuvoton,jkdet-pull-enable; + nuvoton,jkdet-pull-up; + nuvoton,jkdet-polarity = <GPIO_ACTIVE_LOW>; + nuvoton,vref-impedance = <2>; + nuvoton,micbias-voltage = <6>; + nuvoton,jack-insert-debounce = <7>; + nuvoton,jack-eject-debounce = <7>; + nuvoton,dmic-clk-threshold = 3072000; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml index 5f6b37c251a8..0912d3e3fd8e 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml @@ -17,6 +17,9 @@ maintainers: - Jon Hunter <jonathanh@nvidia.com> - Sameer Pujar <spujar@nvidia.com> +allOf: + - $ref: name-prefix.yaml# + properties: $nodename: pattern: "^dspk@[0-9a-f]*$" @@ -48,12 +51,6 @@ properties: sound-name-prefix: pattern: "^DSPK[1-9]$" - $ref: /schemas/types.yaml#/definitions/string - description: - Used as prefix for sink/source names of the component. Must be a - unique string among multiple instances of the same component. - The name can be "DSPK1" or "DSPKx", where x depends on the maximum - available instances on a Tegra SoC. ports: $ref: /schemas/graph.yaml#/properties/ports diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml new file mode 100644 index 000000000000..c4ba12ea3611 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra210-adx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra210 ADX Device Tree Bindings + +description: | + The Audio Demultiplexer (ADX) block takes an input stream with up to + 16 channels and demultiplexes it into four output streams of up to 16 + channels each. A byte RAM helps to form output frames by any combination + of bytes from the input frame. Its design is identical to that of byte + RAM in the AMX except that the data flow direction is reversed. + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Mohan Kumar <mkumard@nvidia.com> + - Sameer Pujar <spujar@nvidia.com> + +allOf: + - $ref: name-prefix.yaml# + +properties: + $nodename: + pattern: "^adx@[0-9a-f]*$" + + compatible: + oneOf: + - const: nvidia,tegra210-adx + - items: + - enum: + - nvidia,tegra194-adx + - nvidia,tegra186-adx + - const: nvidia,tegra210-adx + + reg: + maxItems: 1 + + sound-name-prefix: + pattern: "^ADX[1-9]$" + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + ADX has one input and four outputs. Accordingly ACIF (Audio Client + Interface) port nodes are defined to represent ADX input (port 0) + and outputs (ports 1 to 4). These are connected to corresponding + ports on AHUB (Audio Hub). + properties: + port@0: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: ADX ACIF input port + patternProperties: + '^port@[1-4]': + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: ADX ACIF output ports + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + + adx@702d3800 { + compatible = "nvidia,tegra210-adx"; + reg = <0x702d3800 0x100>; + sound-name-prefix = "ADX1"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml index 1118a9488345..df81d208184a 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml @@ -85,6 +85,26 @@ patternProperties: type: object $ref: nvidia,tegra186-dspk.yaml# + '^mvc@[0-9a-f]+$': + type: object + $ref: nvidia,tegra210-mvc.yaml# + + '^sfc@[0-9a-f]+$': + type: object + $ref: nvidia,tegra210-sfc.yaml# + + '^amx@[0-9a-f]+$': + type: object + $ref: nvidia,tegra210-amx.yaml# + + '^adx@[0-9a-f]+$': + type: object + $ref: nvidia,tegra210-adx.yaml# + + '^amixer@[0-9a-f]+$': + type: object + $ref: nvidia,tegra210-mixer.yaml# + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml new file mode 100644 index 000000000000..bb2111afe5a8 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra210-amx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra210 AMX Device Tree Bindings + +description: | + The Audio Multiplexer (AMX) block can multiplex up to four input streams + each of which can have maximum 16 channels and generate an output stream + with maximum 16 channels. A byte RAM helps to form an output frame by + any combination of bytes from the input frames. + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Mohan Kumar <mkumard@nvidia.com> + - Sameer Pujar <spujar@nvidia.com> + +allOf: + - $ref: name-prefix.yaml# + +properties: + $nodename: + pattern: "^amx@[0-9a-f]*$" + + compatible: + oneOf: + - const: nvidia,tegra210-amx + - items: + - const: nvidia,tegra186-amx + - const: nvidia,tegra210-amx + - const: nvidia,tegra194-amx + + reg: + maxItems: 1 + + sound-name-prefix: + pattern: "^AMX[1-9]$" + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + AMX has four inputs and one output. Accordingly ACIF (Audio Client + Interfaces) port nodes are defined to represent AMX inputs (port 0 + to 3) and output (port 4). These are connected to corresponding + ports on AHUB (Audio Hub). + + patternProperties: + '^port@[0-3]': + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: AMX ACIF input ports + + properties: + port@4: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: AMX ACIF output port + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + + amx@702d3000 { + compatible = "nvidia,tegra210-amx"; + reg = <0x702d3000 0x100>; + sound-name-prefix = "AMX1"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml index fd275a575055..62db982bb01d 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml @@ -16,6 +16,9 @@ maintainers: - Jon Hunter <jonathanh@nvidia.com> - Sameer Pujar <spujar@nvidia.com> +allOf: + - $ref: name-prefix.yaml# + properties: $nodename: pattern: "^dmic@[0-9a-f]*$" @@ -49,12 +52,6 @@ properties: sound-name-prefix: pattern: "^DMIC[1-9]$" - $ref: /schemas/types.yaml#/definitions/string - description: - used as prefix for sink/source names of the component. Must be a - unique string among multiple instances of the same component. - The name can be "DMIC1" or "DMIC2" ... "DMICx", where x depends - on the maximum available instances on a Tegra SoC. ports: $ref: /schemas/graph.yaml#/properties/ports diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml index 63370709c768..f954be636697 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml @@ -16,6 +16,9 @@ maintainers: - Jon Hunter <jonathanh@nvidia.com> - Sameer Pujar <spujar@nvidia.com> +allOf: + - $ref: name-prefix.yaml# + properties: $nodename: pattern: "^i2s@[0-9a-f]*$" @@ -65,12 +68,6 @@ properties: sound-name-prefix: pattern: "^I2S[1-9]$" - $ref: /schemas/types.yaml#/definitions/string - description: - Used as prefix for sink/source names of the component. Must be a - unique string among multiple instances of the same component. - The name can be "I2S1" or "I2S2" ... "I2Sx", where x depends - on the maximum available instances on a Tegra SoC. ports: $ref: /schemas/graph.yaml#/properties/ports diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml new file mode 100644 index 000000000000..428f3c851941 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra210-mixer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra210 Mixer Device Tree Bindings + +description: | + The Mixer supports mixing of up to ten 7.1 audio input streams and + generate five outputs (each of which can be any combination of the + ten input streams). + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Mohan Kumar <mkumard@nvidia.com> + - Sameer Pujar <spujar@nvidia.com> + +allOf: + - $ref: name-prefix.yaml# + +properties: + $nodename: + pattern: "^amixer@[0-9a-f]*$" + + compatible: + oneOf: + - const: nvidia,tegra210-amixer + - items: + - enum: + - nvidia,tegra194-amixer + - nvidia,tegra186-amixer + - const: nvidia,tegra210-amixer + + reg: + maxItems: 1 + + sound-name-prefix: + pattern: "^MIXER[1-9]$" + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + Mixer has ten inputs and five outputs. Accordingly ACIF (Audio + Client Interfaces) port nodes are defined to represent Mixer + inputs (port 0 to 9) and outputs (port 10 to 14). These are + connected to corresponding ports on AHUB (Audio Hub). + + patternProperties: + '^port@[0-9]': + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: Mixer ACIF input ports + '^port@[10-14]': + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: Mixer ACIF output ports + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + + amixer@702dbb00 { + compatible = "nvidia,tegra210-amixer"; + reg = <0x702dbb00 0x800>; + sound-name-prefix = "MIXER1"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml new file mode 100644 index 000000000000..e2f5a8591d8f --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra210-mvc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra210 MVC Device Tree Bindings + +description: | + The Master Volume Control (MVC) provides gain or attenuation to a digital + signal path. It can be used in input or output signal path for per-stream + volume control or it can be used as master volume control. The MVC block + has one input and one output. The input digital stream can be mono or + multi-channel (up to 7.1 channels) stream. An independent mute control is + also included in the MVC block. + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Mohan Kumar <mkumard@nvidia.com> + - Sameer Pujar <spujar@nvidia.com> + +allOf: + - $ref: name-prefix.yaml# + +properties: + $nodename: + pattern: "^mvc@[0-9a-f]*$" + + compatible: + oneOf: + - const: nvidia,tegra210-mvc + - items: + - enum: + - nvidia,tegra194-mvc + - nvidia,tegra186-mvc + - const: nvidia,tegra210-mvc + + reg: + maxItems: 1 + + sound-name-prefix: + pattern: "^MVC[1-9]$" + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: | + MVC ACIF (Audio Client Interface) input port. This is connected + to corresponding ACIF output port on AHUB (Audio Hub). + + port@1: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: | + MVC ACIF output port. This is connected to corresponding ACIF + input port on AHUB. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + + mvc@702da000 { + compatible = "nvidia,tegra210-mvc"; + reg = <0x702da000 0x200>; + sound-name-prefix = "MVC1"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml new file mode 100644 index 000000000000..41ad65173548 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra210-sfc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra210 SFC Device Tree Bindings + +description: | + The Sampling Frequency Converter (SFC) converts the sampling frequency + of the input signal from one frequency to another. It supports sampling + frequency conversions of streams of up to two channels (stereo). + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Mohan Kumar <mkumard@nvidia.com> + - Sameer Pujar <spujar@nvidia.com> + +allOf: + - $ref: name-prefix.yaml# + +properties: + $nodename: + pattern: "^sfc@[0-9a-f]*$" + + compatible: + oneOf: + - const: nvidia,tegra210-sfc + - items: + - enum: + - nvidia,tegra194-sfc + - nvidia,tegra186-sfc + - const: nvidia,tegra210-sfc + + reg: + maxItems: 1 + + sound-name-prefix: + pattern: "^SFC[1-9]$" + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: | + SFC ACIF (Audio Client Interface) input port. This is connected + to corresponding ACIF output port on AHUB (Audio Hub). + + port@1: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: | + SFC ACIF output port. This is connected to corresponding ACIF + input port on AHUB. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + + sfc@702d2000 { + compatible = "nvidia,tegra210-sfc"; + reg = <0x702d2000 0x200>; + sound-name-prefix = "SFC1"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml index ffb8fcfeb629..7667471be1e4 100644 --- a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml +++ b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml @@ -9,6 +9,9 @@ title: NXP/Goodix TFA989X (TFA1) Audio Amplifiers maintainers: - Stephan Gerhold <stephan@gerhold.net> +allOf: + - $ref: name-prefix.yaml# + properties: compatible: enum: @@ -21,11 +24,7 @@ properties: '#sound-dai-cells': const: 0 - sound-name-prefix: - $ref: /schemas/types.yaml#/definitions/string - description: - Used as prefix for sink/source names of the component. Must be a - unique string among multiple instances of the same component. + sound-name-prefix: true vddd-supply: description: regulator phandle for the VDDD power supply. diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml index 443d556caa69..bc762b39c68a 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml @@ -11,7 +11,9 @@ maintainers: properties: compatible: - const: qcom,sm8250-lpass-rx-macro + enum: + - qcom,sc7280-lpass-rx-macro + - qcom,sm8250-lpass-rx-macro reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml index 6b5ca02ccce4..74f53864e7a7 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml @@ -11,7 +11,9 @@ maintainers: properties: compatible: - const: qcom,sm8250-lpass-tx-macro + enum: + - qcom,sc7280-lpass-tx-macro + - qcom,sm8250-lpass-tx-macro reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml index 679b49cbe30f..99f2c3687fbd 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml @@ -11,7 +11,9 @@ maintainers: properties: compatible: - const: qcom,sm8250-lpass-va-macro + enum: + - qcom,sc7280-lpass-va-macro + - qcom,sm8250-lpass-va-macro reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml index 435b019a1e3d..13cdb8a10687 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml @@ -11,7 +11,9 @@ maintainers: properties: compatible: - const: qcom,sm8250-lpass-wsa-macro + enum: + - qcom,sc7280-lpass-wsa-macro + - qcom,sm8250-lpass-wsa-macro reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/qcom,q6afe.txt b/Documentation/devicetree/bindings/sound/qcom,q6afe.txt index 2d6fb2ea75a0..bc6b5f1fe4f1 100644 --- a/Documentation/devicetree/bindings/sound/qcom,q6afe.txt +++ b/Documentation/devicetree/bindings/sound/qcom,q6afe.txt @@ -12,190 +12,9 @@ used by all apr services. Must contain the following properties. from DSP. example "qcom,q6afe" -= AFE DAIs (Digial Audio Interface) -"dais" subnode of the AFE node. It represents afe dais, each afe dai is a -subnode of "dais" representing board specific dai setup. -"dais" node should have following properties followed by dai children. - -- compatible: - Usage: required - Value type: <stringlist> - Definition: must be "qcom,q6afe-dais" - -- #sound-dai-cells - Usage: required - Value type: <u32> - Definition: Must be 1 - -- #address-cells - Usage: required - Value type: <u32> - Definition: Must be 1 - -- #size-cells - Usage: required - Value type: <u32> - Definition: Must be 0 - -== AFE DAI is subnode of "dais" and represent a dai, it includes board specific -configuration of each dai. Must contain the following properties. - -- reg - Usage: required - Value type: <u32> - Definition: Must be dai id - -- qcom,sd-lines - Usage: required for mi2s interface - Value type: <prop-encoded-array> - Definition: Must be list of serial data lines used by this dai. - should be one or more of the 0-3 sd lines. - - - qcom,tdm-sync-mode: - Usage: required for tdm interface - Value type: <prop-encoded-array> - Definition: Synchronization mode. - 0 - Short sync bit mode - 1 - Long sync mode - 2 - Short sync slot mode - - - qcom,tdm-sync-src: - Usage: required for tdm interface - Value type: <prop-encoded-array> - Definition: Synchronization source. - 0 - External source - 1 - Internal source - - - qcom,tdm-data-out: - Usage: required for tdm interface - Value type: <prop-encoded-array> - Definition: Data out signal to drive with other masters. - 0 - Disable - 1 - Enable - - - qcom,tdm-invert-sync: - Usage: required for tdm interface - Value type: <prop-encoded-array> - Definition: Invert the sync. - 0 - Normal - 1 - Invert - - - qcom,tdm-data-delay: - Usage: required for tdm interface - Value type: <prop-encoded-array> - Definition: Number of bit clock to delay data - with respect to sync edge. - 0 - 0 bit clock cycle - 1 - 1 bit clock cycle - 2 - 2 bit clock cycle - - - qcom,tdm-data-align: - Usage: required for tdm interface - Value type: <prop-encoded-array> - Definition: Indicate how data is packed - within the slot. For example, 32 slot width in case of - sample bit width is 24. - 0 - MSB - 1 - LSB - -= AFE CLOCKSS -"clocks" subnode of the AFE node. It represents q6afe clocks -"clocks" node should have following properties. -- compatible: - Usage: required - Value type: <stringlist> - Definition: must be "qcom,q6afe-clocks" - -- #clock-cells: - Usage: required - Value type: <u32> - Definition: Must be 2. Clock Id followed by - below valid clock coupling attributes. - 1 - for no coupled clock - 2 - for dividend of the coupled clock - 3 - for divisor of the coupled clock - 4 - for inverted and no couple clock - = EXAMPLE apr-service@4 { compatible = "qcom,q6afe"; reg = <APR_SVC_AFE>; - - dais { - compatible = "qcom,q6afe-dais"; - #sound-dai-cells = <1>; - #address-cells = <1>; - #size-cells = <0>; - - dai@1 { - reg = <HDMI_RX>; - }; - - dai@24 { - reg = <PRIMARY_TDM_RX_0>; - qcom,tdm-sync-mode = <1>: - qcom,tdm-sync-src = <1>; - qcom,tdm-data-out = <0>; - qcom,tdm-invert-sync = <1>; - qcom,tdm-data-delay = <1>; - qcom,tdm-data-align = <0>; - - }; - - dai@25 { - reg = <PRIMARY_TDM_TX_0>; - qcom,tdm-sync-mode = <1>: - qcom,tdm-sync-src = <1>; - qcom,tdm-data-out = <0>; - qcom,tdm-invert-sync = <1>; - qcom,tdm-data-delay <1>: - qcom,tdm-data-align = <0>; - }; - - dai@16 { - reg = <PRIMARY_MI2S_RX>; - qcom,sd-lines = <0 2>; - }; - - dai@17 { - reg = <PRIMARY_MI2S_TX>; - qcom,sd-lines = <1>; - }; - - dai@18 { - reg = <SECONDARY_MI2S_RX>; - qcom,sd-lines = <0 3>; - }; - - dai@19 { - reg = <SECONDARY_MI2S_TX>; - qcom,sd-lines = <1>; - }; - - dai@20 { - reg = <TERTIARY_MI2S_RX>; - qcom,sd-lines = <1 3>; - }; - - dai@21 { - reg = <TERTIARY_MI2S_TX>; - qcom,sd-lines = <0>; - }; - - dai@22 { - reg = <QUATERNARY_MI2S_RX>; - qcom,sd-lines = <0>; - }; - - dai@23 { - reg = <QUATERNARY_MI2S_TX>; - qcom,sd-lines = <1>; - }; - }; - - clocks { - compatible = "qcom,q6afe-clocks"; - #clock-cells = <2>; - }; }; diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml new file mode 100644 index 000000000000..5d972784321d --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/sound/qcom,q6apm-dai.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Audio Process Manager Digital Audio Interfaces binding + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + This binding describes the Qualcomm APM DAIs in DSP + +properties: + compatible: + const: qcom,q6apm-dais + + reg: + maxItems: 1 + + iommus: + maxItems: 1 + +required: + - compatible + - iommus + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/soc/qcom,gpr.h> + gpr { + compatible = "qcom,gpr"; + #address-cells = <1>; + #size-cells = <0>; + qcom,domain = <GPR_DOMAIN_ID_ADSP>; + service@1 { + compatible = "qcom,q6apm"; + reg = <1>; + + #address-cells = <1>; + #size-cells = <0>; + + apm-dai@1 { + compatible = "qcom,q6apm-dais"; + iommus = <&apps_smmu 0x1801 0x0>; + reg = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/qcom,q6asm.txt b/Documentation/devicetree/bindings/sound/qcom,q6asm.txt index 8c4883becae9..0d0075125243 100644 --- a/Documentation/devicetree/bindings/sound/qcom,q6asm.txt +++ b/Documentation/devicetree/bindings/sound/qcom,q6asm.txt @@ -14,7 +14,7 @@ used by the apr service device. from DSP. example "qcom,q6asm-v2.0" -= ASM DAIs (Digial Audio Interface) += ASM DAIs (Digital Audio Interface) "dais" subnode of the ASM node represents dai specific configuration - compatible: diff --git a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml new file mode 100644 index 000000000000..f83f00737a2f --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-clocks.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm DSP LPASS Clock Controller binding + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + This binding describes the Qualcomm DSP Clock Controller + +properties: + compatible: + enum: + - qcom,q6afe-clocks + - qcom,q6prm-lpass-clocks + + reg: + maxItems: 1 + + '#clock-cells': + const: 2 + description: + Clock Id is followed by clock coupling attributes. + 1 = for no coupled clock + 2 = for dividend of the coupled clock + 3 = for divisor of the coupled clock + 4 = for inverted and no couple clock + +required: + - compatible + - reg + - "#clock-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/soc/qcom,apr.h> + #include <dt-bindings/sound/qcom,q6afe.h> + apr { + #address-cells = <1>; + #size-cells = <0>; + apr-service@4 { + reg = <APR_SVC_AFE>; + #address-cells = <1>; + #size-cells = <0>; + clock-controller@2 { + compatible = "qcom,q6afe-clocks"; + reg = <2>; + #clock-cells = <2>; + }; + }; + }; + + - | + #include <dt-bindings/soc/qcom,gpr.h> + gpr { + compatible = "qcom,gpr"; + qcom,domain = <GPR_DOMAIN_ID_ADSP>; + #address-cells = <1>; + #size-cells = <0>; + service@2 { + reg = <GPR_PRM_MODULE_IID>; + compatible = "qcom,q6prm"; + #address-cells = <1>; + #size-cells = <0>; + clock-controller@2 { + compatible = "qcom,q6prm-lpass-clocks"; + reg = <2>; + #clock-cells = <2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml new file mode 100644 index 000000000000..dc7fba7b92d5 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml @@ -0,0 +1,205 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-ports.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm DSP LPASS(Low Power Audio SubSystem) Audio Ports binding + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + This binding describes the Qualcomm DSP LPASS Audio ports + +properties: + compatible: + enum: + - qcom,q6afe-dais + - qcom,q6apm-lpass-dais + + reg: + maxItems: 1 + + '#sound-dai-cells': + const: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +#Digital Audio Interfaces +patternProperties: + '^dai@[0-9]+$': + type: object + description: + Q6DSP Digital Audio Interfaces. + + properties: + reg: + description: + Digital Audio Interface ID + + qcom,sd-lines: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + List of serial data lines used by this dai.should be one or more of the 0-3 sd lines. + minItems: 1 + maxItems: 4 + uniqueItems: true + items: + minimum: 0 + maximum: 3 + + qcom,tdm-sync-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + description: + TDM Synchronization mode + 0 = Short sync bit mode + 1 = Long sync mode + 2 = Short sync slot mode + + qcom,tdm-sync-src: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: + TDM Synchronization source + 0 = External source + 1 = Internal source + + qcom,tdm-data-out: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: + TDM Data out signal to drive with other masters + 0 = Disable + 1 = Enable + + qcom,tdm-invert-sync: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: + TDM Invert the sync + 0 = Normal + 1 = Invert + + qcom,tdm-data-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + description: + TDM Number of bit clock to delay data + 0 = 0 bit clock cycle + 1 = 1 bit clock cycle + 2 = 2 bit clock cycle + + qcom,tdm-data-align: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: + Indicate how data is packed within the slot. For example, 32 slot + width in case of sample bit width is 24TDM Invert the sync. + 0 = MSB + 1 = LSB + + required: + - reg + + allOf: + - if: + properties: + reg: + contains: + # TDM DAI ID range from PRIMARY_TDM_RX_0 - QUINARY_TDM_TX_7 + items: + minimum: 24 + maximum: 103 + then: + required: + - qcom,tdm-sync-mode + - qcom,tdm-sync-src + - qcom,tdm-data-out + - qcom,tdm-invert-sync + - qcom,tdm-data-delay + - qcom,tdm-data-align + + - if: + properties: + reg: + contains: + # MI2S DAI ID range PRIMARY_MI2S_RX - QUATERNARY_MI2S_TX and + # QUINARY_MI2S_RX - QUINARY_MI2S_TX + items: + oneOf: + - minimum: 16 + maximum: 23 + - minimum: 127 + maximum: 128 + then: + required: + - qcom,sd-lines + + additionalProperties: false + +required: + - compatible + - reg + - "#sound-dai-cells" + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/soc/qcom,apr.h> + #include <dt-bindings/sound/qcom,q6afe.h> + apr { + #address-cells = <1>; + #size-cells = <0>; + apr-service@4 { + reg = <APR_SVC_AFE>; + #address-cells = <1>; + #size-cells = <0>; + q6afedai@1 { + compatible = "qcom,q6afe-dais"; + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + #sound-dai-cells = <1>; + + dai@22 { + reg = <QUATERNARY_MI2S_RX>; + qcom,sd-lines = <0 1 2 3>; + }; + }; + }; + }; + - | + #include <dt-bindings/soc/qcom,gpr.h> + gpr { + compatible = "qcom,gpr"; + #address-cells = <1>; + #size-cells = <0>; + qcom,domain = <GPR_DOMAIN_ID_ADSP>; + service@1 { + compatible = "qcom,q6apm"; + reg = <GPR_APM_MODULE_IID>; + #address-cells = <1>; + #size-cells = <0>; + q6apmdai@1 { + compatible = "qcom,q6apm-lpass-dais"; + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + #sound-dai-cells = <1>; + + dai@22 { + reg = <QUATERNARY_MI2S_RX>; + qcom,sd-lines = <0 1 2 3>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml new file mode 100644 index 000000000000..2b8b7b51fe55 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/realtek,rt5682s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek rt5682s codec devicetree bindings + +maintainers: + - Derek Fang <derek.fang@realtek.com> + +description: | + Rt5682s(ALC5682I-VS) is a rt5682i variant which supports I2C only. + +properties: + compatible: + const: realtek,rt5682s + + reg: + maxItems: 1 + description: I2C address of the device. + + interrupts: + description: The CODEC's interrupt output. + + realtek,dmic1-data-pin: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # dmic1 data is not used + - 1 # using GPIO2 pin as dmic1 data pin + - 2 # using GPIO5 pin as dmic1 data pin + description: | + Specify which GPIO pin be used as DMIC1 data pin. + + realtek,dmic1-clk-pin: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # dmic1 clk is not used + - 1 # using GPIO1 pin as dmic1 clock pin + - 2 # using GPIO3 pin as dmic1 clock pin + description: | + Specify which GPIO pin be used as DMIC1 clk pin. + + realtek,jd-src: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # No JD is used + - 1 # using JD1 as JD source + description: | + Specify which JD source be used. + + realtek,ldo1-en-gpios: + description: | + The GPIO that controls the CODEC's LDO1_EN pin. + + realtek,dmic-clk-rate-hz: + description: | + Set the clock rate (hz) for the requirement of the particular DMIC. + + realtek,dmic-delay-ms: + description: | + Set the delay time (ms) for the requirement of the particular DMIC. + + realtek,dmic-clk-driving-high: + type: boolean + description: | + Set the high driving of the DMIC clock out. + + clocks: + items: + - description: phandle and clock specifier for codec MCLK. + + clock-names: + items: + - const: mclk + + "#clock-cells": + const: 1 + + clock-output-names: + minItems: 2 + maxItems: 2 + description: Name given for DAI word clock and bit clock outputs. + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/gpio/tegra-gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@1a { + compatible = "realtek,rt5682s"; + reg = <0x1a>; + interrupt-parent = <&gpio>; + interrupts = <TEGRA_GPIO(U, 6) IRQ_TYPE_LEVEL_HIGH>; + realtek,ldo1-en-gpios = + <&gpio TEGRA_GPIO(R, 2) GPIO_ACTIVE_HIGH>; + realtek,dmic1-data-pin = <1>; + realtek,dmic1-clk-pin = <1>; + realtek,jd-src = <1>; + + #clock-cells = <1>; + clock-output-names = "rt5682-dai-wclk", "rt5682-dai-bclk"; + + clocks = <&osc>; + clock-names = "mclk"; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/richtek,rt9120.yaml b/Documentation/devicetree/bindings/sound/richtek,rt9120.yaml new file mode 100644 index 000000000000..5655ca568240 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/richtek,rt9120.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/richtek,rt9120.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT9120 Class-D audio amplifier + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + The RT9120 is a high efficiency, I2S-input, stereo audio power amplifier + delivering 2*20W into 8 Ohm BTL speaker loads. It supports the wide input + voltage range from 4.5V to 26.4V to meet the need on most common + applications like as TV, monitors. home entertainment, electronic music + equipment. + +properties: + compatible: + enum: + - richtek,rt9120 + + reg: + description: I2C device address + maxItems: 1 + + pwdnn-gpios: + description: GPIO used for power down, low active + maxItems: 1 + + dvdd-supply: + description: | + Supply for the default on DVDD power, voltage domain must be 3P3V or 1P8V + + '#sound-dai-cells': + const: 0 + +required: + - compatible + - reg + - dvdd-supply + - '#sound-dai-cells' + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + rt9120@1a { + compatible = "richtek,rt9120"; + reg = <0x1a>; + pwdnn-gpios = <&gpio26 2 0>; + dvdd-supply = <&vdd_io_reg>; + #sound-dai-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml b/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml new file mode 100644 index 000000000000..6a7c004bef17 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml @@ -0,0 +1,182 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/rockchip,i2s-tdm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip I2S/TDM Controller + +description: + The Rockchip I2S/TDM Controller is a Time Division Multiplexed + audio interface found in various Rockchip SoCs, allowing up + to 8 channels of audio over a serial interface. + +maintainers: + - Nicolas Frattaroli <frattaroli.nicolas@gmail.com> + +properties: + compatible: + enum: + - rockchip,px30-i2s-tdm + - rockchip,rk1808-i2s-tdm + - rockchip,rk3308-i2s-tdm + - rockchip,rk3568-i2s-tdm + - rockchip,rv1126-i2s-tdm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + dmas: + minItems: 1 + maxItems: 2 + + dma-names: + minItems: 1 + maxItems: 2 + items: + enum: + - rx + - tx + + clocks: + minItems: 3 + items: + - description: clock for TX + - description: clock for RX + - description: AHB clock driving the interface + - description: + Parent clock for mclk_tx (only required when using mclk-calibrate) + - description: + Parent clock for mclk_rx (only required when using mclk-calibrate) + - description: + Clock for sample rates that are an integer multiple of 8000 + (only required when using mclk-calibrate) + - description: + Clock for sample rates that are an integer multiple of 11025 + (only required when using mclk-calibrate) + + clock-names: + minItems: 3 + items: + - const: mclk_tx + - const: mclk_rx + - const: hclk + - const: mclk_tx_src + - const: mclk_rx_src + - const: mclk_root0 + - const: mclk_root1 + + resets: + minItems: 1 + maxItems: 2 + description: resets for the tx and rx directions + + reset-names: + minItems: 1 + maxItems: 2 + items: + enum: + - tx-m + - rx-m + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of the syscon node for the GRF register. + + rockchip,trcm-sync-tx-only: + type: boolean + description: Use TX BCLK/LRCK for both TX and RX. + + rockchip,trcm-sync-rx-only: + type: boolean + description: Use RX BCLK/LRCK for both TX and RX. + + "#sound-dai-cells": + const: 0 + + rockchip,i2s-rx-route: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + Defines the mapping of I2S RX sdis to I2S data bus lines. + By default, they are mapped one-to-one. + rockchip,i2s-rx-route = <3> would mean sdi3 is receiving from data0. + maxItems: 4 + items: + enum: [0, 1, 2, 3] + + rockchip,i2s-tx-route: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + Defines the mapping of I2S TX sdos to I2S data bus lines. + By default, they are mapped one-to-one. + rockchip,i2s-tx-route = <3> would mean sdo3 is sending to data0. + maxItems: 4 + items: + enum: [0, 1, 2, 3] + + rockchip,io-multiplex: + description: + Specify that the GPIO lines on the I2S bus are multiplexed such that + the direction (input/output) needs to be dynamically adjusted. + type: boolean + + +required: + - compatible + - reg + - interrupts + - dmas + - dma-names + - clocks + - clock-names + - resets + - reset-names + - rockchip,grf + - "#sound-dai-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3568-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/pinctrl/rockchip.h> + + bus { + #address-cells = <2>; + #size-cells = <2>; + i2s@fe410000 { + compatible = "rockchip,rk3568-i2s-tdm"; + reg = <0x0 0xfe410000 0x0 0x1000>; + interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru MCLK_I2S1_8CH_TX>, <&cru MCLK_I2S1_8CH_RX>, + <&cru HCLK_I2S1_8CH>; + clock-names = "mclk_tx", "mclk_rx", "hclk"; + dmas = <&dmac1 3>, <&dmac1 2>; + dma-names = "rx", "tx"; + resets = <&cru SRST_M_I2S1_8CH_TX>, <&cru SRST_M_I2S1_8CH_RX>; + reset-names = "tx-m", "rx-m"; + rockchip,trcm-sync-tx-only; + rockchip,grf = <&grf>; + #sound-dai-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = + <&i2s1m0_sclktx + &i2s1m0_sclkrx + &i2s1m0_lrcktx + &i2s1m0_lrckrx + &i2s1m0_sdi0 + &i2s1m0_sdi1 + &i2s1m0_sdi2 + &i2s1m0_sdi3 + &i2s1m0_sdo0 + &i2s1m0_sdo1 + &i2s1m0_sdo2 + &i2s1m0_sdo3>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/rockchip,pdm.txt b/Documentation/devicetree/bindings/sound/rockchip,pdm.txt deleted file mode 100644 index 98572a25122f..000000000000 --- a/Documentation/devicetree/bindings/sound/rockchip,pdm.txt +++ /dev/null @@ -1,46 +0,0 @@ -* Rockchip PDM controller - -Required properties: - -- compatible: "rockchip,pdm" - - "rockchip,px30-pdm" - - "rockchip,rk1808-pdm" - - "rockchip,rk3308-pdm" -- reg: physical base address of the controller and length of memory mapped - region. -- dmas: DMA specifiers for rx dma. See the DMA client binding, - Documentation/devicetree/bindings/dma/dma.txt -- dma-names: should include "rx". -- clocks: a list of phandle + clock-specifer pairs, one for each entry in clock-names. -- clock-names: should contain following: - - "pdm_hclk": clock for PDM BUS - - "pdm_clk" : clock for PDM controller -- resets: a list of phandle + reset-specifer paris, one for each entry in reset-names. -- reset-names: reset names, should include "pdm-m". -- pinctrl-names: Must contain a "default" entry. -- pinctrl-N: One property must exist for each entry in - pinctrl-names. See ../pinctrl/pinctrl-bindings.txt - for details of the property values. - -Example for rk3328 PDM controller: - -pdm: pdm@ff040000 { - compatible = "rockchip,pdm"; - reg = <0x0 0xff040000 0x0 0x1000>; - clocks = <&clk_pdm>, <&clk_gates28 0>; - clock-names = "pdm_clk", "pdm_hclk"; - dmas = <&pdma 16>; - #dma-cells = <1>; - dma-names = "rx"; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&pdmm0_clk - &pdmm0_sdi0 - &pdmm0_sdi1 - &pdmm0_sdi2 - &pdmm0_sdi3>; - pinctrl-1 = <&pdmm0_clk_sleep - &pdmm0_sdi0_sleep - &pdmm0_sdi1_sleep - &pdmm0_sdi2_sleep - &pdmm0_sdi3_sleep>; -}; diff --git a/Documentation/devicetree/bindings/sound/rockchip,pdm.yaml b/Documentation/devicetree/bindings/sound/rockchip,pdm.yaml new file mode 100644 index 000000000000..22e1cf6c0592 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rockchip,pdm.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/rockchip,pdm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip PDM controller + +description: + The Pulse Density Modulation Interface Controller (PDMC) is + a PDM interface controller and decoder that support PDM format. + It integrates a clock generator driving the PDM microphone + and embeds filters which decimate the incoming bit stream to + obtain most common audio rates. + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + enum: + - rockchip,pdm + - rockchip,px30-pdm + - rockchip,rk1808-pdm + - rockchip,rk3308-pdm + - rockchip,rk3568-pdm + - rockchip,rv1126-pdm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: clock for PDM controller + - description: clock for PDM BUS + + clock-names: + items: + - const: pdm_clk + - const: pdm_hclk + + dmas: + maxItems: 1 + + dma-names: + items: + - const: rx + + power-domains: + maxItems: 1 + + resets: + items: + - description: reset for PDM controller + + reset-names: + items: + - const: pdm-m + + rockchip,path-map: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + Defines the mapping of PDM SDIx to PDM PATHx. + By default, they are mapped one-to-one. + maxItems: 4 + uniqueItems: true + items: + enum: [ 0, 1, 2, 3 ] + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + - "#sound-dai-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3328-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/pinctrl/rockchip.h> + + bus { + #address-cells = <2>; + #size-cells = <2>; + + pdm@ff040000 { + compatible = "rockchip,pdm"; + reg = <0x0 0xff040000 0x0 0x1000>; + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru SCLK_PDM>, <&cru HCLK_PDM>; + clock-names = "pdm_clk", "pdm_hclk"; + dmas = <&dmac 16>; + dma-names = "rx"; + #sound-dai-cells = <0>; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&pdmm0_clk + &pdmm0_sdi0 + &pdmm0_sdi1 + &pdmm0_sdi2 + &pdmm0_sdi3>; + pinctrl-1 = <&pdmm0_clk_sleep + &pdmm0_sdi0_sleep + &pdmm0_sdi1_sleep + &pdmm0_sdi2_sleep + &pdmm0_sdi3_sleep>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/rt5659.txt b/Documentation/devicetree/bindings/sound/rt5659.txt index c473df5c878c..013f534fa059 100644 --- a/Documentation/devicetree/bindings/sound/rt5659.txt +++ b/Documentation/devicetree/bindings/sound/rt5659.txt @@ -42,7 +42,7 @@ Optional properties: - realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin. - realtek,reset-gpios : The GPIO that controls the CODEC's RESET pin. -- sound-name-prefix: Please refer to name-prefix.txt +- sound-name-prefix: Please refer to name-prefix.yaml - ports: A Codec may have a single or multiple I2S interfaces. These interfaces on Codec side can be described under 'ports' or 'port'. diff --git a/Documentation/devicetree/bindings/sound/simple-amplifier.txt b/Documentation/devicetree/bindings/sound/simple-amplifier.txt deleted file mode 100644 index b1b097cc9b68..000000000000 --- a/Documentation/devicetree/bindings/sound/simple-amplifier.txt +++ /dev/null @@ -1,17 +0,0 @@ -Simple Amplifier Audio Driver - -Required properties: -- compatible : "dioo,dio2125" or "simple-audio-amplifier" - -Optional properties: -- enable-gpios : the gpio connected to the enable pin of the simple amplifier -- VCC-supply : power supply for the device, as covered - in Documentation/devicetree/bindings/regulator/regulator.txt - -Example: - -amp: analog-amplifier { - compatible = "simple-audio-amplifier"; - VCC-supply = <®ulator>; - enable-gpios = <&gpio GPIOH_3 0>; -}; diff --git a/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml b/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml new file mode 100644 index 000000000000..26379377a7ac --- /dev/null +++ b/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/simple-audio-amplifier.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Simple Audio Amplifier Device Tree Bindings + +maintainers: + - Jerome Brunet <jbrunet@baylibre.com> + +properties: + compatible: + enum: + - dioo,dio2125 + - simple-audio-amplifier + + enable-gpios: + maxItems: 1 + + VCC-supply: + description: > + power supply for the device + + sound-name-prefix: + $ref: /schemas/types.yaml#/definitions/string + description: > + See ./name-prefix.txt + +required: + - compatible + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/meson8-gpio.h> + + analog-amplifier { + compatible = "simple-audio-amplifier"; + VCC-supply = <®ulator>; + enable-gpios = <&gpio GPIOH_3 0>; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml index 5986d1fcbb54..b5fc35ee9b65 100644 --- a/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml +++ b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml @@ -13,6 +13,9 @@ description: | Simple audio multiplexers are driven using gpios, allowing to select which of their input line is connected to the output line. +allOf: + - $ref: name-prefix.yaml# + properties: compatible: const: simple-audio-mux @@ -21,11 +24,7 @@ properties: description: | GPIOs used to select the input line. - sound-name-prefix: - $ref: /schemas/types.yaml#/definitions/string - description: - Used as prefix for sink/source names of the component. Must be a - unique string among multiple instances of the same component. + sound-name-prefix: true required: - compatible diff --git a/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml b/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml index 55ae198220f4..70f62ecd6eb2 100644 --- a/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml +++ b/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml @@ -46,7 +46,27 @@ properties: patternProperties: "^port@[0-9]$": - description: FIXME, Need to define what each port is. + description: | + Port number of DT node is specified by the following DAI channels that + depends on SoC. + ld11-aio,ld20-aio: + 0: hdmi + 1: pcmin2 + 2: line + 3: hpcmout1 + 4: pcmout3 + 5: hiecout1 + 6: epcmout2 + 7: epcmout3 + 8: hieccompout1 + pxs2-aio: + 0: hdmi + 1: line + 2: aux + 3: hiecout1 + 4: iecout1 + 5: hieccompout1 + 6: ieccompout1 $ref: audio-graph-port.yaml# unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml b/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml index 48ddfcbbcbae..be6acfda9999 100644 --- a/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml +++ b/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml @@ -40,7 +40,11 @@ properties: patternProperties: "^port@[0-9]$": - description: FIXME, Need to define what each port is. + description: | + Port number of DT node is specified by the following DAI channels. + 0: line1 + 1: hp + 2: line2 $ref: audio-graph-port.yaml# unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/sound/spdif-transmitter.txt b/Documentation/devicetree/bindings/sound/spdif-transmitter.txt deleted file mode 100644 index 55a85841dd85..000000000000 --- a/Documentation/devicetree/bindings/sound/spdif-transmitter.txt +++ /dev/null @@ -1,10 +0,0 @@ -Device-Tree bindings for dummy spdif transmitter - -Required properties: - - compatible: should be "linux,spdif-dit". - -Example node: - - codec: spdif-transmitter { - compatible = "linux,spdif-dit"; - }; diff --git a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml index 6feb5a09c184..d3966ae04ad0 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 SPI/I2S Controller maintainers: - - Olivier Moysan <olivier.moysan@st.com> + - Olivier Moysan <olivier.moysan@foss.st.com> description: The SPI/I2S block supports I2S/PCM protocols when configured on I2S mode. diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index f97132400bb6..1538d11ce9a8 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 Serial Audio Interface (SAI) maintainers: - - Olivier Moysan <olivier.moysan@st.com> + - Olivier Moysan <olivier.moysan@foss.st.com> description: The SAI interface (Serial Audio Interface) offers a wide set of audio diff --git a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml index b7f7dc452231..837e830c47ac 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 S/PDIF receiver (SPDIFRX) maintainers: - - Olivier Moysan <olivier.moysan@st.com> + - Olivier Moysan <olivier.moysan@foss.st.com> description: | The SPDIFRX peripheral, is designed to receive an S/PDIF flow compliant with diff --git a/Documentation/devicetree/bindings/sound/test-component.yaml b/Documentation/devicetree/bindings/sound/test-component.yaml new file mode 100644 index 000000000000..17fdb4317239 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/test-component.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/test-component.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Test Component Device Tree Bindings + +maintainers: + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> + +properties: + compatible: + enum: + - test-cpu + - test-cpu-verbose + - test-cpu-verbose-dai + - test-cpu-verbose-component + - test-codec + - test-codec-verbose + - test-codec-verbose-dai + - test-codec-verbose-component + +required: + - compatible + +additionalProperties: true + +examples: + - | + test_cpu { + compatible = "test-cpu"; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8962.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8962.yaml new file mode 100644 index 000000000000..0e6249d7c133 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8962.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8962.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Wolfson WM8962 Ultra-Low Power Stereo CODEC + +maintainers: + - patches@opensource.cirrus.com + +properties: + compatible: + const: wlf,wm8962 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + + AVDD-supply: + description: Analogue supply. + + CPVDD-supply: + description: Charge pump power supply. + + DBVDD-supply: + description: Digital Buffer Supply. + + DCVDD-supply: + description: Digital Core Supply. + + MICVDD-supply: + description: Microphone bias amp supply. + + PLLVDD-supply: + description: PLL Supply + + SPKVDD1-supply: + description: Supply for left speaker drivers. + + SPKVDD2-supply: + description: Supply for right speaker drivers. + + spk-mono: + $ref: /schemas/types.yaml#/definitions/flag + description: + If present, the SPK_MONO bit of R51 (Class D Control 2) gets set, + indicating that the speaker is in mono mode. + + mic-cfg: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Default register value for R48 (Additional Control 4). + If absent, the default should be the register default. + + gpio-cfg: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 6 + maxItems: 6 + description: + A list of GPIO configuration register values. If absent, no + configuration of these registers is performed. Note that only values + within [0x0, 0xffff] are valid. Any other value is regarded as setting + the GPIO register to its reset value 0x0. + + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + +required: + - compatible + - reg + - AVDD-supply + - CPVDD-supply + - DBVDD-supply + - DCVDD-supply + - MICVDD-supply + - PLLVDD-supply + - SPKVDD1-supply + - SPKVDD2-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx6qdl-clock.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + wm8962: codec@1a { + compatible = "wlf,wm8962"; + reg = <0x1a>; + clocks = <&clks IMX6QDL_CLK_CKO>; + DCVDD-supply = <®_audio>; + DBVDD-supply = <®_audio>; + AVDD-supply = <®_audio>; + CPVDD-supply = <®_audio>; + MICVDD-supply = <®_audio>; + PLLVDD-supply = <®_audio>; + SPKVDD1-supply = <®_audio>; + SPKVDD2-supply = <®_audio>; + gpio-cfg = < + 0x0000 /* 0:Default */ + 0x0000 /* 1:Default */ + 0x0013 /* 2:FN_DMICCLK */ + 0x0000 /* 3:Default */ + 0x8014 /* 4:FN_DMICCDAT */ + 0x0000 /* 5:Default */ + >; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8978.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8978.yaml new file mode 100644 index 000000000000..96cf9fc9c8b0 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8978.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8978.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Wolfson WM8978 Codec Device Tree Bindings + +maintainers: + - patches@opensource.cirrus.com + +properties: + '#sound-dai-cells': + const: 0 + + compatible: + const: wlf,wm8978 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 526000 + +required: + - '#sound-dai-cells' + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + codec@0 { + #sound-dai-cells = <0>; + compatible = "wlf,wm8978"; + reg = <0>; + spi-max-frequency = <500000>; + }; + }; + + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@1a { + #sound-dai-cells = <0>; + compatible = "wlf,wm8978"; + reg = <0x1a>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/wm8962.txt b/Documentation/devicetree/bindings/sound/wm8962.txt deleted file mode 100644 index c36c649ddfd0..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8962.txt +++ /dev/null @@ -1,43 +0,0 @@ -WM8962 audio CODEC - -This device supports I2C only. - -Required properties: - - - compatible : "wlf,wm8962" - - - reg : the I2C address of the device. - -Optional properties: - - - clocks : The clock source of the mclk - - - spk-mono: This is a boolean property. If present, the SPK_MONO bit - of R51 (Class D Control 2) gets set, indicating that the speaker is - in mono mode. - - - mic-cfg : Default register value for R48 (Additional Control 4). - If absent, the default should be the register default. - - - gpio-cfg : A list of GPIO configuration register values. The list must - be 6 entries long. If absent, no configuration of these registers is - performed. And note that only the value within [0x0, 0xffff] is valid. - Any other value is regarded as setting the GPIO register by its reset - value 0x0. - -Example: - -wm8962: codec@1a { - compatible = "wlf,wm8962"; - reg = <0x1a>; - clocks = <&clks IMX6QDL_CLK_CKO>; - - gpio-cfg = < - 0x0000 /* 0:Default */ - 0x0000 /* 1:Default */ - 0x0013 /* 2:FN_DMICCLK */ - 0x0000 /* 3:Default */ - 0x8014 /* 4:FN_DMICCDAT */ - 0x0000 /* 5:Default */ - >; -}; diff --git a/Documentation/devicetree/bindings/spi/ingenic,spi.yaml b/Documentation/devicetree/bindings/spi/ingenic,spi.yaml index cf56cc484b19..5b1c7a2a6a31 100644 --- a/Documentation/devicetree/bindings/spi/ingenic,spi.yaml +++ b/Documentation/devicetree/bindings/spi/ingenic,spi.yaml @@ -55,7 +55,7 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/jz4770-cgu.h> + #include <dt-bindings/clock/ingenic,jz4770-cgu.h> spi@10043000 { compatible = "ingenic,jz4770-spi", "ingenic,jz4750-spi"; reg = <0x10043000 0x1c>; diff --git a/Documentation/devicetree/bindings/spi/spi-xlp.txt b/Documentation/devicetree/bindings/spi/spi-xlp.txt deleted file mode 100644 index f4925ec0ed33..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-xlp.txt +++ /dev/null @@ -1,38 +0,0 @@ -SPI Master controller for Netlogic XLP MIPS64 SOCs -================================================== - -Currently this SPI controller driver is supported for the following -Netlogic XLP SoCs: - XLP832, XLP316, XLP208, XLP980, XLP532 - -Required properties: -- compatible : Should be "netlogic,xlp832-spi". -- #address-cells : Number of cells required to define a chip select address - on the SPI bus. -- #size-cells : Should be zero. -- reg : Should contain register location and length. -- clocks : Phandle of the spi clock -- interrupts : Interrupt number used by this controller. - -SPI slave nodes must be children of the SPI master node and can contain -properties described in Documentation/devicetree/bindings/spi/spi-bus.txt. - -Example: - - spi: xlp_spi@3a100 { - compatible = "netlogic,xlp832-spi"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0 0x3a100 0x100>; - clocks = <&spi_clk>; - interrupts = <34>; - interrupt-parent = <&pic>; - - spi_nor@1 { - compatible = "spansion,s25sl12801"; - #address-cells = <1>; - #size-cells = <1>; - reg = <1>; /* Chip Select */ - spi-max-frequency = <40000000>; - }; -}; diff --git a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml index 983c4e54c0be..6ec6f556182f 100644 --- a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml @@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 Quad Serial Peripheral Interface (QSPI) bindings maintainers: - - Christophe Kerello <christophe.kerello@st.com> - - Patrice Chotard <patrice.chotard@st.com> + - Christophe Kerello <christophe.kerello@foss.st.com> + - Patrice Chotard <patrice.chotard@foss.st.com> allOf: - $ref: "spi-controller.yaml#" diff --git a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml index 2d9af4c506bb..3d64bed266ac 100644 --- a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml +++ b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml @@ -13,8 +13,8 @@ description: | from 4 to 32-bit data size. maintainers: - - Erwan Leray <erwan.leray@st.com> - - Fabrice Gasnier <fabrice.gasnier@st.com> + - Erwan Leray <erwan.leray@foss.st.com> + - Fabrice Gasnier <fabrice.gasnier@foss.st.com> allOf: - $ref: "spi-controller.yaml#" diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index 3eda5049d183..d4e418b6a1c1 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml @@ -31,6 +31,7 @@ properties: - amlogic,meson-gxbb-sram - arm,juno-sram-ns - atmel,sama5d2-securam + - qcom,rpm-msg-ram - rockchip,rk3288-pmu-sram reg: @@ -60,7 +61,7 @@ properties: type: boolean patternProperties: - "^([a-z]*-)?sram(-section)?@[a-f0-9]+$": + "^([a-z0-9]*-)?sram(-section)?@[a-f0-9]+$": type: object description: Each child of the sram node specifies a region of reserved memory. @@ -135,7 +136,9 @@ if: properties: compatible: contains: - const: rockchip,rk3288-pmu-sram + enum: + - qcom,rpm-msg-ram + - rockchip,rk3288-pmu-sram else: required: diff --git a/Documentation/devicetree/bindings/submitting-patches.rst b/Documentation/devicetree/bindings/submitting-patches.rst index 8087780f1685..36a17b250ccc 100644 --- a/Documentation/devicetree/bindings/submitting-patches.rst +++ b/Documentation/devicetree/bindings/submitting-patches.rst @@ -63,6 +63,9 @@ I. For patch submitters string that is matched by the driver (as in the "nvidia,tegra20-pcie" example above). + 9) Bindings are actively used by multiple projects other than the Linux + Kernel, extra care and consideration may need to be taken when making changes + to existing bindings. II. For kernel maintainers ========================== diff --git a/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm-hc.yaml b/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm-hc.yaml new file mode 100644 index 000000000000..8273ac55b63f --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm-hc.yaml @@ -0,0 +1,149 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/qcom-spmi-adc-tm-hc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm's SPMI PMIC ADC HC Thermal Monitoring +maintainers: + - Dmitry Baryshkov <dmitry.baryshkov@linaro.org> + +properties: + compatible: + const: qcom,spmi-adc-tm-hc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#thermal-sensor-cells": + const: 1 + description: + Number of cells required to uniquely identify the thermal sensors. Since + we have multiple sensors this is set to 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + qcom,avg-samples: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of samples to be used for measurement. + enum: + - 1 + - 2 + - 4 + - 8 + - 16 + default: 1 + + qcom,decimation: + $ref: /schemas/types.yaml#/definitions/uint32 + description: This parameter is used to decrease ADC sampling rate. + Quicker measurements can be made by reducing decimation ratio. + enum: + - 256 + - 512 + - 1024 + default: 1024 + +patternProperties: + "^([-a-z0-9]*)@[0-7]$": + type: object + description: + Represent one thermal sensor. + + properties: + reg: + description: Specify the sensor channel. There are 8 channels in PMIC5's ADC TM + minimum: 0 + maximum: 7 + + io-channels: + description: + From common IIO binding. Used to pipe PMIC ADC channel to thermal monitor + + qcom,ratiometric: + $ref: /schemas/types.yaml#/definitions/flag + description: + Channel calibration type. + If this property is specified VADC will use the VDD reference + (1.875V) and GND for channel calibration. If property is not found, + channel will be calibrated with 0V and 1.25V reference channels, + also known as absolute calibration. + + qcom,hw-settle-time-us: + description: Time between AMUX getting configured and the ADC starting conversion. + enum: [0, 100, 200, 300, 400, 500, 600, 700, 1000, 2000, 4000, 6000, 8000, 10000] + + qcom,pre-scaling: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Used for scaling the channel input signal before the + signal is fed to VADC. The configuration for this node is to know the + pre-determined ratio and use it for post scaling. It is a pair of + integers, denoting the numerator and denominator of the fraction by + which input signal is multiplied. For example, <1 3> indicates the + signal is scaled down to 1/3 of its value before ADC measurement. If + property is not found default value depending on chip will be used. + items: + - const: 1 + - enum: [ 1, 3, 4, 6, 20, 8, 10 ] + + required: + - reg + - io-channels + + additionalProperties: + false + +required: + - compatible + - reg + - interrupts + - "#address-cells" + - "#size-cells" + - "#thermal-sensor-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/iio/qcom,spmi-vadc.h> + #include <dt-bindings/interrupt-controller/irq.h> + spmi_bus { + #address-cells = <1>; + #size-cells = <0>; + pm8998_adc: adc@3100 { + reg = <0x3100>; + compatible = "qcom,spmi-adc-rev2"; + #address-cells = <1>; + #size-cells = <0>; + #io-channel-cells = <1>; + + /* Other propreties are omitted */ + adc-chan@4c { + reg = <ADC5_XO_THERM_100K_PU>; + }; + }; + + pm8998_adc_tm: adc-tm@3400 { + compatible = "qcom,spmi-adc-tm-hc"; + reg = <0x3400>; + interrupts = <0x2 0x34 0x0 IRQ_TYPE_EDGE_RISING>; + #thermal-sensor-cells = <1>; + #address-cells = <1>; + #size-cells = <0>; + + thermistor@1 { + reg = <1>; + io-channels = <&pm8998_adc ADC5_XO_THERM_100K_PU>; + qcom,ratiometric; + qcom,hw-settle-time-us = <200>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml index b96ea277b558..f6c1be226aaa 100644 --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml @@ -12,14 +12,14 @@ maintainers: properties: compatible: enum: - - rockchip,px30-tsadc # PX30 SoCs - - rockchip,rv1108-tsadc # RV1108 SoCs - - rockchip,rk3228-tsadc # RK3228 SoCs - - rockchip,rk3288-tsadc # RK3288 SoCs - - rockchip,rk3328-tsadc # RK3328 SoCs - - rockchip,rk3368-tsadc # RK3368 SoCs - - rockchip,rk3399-tsadc # RK3399 SoCs - - rockchip,rk3568-tsadc # RK3568 SoCs + - rockchip,px30-tsadc + - rockchip,rk3228-tsadc + - rockchip,rk3288-tsadc + - rockchip,rk3328-tsadc + - rockchip,rk3368-tsadc + - rockchip,rk3399-tsadc + - rockchip,rk3568-tsadc + - rockchip,rv1108-tsadc reg: maxItems: 1 @@ -37,11 +37,15 @@ properties: - const: apb_pclk resets: - maxItems: 1 + minItems: 1 + maxItems: 3 reset-names: + minItems: 1 items: - const: tsadc-apb + - const: tsadc + - const: tsadc-phy "#thermal-sensor-cells": const: 1 @@ -71,7 +75,6 @@ required: - clocks - clock-names - resets - - reset-names - "#thermal-sensor-cells" additionalProperties: false diff --git a/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml index 553c9dcdaeeb..c5b25ce44956 100644 --- a/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml @@ -20,6 +20,7 @@ properties: - socionext,uniphier-pxs2-thermal - socionext,uniphier-ld20-thermal - socionext,uniphier-pxs3-thermal + - socionext,uniphier-nx1-thermal interrupts: maxItems: 1 diff --git a/Documentation/devicetree/bindings/thermal/st,stm32-thermal.yaml b/Documentation/devicetree/bindings/thermal/st,stm32-thermal.yaml index c0f59c56003d..bee41cff5142 100644 --- a/Documentation/devicetree/bindings/thermal/st,stm32-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/st,stm32-thermal.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 digital thermal sensor (DTS) binding maintainers: - - David Hernandez Sanchez <david.hernandezsanchez@st.com> + - Pascal Paillet <p.paillet@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml b/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml index df3eb76045e0..98648bf9e151 100644 --- a/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml +++ b/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml @@ -46,7 +46,7 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/x1000-cgu.h> + #include <dt-bindings/clock/ingenic,x1000-cgu.h> ost: timer@12000000 { compatible = "ingenic,x1000-ost"; diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml index 8165df4599cf..7fb37eae9da7 100644 --- a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml +++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml @@ -237,7 +237,7 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/jz4770-cgu.h> + #include <dt-bindings/clock/ingenic,jz4770-cgu.h> #include <dt-bindings/clock/ingenic,tcu.h> tcu: timer@10002000 { compatible = "ingenic,jz4770-tcu", "ingenic,jz4760-tcu", "simple-mfd"; diff --git a/Documentation/devicetree/bindings/timer/st,stm32-timer.yaml b/Documentation/devicetree/bindings/timer/st,stm32-timer.yaml index 176aa3c9baf8..937aa8a56366 100644 --- a/Documentation/devicetree/bindings/timer/st,stm32-timer.yaml +++ b/Documentation/devicetree/bindings/timer/st,stm32-timer.yaml @@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 general-purpose 16 and 32 bits timers bindings maintainers: - - Benjamin Gaignard <benjamin.gaignard@st.com> + - Fabrice Gasnier <fabrice.gasnier@foss.st.com> + - Patrice Chotard <patrice.chotard@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 1e4b3464d734..791079021f1b 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -41,10 +41,6 @@ properties: - adi,adp5585-02 # Analog Devices ADP5589 Keypad Decoder and I/O Expansion - adi,adp5589 - # +/-1C TDM Extended Temp Range I.C - - adi,adt7461 - # +/-1C TDM Extended Temp Range I.C - - adt7461 # AMS iAQ-Core VOC Sensor - ams,iaq-core # i2c serial eeprom (24cxx) @@ -77,6 +73,8 @@ properties: - dallas,ds4510 # Digital Thermometer and Thermostat - dallas,ds75 + # Delta Electronics DPS-650-AB power supply + - delta,dps650ab # Delta Electronics DPS920AB 920W 54V Power Supply - delta,dps920ab # 1/4 Brick DC/DC Regulated Power Module @@ -113,8 +111,14 @@ properties: - mps,mp2888 # Monolithic Power Systems Inc. multi-phase controller mp2975 - mps,mp2975 - # G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface - - gmt,g751 + # Honeywell Humidicon HIH-6130 humidity/temperature sensor + - honeywell,hi6130 + # IBM Common Form Factor Power Supply Versions (all versions) + - ibm,cffps + # IBM Common Form Factor Power Supply Versions 1 + - ibm,cffps1 + # IBM Common Form Factor Power Supply Versions 2 + - ibm,cffps2 # Infineon IR36021 digital POL buck controller - infineon,ir36021 # Infineon IR38064 Voltage Regulator @@ -307,16 +311,22 @@ properties: - ti,hdc1050 # Temperature and humidity sensor with i2c interface - ti,hdc1080 + # Thermometer with SPI interface + - ti,lm70 + - ti,lm71 # Temperature sensor with 2-wire interface - ti,lm73 + # Thermometer with SPI interface + - ti,lm74 # Temperature sensor with integrated fan control - ti,lm96000 # I2C Touch-Screen Controller - ti,tsc2003 # Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface - - ti,tmp102 - # Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface - ti,tmp103 + # Thermometer with SPI interface + - ti,tmp121 + - ti,tmp122 # Digital Temperature Sensor - ti,tmp275 # TI Dual channel DCAP+ multiphase controller TPS53676 with AVSBus diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml index b9ca8ef4f2be..95ac1c18334d 100644 --- a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml @@ -20,6 +20,8 @@ properties: compatible: enum: - samsung,exynos7-ufs + - samsung,exynosautov9-ufs + - samsung,exynosautov9-ufs-vh reg: items: @@ -54,6 +56,14 @@ properties: phy-names: const: ufs-phy + samsung,sysreg: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + description: Should be phandle/offset pair. The phandle to the syscon node + which indicates the FSYSx sysreg interface and the offset of + the control register for UFS io coherency setting. + + dma-coherent: true + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt index a4002624ba14..f512f0290728 100644 --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt @@ -39,6 +39,10 @@ Required properties: "ehci_clk" for the peripheral clock "usb_clk" for the UTMI clock +Optional properties: + - phy_type : For multi port host USB controllers, should be one of + "utmi", or "hsic". + usb1: ehci@800000 { compatible = "atmel,at91sam9g45-ehci", "usb-ehci"; reg = <0x00800000 0x100000>; diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index 10c7d9b6cc53..56a818478cd7 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -9,6 +9,9 @@ title: DesignWare HS OTG USB 2.0 controller Bindings maintainers: - Rob Herring <robh@kernel.org> +allOf: + - $ref: usb-drd.yaml# + properties: compatible: oneOf: @@ -101,12 +104,15 @@ properties: description: reference to the VBUS and ID sensing comparators supply, in order to perform OTG operation, used on STM32MP15 SoCs. - dr_mode: - enum: [host, peripheral, otg] + dr_mode: true - usb-role-switch: - $ref: /schemas/types.yaml#/definitions/flag - description: Support role switch. + otg-rev: true + + hnp-disable: true + + srp-disable: true + + usb-role-switch: true g-rx-fifo-size: $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml index f506225a4d57..59212358fcce 100644 --- a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml +++ b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml @@ -58,7 +58,7 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/jz4740-cgu.h> + #include <dt-bindings/clock/ingenic,jz4740-cgu.h> usb_phy: usb-phy { compatible = "usb-nop-xceiv"; #phy-cells = <0>; diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index e70afc40edb2..2bdaba023c01 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -13,6 +13,7 @@ properties: compatible: items: - enum: + - qcom,ipq6018-dwc3 - qcom,msm8996-dwc3 - qcom,msm8998-dwc3 - qcom,sc7180-dwc3 diff --git a/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml b/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml new file mode 100644 index 000000000000..39228a506b93 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml @@ -0,0 +1,108 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/smsc,usb3503.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SMSC USB3503 High-Speed Hub Controller Device Tree Bindings + +maintainers: + - Dongjin Kim <tobetter@gmail.com> + +properties: + compatible: + enum: + - smsc,usb3503 + - smsc,usb3503a + + reg: + maxItems: 1 + + connect-gpios: + maxItems: 1 + description: > + GPIO for connect + + intn-gpios: + maxItems: 1 + description: > + GPIO for interrupt + + reset-gpios: + maxItems: 1 + description: > + GPIO for reset + + disabled-ports: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 3 + items: + minimum: 1 + maximum: 3 + description: > + Specifies the ports unused using their port number. Do not describe this + property if all ports have to be enabled. + + initial-mode: + enum: [1, 2] + description: > + Specifies initial mode. 1 for Hub mode, 2 for standby mode. + + clocks: + maxItems: 1 + description: > + Clock used for driving REFCLK signal. If not provided the driver assumes + that clock signal is always available, its rate is specified by REF_SEL + pins and a value from the primary reference clock frequencies table is + used. + + clock-names: + const: refclk + + refclk-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + Frequency of the REFCLK signal as defined by REF_SEL pins. If not + provided, driver will not set rate of the REFCLK signal and assume that a + value from the primary reference clock frequencies table is used. + +required: + - compatible + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + usb-hub@8 { + compatible = "smsc,usb3503"; + reg = <0x08>; + connect-gpios = <&gpx3 0 1>; + disabled-ports = <2 3>; + intn-gpios = <&gpx3 4 1>; + reset-gpios = <&gpx3 5 1>; + initial-mode = <1>; + clocks = <&clks 80>; + clock-names = "refclk"; + }; + }; + + - | + #include <dt-bindings/gpio/gpio.h> + + usb-hub { + /* I2C is not connected */ + compatible = "smsc,usb3503"; + initial-mode = <1>; /* initialize in HUB mode */ + disabled-ports = <1>; + intn-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */ + reset-gpios = <&pio 4 16 GPIO_ACTIVE_LOW>; /* PE16 */ + connect-gpios = <&pio 4 17 GPIO_ACTIVE_HIGH>; /* PE17 */ + refclk-frequency = <19200000>; + }; + +... diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 078fb7889593..25ac2c93dc6c 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -73,15 +73,15 @@ properties: phys: minItems: 1 - items: - - description: USB2/HS PHY - - description: USB3/SS PHY + maxItems: 2 phy-names: minItems: 1 + maxItems: 2 items: - - const: usb2-phy - - const: usb3-phy + enum: + - usb2-phy + - usb3-phy resets: minItems: 1 @@ -252,6 +252,14 @@ properties: minimum: 0 maximum: 0x3f + snps,ref-clock-period-ns: + description: + Value for REFCLKPER field of GUCTL register for reference clock period in + nanoseconds, when the hardware set default does not match the actual + clock. + minimum: 1 + maximum: 0x3ff + snps,rx-thr-num-pkt-prd: description: Periodic ESS RX packet threshold count (host mode only). Set this and diff --git a/Documentation/devicetree/bindings/usb/st,stusb160x.yaml b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml index 9a51efa9d101..ead1571e0e43 100644 --- a/Documentation/devicetree/bindings/usb/st,stusb160x.yaml +++ b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml @@ -7,7 +7,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: STMicroelectronics STUSB160x Type-C controller bindings maintainers: - - Amelie Delaunay <amelie.delaunay@st.com> + - Amelie Delaunay <amelie.delaunay@foss.st.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml index f6819bf2a3b5..a4c53b1f1af3 100644 --- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml +++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml @@ -12,10 +12,14 @@ maintainers: description: | Texas Instruments 6598x Type-C Port Switch and Power Delivery controller + A variant of this controller known as Apple CD321x or Apple ACE is also + present on hardware with Apple SoCs such as the M1. + properties: compatible: enum: - ti,tps6598x + - apple,cd321x reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/usb/udc-xilinx.txt b/Documentation/devicetree/bindings/usb/udc-xilinx.txt deleted file mode 100644 index 47b4e397a08d..000000000000 --- a/Documentation/devicetree/bindings/usb/udc-xilinx.txt +++ /dev/null @@ -1,18 +0,0 @@ -Xilinx USB2 device controller - -Required properties: -- compatible : Should be "xlnx,usb2-device-4.00.a" -- reg : Physical base address and size of the USB2 - device registers map. -- interrupts : Should contain single irq line of USB2 device - controller -- xlnx,has-builtin-dma : if DMA is included - -Example: - axi-usb2-device@42e00000 { - compatible = "xlnx,usb2-device-4.00.a"; - interrupts = <0x0 0x39 0x1>; - reg = <0x42e00000 0x10000>; - xlnx,has-builtin-dma; - }; - diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt deleted file mode 100644 index 057dd384d473..000000000000 --- a/Documentation/devicetree/bindings/usb/usb3503.txt +++ /dev/null @@ -1,39 +0,0 @@ -SMSC USB3503 High-Speed Hub Controller - -Required properties: -- compatible: Should be "smsc,usb3503" or "smsc,usb3503a". - -Optional properties: -- reg: Specifies the i2c slave address, it is required and should be 0x08 - if I2C is used. -- connect-gpios: Should specify GPIO for connect. -- disabled-ports: Should specify the ports unused. - '1' or '2' or '3' are available for this property to describe the port - number. 1~3 property values are possible to be described. - Do not describe this property if all ports have to be enabled. -- intn-gpios: Should specify GPIO for interrupt. -- reset-gpios: Should specify GPIO for reset. -- initial-mode: Should specify initial mode. - (1 for HUB mode, 2 for STANDBY mode) -- refclk: Clock used for driving REFCLK signal (optional, if not provided - the driver assumes that clock signal is always available, its - rate is specified by REF_SEL pins and a value from the primary - reference clock frequencies table is used). Use clocks and - clock-names in order to assign it -- refclk-frequency: Frequency of the REFCLK signal as defined by REF_SEL - pins (optional, if not provided, driver will not set rate of the - REFCLK signal and assume that a value from the primary reference - clock frequencies table is used) - -Examples: - usb3503@8 { - compatible = "smsc,usb3503"; - reg = <0x08>; - connect-gpios = <&gpx3 0 1>; - disabled-ports = <2 3>; - intn-gpios = <&gpx3 4 1>; - reset-gpios = <&gpx3 5 1>; - initial-mode = <1>; - clocks = <&clks 80>; - clock-names = "refclk"; - }; diff --git a/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml b/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml new file mode 100644 index 000000000000..04c123c7252a --- /dev/null +++ b/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/xlnx,usb2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx udc controller + +maintainers: + - Manish Narani <manish.narani@xilinx.com> + +properties: + compatible: + const: xlnx,usb2-device-4.00.a + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + xlnx,has-builtin-dma: + description: + If present, hardware has dma capability. + type: boolean + + clocks: + minItems: 1 + + clock-names: + const: s_axi_aclk + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + axi-usb2-device@42e00000 { + compatible = "xlnx,usb2-device-4.00.a"; + interrupts = <0x0 0x39 0x1>; + reg = <0xee000000 0xc00>; + xlnx,has-builtin-dma; + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index a867f7102c35..66d6432fd781 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -131,6 +131,8 @@ patternProperties: description: Asahi Kasei Corp. "^asc,.*": description: All Sensors Corporation + "^asix,.*": + description: ASIX Electronics Corporation "^aspeed,.*": description: ASPEED Technology Inc. "^asus,.*": @@ -191,6 +193,8 @@ patternProperties: description: B&R Industrial Automation GmbH "^bticino,.*": description: Bticino International + "^calamp,.*": + description: CalAmp Corp. "^calaosystems,.*": description: CALAO Systems SAS "^calxeda,.*": @@ -335,6 +339,8 @@ patternProperties: description: EBV Elektronik "^eckelmann,.*": description: Eckelmann AG + "^edimax,.*": + description: EDIMAX Technology Co., Ltd "^edt,.*": description: Emerging Display Technologies "^eeti,.*": @@ -353,6 +359,8 @@ patternProperties: description: Shenzhen Elida Technology Co., Ltd. "^elimo,.*": description: Elimo Engineering Ltd. + "^elpida,.*": + description: Elpida Memory, Inc. "^embest,.*": description: Shenzhen Embest Technology Co., Ltd. "^emlid,.*": @@ -395,6 +403,8 @@ patternProperties: description: Exar Corporation "^excito,.*": description: Excito + "^exegin,.*": + description: Exegin Technologies Limited "^ezchip,.*": description: EZchip Semiconductor "^facebook,.*": @@ -509,6 +519,8 @@ patternProperties: description: Hycon Technology Corp. "^hydis,.*": description: Hydis Technologies + "^hynix,.*": + description: SK Hynix Inc. "^hyundai,.*": description: Hyundai Technology "^i2se,.*": @@ -577,6 +589,8 @@ patternProperties: description: JEDEC Solid State Technology Association "^jesurun,.*": description: Shenzhen Jesurun Electronics Business Dept. + "^jethome,.*": + description: JetHome (IP Sokolov P.A.) "^jianda,.*": description: Jiandangjing Technology Co., Ltd. "^kam,.*": @@ -653,6 +667,8 @@ patternProperties: description: Linux-specific binding "^linx,.*": description: Linx Technologies + "^liteon,.*": + description: LITE-ON Technology Corp. "^litex,.*": description: LiteX SoC builder "^lltc,.*": @@ -1018,6 +1034,8 @@ patternProperties: description: Shenzhen SEI Robotics Co., Ltd "^semtech,.*": description: Semtech Corporation + "^senseair,.*": + description: Senseair AB "^sensirion,.*": description: Sensirion AG "^sensortek,.*": @@ -1100,8 +1118,12 @@ patternProperties: description: Spansion Inc. "^sparkfun,.*": description: SparkFun Electronics + "^spinalhdl,.*": + description: SpinalHDL "^sprd,.*": description: Spreadtrum Communications Inc. + "^ssi,.*": + description: SSI Computer Corp "^sst,.*": description: Silicon Storage Technology, Inc. "^sstar,.*": @@ -1264,6 +1286,8 @@ patternProperties: description: Vitesse Semiconductor Corporation "^vivante,.*": description: Vivante Corporation + "^vivax,.*": + description: Vivax brand by M SAN Grupa d.o.o. "^vocore,.*": description: VoCore Studio "^voipac,.*": diff --git a/Documentation/devicetree/bindings/w1/w1-gpio.txt b/Documentation/devicetree/bindings/w1/w1-gpio.txt deleted file mode 100644 index 3d6554eac240..000000000000 --- a/Documentation/devicetree/bindings/w1/w1-gpio.txt +++ /dev/null @@ -1,27 +0,0 @@ -w1-gpio devicetree bindings - -Required properties: - - - compatible: "w1-gpio" - - gpios: one or two GPIO specs: - - the first one is used as data I/O pin - - the second one is optional. If specified, it is used as - enable pin for an external pin pullup. - -Optional properties: - - - linux,open-drain: if specified, the data pin is considered in - open-drain mode. - -Also refer to the generic w1.txt document. - -Examples: - - onewire { - compatible = "w1-gpio"; - gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; - - battery { - // ... - }; - }; diff --git a/Documentation/devicetree/bindings/w1/w1-gpio.yaml b/Documentation/devicetree/bindings/w1/w1-gpio.yaml new file mode 100644 index 000000000000..8eef2380161b --- /dev/null +++ b/Documentation/devicetree/bindings/w1/w1-gpio.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/w1/w1-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bitbanged GPIO 1-Wire Bus Device Tree Bindings + +maintainers: + - Daniel Mack <zonque@gmail.com> + +properties: + compatible: + const: w1-gpio + + gpios: + minItems: 1 + items: + - description: Data I/O pin + - description: Enable pin for an external pull-up resistor + + linux,open-drain: + type: boolean + description: > + If specified, the data pin is considered in open-drain mode. + +required: + - compatible + - gpios + +additionalProperties: + type: object + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + onewire { + compatible = "w1-gpio"; + gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; + }; + +... diff --git a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml index 9aa3c313c49f..43afa24513b9 100644 --- a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml @@ -24,16 +24,31 @@ properties: - allwinner,sun50i-a100-wdt - allwinner,sun50i-h6-wdt - allwinner,sun50i-h616-wdt + - allwinner,sun50i-r329-wdt + - allwinner,sun50i-r329-wdt-reset - const: allwinner,sun6i-a31-wdt - items: - const: allwinner,suniv-f1c100s-wdt - const: allwinner,sun4i-a10-wdt + - const: allwinner,sun20i-d1-wdt + - items: + - const: allwinner,sun20i-d1-wdt-reset + - const: allwinner,sun20i-d1-wdt reg: maxItems: 1 clocks: - maxItems: 1 + minItems: 1 + items: + - description: High-frequency oscillator input, divided internally + - description: Low-frequency oscillator input, only found on some variants + + clock-names: + minItems: 1 + items: + - const: hosc + - const: losc interrupts: maxItems: 1 @@ -44,6 +59,35 @@ required: - clocks - interrupts +if: + properties: + compatible: + contains: + enum: + - allwinner,sun20i-d1-wdt + - allwinner,sun20i-d1-wdt-reset + - allwinner,sun50i-r329-wdt + - allwinner,sun50i-r329-wdt-reset + +then: + properties: + clocks: + minItems: 2 + + clock-names: + minItems: 2 + + required: + - clock-names + +else: + properties: + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index a4e31ce96e0e..0114871f887a 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -22,6 +22,7 @@ Required properties: - reg : Specifies base physical address and size of the registers. Optional properties: +- mediatek,disable-extrst: disable send output reset signal - interrupts: Watchdog pre-timeout (bark) interrupt. - timeout-sec: contains the watchdog timeout in seconds. - #reset-cells: Should be 1. @@ -31,6 +32,7 @@ Example: watchdog: watchdog@10007000 { compatible = "mediatek,mt8183-wdt", "mediatek,mt6589-wdt"; + mediatek,disable-extrst; reg = <0 0x10007000 0 0x100>; interrupts = <GIC_SPI 139 IRQ_TYPE_NONE>; timeout-sec = <10>; diff --git a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml index 481bf91f988a..39736449ba64 100644 --- a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml +++ b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml @@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 Independent WatchDoG (IWDG) bindings maintainers: - - Yannick Fertre <yannick.fertre@st.com> - - Christophe Roullier <christophe.roullier@st.com> + - Yannick Fertre <yannick.fertre@foss.st.com> + - Christophe Roullier <christophe.roullier@foss.st.com> allOf: - $ref: "watchdog.yaml#" diff --git a/Documentation/devicetree/bindings/writing-bindings.rst b/Documentation/devicetree/bindings/writing-bindings.rst index f7dfb98c156e..18d9e0689d49 100644 --- a/Documentation/devicetree/bindings/writing-bindings.rst +++ b/Documentation/devicetree/bindings/writing-bindings.rst @@ -44,7 +44,7 @@ Properties of prior implementations. DO add new compatibles in case there are new features or bugs. -- DO use a vendor prefix on device specific property names. Consider if +- DO use a vendor prefix on device-specific property names. Consider if properties could be common among devices of the same class. Check other existing bindings for similar devices. diff --git a/Documentation/devicetree/bindings/writing-schema.rst b/Documentation/devicetree/bindings/writing-schema.rst index 23d6579aea2c..ea21c72aeb37 100644 --- a/Documentation/devicetree/bindings/writing-schema.rst +++ b/Documentation/devicetree/bindings/writing-schema.rst @@ -4,7 +4,7 @@ Writing Devicetree Bindings in json-schema ========================================== Devicetree bindings are written using json-schema vocabulary. Schema files are -written in a JSON compatible subset of YAML. YAML is used instead of JSON as it +written in a JSON-compatible subset of YAML. YAML is used instead of JSON as it is considered more human readable and has some advantages such as allowing comments (Prefixed with '#'). @@ -22,16 +22,16 @@ $id URI typically containing the binding's filename and path. For DT schema, it must begin with "http://devicetree.org/schemas/". The URL is used in constructing references to other files specified in schema "$ref" properties. A $ref value - with a leading '/' will have the hostname prepended. A $ref value a relative - path or filename only will be prepended with the hostname and path components - of the current schema file's '$id' value. A URL is used even for local files, - but there may not actually be files present at those locations. + with a leading '/' will have the hostname prepended. A $ref value with only a + relative path or filename will be prepended with the hostname and path + components of the current schema file's '$id' value. A URL is used even for + local files, but there may not actually be files present at those locations. $schema Indicates the meta-schema the schema file adheres to. title - A one line description on the contents of the binding schema. + A one-line description on the contents of the binding schema. maintainers A DT specific property. Contains a list of email address(es) @@ -45,8 +45,8 @@ description select Optional. A json-schema used to match nodes for applying the - schema. By default without 'select', nodes are matched against their possible - compatible string values or node name. Most bindings should not need select. + schema. By default, without 'select', nodes are matched against their possible + compatible-string values or node name. Most bindings should not need select. allOf Optional. A list of other schemas to include. This is used to @@ -56,7 +56,8 @@ allOf properties A set of sub-schema defining all the DT properties for the binding. The exact schema syntax depends on whether properties are known, - common properties (e.g. 'interrupts') or are binding/vendor specific properties. + common properties (e.g. 'interrupts') or are binding/vendor-specific + properties. A property can also define a child DT node with child properties defined under it. @@ -81,23 +82,23 @@ Property Schema The 'properties' section of the schema contains all the DT properties for a binding. Each property contains a set of constraints using json-schema -vocabulary for that property. The properties schemas are what is used for +vocabulary for that property. The properties schemas are what are used for validation of DT files. -For common properties, only additional constraints not covered by the common +For common properties, only additional constraints not covered by the common, binding schema need to be defined such as how many values are valid or what possible values are valid. -Vendor specific properties will typically need more detailed schema. With the +Vendor-specific properties will typically need more detailed schema. With the exception of boolean properties, they should have a reference to a type in schemas/types.yaml. A "description" property is always required. -The Devicetree schemas don't exactly match the YAML encoded DT data produced by +The Devicetree schemas don't exactly match the YAML-encoded DT data produced by dtc. They are simplified to make them more compact and avoid a bunch of boilerplate. The tools process the schema files to produce the final schema for validation. There are currently 2 transformations the tools perform. -The default for arrays in json-schema is they are variable sized and allow more +The default for arrays in json-schema is they are variable-sized and allow more entries than explicitly defined. This can be restricted by defining 'minItems', 'maxItems', and 'additionalItems'. However, for DeviceTree Schemas, a fixed size is desired in most cases, so these properties are added based on the diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst index ec3e71f56009..e445cb146efe 100644 --- a/Documentation/doc-guide/sphinx.rst +++ b/Documentation/doc-guide/sphinx.rst @@ -27,7 +27,7 @@ Sphinx Install ============== The ReST markups currently used by the Documentation/ files are meant to be -built with ``Sphinx`` version 1.3 or higher. +built with ``Sphinx`` version 1.7 or higher. There's a script that checks for the Sphinx requirements. Please see :ref:`sphinx-pre-install` for further details. @@ -43,10 +43,6 @@ or ``virtualenv``, depending on how your distribution packaged Python 3. .. note:: - #) Sphinx versions below 1.5 don't work properly with Python's - docutils version 0.13.1 or higher. So, if you're willing to use - those versions, you should run ``pip install 'docutils==0.12'``. - #) It is recommended to use the RTD theme for html output. Depending on the Sphinx version, it should be installed separately, with ``pip install sphinx_rtd_theme``. @@ -55,13 +51,13 @@ or ``virtualenv``, depending on how your distribution packaged Python 3. those expressions are written using LaTeX notation. It needs texlive installed with amsfonts and amsmath in order to evaluate them. -In summary, if you want to install Sphinx version 1.7.9, you should do:: +In summary, if you want to install Sphinx version 2.4.4, you should do:: - $ virtualenv sphinx_1.7.9 - $ . sphinx_1.7.9/bin/activate - (sphinx_1.7.9) $ pip install -r Documentation/sphinx/requirements.txt + $ virtualenv sphinx_2.4.4 + $ . sphinx_2.4.4/bin/activate + (sphinx_2.4.4) $ pip install -r Documentation/sphinx/requirements.txt -After running ``. sphinx_1.7.9/bin/activate``, the prompt will change, +After running ``. sphinx_2.4.4/bin/activate``, the prompt will change, in order to indicate that you're using the new environment. If you open a new shell, you need to rerun this command to enter again at the virtual environment before building the documentation. @@ -81,7 +77,7 @@ output. PDF and LaTeX builds -------------------- -Such builds are currently supported only with Sphinx versions 1.4 and higher. +Such builds are currently supported only with Sphinx versions 2.4 and higher. For PDF and LaTeX output, you'll also need ``XeLaTeX`` version 3.14159265. @@ -104,8 +100,8 @@ command line options for your distro:: You should run: sudo dnf install -y texlive-luatex85 - /usr/bin/virtualenv sphinx_1.7.9 - . sphinx_1.7.9/bin/activate + /usr/bin/virtualenv sphinx_2.4.4 + . sphinx_2.4.4/bin/activate pip install -r Documentation/sphinx/requirements.txt Can't build as 1 mandatory dependency is missing at ./scripts/sphinx-pre-install line 468. diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index 50ebcda17ad0..3b8f41395f6b 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -39,12 +39,18 @@ CXL Core .. kernel-doc:: drivers/cxl/core/bus.c :doc: cxl core +.. kernel-doc:: drivers/cxl/core/bus.c + :identifiers: + .. kernel-doc:: drivers/cxl/core/pmem.c :doc: cxl pmem .. kernel-doc:: drivers/cxl/core/regs.c :doc: cxl registers +.. kernel-doc:: drivers/cxl/core/mbox.c + :doc: cxl mbox + External Interfaces =================== diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index f5ac4c90b237..2cd7db82d9fe 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -176,12 +176,6 @@ DMA Fences Functions Reference .. kernel-doc:: include/linux/dma-fence.h :internal: -Seqno Hardware Fences -~~~~~~~~~~~~~~~~~~~~~ - -.. kernel-doc:: include/linux/seqno-fence.h - :internal: - DMA Fence Array ~~~~~~~~~~~~~~~ diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index 650096523f4f..148e19381b79 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -287,6 +287,7 @@ IIO devm_iio_device_register() devm_iio_dmaengine_buffer_setup() devm_iio_kfifo_buffer_setup() + devm_iio_map_array_register() devm_iio_triggered_buffer_setup() devm_iio_trigger_alloc() devm_iio_trigger_register() diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst index 64fe7db080e5..1b487a331467 100644 --- a/Documentation/driver-api/generic-counter.rst +++ b/Documentation/driver-api/generic-counter.rst @@ -223,19 +223,6 @@ whether an input line is differential or single-ended) and instead focus on the core idea of what the data and process represent (e.g. position as interpreted from quadrature encoding data). -Userspace Interface -=================== - -Several sysfs attributes are generated by the Generic Counter interface, -and reside under the /sys/bus/counter/devices/counterX directory, where -counterX refers to the respective counter device. Please see -Documentation/ABI/testing/sysfs-bus-counter for detailed -information on each Generic Counter interface sysfs attribute. - -Through these sysfs attributes, programs and scripts may interact with -the Generic Counter paradigm Counts, Signals, and Synapses of respective -counter devices. - Driver API ========== @@ -247,11 +234,14 @@ for defining a counter device. .. kernel-doc:: include/linux/counter.h :internal: -.. kernel-doc:: drivers/counter/counter.c +.. kernel-doc:: drivers/counter/counter-core.c + :export: + +.. kernel-doc:: drivers/counter/counter-chrdev.c :export: -Implementation -============== +Driver Implementation +===================== To support a counter device, a driver must first allocate the available Counter Signals via counter_signal structures. These Signals should @@ -267,25 +257,61 @@ respective counter_count structure. These counter_count structures are set to the counts array member of an allocated counter_device structure before the Counter is registered to the system. -Driver callbacks should be provided to the counter_device structure via -a constant counter_ops structure in order to communicate with the -device: to read and write various Signals and Counts, and to set and get -the "action mode" and "function mode" for various Synapses and Counts -respectively. +Driver callbacks must be provided to the counter_device structure in +order to communicate with the device: to read and write various Signals +and Counts, and to set and get the "action mode" and "function mode" for +various Synapses and Counts respectively. A defined counter_device structure may be registered to the system by passing it to the counter_register function, and unregistered by passing it to the counter_unregister function. Similarly, the -devm_counter_register and devm_counter_unregister functions may be used -if device memory-managed registration is desired. - -Extension sysfs attributes can be created for auxiliary functionality -and data by passing in defined counter_device_ext, counter_count_ext, -and counter_signal_ext structures. In these cases, the -counter_device_ext structure is used for global/miscellaneous exposure -and configuration of the respective Counter device, while the -counter_count_ext and counter_signal_ext structures allow for auxiliary -exposure and configuration of a specific Count or Signal respectively. +devm_counter_register function may be used if device memory-managed +registration is desired. + +The struct counter_comp structure is used to define counter extensions +for Signals, Synapses, and Counts. + +The "type" member specifies the type of high-level data (e.g. BOOL, +COUNT_DIRECTION, etc.) handled by this extension. The "``*_read``" and +"``*_write``" members can then be set by the counter device driver with +callbacks to handle that data using native C data types (i.e. u8, u64, +etc.). + +Convenience macros such as ``COUNTER_COMP_COUNT_U64`` are provided for +use by driver authors. In particular, driver authors are expected to use +the provided macros for standard Counter subsystem attributes in order +to maintain a consistent interface for userspace. For example, a counter +device driver may define several standard attributes like so:: + + struct counter_comp count_ext[] = { + COUNTER_COMP_DIRECTION(count_direction_read), + COUNTER_COMP_ENABLE(count_enable_read, count_enable_write), + COUNTER_COMP_CEILING(count_ceiling_read, count_ceiling_write), + }; + +This makes it simple to see, add, and modify the attributes that are +supported by this driver ("direction", "enable", and "ceiling") and to +maintain this code without getting lost in a web of struct braces. + +Callbacks must match the function type expected for the respective +component or extension. These function types are defined in the struct +counter_comp structure as the "``*_read``" and "``*_write``" union +members. + +The corresponding callback prototypes for the extensions mentioned in +the previous example above would be:: + + int count_direction_read(struct counter_device *counter, + struct counter_count *count, + enum counter_count_direction *direction); + int count_enable_read(struct counter_device *counter, + struct counter_count *count, u8 *enable); + int count_enable_write(struct counter_device *counter, + struct counter_count *count, u8 enable); + int count_ceiling_read(struct counter_device *counter, + struct counter_count *count, u64 *ceiling); + int count_ceiling_write(struct counter_device *counter, + struct counter_count *count, u64 ceiling); Determining the type of extension to create is a matter of scope. @@ -313,52 +339,235 @@ Determining the type of extension to create is a matter of scope. chip overheated via a device extension called "error_overtemp": /sys/bus/counter/devices/counterX/error_overtemp -Architecture -============ - -When the Generic Counter interface counter module is loaded, the -counter_init function is called which registers a bus_type named -"counter" to the system. Subsequently, when the module is unloaded, the -counter_exit function is called which unregisters the bus_type named -"counter" from the system. +Subsystem Architecture +====================== + +Counter drivers pass and take data natively (i.e. ``u8``, ``u64``, etc.) +and the shared counter module handles the translation between the sysfs +interface. This guarantees a standard userspace interface for all +counter drivers, and enables a Generic Counter chrdev interface via a +generalized device driver ABI. + +A high-level view of how a count value is passed down from a counter +driver is exemplified by the following. The driver callbacks are first +registered to the Counter core component for use by the Counter +userspace interface components:: + + Driver callbacks registration: + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +----------------------------+ + | Counter device driver | + +----------------------------+ + | Processes data from device | + +----------------------------+ + | + ------------------- + / driver callbacks / + ------------------- + | + V + +----------------------+ + | Counter core | + +----------------------+ + | Routes device driver | + | callbacks to the | + | userspace interfaces | + +----------------------+ + | + ------------------- + / driver callbacks / + ------------------- + | + +---------------+---------------+ + | | + V V + +--------------------+ +---------------------+ + | Counter sysfs | | Counter chrdev | + +--------------------+ +---------------------+ + | Translates to the | | Translates to the | + | standard Counter | | standard Counter | + | sysfs output | | character device | + +--------------------+ +---------------------+ + +Thereafter, data can be transferred directly between the Counter device +driver and Counter userspace interface:: + + Count data request: + ~~~~~~~~~~~~~~~~~~~ + ---------------------- + / Counter device \ + +----------------------+ + | Count register: 0x28 | + +----------------------+ + | + ----------------- + / raw count data / + ----------------- + | + V + +----------------------------+ + | Counter device driver | + +----------------------------+ + | Processes data from device | + |----------------------------| + | Type: u64 | + | Value: 42 | + +----------------------------+ + | + ---------- + / u64 / + ---------- + | + +---------------+---------------+ + | | + V V + +--------------------+ +---------------------+ + | Counter sysfs | | Counter chrdev | + +--------------------+ +---------------------+ + | Translates to the | | Translates to the | + | standard Counter | | standard Counter | + | sysfs output | | character device | + |--------------------| |---------------------| + | Type: const char * | | Type: u64 | + | Value: "42" | | Value: 42 | + +--------------------+ +---------------------+ + | | + --------------- ----------------------- + / const char * / / struct counter_event / + --------------- ----------------------- + | | + | V + | +-----------+ + | | read | + | +-----------+ + | \ Count: 42 / + | ----------- + | + V + +--------------------------------------------------+ + | `/sys/bus/counter/devices/counterX/countY/count` | + +--------------------------------------------------+ + \ Count: "42" / + -------------------------------------------------- + +There are four primary components involved: + +Counter device driver +--------------------- +Communicates with the hardware device to read/write data; e.g. counter +drivers for quadrature encoders, timers, etc. + +Counter core +------------ +Registers the counter device driver to the system so that the respective +callbacks are called during userspace interaction. + +Counter sysfs +------------- +Translates counter data to the standard Counter sysfs interface format +and vice versa. + +Please refer to the ``Documentation/ABI/testing/sysfs-bus-counter`` file +for a detailed breakdown of the available Generic Counter interface +sysfs attributes. + +Counter chrdev +-------------- +Translates Counter events to the standard Counter character device; data +is transferred via standard character device read calls, while Counter +events are configured via ioctl calls. + +Sysfs Interface +=============== -Counter devices are registered to the system via the counter_register -function, and later removed via the counter_unregister function. The -counter_register function establishes a unique ID for the Counter -device and creates a respective sysfs directory, where X is the -mentioned unique ID: - - /sys/bus/counter/devices/counterX - -Sysfs attributes are created within the counterX directory to expose -functionality, configurations, and data relating to the Counts, Signals, -and Synapses of the Counter device, as well as options and information -for the Counter device itself. - -Each Signal has a directory created to house its relevant sysfs -attributes, where Y is the unique ID of the respective Signal: - - /sys/bus/counter/devices/counterX/signalY - -Similarly, each Count has a directory created to house its relevant -sysfs attributes, where Y is the unique ID of the respective Count: - - /sys/bus/counter/devices/counterX/countY - -For a more detailed breakdown of the available Generic Counter interface -sysfs attributes, please refer to the -Documentation/ABI/testing/sysfs-bus-counter file. +Several sysfs attributes are generated by the Generic Counter interface, +and reside under the ``/sys/bus/counter/devices/counterX`` directory, +where ``X`` is to the respective counter device id. Please see +``Documentation/ABI/testing/sysfs-bus-counter`` for detailed information +on each Generic Counter interface sysfs attribute. -The Signals and Counts associated with the Counter device are registered -to the system as well by the counter_register function. The -signal_read/signal_write driver callbacks are associated with their -respective Signal attributes, while the count_read/count_write and -function_get/function_set driver callbacks are associated with their -respective Count attributes; similarly, the same is true for the -action_get/action_set driver callbacks and their respective Synapse -attributes. If a driver callback is left undefined, then the respective -read/write permission is left disabled for the relevant attributes. +Through these sysfs attributes, programs and scripts may interact with +the Generic Counter paradigm Counts, Signals, and Synapses of respective +counter devices. -Similarly, extension sysfs attributes are created for the defined -counter_device_ext, counter_count_ext, and counter_signal_ext -structures that are passed in. +Counter Character Device +======================== + +Counter character device nodes are created under the ``/dev`` directory +as ``counterX``, where ``X`` is the respective counter device id. +Defines for the standard Counter data types are exposed via the +userspace ``include/uapi/linux/counter.h`` file. + +Counter events +-------------- +Counter device drivers can support Counter events by utilizing the +``counter_push_event`` function:: + + void counter_push_event(struct counter_device *const counter, const u8 event, + const u8 channel); + +The event id is specified by the ``event`` parameter; the event channel +id is specified by the ``channel`` parameter. When this function is +called, the Counter data associated with the respective event is +gathered, and a ``struct counter_event`` is generated for each datum and +pushed to userspace. + +Counter events can be configured by users to report various Counter +data of interest. This can be conceptualized as a list of Counter +component read calls to perform. For example: + + +------------------------+------------------------+ + | COUNTER_EVENT_OVERFLOW | COUNTER_EVENT_INDEX | + +========================+========================+ + | Channel 0 | Channel 0 | + +------------------------+------------------------+ + | * Count 0 | * Signal 0 | + | * Count 1 | * Signal 0 Extension 0 | + | * Signal 3 | * Extension 4 | + | * Count 4 Extension 2 +------------------------+ + | * Signal 5 Extension 0 | Channel 1 | + | +------------------------+ + | | * Signal 4 | + | | * Signal 4 Extension 0 | + | | * Count 7 | + +------------------------+------------------------+ + +When ``counter_push_event(counter, COUNTER_EVENT_INDEX, 1)`` is called +for example, it will go down the list for the ``COUNTER_EVENT_INDEX`` +event channel 1 and execute the read callbacks for Signal 4, Signal 4 +Extension 0, and Count 7 -- the data returned for each is pushed to a +kfifo as a ``struct counter_event``, which userspace can retrieve via a +standard read operation on the respective character device node. + +Userspace +--------- +Userspace applications can configure Counter events via ioctl operations +on the Counter character device node. There following ioctl codes are +supported and provided by the ``linux/counter.h`` userspace header file: + +* :c:macro:`COUNTER_ADD_WATCH_IOCTL` + +* :c:macro:`COUNTER_ENABLE_EVENTS_IOCTL` + +* :c:macro:`COUNTER_DISABLE_EVENTS_IOCTL` + +To configure events to gather Counter data, users first populate a +``struct counter_watch`` with the relevant event id, event channel id, +and the information for the desired Counter component from which to +read, and then pass it via the ``COUNTER_ADD_WATCH_IOCTL`` ioctl +command. + +Note that an event can be watched without gathering Counter data by +setting the ``component.type`` member equal to +``COUNTER_COMPONENT_NONE``. With this configuration the Counter +character device will simply populate the event timestamps for those +respective ``struct counter_event`` elements and ignore the component +value. + +The ``COUNTER_ADD_WATCH_IOCTL`` command will buffer these Counter +watches. When ready, the ``COUNTER_ENABLE_EVENTS_IOCTL`` ioctl command +may be used to activate these Counter watches. + +Userspace applications can then execute a ``read`` operation (optionally +calling ``poll`` first) on the Counter character device node to retrieve +``struct counter_event`` elements with the desired data. diff --git a/Documentation/driver-api/ipmi.rst b/Documentation/driver-api/ipmi.rst index bc281f10ce4b..e224e47b6b09 100644 --- a/Documentation/driver-api/ipmi.rst +++ b/Documentation/driver-api/ipmi.rst @@ -166,8 +166,8 @@ and the type is IPMI_SYSTEM_INTERFACE_ADDR_TYPE. This is used for talking straight to the BMC on the current card. The channel must be IPMI_BMC_CHANNEL. -Messages that are destined to go out on the IPMB bus use the -IPMI_IPMB_ADDR_TYPE address type. The format is:: +Messages that are destined to go out on the IPMB bus going through the +BMC use the IPMI_IPMB_ADDR_TYPE address type. The format is:: struct ipmi_ipmb_addr { @@ -181,6 +181,23 @@ The "channel" here is generally zero, but some devices support more than one channel, it corresponds to the channel as defined in the IPMI spec. +There is also an IPMB direct address for a situation where the sender +is directly on an IPMB bus and doesn't have to go through the BMC. +You can send messages to a specific management controller (MC) on the +IPMB using the IPMI_IPMB_DIRECT_ADDR_TYPE with the following format:: + + struct ipmi_ipmb_direct_addr + { + int addr_type; + short channel; + unsigned char slave_addr; + unsigned char rq_lun; + unsigned char rs_lun; + }; + +The channel is always zero. You can also receive commands from other +MCs that you have registered to handle and respond to them, so you can +use this to implement a management controller on a bus.. Messages -------- @@ -348,6 +365,10 @@ user may be registered for each netfn/cmd/channel, but different users may register for different commands, or the same command if the channel bitmasks do not overlap. +To respond to a received command, set the response bit in the returned +netfn, use the address from the received message, and use the same +msgid that you got in the receive message. + From userland, equivalent IOCTLs are provided to do these functions. @@ -570,6 +591,45 @@ web page. The driver supports a hot add and remove of interfaces through the I2C sysfs interface. +The IPMI IPMB Driver +-------------------- + +This driver is for supporting a system that sits on an IPMB bus; it +allows the interface to look like a normal IPMI interface. Sending +system interface addressed messages to it will cause the message to go +to the registered BMC on the system (default at IPMI address 0x20). + +It also allows you to directly address other MCs on the bus using the +ipmb direct addressing. You can receive commands from other MCs on +the bus and they will be handled through the normal received command +mechanism described above. + +Parameters are:: + + ipmi_ipmb.bmcaddr=<address to use for system interface addresses messages> + ipmi_ipmb.retry_time_ms=<Time between retries on IPMB> + ipmi_ipmb.max_retries=<Number of times to retry a message> + +Loading the module will not result in the driver automatcially +starting unless there is device tree information setting it up. If +you want to instantiate one of these by hand, do:: + + echo ipmi-ipmb <addr> > /sys/class/i2c-dev/i2c-<n>/device/new_device + +Note that the address you give here is the I2C address, not the IPMI +address. So if you want your MC address to be 0x60, you put 0x30 +here. See the I2C driver info for more details. + +Command bridging to other IPMB busses through this interface does not +work. The receive message queue is not implemented, by design. There +is only one receive message queue on a BMC, and that is meant for the +host drivers, not something on the IPMB bus. + +A BMC may have multiple IPMB busses, which bus your device sits on +depends on how the system is wired. You can fetch the channels with +"ipmitool channel info <n>" where <n> is the channel, with the +channels being 0-7 and try the IPMB channels. + Other Pieces ------------ diff --git a/Documentation/driver-api/media/drivers/rkisp1.rst b/Documentation/driver-api/media/drivers/rkisp1.rst new file mode 100644 index 000000000000..ea336958a3af --- /dev/null +++ b/Documentation/driver-api/media/drivers/rkisp1.rst @@ -0,0 +1,43 @@ +.. SPDX-License-Identifier: GPL-2.0 + +The Rockchip Image Signal Processor Driver (rkisp1) +=================================================== + +Versions and their differences +------------------------------ + +The rkisp1 block underwent some changes between SoC implementations. +The vendor designates them as: + +- V10: used at least in rk3288 and rk3399 +- V11: declared in the original vendor code, but not used +- V12: used at least in rk3326 and px30 +- V13: used at least in rk1808 +- V20: used in rk3568 and beyond + +Right now the kernel supports rkisp1 implementations based +on V10 and V12 variants. V11 does not seem to be actually used +and V13 will need some more additions but isn't researched yet, +especially as it seems to be limited to the rk1808 which hasn't +reached much market spread. + +V20 on the other hand will probably be used in future SoCs and +has seen really big changes in the vendor kernel, so will need +quite a bit of research. + +Changes from V10 to V12 +----------------------- + +- V12 supports a new CSI-host implementation but can still + also use the same implementation from V10 +- The module for lens shading correction got changed + from 12bit to 13bit width +- The AWB and AEC modules got replaced to support finer + grained data collection + +Changes from V12 to V13 +----------------------- + +The list for V13 is incomplete and needs further investigation. + +- V13 does not support the old CSI-host implementation anymore diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst index eb1cdfd280ba..ffc712a5f632 100644 --- a/Documentation/driver-api/media/maintainer-entry-profile.rst +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst @@ -71,7 +71,7 @@ media maintainers do the review. The media maintainers that work on specific areas of the subsystem are: -- Digital TV and remote controllers: +- Remote Controllers (infrared): Sean Young <sean@mess.org> - HDMI CEC: diff --git a/Documentation/driver-api/media/v4l2-subdev.rst b/Documentation/driver-api/media/v4l2-subdev.rst index 7736da077fb8..08ea2673b19e 100644 --- a/Documentation/driver-api/media/v4l2-subdev.rst +++ b/Documentation/driver-api/media/v4l2-subdev.rst @@ -191,21 +191,21 @@ registered this way are stored in a global list of subdevices, ready to be picked up by bridge drivers. Bridge drivers in turn have to register a notifier object. This is -performed using the :c:func:`v4l2_async_notifier_register` call. To +performed using the :c:func:`v4l2_async_nf_register` call. To unregister the notifier the driver has to call -:c:func:`v4l2_async_notifier_unregister`. The former of the two functions +:c:func:`v4l2_async_nf_unregister`. The former of the two functions takes two arguments: a pointer to struct :c:type:`v4l2_device` and a pointer to struct :c:type:`v4l2_async_notifier`. Before registering the notifier, bridge drivers must do two things: first, the -notifier must be initialized using the :c:func:`v4l2_async_notifier_init`. +notifier must be initialized using the :c:func:`v4l2_async_nf_init`. Second, bridge drivers can then begin to form a list of subdevice descriptors that the bridge device needs for its operation. Several functions are available to add subdevice descriptors to a notifier, depending on the type of device and the needs of the driver. -:c:func:`v4l2_async_notifier_add_fwnode_remote_subdev` and -:c:func:`v4l2_async_notifier_add_i2c_subdev` are for bridge and ISP drivers for +:c:func:`v4l2_async_nf_add_fwnode_remote` and +:c:func:`v4l2_async_nf_add_i2c` are for bridge and ISP drivers for registering their async sub-devices with the notifier. :c:func:`v4l2_async_register_subdev_sensor` is a helper function for @@ -230,8 +230,8 @@ These functions allocate an async sub-device descriptor which is of type struct ... - my_asd = v4l2_async_notifier_add_fwnode_remote_subdev(¬ifier, ep, - struct my_async_subdev); + my_asd = v4l2_async_nf_add_fwnode_remote(¬ifier, ep, + struct my_async_subdev); fwnode_handle_put(ep); if (IS_ERR(asd)) diff --git a/Documentation/driver-api/mmc/mmc-tools.rst b/Documentation/driver-api/mmc/mmc-tools.rst index a231e9644351..eee1c2ccfa8f 100644 --- a/Documentation/driver-api/mmc/mmc-tools.rst +++ b/Documentation/driver-api/mmc/mmc-tools.rst @@ -2,10 +2,10 @@ MMC tools introduction ====================== -There is one MMC test tools called mmc-utils, which is maintained by Chris Ball, +There is one MMC test tools called mmc-utils, which is maintained by Ulf Hansson, you can find it at the below public git repository: - https://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/ + https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git Functions ========= diff --git a/Documentation/driver-api/serial/n_gsm.rst b/Documentation/driver-api/serial/n_gsm.rst index 87dfcd54a96b..8fe723ab9c67 100644 --- a/Documentation/driver-api/serial/n_gsm.rst +++ b/Documentation/driver-api/serial/n_gsm.rst @@ -12,13 +12,16 @@ modems connected to a physical serial port. How to use it ------------- -1. initialize the modem in 0710 mux mode (usually AT+CMUX= command) through - its serial port. Depending on the modem used, you can pass more or less - parameters to this command, -2. switch the serial line to using the n_gsm line discipline by using - TIOCSETD ioctl, -3. configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl, -4. obtain base gsmtty number for the used serial port, +1. config initiator +^^^^^^^^^^^^^^^^^^^^^ + +1.1 initialize the modem in 0710 mux mode (usually AT+CMUX= command) through + its serial port. Depending on the modem used, you can pass more or less + parameters to this command. +1.2 switch the serial line to using the n_gsm line discipline by using + TIOCSETD ioctl. +1.3 configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl. +1.4 obtain base gsmtty number for the used serial port. Major parts of the initialization program : (a good starting point is util-linux-ng/sys-utils/ldattach.c):: @@ -70,14 +73,14 @@ Major parts of the initialization program : daemon(0,0); pause(); -5. use these devices as plain serial ports. +1.5 use these devices as plain serial ports. for example, it's possible: - and to use gnokii to send / receive SMS on ttygsm1 - to use ppp to establish a datalink on ttygsm2 -6. first close all virtual ports before closing the physical port. +1.6 first close all virtual ports before closing the physical port. Note that after closing the physical port the modem is still in multiplexing mode. This may prevent a successful re-opening of the port later. To avoid @@ -87,6 +90,56 @@ Major parts of the initialization program : 0xf9, 0x03, 0xef, 0x03, 0xc3, 0x16, 0xf9. +2. config requester +^^^^^^^^^^^^^^^^^^^^^ + +2.1 receive string "AT+CMUX= command" through its serial port,initialize + mux mode config +2.2 switch the serial line to using the n_gsm line discipline by using + TIOCSETD ioctl. +2.3 configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl. +2.4 obtain base gsmtty number for the used serial port, + + #include <stdio.h> + #include <stdint.h> + #include <linux/gsmmux.h> + #include <linux/tty.h> + #define DEFAULT_SPEED B115200 + #define SERIAL_PORT /dev/ttyS0 + + int ldisc = N_GSM0710; + struct gsm_config c; + struct termios configuration; + uint32_t first; + + /* open the serial port */ + fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY); + + /* configure the serial port : speed, flow control ... */ + + /* get serial data and check "AT+CMUX=command" parameter ... */ + + /* use n_gsm line discipline */ + ioctl(fd, TIOCSETD, &ldisc); + + /* get n_gsm configuration */ + ioctl(fd, GSMIOC_GETCONF, &c); + /* we are requester and need encoding 0 (basic) */ + c.initiator = 0; + c.encapsulation = 0; + /* our modem defaults to a maximum size of 127 bytes */ + c.mru = 127; + c.mtu = 127; + /* set the new configuration */ + ioctl(fd, GSMIOC_SETCONF, &c); + /* get first gsmtty device node */ + ioctl(fd, GSMIOC_GETFIRST, &first); + printf("first muxed line: /dev/gsmtty%i\n", first); + + /* and wait for ever to keep the line discipline enabled */ + daemon(0,0); + pause(); + Additional Documentation ------------------------ More practical details on the protocol and how it's supported by industrial diff --git a/Documentation/driver-api/serial/tty.rst b/Documentation/driver-api/serial/tty.rst index dd972caacf3e..4b709f392713 100644 --- a/Documentation/driver-api/serial/tty.rst +++ b/Documentation/driver-api/serial/tty.rst @@ -58,7 +58,7 @@ close() This is called on a terminal when the line hangup() Called when the tty line is hung up. The line discipline should cease I/O to the tty. No further calls into the ldisc code will occur. - The return value is ignored. Can sleep. + Can sleep. read() (optional) A process requests reading data from the line. Multiple read calls may occur in parallel diff --git a/Documentation/driver-api/thermal/sysfs-api.rst b/Documentation/driver-api/thermal/sysfs-api.rst index c93fa5e961a0..2e0f79a9e2ee 100644 --- a/Documentation/driver-api/thermal/sysfs-api.rst +++ b/Documentation/driver-api/thermal/sysfs-api.rst @@ -428,6 +428,9 @@ of thermal zone device. E.g. the generic thermal driver registers one hwmon class device and build the associated hwmon sysfs I/F for all the registered ACPI thermal zones. +Please read Documentation/ABI/testing/sysfs-class-thermal for thermal +zone and cooling device attribute details. + :: /sys/class/hwmon/hwmon[0-*]: @@ -437,228 +440,6 @@ ACPI thermal zones. Please read Documentation/hwmon/sysfs-interface.rst for additional information. -Thermal zone attributes ------------------------ - -type - Strings which represent the thermal zone type. - This is given by thermal zone driver as part of registration. - E.g: "acpitz" indicates it's an ACPI thermal device. - In order to keep it consistent with hwmon sys attribute; this should - be a short, lowercase string, not containing spaces nor dashes. - RO, Required - -temp - Current temperature as reported by thermal zone (sensor). - Unit: millidegree Celsius - RO, Required - -mode - One of the predefined values in [enabled, disabled]. - This file gives information about the algorithm that is currently - managing the thermal zone. It can be either default kernel based - algorithm or user space application. - - enabled - enable Kernel Thermal management. - disabled - Preventing kernel thermal zone driver actions upon - trip points so that user application can take full - charge of the thermal management. - - RW, Optional - -policy - One of the various thermal governors used for a particular zone. - - RW, Required - -available_policies - Available thermal governors which can be used for a particular zone. - - RO, Required - -`trip_point_[0-*]_temp` - The temperature above which trip point will be fired. - - Unit: millidegree Celsius - - RO, Optional - -`trip_point_[0-*]_type` - Strings which indicate the type of the trip point. - - E.g. it can be one of critical, hot, passive, `active[0-*]` for ACPI - thermal zone. - - RO, Optional - -`trip_point_[0-*]_hyst` - The hysteresis value for a trip point, represented as an integer - Unit: Celsius - RW, Optional - -`cdev[0-*]` - Sysfs link to the thermal cooling device node where the sys I/F - for cooling device throttling control represents. - - RO, Optional - -`cdev[0-*]_trip_point` - The trip point in this thermal zone which `cdev[0-*]` is associated - with; -1 means the cooling device is not associated with any trip - point. - - RO, Optional - -`cdev[0-*]_weight` - The influence of `cdev[0-*]` in this thermal zone. This value - is relative to the rest of cooling devices in the thermal - zone. For example, if a cooling device has a weight double - than that of other, it's twice as effective in cooling the - thermal zone. - - RW, Optional - -emul_temp - Interface to set the emulated temperature method in thermal zone - (sensor). After setting this temperature, the thermal zone may pass - this temperature to platform emulation function if registered or - cache it locally. This is useful in debugging different temperature - threshold and its associated cooling action. This is write only node - and writing 0 on this node should disable emulation. - Unit: millidegree Celsius - - WO, Optional - - WARNING: - Be careful while enabling this option on production systems, - because userland can easily disable the thermal policy by simply - flooding this sysfs node with low temperature values. - -sustainable_power - An estimate of the sustained power that can be dissipated by - the thermal zone. Used by the power allocator governor. For - more information see Documentation/driver-api/thermal/power_allocator.rst - - Unit: milliwatts - - RW, Optional - -k_po - The proportional term of the power allocator governor's PID - controller during temperature overshoot. Temperature overshoot - is when the current temperature is above the "desired - temperature" trip point. For more information see - Documentation/driver-api/thermal/power_allocator.rst - - RW, Optional - -k_pu - The proportional term of the power allocator governor's PID - controller during temperature undershoot. Temperature undershoot - is when the current temperature is below the "desired - temperature" trip point. For more information see - Documentation/driver-api/thermal/power_allocator.rst - - RW, Optional - -k_i - The integral term of the power allocator governor's PID - controller. This term allows the PID controller to compensate - for long term drift. For more information see - Documentation/driver-api/thermal/power_allocator.rst - - RW, Optional - -k_d - The derivative term of the power allocator governor's PID - controller. For more information see - Documentation/driver-api/thermal/power_allocator.rst - - RW, Optional - -integral_cutoff - Temperature offset from the desired temperature trip point - above which the integral term of the power allocator - governor's PID controller starts accumulating errors. For - example, if integral_cutoff is 0, then the integral term only - accumulates error when temperature is above the desired - temperature trip point. For more information see - Documentation/driver-api/thermal/power_allocator.rst - - Unit: millidegree Celsius - - RW, Optional - -slope - The slope constant used in a linear extrapolation model - to determine a hotspot temperature based off the sensor's - raw readings. It is up to the device driver to determine - the usage of these values. - - RW, Optional - -offset - The offset constant used in a linear extrapolation model - to determine a hotspot temperature based off the sensor's - raw readings. It is up to the device driver to determine - the usage of these values. - - RW, Optional - -Cooling device attributes -------------------------- - -type - String which represents the type of device, e.g: - - - for generic ACPI: should be "Fan", "Processor" or "LCD" - - for memory controller device on intel_menlow platform: - should be "Memory controller". - - RO, Required - -max_state - The maximum permissible cooling state of this cooling device. - - RO, Required - -cur_state - The current cooling state of this cooling device. - The value can any integer numbers between 0 and max_state: - - - cur_state == 0 means no cooling - - cur_state == max_state means the maximum cooling. - - RW, Required - -stats/reset - Writing any value resets the cooling device's statistics. - WO, Required - -stats/time_in_state_ms: - The amount of time spent by the cooling device in various cooling - states. The output will have "<state> <time>" pair in each line, which - will mean this cooling device spent <time> msec of time at <state>. - Output will have one line for each of the supported states. - RO, Required - - -stats/total_trans: - A single positive value showing the total number of times the state of a - cooling device is changed. - - RO, Required - -stats/trans_table: - This gives fine grained information about all the cooling state - transitions. The cat output here is a two dimensional matrix, where an - entry <i,j> (row i, column j) represents the number of transitions from - State_i to State_j. If the transition table is bigger than PAGE_SIZE, - reading this will return an -EFBIG error. - RO, Required - 3. A simple implementation ========================== diff --git a/Documentation/driver-api/usb/writing_usb_driver.rst b/Documentation/driver-api/usb/writing_usb_driver.rst index 2176297e5765..b43e1ce49f0e 100644 --- a/Documentation/driver-api/usb/writing_usb_driver.rst +++ b/Documentation/driver-api/usb/writing_usb_driver.rst @@ -57,9 +57,12 @@ structure. The skeleton driver declares a :c:type:`usb_driver` as:: .name = "skeleton", .probe = skel_probe, .disconnect = skel_disconnect, - .fops = &skel_fops, - .minor = USB_SKEL_MINOR_BASE, + .suspend = skel_suspend, + .resume = skel_resume, + .pre_reset = skel_pre_reset, + .post_reset = skel_post_reset, .id_table = skel_table, + .supports_autosuspend = 1, }; @@ -81,7 +84,7 @@ this user-space interaction. The skeleton driver needs this kind of interface, so it provides a minor starting number and a pointer to its :c:type:`file_operations` functions. -The USB driver is then registered with a call to :c:func:`usb_register`, +The USB driver is then registered with a call to usb_register(), usually in the driver's init function, as shown here:: static int __init usb_skel_init(void) @@ -102,7 +105,7 @@ usually in the driver's init function, as shown here:: When the driver is unloaded from the system, it needs to deregister -itself with the USB subsystem. This is done with the :c:func:`usb_deregister` +itself with the USB subsystem. This is done with usb_deregister() function:: static void __exit usb_skel_exit(void) @@ -231,7 +234,7 @@ error message. This can be shown with the following code:: skel->bulk_in_endpointAddr), skel->bulk_in_buffer, skel->bulk_in_size, - &count, HZ*10); + &count, 5000); /* if the read was successful, copy the data to user space */ if (!retval) { if (copy_to_user (buffer, skel->bulk_in_buffer, count)) diff --git a/Documentation/features/core/thread-info-in-task/arch-support.txt b/Documentation/features/core/thread-info-in-task/arch-support.txt index 9f0259bbd7df..3361e86b0958 100644 --- a/Documentation/features/core/thread-info-in-task/arch-support.txt +++ b/Documentation/features/core/thread-info-in-task/arch-support.txt @@ -20,7 +20,7 @@ | nds32: | ok | | nios2: | TODO | | openrisc: | TODO | - | parisc: | TODO | + | parisc: | ok | | powerpc: | ok | | riscv: | ok | | s390: | ok | diff --git a/Documentation/filesystems/autofs.rst b/Documentation/filesystems/autofs.rst index 681c6a492bc0..4f490278d22f 100644 --- a/Documentation/filesystems/autofs.rst +++ b/Documentation/filesystems/autofs.rst @@ -35,7 +35,7 @@ This document describes only the kernel module and the interactions required with any user-space program. Subsequent text refers to this as the "automount daemon" or simply "the daemon". -"autofs" is a Linux kernel module with provides the "autofs" +"autofs" is a Linux kernel module which provides the "autofs" filesystem type. Several "autofs" filesystems can be mounted and they can each be managed separately, or all managed by the same daemon. diff --git a/Documentation/filesystems/cifs/ksmbd.rst b/Documentation/filesystems/cifs/ksmbd.rst index a1326157d53f..b0d354fd8066 100644 --- a/Documentation/filesystems/cifs/ksmbd.rst +++ b/Documentation/filesystems/cifs/ksmbd.rst @@ -50,11 +50,11 @@ ksmbd.mountd (user space daemon) -------------------------------- ksmbd.mountd is userspace process to, transfer user account and password that -are registered using ksmbd.adduser(part of utils for user space). Further it +are registered using ksmbd.adduser (part of utils for user space). Further it allows sharing information parameters that parsed from smb.conf to ksmbd in kernel. For the execution part it has a daemon which is continuously running and connected to the kernel interface using netlink socket, it waits for the -requests(dcerpc and share/user info). It handles RPC calls (at a minimum few +requests (dcerpc and share/user info). It handles RPC calls (at a minimum few dozen) that are most important for file server from NetShareEnum and NetServerGetInfo. Complete DCE/RPC response is prepared from the user space and passed over to the associated kernel thread for the client. @@ -154,11 +154,11 @@ Each layer 1. Enable all component prints # sudo ksmbd.control -d "all" -2. Enable one of components(smb, auth, vfs, oplock, ipc, conn, rdma) +2. Enable one of components (smb, auth, vfs, oplock, ipc, conn, rdma) # sudo ksmbd.control -d "smb" -3. Show what prints are enable. - # cat/sys/class/ksmbd-control/debug +3. Show what prints are enabled. + # cat /sys/class/ksmbd-control/debug [smb] auth vfs oplock ipc conn [rdma] 4. Disable prints: diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst index b97579b7d8fb..01df283c7d04 100644 --- a/Documentation/filesystems/erofs.rst +++ b/Documentation/filesystems/erofs.rst @@ -19,9 +19,10 @@ It is designed as a better filesystem solution for the following scenarios: immutable and bit-for-bit identical to the official golden image for their releases due to security and other considerations and - - hope to save some extra storage space with guaranteed end-to-end performance - by using reduced metadata and transparent file compression, especially - for those embedded devices with limited memory (ex, smartphone); + - hope to minimize extra storage space with guaranteed end-to-end performance + by using compact layout, transparent file compression and direct access, + especially for those embedded devices with limited memory and high-density + hosts with numerous containers; Here is the main features of EROFS: @@ -51,7 +52,9 @@ Here is the main features of EROFS: - Support POSIX.1e ACLs by using xattrs; - Support transparent data compression as an option: - LZ4 algorithm with the fixed-sized output compression for high performance. + LZ4 algorithm with the fixed-sized output compression for high performance; + + - Multiple device support for multi-layer container images. The following git tree provides the file system user-space tools under development (ex, formatting tool mkfs.erofs): @@ -87,6 +90,7 @@ cache_strategy=%s Select a strategy for cached decompression from now on: dax={always,never} Use direct access (no page cache). See Documentation/filesystems/dax.rst. dax A legacy option which is an alias for ``dax=always``. +device=%s Specify a path to an extra device to be used together. =================== ========================================================= On-disk details diff --git a/Documentation/filesystems/ext4/orphan.rst b/Documentation/filesystems/ext4/orphan.rst index bb19ecd1b626..03cca178864b 100644 --- a/Documentation/filesystems/ext4/orphan.rst +++ b/Documentation/filesystems/ext4/orphan.rst @@ -12,41 +12,31 @@ track the inode as orphan so that in case of crash extra blocks allocated to the file get truncated. Traditionally ext4 tracks orphan inodes in a form of single linked list where -superblock contains the inode number of the last orphan inode (s\_last\_orphan +superblock contains the inode number of the last orphan inode (s_last_orphan field) and then each inode contains inode number of the previously orphaned -inode (we overload i\_dtime inode field for this). However this filesystem +inode (we overload i_dtime inode field for this). However this filesystem global single linked list is a scalability bottleneck for workloads that result in heavy creation of orphan inodes. When orphan file feature -(COMPAT\_ORPHAN\_FILE) is enabled, the filesystem has a special inode -(referenced from the superblock through s\_orphan_file_inum) with several +(COMPAT_ORPHAN_FILE) is enabled, the filesystem has a special inode +(referenced from the superblock through s_orphan_file_inum) with several blocks. Each of these blocks has a structure: -.. list-table:: - :widths: 8 8 24 40 - :header-rows: 1 - - * - Offset - - Type - - Name - - Description - * - 0x0 - - Array of \_\_le32 entries - - Orphan inode entries - - Each \_\_le32 entry is either empty (0) or it contains inode number of - an orphan inode. - * - blocksize - 8 - - \_\_le32 - - ob\_magic - - Magic value stored in orphan block tail (0x0b10ca04) - * - blocksize - 4 - - \_\_le32 - - ob\_checksum - - Checksum of the orphan block. +============= ================ =============== =============================== +Offset Type Name Description +============= ================ =============== =============================== +0x0 Array of Orphan inode Each __le32 entry is either + __le32 entries entries empty (0) or it contains + inode number of an orphan + inode. +blocksize-8 __le32 ob_magic Magic value stored in orphan + block tail (0x0b10ca04) +blocksize-4 __le32 ob_checksum Checksum of the orphan block. +============= ================ =============== =============================== When a filesystem with orphan file feature is writeably mounted, we set -RO\_COMPAT\_ORPHAN\_PRESENT feature in the superblock to indicate there may +RO_COMPAT_ORPHAN_PRESENT feature in the superblock to indicate there may be valid orphan entries. In case we see this feature when mounting the filesystem, we read the whole orphan file and process all orphan inodes found there as usual. When cleanly unmounting the filesystem we remove the -RO\_COMPAT\_ORPHAN\_PRESENT feature to avoid unnecessary scanning of the orphan +RO_COMPAT_ORPHAN_PRESENT feature to avoid unnecessary scanning of the orphan file and also make the filesystem fully compatible with older kernels. diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index 09de6ebbbdfa..d7b84695f56a 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -197,10 +197,29 @@ fault_type=%d Support configuring fault injection type, should be FAULT_DISCARD 0x000002000 FAULT_WRITE_IO 0x000004000 FAULT_SLAB_ALLOC 0x000008000 + FAULT_DQUOT_INIT 0x000010000 =================== =========== mode=%s Control block allocation mode which supports "adaptive" and "lfs". In "lfs" mode, there should be no random writes towards main area. + "fragment:segment" and "fragment:block" are newly added here. + These are developer options for experiments to simulate filesystem + fragmentation/after-GC situation itself. The developers use these + modes to understand filesystem fragmentation/after-GC condition well, + and eventually get some insights to handle them better. + In "fragment:segment", f2fs allocates a new segment in ramdom + position. With this, we can simulate the after-GC condition. + In "fragment:block", we can scatter block allocation with + "max_fragment_chunk" and "max_fragment_hole" sysfs nodes. + We added some randomness to both chunk and hole size to make + it close to realistic IO pattern. So, in this mode, f2fs will allocate + 1..<max_fragment_chunk> blocks in a chunk and make a hole in the + length of 1..<max_fragment_hole> by turns. With this, the newly + allocated blocks will be scattered throughout the whole partition. + Note that "fragment:block" implicitly enables "fragment:segment" + option for more randomness. + Please, use these options for your experiments and we strongly + recommend to re-format the filesystem after using these options. io_bits=%u Set the bit size of write IO requests. It should be set with "mode=lfs". usrquota Enable plain user disk quota accounting. @@ -283,7 +302,7 @@ compress_extension=%s Support adding specified extension, so that f2fs can enab For other files, we can still enable compression via ioctl. Note that, there is one reserved special extension '*', it can be set to enable compression for all files. -nocompress_extension=%s Support adding specified extension, so that f2fs can disable +nocompress_extension=%s Support adding specified extension, so that f2fs can disable compression on those corresponding files, just contrary to compression extension. If you know exactly which files cannot be compressed, you can use this. The same extension name can't appear in both compress and nocompress diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 0eb799d9d05a..4d5d50dca65c 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -77,11 +77,11 @@ Side-channel attacks fscrypt is only resistant to side-channel attacks, such as timing or electromagnetic attacks, to the extent that the underlying Linux -Cryptographic API algorithms are. If a vulnerable algorithm is used, -such as a table-based implementation of AES, it may be possible for an -attacker to mount a side channel attack against the online system. -Side channel attacks may also be mounted against applications -consuming decrypted data. +Cryptographic API algorithms or inline encryption hardware are. If a +vulnerable algorithm is used, such as a table-based implementation of +AES, it may be possible for an attacker to mount a side channel attack +against the online system. Side channel attacks may also be mounted +against applications consuming decrypted data. Unauthorized file access ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -176,11 +176,11 @@ Master Keys Each encrypted directory tree is protected by a *master key*. Master keys can be up to 64 bytes long, and must be at least as long as the -greater of the key length needed by the contents and filenames -encryption modes being used. For example, if AES-256-XTS is used for -contents encryption, the master key must be 64 bytes (512 bits). Note -that the XTS mode is defined to require a key twice as long as that -required by the underlying block cipher. +greater of the security strength of the contents and filenames +encryption modes being used. For example, if any AES-256 mode is +used, the master key must be at least 256 bits, i.e. 32 bytes. A +stricter requirement applies if the key is used by a v1 encryption +policy and AES-256-XTS is used; such keys must be 64 bytes. To "unlock" an encrypted directory tree, userspace must provide the appropriate master key. There can be any number of master keys, each @@ -1135,6 +1135,50 @@ where applications may later write sensitive data. It is recommended that systems implementing a form of "verified boot" take advantage of this by validating all top-level encryption policies prior to access. +Inline encryption support +========================= + +By default, fscrypt uses the kernel crypto API for all cryptographic +operations (other than HKDF, which fscrypt partially implements +itself). The kernel crypto API supports hardware crypto accelerators, +but only ones that work in the traditional way where all inputs and +outputs (e.g. plaintexts and ciphertexts) are in memory. fscrypt can +take advantage of such hardware, but the traditional acceleration +model isn't particularly efficient and fscrypt hasn't been optimized +for it. + +Instead, many newer systems (especially mobile SoCs) have *inline +encryption hardware* that can encrypt/decrypt data while it is on its +way to/from the storage device. Linux supports inline encryption +through a set of extensions to the block layer called *blk-crypto*. +blk-crypto allows filesystems to attach encryption contexts to bios +(I/O requests) to specify how the data will be encrypted or decrypted +in-line. For more information about blk-crypto, see +:ref:`Documentation/block/inline-encryption.rst <inline_encryption>`. + +On supported filesystems (currently ext4 and f2fs), fscrypt can use +blk-crypto instead of the kernel crypto API to encrypt/decrypt file +contents. To enable this, set CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y in +the kernel configuration, and specify the "inlinecrypt" mount option +when mounting the filesystem. + +Note that the "inlinecrypt" mount option just specifies to use inline +encryption when possible; it doesn't force its use. fscrypt will +still fall back to using the kernel crypto API on files where the +inline encryption hardware doesn't have the needed crypto capabilities +(e.g. support for the needed encryption algorithm and data unit size) +and where blk-crypto-fallback is unusable. (For blk-crypto-fallback +to be usable, it must be enabled in the kernel configuration with +CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y.) + +Currently fscrypt always uses the filesystem block size (which is +usually 4096 bytes) as the data unit size. Therefore, it can only use +inline encryption hardware that supports that data unit size. + +Inline encryption doesn't affect the ciphertext or other aspects of +the on-disk format, so users may freely switch back and forth between +using "inlinecrypt" and not using "inlinecrypt". + Implementation details ====================== @@ -1184,6 +1228,13 @@ keys`_ and `DIRECT_KEY policies`_. Data path changes ----------------- +When inline encryption is used, filesystems just need to associate +encryption contexts with bios to specify how the block layer or the +inline encryption hardware will encrypt/decrypt the file contents. + +When inline encryption isn't used, filesystems must encrypt/decrypt +the file contents themselves, as described below: + For the read path (->readpage()) of regular files, filesystems can read the ciphertext into the page cache and decrypt it in-place. The page lock must be held until decryption has finished, to prevent the @@ -1197,18 +1248,6 @@ buffer. Some filesystems, such as UBIFS, already use temporary buffers regardless of encryption. Other filesystems, such as ext4 and F2FS, have to allocate bounce pages specially for encryption. -Fscrypt is also able to use inline encryption hardware instead of the -kernel crypto API for en/decryption of file contents. When possible, -and if directed to do so (by specifying the 'inlinecrypt' mount option -for an ext4/F2FS filesystem), it adds encryption contexts to bios and -uses blk-crypto to perform the en/decryption instead of making use of -the above read/write path changes. Of course, even if directed to -make use of inline encryption, fscrypt will only be able to do so if -either hardware inline encryption support is available for the -selected encryption algorithm or CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK -is selected. If neither is the case, fscrypt will fall back to using -the above mentioned read/write path changes for en/decryption. - Filename hashing and encoding ----------------------------- diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index c0ad233963ae..bee63d42e5ec 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -29,7 +29,6 @@ algorithms work. fiemap files locks - mandatory-locking mount_api quota seq_file diff --git a/Documentation/filesystems/locks.rst b/Documentation/filesystems/locks.rst index c5ae858b1aac..26429317dbbc 100644 --- a/Documentation/filesystems/locks.rst +++ b/Documentation/filesystems/locks.rst @@ -57,16 +57,9 @@ fcntl(), with all the problems that implies. 1.3 Mandatory Locking As A Mount Option --------------------------------------- -Mandatory locking, as described in -'Documentation/filesystems/mandatory-locking.rst' was prior to this release a -general configuration option that was valid for all mounted filesystems. This -had a number of inherent dangers, not the least of which was the ability to -freeze an NFS server by asking it to read a file for which a mandatory lock -existed. - -From this release of the kernel, mandatory locking can be turned on and off -on a per-filesystem basis, using the mount options 'mand' and 'nomand'. -The default is to disallow mandatory locking. The intention is that -mandatory locking only be enabled on a local filesystem as the specific need -arises. +Mandatory locking was prior to this release a general configuration option +that was valid for all mounted filesystems. This had a number of inherent +dangers, not the least of which was the ability to freeze an NFS server by +asking it to read a file for which a mandatory lock existed. +Such option was dropped in Kernel v5.14. diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 57a641847818..375baca7edcd 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 ================================= -NETWORK FILESYSTEM HELPER LIBRARY +Network Filesystem Helper Library ================================= .. Contents: @@ -37,22 +37,22 @@ into a common call framework. The following services are provided: - * Handles transparent huge pages (THPs). + * Handle folios that span multiple pages. - * Insulates the netfs from VM interface changes. + * Insulate the netfs from VM interface changes. - * Allows the netfs to arbitrarily split reads up into pieces, even ones that - don't match page sizes or page alignments and that may cross pages. + * Allow the netfs to arbitrarily split reads up into pieces, even ones that + don't match folio sizes or folio alignments and that may cross folios. - * Allows the netfs to expand a readahead request in both directions to meet - its needs. + * Allow the netfs to expand a readahead request in both directions to meet its + needs. - * Allows the netfs to partially fulfil a read, which will then be resubmitted. + * Allow the netfs to partially fulfil a read, which will then be resubmitted. - * Handles local caching, allowing cached data and server-read data to be + * Handle local caching, allowing cached data and server-read data to be interleaved for a single request. - * Handles clearing of bufferage that aren't on the server. + * Handle clearing of bufferage that aren't on the server. * Handle retrying of reads that failed, switching reads from the cache to the server as necessary. @@ -70,22 +70,22 @@ Read Helper Functions Three read helpers are provided:: - * void netfs_readahead(struct readahead_control *ractl, - const struct netfs_read_request_ops *ops, - void *netfs_priv);`` - * int netfs_readpage(struct file *file, - struct page *page, - const struct netfs_read_request_ops *ops, - void *netfs_priv); - * int netfs_write_begin(struct file *file, - struct address_space *mapping, - loff_t pos, - unsigned int len, - unsigned int flags, - struct page **_page, - void **_fsdata, - const struct netfs_read_request_ops *ops, - void *netfs_priv); + void netfs_readahead(struct readahead_control *ractl, + const struct netfs_read_request_ops *ops, + void *netfs_priv); + int netfs_readpage(struct file *file, + struct folio *folio, + const struct netfs_read_request_ops *ops, + void *netfs_priv); + int netfs_write_begin(struct file *file, + struct address_space *mapping, + loff_t pos, + unsigned int len, + unsigned int flags, + struct folio **_folio, + void **_fsdata, + const struct netfs_read_request_ops *ops, + void *netfs_priv); Each corresponds to a VM operation, with the addition of a couple of parameters for the use of the read helpers: @@ -103,8 +103,8 @@ Both of these values will be stored into the read request structure. For ->readahead() and ->readpage(), the network filesystem should just jump into the corresponding read helper; whereas for ->write_begin(), it may be a little more complicated as the network filesystem might want to flush -conflicting writes or track dirty data and needs to put the acquired page if an -error occurs after calling the helper. +conflicting writes or track dirty data and needs to put the acquired folio if +an error occurs after calling the helper. The helpers manage the read request, calling back into the network filesystem through the suppplied table of operations. Waits will be performed as @@ -253,7 +253,7 @@ through which it can issue requests and negotiate:: void (*issue_op)(struct netfs_read_subrequest *subreq); bool (*is_still_valid)(struct netfs_read_request *rreq); int (*check_write_begin)(struct file *file, loff_t pos, unsigned len, - struct page *page, void **_fsdata); + struct folio *folio, void **_fsdata); void (*done)(struct netfs_read_request *rreq); void (*cleanup)(struct address_space *mapping, void *netfs_priv); }; @@ -313,13 +313,14 @@ The operations are as follows: There is no return value; the netfs_subreq_terminated() function should be called to indicate whether or not the operation succeeded and how much data - it transferred. The filesystem also should not deal with setting pages + it transferred. The filesystem also should not deal with setting folios uptodate, unlocking them or dropping their refs - the helpers need to deal with this as they have to coordinate with copying to the local cache. - Note that the helpers have the pages locked, but not pinned. It is possible - to use the ITER_XARRAY iov iterator to refer to the range of the inode that - is being operated upon without the need to allocate large bvec tables. + Note that the helpers have the folios locked, but not pinned. It is + possible to use the ITER_XARRAY iov iterator to refer to the range of the + inode that is being operated upon without the need to allocate large bvec + tables. * ``is_still_valid()`` @@ -330,15 +331,15 @@ The operations are as follows: * ``check_write_begin()`` [Optional] This is called from the netfs_write_begin() helper once it has - allocated/grabbed the page to be modified to allow the filesystem to flush + allocated/grabbed the folio to be modified to allow the filesystem to flush conflicting state before allowing it to be modified. - It should return 0 if everything is now fine, -EAGAIN if the page should be + It should return 0 if everything is now fine, -EAGAIN if the folio should be regrabbed and any other error code to abort the operation. * ``done`` - [Optional] This is called after the pages in the request have all been + [Optional] This is called after the folios in the request have all been unlocked (and marked uptodate if applicable). * ``cleanup`` @@ -390,7 +391,7 @@ The read helpers work by the following general procedure: * If NETFS_SREQ_CLEAR_TAIL was set, a short read will be cleared to the end of the slice instead of reissuing. - * Once the data is read, the pages that have been fully read/cleared: + * Once the data is read, the folios that have been fully read/cleared: * Will be marked uptodate. @@ -398,11 +399,11 @@ The read helpers work by the following general procedure: * Unlocked - * Any pages that need writing to the cache will then have DIO writes issued. + * Any folios that need writing to the cache will then have DIO writes issued. * Synchronous operations will wait for reading to be complete. - * Writes to the cache will proceed asynchronously and the pages will have the + * Writes to the cache will proceed asynchronously and the folios will have the PG_fscache mark removed when that completes. * The request structures will be cleaned up when everything has completed. @@ -452,6 +453,9 @@ operation table looks like the following:: netfs_io_terminated_t term_func, void *term_func_priv); + int (*prepare_write)(struct netfs_cache_resources *cres, + loff_t *_start, size_t *_len, loff_t i_size); + int (*write)(struct netfs_cache_resources *cres, loff_t start_pos, struct iov_iter *iter, @@ -509,6 +513,14 @@ The methods defined in the table are: indicating whether the termination is definitely happening in the caller's context. + * ``prepare_write()`` + + [Required] Called to adjust a write to the cache and check that there is + sufficient space in the cache. The start and length values indicate the + size of the write that netfslib is proposing, and this can be adjusted by + the cache to respect DIO boundaries. The file size is passed for + information. + * ``write()`` [Required] Called to write to the cache. The start file offset is given @@ -524,3 +536,10 @@ Note that these methods are passed a pointer to the cache resource structure, not the read request structure as they could be used in other situations where there isn't a read request structure as well, such as writing dirty data to the cache. + + +API Function Reference +====================== + +.. kernel-doc:: include/linux/netfs.h +.. kernel-doc:: fs/netfs/read_helper.c diff --git a/Documentation/filesystems/nfs/index.rst b/Documentation/filesystems/nfs/index.rst index 65805624e39b..288d8ddb2bc6 100644 --- a/Documentation/filesystems/nfs/index.rst +++ b/Documentation/filesystems/nfs/index.rst @@ -11,3 +11,4 @@ NFS rpc-server-gss nfs41-server knfsd-stats + reexport diff --git a/Documentation/filesystems/nfs/reexport.rst b/Documentation/filesystems/nfs/reexport.rst new file mode 100644 index 000000000000..ff9ae4a46530 --- /dev/null +++ b/Documentation/filesystems/nfs/reexport.rst @@ -0,0 +1,113 @@ +Reexporting NFS filesystems +=========================== + +Overview +-------- + +It is possible to reexport an NFS filesystem over NFS. However, this +feature comes with a number of limitations. Before trying it, we +recommend some careful research to determine whether it will work for +your purposes. + +A discussion of current known limitations follows. + +"fsid=" required, crossmnt broken +--------------------------------- + +We require the "fsid=" export option on any reexport of an NFS +filesystem. You can use "uuidgen -r" to generate a unique argument. + +The "crossmnt" export does not propagate "fsid=", so it will not allow +traversing into further nfs filesystems; if you wish to export nfs +filesystems mounted under the exported filesystem, you'll need to export +them explicitly, assigning each its own unique "fsid= option. + +Reboot recovery +--------------- + +The NFS protocol's normal reboot recovery mechanisms don't work for the +case when the reexport server reboots. Clients will lose any locks +they held before the reboot, and further IO will result in errors. +Closing and reopening files should clear the errors. + +Filehandle limits +----------------- + +If the original server uses an X byte filehandle for a given object, the +reexport server's filehandle for the reexported object will be X+22 +bytes, rounded up to the nearest multiple of four bytes. + +The result must fit into the RFC-mandated filehandle size limits: + ++-------+-----------+ +| NFSv2 | 32 bytes | ++-------+-----------+ +| NFSv3 | 64 bytes | ++-------+-----------+ +| NFSv4 | 128 bytes | ++-------+-----------+ + +So, for example, you will only be able to reexport a filesystem over +NFSv2 if the original server gives you filehandles that fit in 10 +bytes--which is unlikely. + +In general there's no way to know the maximum filehandle size given out +by an NFS server without asking the server vendor. + +But the following table gives a few examples. The first column is the +typical length of the filehandle from a Linux server exporting the given +filesystem, the second is the length after that nfs export is reexported +by another Linux host: + ++--------+-------------------+----------------+ +| | filehandle length | after reexport | ++========+===================+================+ +| ext4: | 28 bytes | 52 bytes | ++--------+-------------------+----------------+ +| xfs: | 32 bytes | 56 bytes | ++--------+-------------------+----------------+ +| btrfs: | 40 bytes | 64 bytes | ++--------+-------------------+----------------+ + +All will therefore fit in an NFSv3 or NFSv4 filehandle after reexport, +but none are reexportable over NFSv2. + +Linux server filehandles are a bit more complicated than this, though; +for example: + + - The (non-default) "subtreecheck" export option generally + requires another 4 to 8 bytes in the filehandle. + - If you export a subdirectory of a filesystem (instead of + exporting the filesystem root), that also usually adds 4 to 8 + bytes. + - If you export over NFSv2, knfsd usually uses a shorter + filesystem identifier that saves 8 bytes. + - The root directory of an export uses a filehandle that is + shorter. + +As you can see, the 128-byte NFSv4 filehandle is large enough that +you're unlikely to have trouble using NFSv4 to reexport any filesystem +exported from a Linux server. In general, if the original server is +something that also supports NFSv3, you're *probably* OK. Re-exporting +over NFSv3 may be dicier, and reexporting over NFSv2 will probably +never work. + +For more details of Linux filehandle structure, the best reference is +the source code and comments; see in particular: + + - include/linux/exportfs.h:enum fid_type + - include/uapi/linux/nfsd/nfsfh.h:struct nfs_fhbase_new + - fs/nfsd/nfsfh.c:set_version_and_fsid_type + - fs/nfs/export.c:nfs_encode_fh + +Open DENY bits ignored +---------------------- + +NFS since NFSv4 supports ALLOW and DENY bits taken from Windows, which +allow you, for example, to open a file in a mode which forbids other +read opens or write opens. The Linux client doesn't use them, and the +server's support has always been incomplete: they are enforced only +against other NFS users, not against processes accessing the exported +filesystem locally. A reexport server will also not pass them along to +the original server, so they will not be enforced between clients of +different reexport servers. diff --git a/Documentation/filesystems/ntfs3.rst b/Documentation/filesystems/ntfs3.rst index ffe9ea0c1499..d67ccd22c63b 100644 --- a/Documentation/filesystems/ntfs3.rst +++ b/Documentation/filesystems/ntfs3.rst @@ -4,103 +4,112 @@ NTFS3 ===== - Summary and Features ==================== -NTFS3 is fully functional NTFS Read-Write driver. The driver works with -NTFS versions up to 3.1, normal/compressed/sparse files -and journal replaying. File system type to use on mount is 'ntfs3'. +NTFS3 is fully functional NTFS Read-Write driver. The driver works with NTFS +versions up to 3.1. File system type to use on mount is *ntfs3*. - This driver implements NTFS read/write support for normal, sparse and compressed files. -- Supports native journal replaying; -- Supports extended attributes - Predefined extended attributes: - - 'system.ntfs_security' gets/sets security - descriptor (SECURITY_DESCRIPTOR_RELATIVE) - - 'system.ntfs_attrib' gets/sets ntfs file/dir attributes. - Note: applied to empty files, this allows to switch type between - sparse(0x200), compressed(0x800) and normal; +- Supports native journal replaying. - Supports NFS export of mounted NTFS volumes. +- Supports extended attributes. Predefined extended attributes: + + - *system.ntfs_security* gets/sets security + + Descriptor: SECURITY_DESCRIPTOR_RELATIVE + + - *system.ntfs_attrib* gets/sets ntfs file/dir attributes. + + Note: Applied to empty files, this allows to switch type between + sparse(0x200), compressed(0x800) and normal. Mount Options ============= The list below describes mount options supported by NTFS3 driver in addition to -generic ones. +generic ones. You can use every mount option with **no** option. If it is in +this table marked with no it means default is without **no**. -=============================================================================== +.. flat-table:: + :widths: 1 5 + :fill-cells: -nls=name This option informs the driver how to interpret path - strings and translate them to Unicode and back. If - this option is not set, the default codepage will be - used (CONFIG_NLS_DEFAULT). - Examples: - 'nls=utf8' + * - iocharset=name + - This option informs the driver how to interpret path strings and + translate them to Unicode and back. If this option is not set, the + default codepage will be used (CONFIG_NLS_DEFAULT). -uid= -gid= -umask= Controls the default permissions for files/directories created - after the NTFS volume is mounted. + Example: iocharset=utf8 -fmask= -dmask= Instead of specifying umask which applies both to - files and directories, fmask applies only to files and - dmask only to directories. + * - uid= + - :rspan:`1` + * - gid= -nohidden Files with the Windows-specific HIDDEN (FILE_ATTRIBUTE_HIDDEN) - attribute will not be shown under Linux. + * - umask= + - Controls the default permissions for files/directories created after + the NTFS volume is mounted. -sys_immutable Files with the Windows-specific SYSTEM - (FILE_ATTRIBUTE_SYSTEM) attribute will be marked as system - immutable files. + * - dmask= + - :rspan:`1` Instead of specifying umask which applies both to files and + directories, fmask applies only to files and dmask only to directories. + * - fmask= -discard Enable support of the TRIM command for improved performance - on delete operations, which is recommended for use with the - solid-state drives (SSD). + * - noacsrules + - "No access rules" mount option sets access rights for files/folders to + 777 and owner/group to root. This mount option absorbs all other + permissions. -force Forces the driver to mount partitions even if 'dirty' flag - (volume dirty) is set. Not recommended for use. + - Permissions change for files/folders will be reported as successful, + but they will remain 777. -sparse Create new files as "sparse". + - Owner/group change will be reported as successful, butthey will stay + as root. -showmeta Use this parameter to show all meta-files (System Files) on - a mounted NTFS partition. - By default, all meta-files are hidden. + * - nohidden + - Files with the Windows-specific HIDDEN (FILE_ATTRIBUTE_HIDDEN) attribute + will not be shown under Linux. -prealloc Preallocate space for files excessively when file size is - increasing on writes. Decreases fragmentation in case of - parallel write operations to different files. + * - sys_immutable + - Files with the Windows-specific SYSTEM (FILE_ATTRIBUTE_SYSTEM) attribute + will be marked as system immutable files. -no_acs_rules "No access rules" mount option sets access rights for - files/folders to 777 and owner/group to root. This mount - option absorbs all other permissions: - - permissions change for files/folders will be reported - as successful, but they will remain 777; - - owner/group change will be reported as successful, but - they will stay as root + * - discard + - Enable support of the TRIM command for improved performance on delete + operations, which is recommended for use with the solid-state drives + (SSD). -acl Support POSIX ACLs (Access Control Lists). Effective if - supported by Kernel. Not to be confused with NTFS ACLs. - The option specified as acl enables support for POSIX ACLs. + * - force + - Forces the driver to mount partitions even if volume is marked dirty. + Not recommended for use. -noatime All files and directories will not update their last access - time attribute if a partition is mounted with this parameter. - This option can speed up file system operation. + * - sparse + - Create new files as sparse. -=============================================================================== + * - showmeta + - Use this parameter to show all meta-files (System Files) on a mounted + NTFS partition. By default, all meta-files are hidden. -ToDo list -========= + * - prealloc + - Preallocate space for files excessively when file size is increasing on + writes. Decreases fragmentation in case of parallel write operations to + different files. -- Full journaling support (currently journal replaying is supported) over JBD. + * - acl + - Support POSIX ACLs (Access Control Lists). Effective if supported by + Kernel. Not to be confused with NTFS ACLs. The option specified as acl + enables support for POSIX ACLs. +Todo list +========= +- Full journaling support over JBD. Currently journal replaying is supported + which is not necessarily as effectice as JBD would be. References ========== -https://www.paragon-software.com/home/ntfs-linux-professional/ - - Commercial version of the NTFS driver for Linux. +- Commercial version of the NTFS driver for Linux. + https://www.paragon-software.com/home/ntfs-linux-professional/ -almaz.alexandrovich@paragon-software.com - - Direct e-mail address for feedback and requests on the NTFS3 implementation. +- Direct e-mail address for feedback and requests on the NTFS3 implementation. + almaz.alexandrovich@paragon-software.com diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 042c418f4090..8d7f141c6fc7 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -1857,19 +1857,19 @@ For example:: This file contains lines of the form:: 36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue - (1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11) - - (1) mount ID: unique identifier of the mount (may be reused after umount) - (2) parent ID: ID of parent (or of self for the top of the mount tree) - (3) major:minor: value of st_dev for files on filesystem - (4) root: root of the mount within the filesystem - (5) mount point: mount point relative to the process's root - (6) mount options: per mount options - (7) optional fields: zero or more fields of the form "tag[:value]" - (8) separator: marks the end of the optional fields - (9) filesystem type: name of filesystem of the form "type[.subtype]" - (10) mount source: filesystem specific information or "none" - (11) super options: per super block options + (1)(2)(3) (4) (5) (6) (n…m) (m+1)(m+2) (m+3) (m+4) + + (1) mount ID: unique identifier of the mount (may be reused after umount) + (2) parent ID: ID of parent (or of self for the top of the mount tree) + (3) major:minor: value of st_dev for files on filesystem + (4) root: root of the mount within the filesystem + (5) mount point: mount point relative to the process's root + (6) mount options: per mount options + (n…m) optional fields: zero or more fields of the form "tag[:value]" + (m+1) separator: marks the end of the optional fields + (m+2) filesystem type: name of filesystem of the form "type[.subtype]" + (m+3) mount source: filesystem specific information or "none" + (m+4) super options: per super block options Parsers should ignore all unrecognised optional fields. Currently the possible optional fields are: diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index a99ee402b212..b053b0c3d696 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -26,5 +26,6 @@ ACPI Support acpi-lid lpit video_extension + non-d0-probe extcon-intel-int3496 intel-pmc-mux diff --git a/Documentation/firmware-guide/acpi/non-d0-probe.rst b/Documentation/firmware-guide/acpi/non-d0-probe.rst new file mode 100644 index 000000000000..7afd16701a02 --- /dev/null +++ b/Documentation/firmware-guide/acpi/non-d0-probe.rst @@ -0,0 +1,78 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================== +Probing devices in other D states than 0 +======================================== + +Introduction +============ + +In some cases it may be preferred to leave certain devices powered off for the +entire system bootup if powering on these devices has adverse side effects, +beyond just powering on the said device. + +How it works +============ + +The _DSC (Device State for Configuration) object that evaluates to an integer +may be used to tell Linux the highest allowed D state for a device during +probe. The support for _DSC requires support from the kernel bus type if the +bus driver normally sets the device in D0 state for probe. + +The downside of using _DSC is that as the device is not powered on, even if +there's a problem with the device, the driver likely probes just fine but the +first user will find out the device doesn't work, instead of a failure at probe +time. This feature should thus be used sparingly. + +I²C +--- + +If an I²C driver indicates its support for this by setting the +I2C_DRV_ACPI_WAIVE_D0_PROBE flag in struct i2c_driver.flags field and the +_DSC object evaluates to integer higher than the D state of the device, +the device will not be powered on (put in D0 state) for probe. + +D states +-------- + +The D states and thus also the allowed values for _DSC are listed below. Refer +to [1] for more information on device power states. + +.. code-block:: text + + Number State Description + 0 D0 Device fully powered on + 1 D1 + 2 D2 + 3 D3hot + 4 D3cold Off + +References +========== + +[1] https://uefi.org/specifications/ACPI/6.4/02_Definition_of_Terms/Definition_of_Terms.html#device-power-state-definitions + +Example +======= + +An ASL example describing an ACPI device using _DSC object to tell Operating +System the device should remain powered off during probe looks like this. Some +objects not relevant from the example point of view have been omitted. + +.. code-block:: text + + Device (CAM0) + { + Name (_HID, "SONY319A") + Name (_UID, Zero) + Name (_CRS, ResourceTemplate () + { + I2cSerialBus(0x0020, ControllerInitiated, 0x00061A80, + AddressingMode7Bit, "\\_SB.PCI0.I2C0", + 0x00, ResourceConsumer) + }) + Method (_DSC, 0, NotSerialized) + { + Return (0x4) + } + } diff --git a/Documentation/firmware-guide/acpi/osi.rst b/Documentation/firmware-guide/acpi/osi.rst index 29e9ef79ebc0..05869c0045d7 100644 --- a/Documentation/firmware-guide/acpi/osi.rst +++ b/Documentation/firmware-guide/acpi/osi.rst @@ -74,7 +74,7 @@ The ACPI BIOS flow would include an evaluation of _OS, and the AML interpreter in the kernel would return to it a string identifying the OS: Windows 98, SE: "Microsoft Windows" -Windows ME: "Microsoft WindowsME:Millenium Edition" +Windows ME: "Microsoft WindowsME:Millennium Edition" Windows NT: "Microsoft Windows NT" The idea was on a platform tasked with running multiple OS's, diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst index 364680cdad2e..8ba72e898099 100644 --- a/Documentation/gpu/amdgpu.rst +++ b/Documentation/gpu/amdgpu.rst @@ -300,8 +300,8 @@ pcie_replay_count .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c :doc: pcie_replay_count -+GPU SmartShift Information -============================ +GPU SmartShift Information +========================== GPU SmartShift information via sysfs diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 06af044c882f..607f78f0f189 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -111,15 +111,6 @@ Component Helper Usage .. kernel-doc:: drivers/gpu/drm/drm_drv.c :doc: component helper usage recommendations -IRQ Helper Library -~~~~~~~~~~~~~~~~~~ - -.. kernel-doc:: drivers/gpu/drm/drm_irq.c - :doc: irq helpers - -.. kernel-doc:: drivers/gpu/drm/drm_irq.c - :export: - Memory Manager Initialization ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 389892f36185..ec2f65b31930 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -151,6 +151,18 @@ Overview .. kernel-doc:: drivers/gpu/drm/drm_bridge.c :doc: overview +Display Driver Integration +-------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_bridge.c + :doc: display driver integration + +Special Care with MIPI-DSI bridges +---------------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_bridge.c + :doc: special care dsi + Bridge Operations ----------------- diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 8126beadc7df..e0538083a2c0 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -28,56 +28,53 @@ UMA devices. The Translation Table Manager (TTM) =================================== -TTM design background and information belongs here. +.. kernel-doc:: drivers/gpu/drm/ttm/ttm_module.c + :doc: TTM -TTM initialization ------------------- +.. kernel-doc:: include/drm/ttm/ttm_caching.h + :internal: - **Warning** - This section is outdated. +TTM device object reference +--------------------------- -Drivers wishing to support TTM must pass a filled :c:type:`ttm_bo_driver -<ttm_bo_driver>` structure to ttm_device_init, together with an -initialized global reference to the memory manager. The ttm_bo_driver -structure contains several fields with function pointers for -initializing the TTM, allocating and freeing memory, waiting for command -completion and fence synchronization, and memory migration. +.. kernel-doc:: include/drm/ttm/ttm_device.h + :internal: -The :c:type:`struct drm_global_reference <drm_global_reference>` is made -up of several fields: +.. kernel-doc:: drivers/gpu/drm/ttm/ttm_device.c + :export: -.. code-block:: c +TTM resource placement reference +-------------------------------- - struct drm_global_reference { - enum ttm_global_types global_type; - size_t size; - void *object; - int (*init) (struct drm_global_reference *); - void (*release) (struct drm_global_reference *); - }; - - -There should be one global reference structure for your memory manager -as a whole, and there will be others for each object created by the -memory manager at runtime. Your global TTM should have a type of -TTM_GLOBAL_TTM_MEM. The size field for the global object should be -sizeof(struct ttm_mem_global), and the init and release hooks should -point at your driver-specific init and release routines, which probably -eventually call ttm_mem_global_init and ttm_mem_global_release, -respectively. +.. kernel-doc:: include/drm/ttm/ttm_placement.h + :internal: + +TTM resource object reference +----------------------------- + +.. kernel-doc:: include/drm/ttm/ttm_resource.h + :internal: -Once your global TTM accounting structure is set up and initialized by -calling ttm_global_item_ref() on it, you need to create a buffer -object TTM to provide a pool for buffer object allocation by clients and -the kernel itself. The type of this object should be -TTM_GLOBAL_TTM_BO, and its size should be sizeof(struct -ttm_bo_global). Again, driver-specific init and release functions may -be provided, likely eventually calling ttm_bo_global_ref_init() and -ttm_bo_global_ref_release(), respectively. Also, like the previous -object, ttm_global_item_ref() is used to create an initial reference -count for the TTM, which will call your initialization function. +.. kernel-doc:: drivers/gpu/drm/ttm/ttm_resource.c + :export: + +TTM TT object reference +----------------------- + +.. kernel-doc:: include/drm/ttm/ttm_tt.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/ttm/ttm_tt.c + :export: -See the radeon_ttm.c file for an example of usage. +TTM page pool reference +----------------------- + +.. kernel-doc:: include/drm/ttm/ttm_pool.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/ttm/ttm_pool.c + :export: The Graphics Execution Manager (GEM) ==================================== @@ -504,3 +501,6 @@ Scheduler Function References .. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c :export: + +.. kernel-doc:: drivers/gpu/drm/scheduler/sched_entity.c + :export: diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 204ebdaadb45..b7d801993bfa 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -183,26 +183,23 @@ Frame Buffer Compression (FBC) Display Refresh Rate Switching (DRRS) ------------------------------------- -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c :doc: Display Refresh Rate Switching (DRRS) -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c - :functions: intel_dp_set_drrs_state +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c + :functions: intel_drrs_enable -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c - :functions: intel_edp_drrs_enable +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c + :functions: intel_drrs_disable -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c - :functions: intel_edp_drrs_disable +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c + :functions: intel_drrs_invalidate -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c - :functions: intel_edp_drrs_invalidate +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c + :functions: intel_drrs_flush -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c - :functions: intel_edp_drrs_flush - -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c - :functions: intel_dp_drrs_init +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c + :functions: intel_drrs_init DPIO ---- @@ -474,6 +471,14 @@ Object Tiling IOCTLs .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_tiling.c :doc: buffer object tiling +Protected Objects +----------------- + +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp.c + :doc: PXP + +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_types.h + Microcontrollers ================ @@ -498,6 +503,8 @@ GuC .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.c :doc: GuC +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.h + GuC Firmware Layout ~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h b/Documentation/gpu/rfc/i915_parallel_execbuf.h deleted file mode 100644 index 8cbe2c4e0172..000000000000 --- a/Documentation/gpu/rfc/i915_parallel_execbuf.h +++ /dev/null @@ -1,122 +0,0 @@ -/* SPDX-License-Identifier: MIT */ -/* - * Copyright © 2021 Intel Corporation - */ - -#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see i915_context_engines_parallel_submit */ - -/** - * struct drm_i915_context_engines_parallel_submit - Configure engine for - * parallel submission. - * - * Setup a slot in the context engine map to allow multiple BBs to be submitted - * in a single execbuf IOCTL. Those BBs will then be scheduled to run on the GPU - * in parallel. Multiple hardware contexts are created internally in the i915 - * run these BBs. Once a slot is configured for N BBs only N BBs can be - * submitted in each execbuf IOCTL and this is implicit behavior e.g. The user - * doesn't tell the execbuf IOCTL there are N BBs, the execbuf IOCTL knows how - * many BBs there are based on the slot's configuration. The N BBs are the last - * N buffer objects or first N if I915_EXEC_BATCH_FIRST is set. - * - * The default placement behavior is to create implicit bonds between each - * context if each context maps to more than 1 physical engine (e.g. context is - * a virtual engine). Also we only allow contexts of same engine class and these - * contexts must be in logically contiguous order. Examples of the placement - * behavior described below. Lastly, the default is to not allow BBs to - * preempted mid BB rather insert coordinated preemption on all hardware - * contexts between each set of BBs. Flags may be added in the future to change - * both of these default behaviors. - * - * Returns -EINVAL if hardware context placement configuration is invalid or if - * the placement configuration isn't supported on the platform / submission - * interface. - * Returns -ENODEV if extension isn't supported on the platform / submission - * interface. - * - * .. code-block:: none - * - * Example 1 pseudo code: - * CS[X] = generic engine of same class, logical instance X - * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE - * set_engines(INVALID) - * set_parallel(engine_index=0, width=2, num_siblings=1, - * engines=CS[0],CS[1]) - * - * Results in the following valid placement: - * CS[0], CS[1] - * - * Example 2 pseudo code: - * CS[X] = generic engine of same class, logical instance X - * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE - * set_engines(INVALID) - * set_parallel(engine_index=0, width=2, num_siblings=2, - * engines=CS[0],CS[2],CS[1],CS[3]) - * - * Results in the following valid placements: - * CS[0], CS[1] - * CS[2], CS[3] - * - * This can also be thought of as 2 virtual engines described by 2-D array - * in the engines the field with bonds placed between each index of the - * virtual engines. e.g. CS[0] is bonded to CS[1], CS[2] is bonded to - * CS[3]. - * VE[0] = CS[0], CS[2] - * VE[1] = CS[1], CS[3] - * - * Example 3 pseudo code: - * CS[X] = generic engine of same class, logical instance X - * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE - * set_engines(INVALID) - * set_parallel(engine_index=0, width=2, num_siblings=2, - * engines=CS[0],CS[1],CS[1],CS[3]) - * - * Results in the following valid and invalid placements: - * CS[0], CS[1] - * CS[1], CS[3] - Not logical contiguous, return -EINVAL - */ -struct drm_i915_context_engines_parallel_submit { - /** - * @base: base user extension. - */ - struct i915_user_extension base; - - /** - * @engine_index: slot for parallel engine - */ - __u16 engine_index; - - /** - * @width: number of contexts per parallel engine - */ - __u16 width; - - /** - * @num_siblings: number of siblings per context - */ - __u16 num_siblings; - - /** - * @mbz16: reserved for future use; must be zero - */ - __u16 mbz16; - - /** - * @flags: all undefined flags must be zero, currently not defined flags - */ - __u64 flags; - - /** - * @mbz64: reserved for future use; must be zero - */ - __u64 mbz64[3]; - - /** - * @engines: 2-d array of engine instances to configure parallel engine - * - * length = width (i) * num_siblings (j) - * index = j + i * num_siblings - */ - struct i915_engine_class_instance engines[0]; - -} __packed; - diff --git a/Documentation/gpu/rfc/i915_scheduler.rst b/Documentation/gpu/rfc/i915_scheduler.rst index cbda75065dad..d630f15ab795 100644 --- a/Documentation/gpu/rfc/i915_scheduler.rst +++ b/Documentation/gpu/rfc/i915_scheduler.rst @@ -135,8 +135,8 @@ Add I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT and drm_i915_context_engines_parallel_submit to the uAPI to implement this extension. -.. kernel-doc:: Documentation/gpu/rfc/i915_parallel_execbuf.h - :functions: drm_i915_context_engines_parallel_submit +.. kernel-doc:: include/uapi/drm/i915_drm.h + :functions: i915_context_engines_parallel_submit Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL ------------------------------------------------------------------- diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 12e61869939e..60d1d7ee0719 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -314,16 +314,19 @@ Level: Advanced Garbage collect fbdev scrolling acceleration -------------------------------------------- -Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode = -SCROLL_REDRAW. There's a ton of code this will allow us to remove: +Scroll acceleration has been disabled in fbcon. Now it works as the old +SCROLL_REDRAW mode. A ton of code was removed in fbcon.c and the hook bmove was +removed from fbcon_ops. +Remaining tasks: -- lots of code in fbcon.c - -- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called +- a bunch of the hooks in fbcon_ops could be removed or simplified by calling directly instead of the function table (with a switch on p->rotate) - fb_copyarea is unused after this, and can be deleted from all drivers +- after that, fb_copyarea can be deleted from fb_ops in include/linux/fb.h as + well as cfb_copyarea + Note that not all acceleration code can be deleted, since clearing and cursor support is still accelerated, which might be good candidates for further deletion projects. @@ -353,23 +356,6 @@ converted, except for struct drm_driver.gem_prime_mmap. Level: Intermediate -Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate ---------------------------------------------------------- - -For cases where drivers are attempting to grab the modeset locks with a local -acquire context. Replace the boilerplate code surrounding -drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN() and -DRM_MODESET_LOCK_ALL_END() instead. - -This should also be done for all places where drm_modeset_lock_all() is still -used. - -As a reference, take a look at the conversions already completed in drm core. - -Contact: Sean Paul, respective driver maintainers - -Level: Starter - Rename CMA helpers to DMA helpers --------------------------------- diff --git a/Documentation/hwmon/dell-smm-hwmon.rst b/Documentation/hwmon/dell-smm-hwmon.rst index 3bf77a5df995..beec88491171 100644 --- a/Documentation/hwmon/dell-smm-hwmon.rst +++ b/Documentation/hwmon/dell-smm-hwmon.rst @@ -34,6 +34,9 @@ Name Perm Description =============================== ======= ======================================= fan[1-3]_input RO Fan speed in RPM. fan[1-3]_label RO Fan label. +fan[1-3]_min RO Minimal Fan speed in RPM +fan[1-3]_max RO Maximal Fan speed in RPM +fan[1-3]_target RO Expected Fan speed in RPM pwm[1-3] RW Control the fan PWM duty-cycle. pwm1_enable WO Enable or disable automatic BIOS fan control (not supported on all laptops, diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index f790f1260c33..7046bf1870d9 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -130,6 +130,7 @@ Hardware Monitoring Kernel Drivers max31785 max31790 max34440 + max6620 max6639 max6642 max6650 diff --git a/Documentation/hwmon/lm25066.rst b/Documentation/hwmon/lm25066.rst index 9f1d7e4d3ca1..a2098eb24090 100644 --- a/Documentation/hwmon/lm25066.rst +++ b/Documentation/hwmon/lm25066.rst @@ -79,6 +79,8 @@ This driver does not auto-detect devices. You will have to instantiate the devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for details. +The shunt (sense) resistor value can be configured by a device tree property; +see Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml for details. Platform data support --------------------- diff --git a/Documentation/hwmon/lm90.rst b/Documentation/hwmon/lm90.rst index 3da8c6e06a36..05391fb4042d 100644 --- a/Documentation/hwmon/lm90.rst +++ b/Documentation/hwmon/lm90.rst @@ -265,6 +265,16 @@ Supported chips: https://www.ti.com/litv/pdf/sbos686 + * Texas Instruments TMP461 + + Prefix: 'tmp461' + + Addresses scanned: I2C 0x48 through 0x4F + + Datasheet: Publicly available at TI website + + https://www.ti.com/lit/gpn/tmp461 + Author: Jean Delvare <jdelvare@suse.de> diff --git a/Documentation/hwmon/max6620.rst b/Documentation/hwmon/max6620.rst new file mode 100644 index 000000000000..84c1c44d3de4 --- /dev/null +++ b/Documentation/hwmon/max6620.rst @@ -0,0 +1,46 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver max6620 +===================== + +Supported chips: + + Maxim MAX6620 + + Prefix: 'max6620' + + Addresses scanned: none + + Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6620.pdf + +Authors: + - L\. Grunenberg <contact@lgrunenberg.de> + - Cumulus Networks <support@cumulusnetworks.com> + - Shuotian Cheng <shuche@microsoft.com> + - Arun Saravanan Balachandran <Arun_Saravanan_Balac@dell.com> + +Description +----------- + +This driver implements support for Maxim MAX6620 fan controller. + +The driver configures the fan controller in RPM mode. To give the readings more +range or accuracy, the desired value can be set by a programmable register +(1, 2, 4, 8, 16 or 32). Set higher values for larger speeds. + +The driver provides the following sensor access in sysfs: + +================ ======= ===================================================== +fan[1-4]_alarm ro Fan alarm. +fan[1-4]_div rw Sets the nominal RPM range of the fan. Valid values + are 1, 2, 4, 8, 16 and 32. +fan[1-4]_input ro Fan speed in RPM. +fan[1-4]_target rw Desired fan speed in RPM. +================ ======= ===================================================== + +Usage notes +----------- + +This driver does not auto-detect devices. You will have to instantiate the +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for +details. diff --git a/Documentation/hwmon/sysfs-interface.rst b/Documentation/hwmon/sysfs-interface.rst index 13c5acb72d63..85652a6aaa3e 100644 --- a/Documentation/hwmon/sysfs-interface.rst +++ b/Documentation/hwmon/sysfs-interface.rst @@ -89,6 +89,8 @@ hardware implementation. All entries (except name) are optional, and should only be created in a given driver if the chip has the feature. +See Documentation/ABI/testing/sysfs-class-hwmon for a complete description +of the attributes. ***************** Global attributes @@ -96,22 +98,9 @@ Global attributes `name` The chip name. - This should be a short, lowercase string, not containing - whitespace, dashes, or the wildcard character '*'. - This attribute represents the chip name. It is the only - mandatory attribute. - I2C devices get this attribute created automatically. - - RO `update_interval` The interval at which the chip will update readings. - Unit: millisecond - - RW - - Some devices have a variable update rate or interval. - This attribute can be used to change it to the desired value. ******** @@ -121,148 +110,51 @@ Voltages `in[0-*]_min` Voltage min value. - Unit: millivolt - - RW - `in[0-*]_lcrit` Voltage critical min value. - Unit: millivolt - - RW - - If voltage drops to or below this limit, the system may - take drastic action such as power down or reset. At the very - least, it should report a fault. - `in[0-*]_max` Voltage max value. - Unit: millivolt - - RW - `in[0-*]_crit` Voltage critical max value. - Unit: millivolt - - RW - - If voltage reaches or exceeds this limit, the system may - take drastic action such as power down or reset. At the very - least, it should report a fault. - `in[0-*]_input` Voltage input value. - Unit: millivolt - - RO - - Voltage measured on the chip pin. - - Actual voltage depends on the scaling resistors on the - motherboard, as recommended in the chip datasheet. - - This varies by chip and by motherboard. - Because of this variation, values are generally NOT scaled - by the chip driver, and must be done by the application. - However, some drivers (notably lm87 and via686a) - do scale, because of internal resistors built into a chip. - These drivers will output the actual voltage. Rule of - thumb: drivers should report the voltage values at the - "pins" of the chip. - `in[0-*]_average` Average voltage - Unit: millivolt - - RO - `in[0-*]_lowest` Historical minimum voltage - Unit: millivolt - - RO - `in[0-*]_highest` Historical maximum voltage - Unit: millivolt - - RO - `in[0-*]_reset_history` Reset inX_lowest and inX_highest - WO - `in_reset_history` Reset inX_lowest and inX_highest for all sensors - WO - `in[0-*]_label` Suggested voltage channel label. - Text string - - Should only be created if the driver has hints about what - this voltage channel is being used for, and user-space - doesn't. In all other cases, the label is provided by - user-space. - - RO - `in[0-*]_enable` Enable or disable the sensors. - When disabled the sensor read will return -ENODATA. - - - 1: Enable - - 0: Disable - - RW - `cpu[0-*]_vid` CPU core reference voltage. - Unit: millivolt - - RO - - Not always correct. - `vrm` Voltage Regulator Module version number. - RW (but changing it should no more be necessary) - - Originally the VRM standard version multiplied by 10, but now - an arbitrary number, as not all standards have a version - number. - - Affects the way the driver calculates the CPU core reference - voltage from the vid pins. - `in[0-*]_rated_min` Minimum rated voltage. - Unit: millivolt - - RO - `in[0-*]_rated_max` Maximum rated voltage. - Unit: millivolt - - RO - Also see the Alarms section for status flags associated with voltages. @@ -273,83 +165,27 @@ Fans `fan[1-*]_min` Fan minimum value - Unit: revolution/min (RPM) - - RW - `fan[1-*]_max` Fan maximum value - Unit: revolution/min (RPM) - - Only rarely supported by the hardware. - RW - `fan[1-*]_input` Fan input value. - Unit: revolution/min (RPM) - - RO - `fan[1-*]_div` Fan divisor. - Integer value in powers of two (1, 2, 4, 8, 16, 32, 64, 128). - - RW - - Some chips only support values 1, 2, 4 and 8. - Note that this is actually an internal clock divisor, which - affects the measurable speed range, not the read value. - `fan[1-*]_pulses` Number of tachometer pulses per fan revolution. - Integer value, typically between 1 and 4. - - RW - - This value is a characteristic of the fan connected to the - device's input, so it has to be set in accordance with the fan - model. - - Should only be created if the chip has a register to configure - the number of pulses. In the absence of such a register (and - thus attribute) the value assumed by all devices is 2 pulses - per fan revolution. - `fan[1-*]_target` Desired fan speed - Unit: revolution/min (RPM) - - RW - - Only makes sense if the chip supports closed-loop fan speed - control based on the measured fan speed. - `fan[1-*]_label` Suggested fan channel label. - Text string - - Should only be created if the driver has hints about what - this fan channel is being used for, and user-space doesn't. - In all other cases, the label is provided by user-space. - - RO - `fan[1-*]_enable` Enable or disable the sensors. - When disabled the sensor read will return -ENODATA. - - - 1: Enable - - 0: Disable - - RW - Also see the Alarms section for status flags associated with fans. @@ -360,63 +196,25 @@ PWM `pwm[1-*]` Pulse width modulation fan control. - Integer value in the range 0 to 255 - - RW - - 255 is max or 100%. - `pwm[1-*]_enable` Fan speed control method: - - 0: no fan speed control (i.e. fan at full speed) - - 1: manual fan speed control enabled (using `pwm[1-*]`) - - 2+: automatic fan speed control enabled - - Check individual chip documentation files for automatic mode - details. - - RW - `pwm[1-*]_mode` - - 0: DC mode (direct current) - - 1: PWM mode (pulse-width modulation) - - RW + direct current or pulse-width modulation. `pwm[1-*]_freq` Base PWM frequency in Hz. - Only possibly available when pwmN_mode is PWM, but not always - present even then. - - RW - `pwm[1-*]_auto_channels_temp` Select which temperature channels affect this PWM output in auto mode. - Bitfield, 1 is temp1, 2 is temp2, 4 is temp3 etc... - Which values are possible depend on the chip used. - - RW - `pwm[1-*]_auto_point[1-*]_pwm` / `pwm[1-*]_auto_point[1-*]_temp` / `pwm[1-*]_auto_point[1-*]_temp_hyst` Define the PWM vs temperature curve. - Number of trip points is chip-dependent. Use this for chips - which associate trip points to PWM output channels. - - RW - `temp[1-*]_auto_point[1-*]_pwm` / `temp[1-*]_auto_point[1-*]_temp` / `temp[1-*]_auto_point[1-*]_temp_hyst` Define the PWM vs temperature curve. - Number of trip points is chip-dependent. Use this for chips - which associate trip points to temperature channels. - - RW - There is a third case where trip points are associated to both PWM output channels and temperature channels: the PWM values are associated to PWM output channels while the temperature values are associated to temperature @@ -434,182 +232,70 @@ Temperatures `temp[1-*]_type` Sensor type selection. - Integers 1 to 6 - - RW - - - 1: CPU embedded diode - - 2: 3904 transistor - - 3: thermal diode - - 4: thermistor - - 5: AMD AMDSI - - 6: Intel PECI - - Not all types are supported by all chips - `temp[1-*]_max` Temperature max value. - Unit: millidegree Celsius (or millivolt, see below) - - RW - `temp[1-*]_min` Temperature min value. - Unit: millidegree Celsius - - RW - `temp[1-*]_max_hyst` Temperature hysteresis value for max limit. - Unit: millidegree Celsius - - Must be reported as an absolute temperature, NOT a delta - from the max value. - - RW - `temp[1-*]_min_hyst` Temperature hysteresis value for min limit. - Unit: millidegree Celsius - - Must be reported as an absolute temperature, NOT a delta - from the min value. - - RW `temp[1-*]_input` - Temperature input value. - - Unit: millidegree Celsius - - RO + Temperature input value. `temp[1-*]_crit` Temperature critical max value, typically greater than corresponding temp_max values. - Unit: millidegree Celsius - - RW - `temp[1-*]_crit_hyst` Temperature hysteresis value for critical limit. - Unit: millidegree Celsius - - Must be reported as an absolute temperature, NOT a delta - from the critical value. - - RW - `temp[1-*]_emergency` Temperature emergency max value, for chips supporting more than - two upper temperature limits. Must be equal or greater than - corresponding temp_crit values. - - Unit: millidegree Celsius - - RW + two upper temperature limits. `temp[1-*]_emergency_hyst` Temperature hysteresis value for emergency limit. - Unit: millidegree Celsius - - Must be reported as an absolute temperature, NOT a delta - from the emergency value. - - RW - `temp[1-*]_lcrit` Temperature critical min value, typically lower than corresponding temp_min values. - Unit: millidegree Celsius - - RW - `temp[1-*]_lcrit_hyst` Temperature hysteresis value for critical min limit. - Unit: millidegree Celsius - - Must be reported as an absolute temperature, NOT a delta - from the critical min value. - - RW - `temp[1-*]_offset` Temperature offset which is added to the temperature reading by the chip. - Unit: millidegree Celsius - - Read/Write value. - `temp[1-*]_label` Suggested temperature channel label. - Text string - - Should only be created if the driver has hints about what - this temperature channel is being used for, and user-space - doesn't. In all other cases, the label is provided by - user-space. - - RO - `temp[1-*]_lowest` Historical minimum temperature - Unit: millidegree Celsius - - RO - `temp[1-*]_highest` Historical maximum temperature - Unit: millidegree Celsius - - RO - `temp[1-*]_reset_history` Reset temp_lowest and temp_highest - WO - `temp_reset_history` Reset temp_lowest and temp_highest for all sensors - WO - `temp[1-*]_enable` Enable or disable the sensors. - When disabled the sensor read will return -ENODATA. - - - 1: Enable - - 0: Disable - - RW - `temp[1-*]_rated_min` Minimum rated temperature. - Unit: millidegree Celsius - - RO - `temp[1-*]_rated_max` Maximum rated temperature. - Unit: millidegree Celsius - - RO - Some chips measure temperature using external thermistors and an ADC, and report the temperature measurement as a voltage. Converting this voltage back to a temperature (or the other way around for limits) requires @@ -627,58 +313,28 @@ Currents ******** `curr[1-*]_max` - Current max value - - Unit: milliampere - - RW + Current max value. `curr[1-*]_min` Current min value. - Unit: milliampere - - RW - `curr[1-*]_lcrit` Current critical low value - Unit: milliampere - - RW - `curr[1-*]_crit` Current critical high value. - Unit: milliampere - - RW - `curr[1-*]_input` - Current input value - - Unit: milliampere - - RO + Current input value. `curr[1-*]_average` - Average current use - - Unit: milliampere - - RO + Average current use. `curr[1-*]_lowest` - Historical minimum current - - Unit: milliampere - - RO + Historical minimum current. `curr[1-*]_highest` - Historical maximum current - Unit: milliampere - RO + Historical maximum current. `curr[1-*]_reset_history` Reset currX_lowest and currX_highest @@ -686,34 +342,17 @@ Currents WO `curr_reset_history` - Reset currX_lowest and currX_highest for all sensors - - WO + Reset currX_lowest and currX_highest for all sensors. `curr[1-*]_enable` Enable or disable the sensors. - When disabled the sensor read will return -ENODATA. - - - 1: Enable - - 0: Disable - - RW - `curr[1-*]_rated_min` Minimum rated current. - Unit: milliampere - - RO - `curr[1-*]_rated_max` Maximum rated current. - Unit: milliampere - - RO - Also see the Alarms section for status flags associated with currents. ***** @@ -721,141 +360,62 @@ Power ***** `power[1-*]_average` - Average power use - - Unit: microWatt - - RO + Average power use. `power[1-*]_average_interval` - Power use averaging interval. A poll - notification is sent to this file if the - hardware changes the averaging interval. - - Unit: milliseconds - - RW + Power use averaging interval. `power[1-*]_average_interval_max` - Maximum power use averaging interval - - Unit: milliseconds - - RO + Maximum power use averaging interval. `power[1-*]_average_interval_min` - Minimum power use averaging interval - - Unit: milliseconds - - RO + Minimum power use averaging interval. `power[1-*]_average_highest` - Historical average maximum power use - - Unit: microWatt - - RO + Historical average maximum power use `power[1-*]_average_lowest` - Historical average minimum power use - - Unit: microWatt - - RO + Historical average minimum power use `power[1-*]_average_max` - A poll notification is sent to - `power[1-*]_average` when power use - rises above this value. - - Unit: microWatt - - RW + A poll notification is sent to `power[1-*]_average` when + power use rises above this value. `power[1-*]_average_min` - A poll notification is sent to - `power[1-*]_average` when power use - sinks below this value. - - Unit: microWatt - - RW + A poll notification is sent to `power[1-*]_average` when + power use sinks below this value. `power[1-*]_input` - Instantaneous power use - - Unit: microWatt - - RO + Instantaneous power use. `power[1-*]_input_highest` - Historical maximum power use - - Unit: microWatt - - RO + Historical maximum power use `power[1-*]_input_lowest` - Historical minimum power use - - Unit: microWatt - - RO + Historical minimum power use. `power[1-*]_reset_history` - Reset input_highest, input_lowest, - average_highest and average_lowest. - - WO + Reset input_highest, input_lowest, average_highest and + average_lowest. `power[1-*]_accuracy` - Accuracy of the power meter. - - Unit: Percent - - RO + Accuracy of the power meter. `power[1-*]_cap` - If power use rises above this limit, the - system should take action to reduce power use. - A poll notification is sent to this file if the - cap is changed by the hardware. The `*_cap` - files only appear if the cap is known to be - enforced by hardware. - - Unit: microWatt - - RW + If power use rises above this limit, the + system should take action to reduce power use. `power[1-*]_cap_hyst` - Margin of hysteresis built around capping and - notification. - - Unit: microWatt - - RW + Margin of hysteresis built around capping and notification. `power[1-*]_cap_max` - Maximum cap that can be set. - - Unit: microWatt - - RO + Maximum cap that can be set. `power[1-*]_cap_min` - Minimum cap that can be set. - - Unit: microWatt - - RO + Minimum cap that can be set. `power[1-*]_max` - Maximum power. - - Unit: microWatt - - RW + Maximum power. `power[1-*]_crit` Critical maximum power. @@ -923,37 +483,16 @@ Humidity ******** `humidity[1-*]_input` - Humidity - - Unit: milli-percent (per cent mille, pcm) - - RO - + Humidity. `humidity[1-*]_enable` - Enable or disable the sensors - - When disabled the sensor read will return - -ENODATA. - - - 1: Enable - - 0: Disable - - RW + Enable or disable the sensors. `humidity[1-*]_rated_min` - Minimum rated humidity. - - Unit: milli-percent (per cent mille, pcm) - - RO + Minimum rated humidity. `humidity[1-*]_rated_max` - Maximum rated humidity. - - Unit: milli-percent (per cent mille, pcm) - - RO + Maximum rated humidity. ****** Alarms @@ -1004,30 +543,15 @@ supports it. When this boolean has value 1, the measurement for that channel should not be trusted. `fan[1-*]_fault` / `temp[1-*]_fault` - Input fault condition - - - 0: no fault occurred - - 1: fault condition - - RO + Input fault condition. Some chips also offer the possibility to get beeped when an alarm occurs: `beep_enable` - Master beep enable - - - 0: no beeps - - 1: beeps - - RW + Master beep enable. `in[0-*]_beep`, `curr[1-*]_beep`, `fan[1-*]_beep`, `temp[1-*]_beep`, - Channel beep - - - 0: disable - - 1: enable - - RW + Channel beep. In theory, a chip could provide per-limit beep masking, but no such chip was seen so far. @@ -1039,29 +563,8 @@ for compatibility reasons: `alarms` Alarm bitmask. - RO - - Integer representation of one to four bytes. - - A '1' bit means an alarm. - - Chips should be programmed for 'comparator' mode so that - the alarm will 'come back' after you read the register - if it is still valid. - - Generally a direct representation of a chip's internal - alarm registers; there is no standard for the position - of individual bits. For this reason, the use of this - interface file for new drivers is discouraged. Use - `individual *_alarm` and `*_fault` files instead. - Bits are defined in kernel/include/sensors.h. - `beep_mask` Bitmask for beep. - Same format as 'alarms' with the same bit locations, - use discouraged for the same reason. Use individual - `*_beep` files instead. - RW ******************* @@ -1069,25 +572,10 @@ Intrusion detection ******************* `intrusion[0-*]_alarm` - Chassis intrusion detection - - - 0: OK - - 1: intrusion detected - - RW - - Contrary to regular alarm flags which clear themselves - automatically when read, this one sticks until cleared by - the user. This is done by writing 0 to the file. Writing - other values is unsupported. + Chassis intrusion detection. `intrusion[0-*]_beep` - Chassis intrusion beep - - 0: disable - 1: enable - - RW + Chassis intrusion beep. **************************** Average sample configuration diff --git a/Documentation/hwmon/tmp401.rst b/Documentation/hwmon/tmp401.rst index 14bf1fbf4493..3aacf3d3bdf3 100644 --- a/Documentation/hwmon/tmp401.rst +++ b/Documentation/hwmon/tmp401.rst @@ -43,12 +43,6 @@ Supported chips: Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp435.html - * Texas Instruments TMP461 - - Prefix: 'tmp461' - - Datasheet: https://www.ti.com/product/tmp461 - Authors: @@ -60,7 +54,7 @@ Description ----------- This driver implements support for Texas Instruments TMP401, TMP411, -TMP431, TMP432, TMP435, and TMP461 chips. These chips implement one or two +TMP431, TMP432, and TMP435 chips. These chips implement one or two remote and one local temperature sensors. Temperature is measured in degrees Celsius. Resolution of the remote sensor is 0.0625 degree. Local sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not @@ -84,10 +78,3 @@ some additional features. TMP432 is compatible with TMP401 and TMP431. It supports two external temperature sensors. - -TMP461 is compatible with TMP401. It supports offset correction -that is applied to the remote sensor. - -* Sensor offset values are temperature values - - Exported via sysfs attribute tempX_offset diff --git a/Documentation/hwmon/tmp421.rst b/Documentation/hwmon/tmp421.rst index ddcd5159c75d..a3002117bbd7 100644 --- a/Documentation/hwmon/tmp421.rst +++ b/Documentation/hwmon/tmp421.rst @@ -64,3 +64,13 @@ the temperature values via the following sysfs files: **temp[1-4]_input** **temp[2-4]_fault** + +Each sensor can be individually disabled via Devicetree or from sysfs +via: + +**temp[1-4]_enable** + +If labels were specified in Devicetree, additional sysfs files will +be present: + +**temp[1-4]_label** diff --git a/Documentation/i2c/smbus-protocol.rst b/Documentation/i2c/smbus-protocol.rst index 9e07e6bbe6a3..00d8e17d0aca 100644 --- a/Documentation/i2c/smbus-protocol.rst +++ b/Documentation/i2c/smbus-protocol.rst @@ -36,6 +36,8 @@ Key to symbols =============== ============================================================= S Start condition +Sr Repeated start condition, used to switch from write to + read mode. P Stop condition Rd/Wr (1 bit) Read/Write bit. Rd equals 1, Wr equals 0. A, NA (1 bit) Acknowledge (ACK) and Not Acknowledge (NACK) bit @@ -100,7 +102,7 @@ Implemented by i2c_smbus_read_byte_data() This reads a single byte from a device, from a designated register. The register is specified through the Comm byte:: - S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P + S Addr Wr [A] Comm [A] Sr Addr Rd [A] [Data] NA P Functionality flag: I2C_FUNC_SMBUS_READ_BYTE_DATA @@ -114,7 +116,7 @@ This operation is very like Read Byte; again, data is read from a device, from a designated register that is specified through the Comm byte. But this time, the data is a complete word (16 bits):: - S Addr Wr [A] Comm [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P + S Addr Wr [A] Comm [A] Sr Addr Rd [A] [DataLow] A [DataHigh] NA P Functionality flag: I2C_FUNC_SMBUS_READ_WORD_DATA @@ -164,7 +166,7 @@ This command selects a device register (through the Comm byte), sends 16 bits of data to it, and reads 16 bits of data in return:: S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] - S Addr Rd [A] [DataLow] A [DataHigh] NA P + Sr Addr Rd [A] [DataLow] A [DataHigh] NA P Functionality flag: I2C_FUNC_SMBUS_PROC_CALL @@ -181,7 +183,7 @@ of data is specified by the device in the Count byte. :: S Addr Wr [A] Comm [A] - S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P + Sr Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P Functionality flag: I2C_FUNC_SMBUS_READ_BLOCK_DATA @@ -212,7 +214,7 @@ This command selects a device register (through the Comm byte), sends 1 to 31 bytes of data to it, and reads 1 to 31 bytes of data in return:: S Addr Wr [A] Comm [A] Count [A] Data [A] ... - S Addr Rd [A] [Count] A [Data] ... A P + Sr Addr Rd [A] [Count] A [Data] ... A P Functionality flag: I2C_FUNC_SMBUS_BLOCK_PROC_CALL @@ -300,7 +302,7 @@ This command reads a block of bytes from a device, from a designated register that is specified through the Comm byte:: S Addr Wr [A] Comm [A] - S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P + Sr Addr Rd [A] [Data] A [Data] A ... A [Data] NA P Functionality flag: I2C_FUNC_SMBUS_READ_I2C_BLOCK diff --git a/Documentation/kbuild/Kconfig.recursion-issue-02 b/Documentation/kbuild/Kconfig.recursion-issue-02 index 0034eb494d11..09dcb92d9b43 100644 --- a/Documentation/kbuild/Kconfig.recursion-issue-02 +++ b/Documentation/kbuild/Kconfig.recursion-issue-02 @@ -42,7 +42,7 @@ # "select FW_LOADER" [0], in the end the simple alternative solution to this # problem consisted on matching semantics with newly introduced features. # -# [0] https://lkml.kernel.org/r/1432241149-8762-1-git-send-email-mcgrof@do-not-panic.com +# [0] https://lore.kernel.org/r/1432241149-8762-1-git-send-email-mcgrof@do-not-panic.com mainmenu "Simple example to demo cumulative kconfig recursive dependency implication" diff --git a/Documentation/kbuild/gcc-plugins.rst b/Documentation/kbuild/gcc-plugins.rst index 3349966f213d..0ba76719f1b9 100644 --- a/Documentation/kbuild/gcc-plugins.rst +++ b/Documentation/kbuild/gcc-plugins.rst @@ -32,6 +32,32 @@ This infrastructure was ported from grsecurity [6]_ and PaX [7]_. .. [7] https://pax.grsecurity.net/ +Purpose +======= + +GCC plugins are designed to provide a place to experiment with potential +compiler features that are neither in GCC nor Clang upstream. Once +their utility is proven, the goal is to upstream the feature into GCC +(and Clang), and then to finally remove them from the kernel once the +feature is available in all supported versions of GCC. + +Specifically, new plugins should implement only features that have no +upstream compiler support (in either GCC or Clang). + +When a feature exists in Clang but not GCC, effort should be made to +bring the feature to upstream GCC (rather than just as a kernel-specific +GCC plugin), so the entire ecosystem can benefit from it. + +Similarly, even if a feature provided by a GCC plugin does *not* exist +in Clang, but the feature is proven to be useful, effort should be spent +to upstream the feature to GCC (and Clang). + +After a feature is available in upstream GCC, the plugin will be made +unbuildable for the corresponding GCC version (and later). Once all +kernel-supported versions of GCC provide the feature, the plugin will +be removed from the kernel. + + Files ===== @@ -70,7 +96,6 @@ Enable the GCC plugin infrastructure and some plugin(s) you want to use in the kernel config:: CONFIG_GCC_PLUGINS=y - CONFIG_GCC_PLUGIN_CYC_COMPLEXITY=y CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y ... @@ -89,4 +114,3 @@ The GCC plugins are in scripts/gcc-plugins/. You need to put plugin source files right under scripts/gcc-plugins/. Creating subdirectories is not supported. It must be added to scripts/gcc-plugins/Makefile, scripts/Makefile.gcc-plugins and a relevant Kconfig file. -See the cyc_complexity_plugin.c (CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) GCC plugin. diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index db3af0b45baf..b008b90b92c9 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -1050,22 +1050,9 @@ is not sufficient this sometimes needs to be explicit. The above assignment instructs kbuild to descend down in the directory compressed/ when "make clean" is executed. -To support the clean infrastructure in the Makefiles that build the -final bootimage there is an optional target named archclean: - - Example:: - - #arch/x86/Makefile - archclean: - $(Q)$(MAKE) $(clean)=arch/x86/boot - -When "make clean" is executed, make will descend down in arch/x86/boot, -and clean as usual. The Makefile located in arch/x86/boot/ may use -the subdir- trick to descend further down. - Note 1: arch/$(SRCARCH)/Makefile cannot use "subdir-", because that file is -included in the top level makefile, and the kbuild infrastructure -is not operational at that point. +included in the top level makefile. Instead, arch/$(SRCARCH)/Kbuild can use +"subdir-". Note 2: All directories listed in core-y, libs-y, drivers-y and net-y will be visited during "make clean". diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst index 90bc3f51eda9..e6cd40663ea5 100644 --- a/Documentation/kernel-hacking/locking.rst +++ b/Documentation/kernel-hacking/locking.rst @@ -1352,7 +1352,19 @@ Mutex API reference Futex API reference =================== -.. kernel-doc:: kernel/futex.c +.. kernel-doc:: kernel/futex/core.c + :internal: + +.. kernel-doc:: kernel/futex/futex.h + :internal: + +.. kernel-doc:: kernel/futex/pi.c + :internal: + +.. kernel-doc:: kernel/futex/requeue.c + :internal: + +.. kernel-doc:: kernel/futex/waitwake.c :internal: Further reading diff --git a/Documentation/leds/well-known-leds.txt b/Documentation/leds/well-known-leds.txt index 4a8b9dc4bf52..2160382c86be 100644 --- a/Documentation/leds/well-known-leds.txt +++ b/Documentation/leds/well-known-leds.txt @@ -16,6 +16,20 @@ but then try the legacy ones, too. Notice there's a list of functions in include/dt-bindings/leds/common.h . +* Gamepads and joysticks + +Game controllers may feature LEDs to indicate a player number. This is commonly +used on game consoles in which multiple controllers can be connected to a system. +The "player LEDs" are then programmed with a pattern to indicate a particular +player. For example, a game controller with 4 LEDs, may be programmed with "x---" +to indicate player 1, "-x--" to indicate player 2 etcetera where "x" means on. +Input drivers can utilize the LED class to expose the individual player LEDs +of a game controller using the function "player". +Note: tracking and management of Player IDs is the responsibility of user space, +though drivers may pick a default value. + +Good: "input*:*:player-{1,2,3,4,5} + * Keyboards Good: "input*:*:capslock" diff --git a/Documentation/locking/ww-mutex-design.rst b/Documentation/locking/ww-mutex-design.rst index 6a4d7319f8f0..6a8f8beb9ec4 100644 --- a/Documentation/locking/ww-mutex-design.rst +++ b/Documentation/locking/ww-mutex-design.rst @@ -60,7 +60,7 @@ Concepts Compared to normal mutexes two additional concepts/objects show up in the lock interface for w/w mutexes: -Acquire context: To ensure eventual forward progress it is important the a task +Acquire context: To ensure eventual forward progress it is important that a task trying to acquire locks doesn't grab a new reservation id, but keeps the one it acquired when starting the lock acquisition. This ticket is stored in the acquire context. Furthermore the acquire context keeps track of debugging state diff --git a/Documentation/maintainer/pull-requests.rst b/Documentation/maintainer/pull-requests.rst index 1a2f99b67d25..e072de60ccb0 100644 --- a/Documentation/maintainer/pull-requests.rst +++ b/Documentation/maintainer/pull-requests.rst @@ -15,7 +15,7 @@ please direct abuse to Tobin C. Harding <me@tobin.cc>. Original email thread:: - http://lkml.kernel.org/r/20171114110500.GA21175@kroah.com + https://lore.kernel.org/r/20171114110500.GA21175@kroah.com Create Branch diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst index 4b59cf2c599f..5edf50d7dbd5 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst @@ -543,6 +543,8 @@ The CR-space dump uses vsc interface which is valid even if the FW command interface is not functional, which is the case in most FW fatal errors. The recover function runs recover flow which reloads the driver and triggers fw reset if needed. +On firmware error, the health buffer is dumped into the dmesg. The log +level is derived from the error's severity (given in health buffer). User commands examples: @@ -700,3 +702,61 @@ Eswitch QoS tracepoints: $ cat /sys/kernel/debug/tracing/trace ... <...>-27418 [006] .... 76547.187258: mlx5_esw_group_qos_destroy: (0000:82:00.0) group=000000007b576bb3 tsar_ix=1 + +SF tracepoints: + +- mlx5_sf_add: trace addition of the SF port:: + + $ echo mlx5:mlx5_sf_add >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + devlink-9363 [031] ..... 24610.188722: mlx5_sf_add: (0000:06:00.0) port_index=32768 controller=0 hw_id=0x8000 sfnum=88 + +- mlx5_sf_free: trace freeing of the SF port:: + + $ echo mlx5:mlx5_sf_free >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + devlink-9830 [038] ..... 26300.404749: mlx5_sf_free: (0000:06:00.0) port_index=32768 controller=0 hw_id=0x8000 + +- mlx5_sf_hwc_alloc: trace allocating of the hardware SF context:: + + $ echo mlx5:mlx5_sf_hwc_alloc >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + devlink-9775 [031] ..... 26296.385259: mlx5_sf_hwc_alloc: (0000:06:00.0) controller=0 hw_id=0x8000 sfnum=88 + +- mlx5_sf_hwc_free: trace freeing of the hardware SF context:: + + $ echo mlx5:mlx5_sf_hwc_free >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + kworker/u128:3-9093 [046] ..... 24625.365771: mlx5_sf_hwc_free: (0000:06:00.0) hw_id=0x8000 + +- mlx5_sf_hwc_deferred_free : trace deferred freeing of the hardware SF context:: + + $ echo mlx5:mlx5_sf_hwc_deferred_free >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + devlink-9519 [046] ..... 24624.400271: mlx5_sf_hwc_deferred_free: (0000:06:00.0) hw_id=0x8000 + +- mlx5_sf_vhca_event: trace SF vhca event and state:: + + $ echo mlx5:mlx5_sf_vhca_event >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + kworker/u128:3-9093 [046] ..... 24625.365525: mlx5_sf_vhca_event: (0000:06:00.0) hw_id=0x8000 sfnum=88 vhca_state=1 + +- mlx5_sf_dev_add : trace SF device add event:: + + $ echo mlx5:mlx5_sf_dev_add>> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + kworker/u128:3-9093 [000] ..... 24616.524495: mlx5_sf_dev_add: (0000:06:00.0) sfdev=00000000fc5d96fd aux_id=4 hw_id=0x8000 sfnum=88 + +- mlx5_sf_dev_del : trace SF device delete event:: + + $ echo mlx5:mlx5_sf_dev_del >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + kworker/u128:3-9093 [044] ..... 24624.400749: mlx5_sf_dev_del: (0000:06:00.0) sfdev=00000000fc5d96fd aux_id=4 hw_id=0x8000 sfnum=88 diff --git a/Documentation/networking/devlink/bnxt.rst b/Documentation/networking/devlink/bnxt.rst index 3dfd84ccb1c7..a4fb27663cd6 100644 --- a/Documentation/networking/devlink/bnxt.rst +++ b/Documentation/networking/devlink/bnxt.rst @@ -22,6 +22,8 @@ Parameters - Permanent * - ``msix_vec_per_pf_min`` - Permanent + * - ``enable_remote_dev_reset`` + - Runtime The ``bnxt`` driver also implements the following driver-specific parameters. diff --git a/Documentation/networking/devlink/devlink-region.rst b/Documentation/networking/devlink/devlink-region.rst index 58fe95e9a49d..f06dca9a1eb6 100644 --- a/Documentation/networking/devlink/devlink-region.rst +++ b/Documentation/networking/devlink/devlink-region.rst @@ -44,8 +44,8 @@ example usage # Show all of the exposed regions with region sizes: $ devlink region show - pci/0000:00:05.0/cr-space: size 1048576 snapshot [1 2] - pci/0000:00:05.0/fw-health: size 64 snapshot [1 2] + pci/0000:00:05.0/cr-space: size 1048576 snapshot [1 2] max 8 + pci/0000:00:05.0/fw-health: size 64 snapshot [1 2] max 8 # Delete a snapshot using: $ devlink region del pci/0000:00:05.0/cr-space snapshot 1 diff --git a/Documentation/networking/devlink/ice.rst b/Documentation/networking/devlink/ice.rst index a432dc419fa4..59c78e9717d2 100644 --- a/Documentation/networking/devlink/ice.rst +++ b/Documentation/networking/devlink/ice.rst @@ -30,10 +30,11 @@ The ``ice`` driver reports the following versions PHY, link, etc. * - ``fw.mgmt.api`` - running - - 1.5 - - 2-digit version number of the API exported over the AdminQ by the - management firmware. Used by the driver to identify what commands - are supported. + - 1.5.1 + - 3-digit version number (major.minor.patch) of the API exported over + the AdminQ by the management firmware. Used by the driver to + identify what commands are supported. Historical versions of the + kernel only displayed a 2-digit version number (major.minor). * - ``fw.mgmt.build`` - running - 0x305d955f @@ -141,6 +142,10 @@ Users can request an immediate capture of a snapshot via the .. code:: shell + $ devlink region show + pci/0000:01:00.0/nvm-flash: size 10485760 snapshot [] max 1 + pci/0000:01:00.0/device-caps: size 4096 snapshot [] max 10 + $ devlink region new pci/0000:01:00.0/nvm-flash snapshot 1 $ devlink region dump pci/0000:01:00.0/nvm-flash snapshot 1 diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst index 45b5f8b341df..443123772f44 100644 --- a/Documentation/networking/devlink/index.rst +++ b/Documentation/networking/devlink/index.rst @@ -47,3 +47,5 @@ parameters, info versions, and other features it supports. ti-cpsw-switch am65-nuss-cpsw-switch prestera + iosm + octeontx2 diff --git a/Documentation/networking/devlink/iosm.rst b/Documentation/networking/devlink/iosm.rst new file mode 100644 index 000000000000..6136181339aa --- /dev/null +++ b/Documentation/networking/devlink/iosm.rst @@ -0,0 +1,162 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================== +iosm devlink support +==================== + +This document describes the devlink features implemented by the ``iosm`` +device driver. + +Parameters +========== + +The ``iosm`` driver implements the following driver-specific parameters. + +.. list-table:: Driver-specific parameters implemented + :widths: 5 5 5 85 + + * - Name + - Type + - Mode + - Description + * - ``erase_full_flash`` + - u8 + - runtime + - erase_full_flash parameter is used to check if full erase is required for + the device during firmware flashing. + If set, Full nand erase command will be sent to the device. By default, + only conditional erase support is enabled. + + +Flash Update +============ + +The ``iosm`` driver implements support for flash update using the +``devlink-flash`` interface. + +It supports updating the device flash using a combined flash image which contains +the Bootloader images and other modem software images. + +The driver uses DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT to identify type of +firmware image that need to be flashed as requested by user space application. +Supported firmware image types. + +.. list-table:: Firmware Image types + :widths: 15 85 + + * - Name + - Description + * - ``PSI RAM`` + - Primary Signed Image + * - ``EBL`` + - External Bootloader + * - ``FLS`` + - Modem Software Image + +PSI RAM and EBL are the RAM images which are injected to the device when the +device is in BOOT ROM stage. Once this is successful, the actual modem firmware +image is flashed to the device. The modem software image contains multiple files +each having one secure bin file and at least one Loadmap/Region file. For flashing +these files, appropriate commands are sent to the modem device along with the +data required for flashing. The data like region count and address of each region +has to be passed to the driver using the devlink param command. + +If the device has to be fully erased before firmware flashing, user application +need to set the erase_full_flash parameter using devlink param command. +By default, conditional erase feature is supported. + +Flash Commands: +=============== +1) When modem is in Boot ROM stage, user can use below command to inject PSI RAM +image using devlink flash command. + +$ devlink dev flash pci/0000:02:00.0 file <PSI_RAM_File_name> + +2) If user want to do a full erase, below command need to be issued to set the +erase full flash param (To be set only if full erase required). + +$ devlink dev param set pci/0000:02:00.0 name erase_full_flash value true cmode runtime + +3) Inject EBL after the modem is in PSI stage. + +$ devlink dev flash pci/0000:02:00.0 file <EBL_File_name> + +4) Once EBL is injected successfully, then the actual firmware flashing takes +place. Below is the sequence of commands used for each of the firmware images. + +a) Flash secure bin file. + +$ devlink dev flash pci/0000:02:00.0 file <Secure_bin_file_name> + +b) Flashing the Loadmap/Region file + +$ devlink dev flash pci/0000:02:00.0 file <Load_map_file_name> + +Regions +======= + +The ``iosm`` driver supports dumping the coredump logs. + +In case a firmware encounters an exception, a snapshot will be taken by the +driver. Following regions are accessed for device internal data. + +.. list-table:: Regions implemented + :widths: 15 85 + + * - Name + - Description + * - ``report.json`` + - The summary of exception details logged as part of this region. + * - ``coredump.fcd`` + - This region contains the details related to the exception occurred in the + device (RAM dump). + * - ``cdd.log`` + - This region contains the logs related to the modem CDD driver. + * - ``eeprom.bin`` + - This region contains the eeprom logs. + * - ``bootcore_trace.bin`` + - This region contains the current instance of bootloader logs. + * - ``bootcore_prev_trace.bin`` + - This region contains the previous instance of bootloader logs. + + +Region commands +=============== + +$ devlink region show + +$ devlink region new pci/0000:02:00.0/report.json + +$ devlink region dump pci/0000:02:00.0/report.json snapshot 0 + +$ devlink region del pci/0000:02:00.0/report.json snapshot 0 + +$ devlink region new pci/0000:02:00.0/coredump.fcd + +$ devlink region dump pci/0000:02:00.0/coredump.fcd snapshot 1 + +$ devlink region del pci/0000:02:00.0/coredump.fcd snapshot 1 + +$ devlink region new pci/0000:02:00.0/cdd.log + +$ devlink region dump pci/0000:02:00.0/cdd.log snapshot 2 + +$ devlink region del pci/0000:02:00.0/cdd.log snapshot 2 + +$ devlink region new pci/0000:02:00.0/eeprom.bin + +$ devlink region dump pci/0000:02:00.0/eeprom.bin snapshot 3 + +$ devlink region del pci/0000:02:00.0/eeprom.bin snapshot 3 + +$ devlink region new pci/0000:02:00.0/bootcore_trace.bin + +$ devlink region dump pci/0000:02:00.0/bootcore_trace.bin snapshot 4 + +$ devlink region del pci/0000:02:00.0/bootcore_trace.bin snapshot 4 + +$ devlink region new pci/0000:02:00.0/bootcore_prev_trace.bin + +$ devlink region dump pci/0000:02:00.0/bootcore_prev_trace.bin snapshot 5 + +$ devlink region del pci/0000:02:00.0/bootcore_prev_trace.bin snapshot 5 diff --git a/Documentation/networking/devlink/octeontx2.rst b/Documentation/networking/devlink/octeontx2.rst new file mode 100644 index 000000000000..610de99b728a --- /dev/null +++ b/Documentation/networking/devlink/octeontx2.rst @@ -0,0 +1,42 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +octeontx2 devlink support +========================= + +This document describes the devlink features implemented by the ``octeontx2 AF, PF and VF`` +device drivers. + +Parameters +========== + +The ``octeontx2 PF and VF`` drivers implement the following driver-specific parameters. + +.. list-table:: Driver-specific parameters implemented + :widths: 5 5 5 85 + + * - Name + - Type + - Mode + - Description + * - ``mcam_count`` + - u16 + - runtime + - Select number of match CAM entries to be allocated for an interface. + The same is used for ntuple filters of the interface. Supported by + PF and VF drivers. + +The ``octeontx2 AF`` driver implements the following driver-specific parameters. + +.. list-table:: Driver-specific parameters implemented + :widths: 5 5 5 85 + + * - Name + - Type + - Mode + - Description + * - ``dwrr_mtu`` + - u32 + - runtime + - Use to set the quantum which hardware uses for scheduling among transmit queues. + Hardware uses weighted DWRR algorithm to schedule among all transmit queues. diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index d9b55b7a1a4d..7b598c7e3912 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -41,6 +41,11 @@ In the message structure descriptions below, if an attribute name is suffixed with "+", parent nest can contain multiple attributes of the same type. This implements an array of entries. +Attributes that need to be filled-in by device drivers and that are dumped to +user space based on whether they are valid or not should not use zero as a +valid value. This avoids the need to explicitly signal the validity of the +attribute in the device driver API. + Request header ============== @@ -179,7 +184,7 @@ according to message purpose: Userspace to kernel: - ===================================== ================================ + ===================================== ================================= ``ETHTOOL_MSG_STRSET_GET`` get string set ``ETHTOOL_MSG_LINKINFO_GET`` get link settings ``ETHTOOL_MSG_LINKINFO_SET`` set link settings @@ -213,7 +218,9 @@ Userspace to kernel: ``ETHTOOL_MSG_MODULE_EEPROM_GET`` read SFP module EEPROM ``ETHTOOL_MSG_STATS_GET`` get standard statistics ``ETHTOOL_MSG_PHC_VCLOCKS_GET`` get PHC virtual clocks info - ===================================== ================================ + ``ETHTOOL_MSG_MODULE_SET`` set transceiver module parameters + ``ETHTOOL_MSG_MODULE_GET`` get transceiver module parameters + ===================================== ================================= Kernel to userspace: @@ -252,6 +259,7 @@ Kernel to userspace: ``ETHTOOL_MSG_MODULE_EEPROM_GET_REPLY`` read SFP module EEPROM ``ETHTOOL_MSG_STATS_GET_REPLY`` standard statistics ``ETHTOOL_MSG_PHC_VCLOCKS_GET_REPLY`` PHC virtual clocks info + ``ETHTOOL_MSG_MODULE_GET_REPLY`` transceiver module parameters ======================================== ================================= ``GET`` requests are sent by userspace applications to retrieve device @@ -520,6 +528,8 @@ Link extended states: power required from cable or module ``ETHTOOL_LINK_EXT_STATE_OVERHEAT`` The module is overheated + + ``ETHTOOL_LINK_EXT_STATE_MODULE`` Transceiver module issue ================================================ ============================================ Link extended substates: @@ -613,6 +623,14 @@ Link extended substates: ``ETHTOOL_LINK_EXT_SUBSTATE_CI_CABLE_TEST_FAILURE`` Cable test failure =================================================== ============================================ + Transceiver module issue substates: + + =================================================== ============================================ + ``ETHTOOL_LINK_EXT_SUBSTATE_MODULE_CMIS_NOT_READY`` The CMIS Module State Machine did not reach + the ModuleReady state. For example, if the + module is stuck at ModuleFault state + =================================================== ============================================ + DEBUG_GET ========= @@ -1521,6 +1539,63 @@ Kernel response contents: ``ETHTOOL_A_PHC_VCLOCKS_INDEX`` s32 PHC index array ==================================== ====== ========================== +MODULE_GET +========== + +Gets transceiver module parameters. + +Request contents: + + ===================================== ====== ========================== + ``ETHTOOL_A_MODULE_HEADER`` nested request header + ===================================== ====== ========================== + +Kernel response contents: + + ====================================== ====== ========================== + ``ETHTOOL_A_MODULE_HEADER`` nested reply header + ``ETHTOOL_A_MODULE_POWER_MODE_POLICY`` u8 power mode policy + ``ETHTOOL_A_MODULE_POWER_MODE`` u8 operational power mode + ====================================== ====== ========================== + +The optional ``ETHTOOL_A_MODULE_POWER_MODE_POLICY`` attribute encodes the +transceiver module power mode policy enforced by the host. The default policy +is driver-dependent, but "auto" is the recommended default and it should be +implemented by new drivers and drivers where conformance to a legacy behavior +is not critical. + +The optional ``ETHTHOOL_A_MODULE_POWER_MODE`` attribute encodes the operational +power mode policy of the transceiver module. It is only reported when a module +is plugged-in. Possible values are: + +.. kernel-doc:: include/uapi/linux/ethtool.h + :identifiers: ethtool_module_power_mode + +MODULE_SET +========== + +Sets transceiver module parameters. + +Request contents: + + ====================================== ====== ========================== + ``ETHTOOL_A_MODULE_HEADER`` nested request header + ``ETHTOOL_A_MODULE_POWER_MODE_POLICY`` u8 power mode policy + ====================================== ====== ========================== + +When set, the optional ``ETHTOOL_A_MODULE_POWER_MODE_POLICY`` attribute is used +to set the transceiver module power policy enforced by the host. Possible +values are: + +.. kernel-doc:: include/uapi/linux/ethtool.h + :identifiers: ethtool_module_power_mode_policy + +For SFF-8636 modules, low power mode is forced by the host according to table +6-10 in revision 2.10a of the specification. + +For CMIS modules, low power mode is forced by the host according to table 6-12 +in revision 5.0 of the specification. + Request translation =================== @@ -1620,4 +1695,6 @@ are netlink only. n/a ``ETHTOOL_MSG_CABLE_TEST_TDR_ACT`` n/a ``ETHTOOL_MSG_TUNNEL_INFO_GET`` n/a ``ETHTOOL_MSG_PHC_VCLOCKS_GET`` + n/a ``ETHTOOL_MSG_MODULE_GET`` + n/a ``ETHTOOL_MSG_MODULE_SET`` =================================== ===================================== diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index d91ab28718d4..c04431144f7a 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -989,14 +989,6 @@ tcp_challenge_ack_limit - INTEGER in RFC 5961 (Improving TCP's Robustness to Blind In-Window Attacks) Default: 1000 -tcp_rx_skb_cache - BOOLEAN - Controls a per TCP socket cache of one skb, that might help - performance of some workloads. This might be dangerous - on systems with a lot of TCP sockets, since it increases - memory usage. - - Default: 0 (disabled) - UDP variables ============= @@ -1012,13 +1004,11 @@ udp_l3mdev_accept - BOOLEAN udp_mem - vector of 3 INTEGERs: min, pressure, max Number of pages allowed for queueing by all UDP sockets. - min: Below this number of pages UDP is not bothered about its - memory appetite. When amount of memory allocated by UDP exceeds - this number, UDP starts to moderate memory usage. + min: Number of pages allowed for queueing by all UDP sockets. pressure: This value was introduced to follow format of tcp_mem. - max: Number of pages allowed for queueing by all UDP sockets. + max: This value was introduced to follow format of tcp_mem. Default is calculated at boot time from amount of available memory. @@ -1619,6 +1609,15 @@ arp_accept - BOOLEAN gratuitous arp frame, the arp table will be updated regardless if this setting is on or off. +arp_evict_nocarrier - BOOLEAN + Clears the ARP cache on NOCARRIER events. This option is important for + wireless devices where the ARP cache should not be cleared when roaming + between access points on the same network. In most cases this should + remain as the default (1). + + - 1 - (default): Clear the ARP cache on NOCARRIER events + - 0 - Do not clear ARP cache on NOCARRIER events + mcast_solicit - INTEGER The maximum number of multicast probes in INCOMPLETE state, when the associated hardware address is unknown. Defaults @@ -2349,6 +2348,15 @@ ndisc_tclass - INTEGER * 0 - (default) +ndisc_evict_nocarrier - BOOLEAN + Clears the neighbor discovery table on NOCARRIER events. This option is + important for wireless devices where the neighbor discovery cache should + not be cleared when roaming between access points on the same network. + In most cases this should remain as the default (1). + + - 1 - (default): Clear neighbor discover cache on NOCARRIER events. + - 0 - Do not clear neighbor discovery cache on NOCARRIER events. + mldv1_unsolicited_report_interval - INTEGER The interval in milliseconds in which the next unsolicited MLDv1 report retransmit will take place. diff --git a/Documentation/networking/ipvs-sysctl.rst b/Documentation/networking/ipvs-sysctl.rst index 2afccc63856e..387fda80f05f 100644 --- a/Documentation/networking/ipvs-sysctl.rst +++ b/Documentation/networking/ipvs-sysctl.rst @@ -37,8 +37,7 @@ conn_reuse_mode - INTEGER 0: disable any special handling on port reuse. The new connection will be delivered to the same real server that was - servicing the previous connection. This will effectively - disable expire_nodest_conn. + servicing the previous connection. bit 1: enable rescheduling of new connections when it is safe. That is, whenever expire_nodest_conn and for TCP sockets, when @@ -300,3 +299,14 @@ sync_version - INTEGER Kernels with this sync_version entry are able to receive messages of both version 1 and version 2 of the synchronisation protocol. + +run_estimation - BOOLEAN + 0 - disabled + not 0 - enabled (default) + + If disabled, the estimation will be stop, and you can't see + any update on speed estimation data. + + You can always re-enable estimation by setting this value to 1. + But be careful, the first estimation after re-enable is not + accurate. diff --git a/Documentation/networking/mctp.rst b/Documentation/networking/mctp.rst index 6100cdc220f6..46f74bffce0f 100644 --- a/Documentation/networking/mctp.rst +++ b/Documentation/networking/mctp.rst @@ -59,11 +59,11 @@ specified with a ``sockaddr`` type, with a single-byte endpoint address: }; struct sockaddr_mctp { - unsigned short int smctp_family; - int smctp_network; - struct mctp_addr smctp_addr; - __u8 smctp_type; - __u8 smctp_tag; + __kernel_sa_family_t smctp_family; + unsigned int smctp_network; + struct mctp_addr smctp_addr; + __u8 smctp_type; + __u8 smctp_tag; }; #define MCTP_NET_ANY 0x0 @@ -211,3 +211,62 @@ remote address is already known, or the message does not require a reply. Like the send calls, sockets will only receive responses to requests they have sent (TO=1) and may only respond (TO=0) to requests they have received. + +Kernel internals +================ + +There are a few possible packet flows in the MCTP stack: + +1. local TX to remote endpoint, message <= MTU:: + + sendmsg() + -> mctp_local_output() + : route lookup + -> rt->output() (== mctp_route_output) + -> dev_queue_xmit() + +2. local TX to remote endpoint, message > MTU:: + + sendmsg() + -> mctp_local_output() + -> mctp_do_fragment_route() + : creates packet-sized skbs. For each new skb: + -> rt->output() (== mctp_route_output) + -> dev_queue_xmit() + +3. remote TX to local endpoint, single-packet message:: + + mctp_pkttype_receive() + : route lookup + -> rt->output() (== mctp_route_input) + : sk_key lookup + -> sock_queue_rcv_skb() + +4. remote TX to local endpoint, multiple-packet message:: + + mctp_pkttype_receive() + : route lookup + -> rt->output() (== mctp_route_input) + : sk_key lookup + : stores skb in struct sk_key->reasm_head + + mctp_pkttype_receive() + : route lookup + -> rt->output() (== mctp_route_input) + : sk_key lookup + : finds existing reassembly in sk_key->reasm_head + : appends new fragment + -> sock_queue_rcv_skb() + +Key refcounts +------------- + + * keys are refed by: + + - a skb: during route output, stored in ``skb->cb``. + + - netns and sock lists. + + * keys can be associated with a device, in which case they hold a + reference to the dev (set through ``key->dev``, counted through + ``dev->key_count``). Multiple keys can reference the device. diff --git a/Documentation/networking/msg_zerocopy.rst b/Documentation/networking/msg_zerocopy.rst index ace56204dd03..15920db8d35d 100644 --- a/Documentation/networking/msg_zerocopy.rst +++ b/Documentation/networking/msg_zerocopy.rst @@ -50,7 +50,7 @@ the excellent reporting over at LWN.net or read the original code. patchset [PATCH net-next v4 0/9] socket sendmsg MSG_ZEROCOPY - https://lkml.kernel.org/netdev/20170803202945.70750-1-willemdebruijn.kernel@gmail.com + https://lore.kernel.org/netdev/20170803202945.70750-1-willemdebruijn.kernel@gmail.com Interface diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst index a722eb30e014..80b13353254a 100644 --- a/Documentation/networking/timestamping.rst +++ b/Documentation/networking/timestamping.rst @@ -486,8 +486,8 @@ of packets. Drivers are free to use a more permissive configuration than the requested configuration. It is expected that drivers should only implement directly the most generic mode that can be supported. For example if the hardware can -support HWTSTAMP_FILTER_V2_EVENT, then it should generally always upscale -HWTSTAMP_FILTER_V2_L2_SYNC_MESSAGE, and so forth, as HWTSTAMP_FILTER_V2_EVENT +support HWTSTAMP_FILTER_PTP_V2_EVENT, then it should generally always upscale +HWTSTAMP_FILTER_PTP_V2_L2_SYNC, and so forth, as HWTSTAMP_FILTER_PTP_V2_EVENT is more generic (and more useful to applications). A driver which supports hardware time stamping shall update the struct diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index 8a2788afe89b..5ac62a7b4b7c 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -84,6 +84,16 @@ CONFIG_ENERGY_MODEL must be enabled to use the EM framework. 2.2 Registration of performance domains ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Registration of 'advanced' EM +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The 'advanced' EM gets it's name due to the fact that the driver is allowed +to provide more precised power model. It's not limited to some implemented math +formula in the framework (like it's in 'simple' EM case). It can better reflect +the real power measurements performed for each performance state. Thus, this +registration method should be preferred in case considering EM static power +(leakage) is important. + Drivers are expected to register performance domains into the EM framework by calling the following API:: @@ -103,6 +113,18 @@ to: return warning/error, stop working or panic. See Section 3. for an example of driver implementing this callback, or Section 2.4 for further documentation on this API +Registration of 'simple' EM +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The 'simple' EM is registered using the framework helper function +cpufreq_register_em_with_opp(). It implements a power model which is tight to +math formula:: + + Power = C * V^2 * f + +The EM which is registered using this method might not reflect correctly the +physics of a real device, e.g. when static power (leakage) is important. + 2.3 Accessing performance domains ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -138,6 +160,10 @@ or in Section 2.4 3. Example driver ----------------- +The CPUFreq framework supports dedicated callback for registering +the EM for a given CPU(s) 'policy' object: cpufreq_driver::register_em(). +That callback has to be implemented properly for a given driver, +because the framework would call it at the right time during setup. This section provides a simple example of a CPUFreq driver registering a performance domain in the Energy Model framework using the (fake) 'foo' protocol. The driver implements an est_power() function to be provided to the @@ -167,25 +193,22 @@ EM framework:: 20 return 0; 21 } 22 - 23 static int foo_cpufreq_init(struct cpufreq_policy *policy) + 23 static void foo_cpufreq_register_em(struct cpufreq_policy *policy) 24 { 25 struct em_data_callback em_cb = EM_DATA_CB(est_power); 26 struct device *cpu_dev; - 27 int nr_opp, ret; + 27 int nr_opp; 28 29 cpu_dev = get_cpu_device(cpumask_first(policy->cpus)); 30 - 31 /* Do the actual CPUFreq init work ... */ - 32 ret = do_foo_cpufreq_init(policy); - 33 if (ret) - 34 return ret; - 35 - 36 /* Find the number of OPPs for this policy */ - 37 nr_opp = foo_get_nr_opp(policy); + 31 /* Find the number of OPPs for this policy */ + 32 nr_opp = foo_get_nr_opp(policy); + 33 + 34 /* And register the new performance domain */ + 35 em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus, + 36 true); + 37 } 38 - 39 /* And register the new performance domain */ - 40 em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus, - 41 true); - 42 - 43 return 0; - 44 } + 39 static struct cpufreq_driver foo_cpufreq_driver = { + 40 .register_em = foo_cpufreq_register_em, + 41 }; diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index e35ab74a0f80..b398b8576417 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -54,7 +54,7 @@ mcelog 0.6 mcelog --version iptables 1.4.2 iptables -V openssl & libcrypto 1.0.0 openssl version bc 1.06.95 bc --version -Sphinx\ [#f1]_ 1.3 sphinx-build --version +Sphinx\ [#f1]_ 1.7 sphinx-build --version ====================== =============== ======================================== .. [#f1] Sphinx is needed only to build the Kernel documentation diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index 42969ab37b34..03eb53fd029a 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -480,13 +480,48 @@ closing function brace line. E.g.: } EXPORT_SYMBOL(system_is_up); +6.1) Function prototypes +************************ + In function prototypes, include parameter names with their data types. Although this is not required by the C language, it is preferred in Linux because it is a simple way to add valuable information for the reader. -Do not use the ``extern`` keyword with function prototypes as this makes +Do not use the ``extern`` keyword with function declarations as this makes lines longer and isn't strictly necessary. +When writing function prototypes, please keep the `order of elements regular +<https://lore.kernel.org/mm-commits/CAHk-=wiOCLRny5aifWNhr621kYrJwhfURsa0vFPeUEm8mF0ufg@mail.gmail.com/>`_. +For example, using this function declaration example:: + + __init void * __must_check action(enum magic value, size_t size, u8 count, + char *fmt, ...) __printf(4, 5) __malloc; + +The preferred order of elements for a function prototype is: + +- storage class (below, ``static __always_inline``, noting that ``__always_inline`` + is technically an attribute but is treated like ``inline``) +- storage class attributes (here, ``__init`` -- i.e. section declarations, but also + things like ``__cold``) +- return type (here, ``void *``) +- return type attributes (here, ``__must_check``) +- function name (here, ``action``) +- function parameters (here, ``(enum magic value, size_t size, u8 count, char *fmt, ...)``, + noting that parameter names should always be included) +- function parameter attributes (here, ``__printf(4, 5)``) +- function behavior attributes (here, ``__malloc``) + +Note that for a function **definition** (i.e. the actual function body), +the compiler does not allow function parameter attributes after the +function parameters. In these cases, they should go after the storage +class attributes (e.g. note the changed position of ``__printf(4, 5)`` +below, compared to the **declaration** example above):: + + static __always_inline __init __printf(4, 5) void * __must_check action(enum magic value, + size_t size, u8 count, char *fmt, ...) __malloc + { + ... + } 7) Centralized exiting of functions ----------------------------------- @@ -855,7 +890,7 @@ Kernel messages do not have to be terminated with a period. Printing numbers in parentheses (%d) adds no value and should be avoided. -There are a number of driver model diagnostic macros in <linux/device.h> +There are a number of driver model diagnostic macros in <linux/dev_printk.h> which you should use to make sure messages are matched to the right device and driver, and are tagged with the right level: dev_err(), dev_warn(), dev_info(), and so forth. For messages that aren't associated with a diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst index 8ced754a5a0f..388cb19f5dbb 100644 --- a/Documentation/process/deprecated.rst +++ b/Documentation/process/deprecated.rst @@ -59,8 +59,9 @@ risk of them overflowing. This could lead to values wrapping around and a smaller allocation being made than the caller was expecting. Using those allocations could lead to linear overflows of heap memory and other misbehaviors. (One exception to this is literal values where the compiler -can warn if they might overflow. Though using literals for arguments as -suggested below is also harmless.) +can warn if they might overflow. However, the preferred way in these +cases is to refactor the code as suggested below to avoid the open-coded +arithmetic.) For example, do not use ``count * size`` as an argument, as in:: diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index dd231ffc8422..9f1b88492bb3 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -27,6 +27,7 @@ Below are the essential guides that every developer should read. submitting-patches programming-language coding-style + maintainer-handbooks maintainer-pgp-guide email-clients kernel-enforcement-statement diff --git a/Documentation/process/maintainer-handbooks.rst b/Documentation/process/maintainer-handbooks.rst new file mode 100644 index 000000000000..6af1abb0da48 --- /dev/null +++ b/Documentation/process/maintainer-handbooks.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _maintainer_handbooks_main: + +Subsystem and maintainer tree specific development process notes +================================================================ + +The purpose of this document is to provide subsystem specific information +which is supplementary to the general development process handbook +:ref:`Documentation/process <development_process_main>`. + +Contents: + +.. toctree:: + :numbered: + :maxdepth: 2 + + maintainer-tip diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst new file mode 100644 index 000000000000..c74f4a81588b --- /dev/null +++ b/Documentation/process/maintainer-tip.rst @@ -0,0 +1,785 @@ +.. SPDX-License-Identifier: GPL-2.0 + +The tip tree handbook +===================== + +What is the tip tree? +--------------------- + +The tip tree is a collection of several subsystems and areas of +development. The tip tree is both a direct development tree and a +aggregation tree for several sub-maintainer trees. The tip tree gitweb URL +is: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git + +The tip tree contains the following subsystems: + + - **x86 architecture** + + The x86 architecture development takes place in the tip tree except + for the x86 KVM and XEN specific parts which are maintained in the + corresponding subsystems and routed directly to mainline from + there. It's still good practice to Cc the x86 maintainers on + x86-specific KVM and XEN patches. + + Some x86 subsystems have their own maintainers in addition to the + overall x86 maintainers. Please Cc the overall x86 maintainers on + patches touching files in arch/x86 even when they are not called out + by the MAINTAINER file. + + Note, that ``x86@kernel.org`` is not a mailing list. It is merely a + mail alias which distributes mails to the x86 top-level maintainer + team. Please always Cc the Linux Kernel mailing list (LKML) + ``linux-kernel@vger.kernel.org``, otherwise your mail ends up only in + the private inboxes of the maintainers. + + - **Scheduler** + + Scheduler development takes place in the -tip tree, in the + sched/core branch - with occasional sub-topic trees for + work-in-progress patch-sets. + + - **Locking and atomics** + + Locking development (including atomics and other synchronization + primitives that are connected to locking) takes place in the -tip + tree, in the locking/core branch - with occasional sub-topic trees + for work-in-progress patch-sets. + + - **Generic interrupt subsystem and interrupt chip drivers**: + + - interrupt core development happens in the irq/core branch + + - interrupt chip driver development also happens in the irq/core + branch, but the patches are usually applied in a separate maintainer + tree and then aggregated into irq/core + + - **Time, timers, timekeeping, NOHZ and related chip drivers**: + + - timekeeping, clocksource core, NTP and alarmtimer development + happens in the timers/core branch, but patches are usually applied in + a separate maintainer tree and then aggregated into timers/core + + - clocksource/event driver development happens in the timers/core + branch, but patches are mostly applied in a separate maintainer tree + and then aggregated into timers/core + + - **Performance counters core, architecture support and tooling**: + + - perf core and architecture support development happens in the + perf/core branch + + - perf tooling development happens in the perf tools maintainer + tree and is aggregated into the tip tree. + + - **CPU hotplug core** + + - **RAS core** + + Mostly x86-specific RAS patches are collected in the tip ras/core + branch. + + - **EFI core** + + EFI development in the efi git tree. The collected patches are + aggregated in the tip efi/core branch. + + - **RCU** + + RCU development happens in the linux-rcu tree. The resulting changes + are aggregated into the tip core/rcu branch. + + - **Various core code components**: + + - debugobjects + + - objtool + + - random bits and pieces + + +Patch submission notes +---------------------- + +Selecting the tree/branch +^^^^^^^^^^^^^^^^^^^^^^^^^ + +In general, development against the head of the tip tree master branch is +fine, but for the subsystems which are maintained separately, have their +own git tree and are only aggregated into the tip tree, development should +take place against the relevant subsystem tree or branch. + +Bug fixes which target mainline should always be applicable against the +mainline kernel tree. Potential conflicts against changes which are already +queued in the tip tree are handled by the maintainers. + +Patch subject +^^^^^^^^^^^^^ + +The tip tree preferred format for patch subject prefixes is +'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:', +'genirq/core:'. Please do not use file names or complete file paths as +prefix. 'git log path/to/file' should give you a reasonable hint in most +cases. + +The condensed patch description in the subject line should start with a +uppercase letter and should be written in imperative tone. + + +Changelog +^^^^^^^^^ + +The general rules about changelogs in the process documentation, see +:ref:`Documentation/process/ <submittingpatches>`, apply. + +The tip tree maintainers set value on following these rules, especially on +the request to write changelogs in imperative mood and not impersonating +code or the execution of it. This is not just a whim of the +maintainers. Changelogs written in abstract words are more precise and +tend to be less confusing than those written in the form of novels. + +It's also useful to structure the changelog into several paragraphs and not +lump everything together into a single one. A good structure is to explain +the context, the problem and the solution in separate paragraphs and this +order. + +Examples for illustration: + + Example 1:: + + x86/intel_rdt/mbm: Fix MBM overflow handler during hot cpu + + When a CPU is dying, we cancel the worker and schedule a new worker on a + different CPU on the same domain. But if the timer is already about to + expire (say 0.99s) then we essentially double the interval. + + We modify the hot cpu handling to cancel the delayed work on the dying + cpu and run the worker immediately on a different cpu in same domain. We + donot flush the worker because the MBM overflow worker reschedules the + worker on same CPU and scans the domain->cpu_mask to get the domain + pointer. + + Improved version:: + + x86/intel_rdt/mbm: Fix MBM overflow handler during CPU hotplug + + When a CPU is dying, the overflow worker is canceled and rescheduled on a + different CPU in the same domain. But if the timer is already about to + expire this essentially doubles the interval which might result in a non + detected overflow. + + Cancel the overflow worker and reschedule it immediately on a different CPU + in the same domain. The work could be flushed as well, but that would + reschedule it on the same CPU. + + Example 2:: + + time: POSIX CPU timers: Ensure that variable is initialized + + If cpu_timer_sample_group returns -EINVAL, it will not have written into + *sample. Checking for cpu_timer_sample_group's return value precludes the + potential use of an uninitialized value of now in the following block. + Given an invalid clock_idx, the previous code could otherwise overwrite + *oldval in an undefined manner. This is now prevented. We also exploit + short-circuiting of && to sample the timer only if the result will + actually be used to update *oldval. + + Improved version:: + + posix-cpu-timers: Make set_process_cpu_timer() more robust + + Because the return value of cpu_timer_sample_group() is not checked, + compilers and static checkers can legitimately warn about a potential use + of the uninitialized variable 'now'. This is not a runtime issue as all + call sites hand in valid clock ids. + + Also cpu_timer_sample_group() is invoked unconditionally even when the + result is not used because *oldval is NULL. + + Make the invocation conditional and check the return value. + + Example 3:: + + The entity can also be used for other purposes. + + Let's rename it to be more generic. + + Improved version:: + + The entity can also be used for other purposes. + + Rename it to be more generic. + + +For complex scenarios, especially race conditions and memory ordering +issues, it is valuable to depict the scenario with a table which shows +the parallelism and the temporal order of events. Here is an example:: + + CPU0 CPU1 + free_irq(X) interrupt X + spin_lock(desc->lock) + wake irq thread() + spin_unlock(desc->lock) + spin_lock(desc->lock) + remove action() + shutdown_irq() + release_resources() thread_handler() + spin_unlock(desc->lock) access released resources. + ^^^^^^^^^^^^^^^^^^^^^^^^^ + synchronize_irq() + +Lockdep provides similar useful output to depict a possible deadlock +scenario:: + + CPU0 CPU1 + rtmutex_lock(&rcu->rt_mutex) + spin_lock(&rcu->rt_mutex.wait_lock) + local_irq_disable() + spin_lock(&timer->it_lock) + spin_lock(&rcu->mutex.wait_lock) + --> Interrupt + spin_lock(&timer->it_lock) + + +Function references in changelogs +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +When a function is mentioned in the changelog, either the text body or the +subject line, please use the format 'function_name()'. Omitting the +brackets after the function name can be ambiguous:: + + Subject: subsys/component: Make reservation_count static + + reservation_count is only used in reservation_stats. Make it static. + +The variant with brackets is more precise:: + + Subject: subsys/component: Make reservation_count() static + + reservation_count() is only called from reservation_stats(). Make it + static. + + +Backtraces in changelogs +^^^^^^^^^^^^^^^^^^^^^^^^ + +See :ref:`backtraces`. + +Ordering of commit tags +^^^^^^^^^^^^^^^^^^^^^^^ + +To have a uniform view of the commit tags, the tip maintainers use the +following tag ordering scheme: + + - Fixes: 12char-SHA1 ("sub/sys: Original subject line") + + A Fixes tag should be added even for changes which do not need to be + backported to stable kernels, i.e. when addressing a recently introduced + issue which only affects tip or the current head of mainline. These tags + are helpful to identify the original commit and are much more valuable + than prominently mentioning the commit which introduced a problem in the + text of the changelog itself because they can be automatically + extracted. + + The following example illustrates the difference:: + + Commit + + abcdef012345678 ("x86/xxx: Replace foo with bar") + + left an unused instance of variable foo around. Remove it. + + Signed-off-by: J.Dev <j.dev@mail> + + Please say instead:: + + The recent replacement of foo with bar left an unused instance of + variable foo around. Remove it. + + Fixes: abcdef012345678 ("x86/xxx: Replace foo with bar") + Signed-off-by: J.Dev <j.dev@mail> + + The latter puts the information about the patch into the focus and + amends it with the reference to the commit which introduced the issue + rather than putting the focus on the original commit in the first place. + + - Reported-by: ``Reporter <reporter@mail>`` + + - Originally-by: ``Original author <original-author@mail>`` + + - Suggested-by: ``Suggester <suggester@mail>`` + + - Co-developed-by: ``Co-author <co-author@mail>`` + + Signed-off: ``Co-author <co-author@mail>`` + + Note, that Co-developed-by and Signed-off-by of the co-author(s) must + come in pairs. + + - Signed-off-by: ``Author <author@mail>`` + + The first Signed-off-by (SOB) after the last Co-developed-by/SOB pair is the + author SOB, i.e. the person flagged as author by git. + + - Signed-off-by: ``Patch handler <handler@mail>`` + + SOBs after the author SOB are from people handling and transporting + the patch, but were not involved in development. SOB chains should + reflect the **real** route a patch took as it was propagated to us, + with the first SOB entry signalling primary authorship of a single + author. Acks should be given as Acked-by lines and review approvals + as Reviewed-by lines. + + If the handler made modifications to the patch or the changelog, then + this should be mentioned **after** the changelog text and **above** + all commit tags in the following format:: + + ... changelog text ends. + + [ handler: Replaced foo by bar and updated changelog ] + + First-tag: ..... + + Note the two empty new lines which separate the changelog text and the + commit tags from that notice. + + If a patch is sent to the mailing list by a handler then the author has + to be noted in the first line of the changelog with:: + + From: Author <author@mail> + + Changelog text starts here.... + + so the authorship is preserved. The 'From:' line has to be followed + by a empty newline. If that 'From:' line is missing, then the patch + would be attributed to the person who sent (transported, handled) it. + The 'From:' line is automatically removed when the patch is applied + and does not show up in the final git changelog. It merely affects + the authorship information of the resulting Git commit. + + - Tested-by: ``Tester <tester@mail>`` + + - Reviewed-by: ``Reviewer <reviewer@mail>`` + + - Acked-by: ``Acker <acker@mail>`` + + - Cc: ``cc-ed-person <person@mail>`` + + If the patch should be backported to stable, then please add a '``Cc: + stable@vger.kernel.org``' tag, but do not Cc stable when sending your + mail. + + - Link: ``https://link/to/information`` + + For referring to an email on LKML or other kernel mailing lists, + please use the lore.kernel.org redirector URL:: + + https://lore.kernel.org/r/email-message@id + + The kernel.org redirector is considered a stable URL, unlike other email + archives. + + Maintainers will add a Link tag referencing the email of the patch + submission when they apply a patch to the tip tree. This tag is useful + for later reference and is also used for commit notifications. + +Please do not use combined tags, e.g. ``Reported-and-tested-by``, as +they just complicate automated extraction of tags. + + +Links to documentation +^^^^^^^^^^^^^^^^^^^^^^ + +Providing links to documentation in the changelog is a great help to later +debugging and analysis. Unfortunately, URLs often break very quickly +because companies restructure their websites frequently. Non-'volatile' +exceptions include the Intel SDM and the AMD APM. + +Therefore, for 'volatile' documents, please create an entry in the kernel +bugzilla https://bugzilla.kernel.org and attach a copy of these documents +to the bugzilla entry. Finally, provide the URL of the bugzilla entry in +the changelog. + +Patch resend or reminders +^^^^^^^^^^^^^^^^^^^^^^^^^ + +See :ref:`resend_reminders`. + +Merge window +^^^^^^^^^^^^ + +Please do not expect large patch series to be handled during the merge +window or even during the week before. Such patches should be submitted in +mergeable state *at* *least* a week before the merge window opens. +Exceptions are made for bug fixes and *sometimes* for small standalone +drivers for new hardware or minimally invasive patches for hardware +enablement. + +During the merge window, the maintainers instead focus on following the +upstream changes, fixing merge window fallout, collecting bug fixes, and +allowing themselves a breath. Please respect that. + +The release candidate -rc1 is the starting point for new patches to be +applied which are targeted for the next merge window. + + +Git +^^^ + +The tip maintainers accept git pull requests from maintainers who provide +subsystem changes for aggregation in the tip tree. + +Pull requests for new patch submissions are usually not accepted and do not +replace proper patch submission to the mailing list. The main reason for +this is that the review workflow is email based. + +If you submit a larger patch series it is helpful to provide a git branch +in a private repository which allows interested people to easily pull the +series for testing. The usual way to offer this is a git URL in the cover +letter of the patch series. + + +Coding style notes +------------------ + +Comment style +^^^^^^^^^^^^^ + +Sentences in comments start with an uppercase letter. + +Single line comments:: + + /* This is a single line comment */ + +Multi-line comments:: + + /* + * This is a properly formatted + * multi-line comment. + * + * Larger multi-line comments should be split into paragraphs. + */ + +No tail comments: + + Please refrain from using tail comments. Tail comments disturb the + reading flow in almost all contexts, but especially in code:: + + if (somecondition_is_true) /* Don't put a comment here */ + dostuff(); /* Neither here */ + + seed = MAGIC_CONSTANT; /* Nor here */ + + Use freestanding comments instead:: + + /* This condition is not obvious without a comment */ + if (somecondition_is_true) { + /* This really needs to be documented */ + dostuff(); + } + + /* This magic initialization needs a comment. Maybe not? */ + seed = MAGIC_CONSTANT; + +Comment the important things: + + Comments should be added where the operation is not obvious. Documenting + the obvious is just a distraction:: + + /* Decrement refcount and check for zero */ + if (refcount_dec_and_test(&p->refcnt)) { + do; + lots; + of; + magic; + things; + } + + Instead, comments should explain the non-obvious details and document + constraints:: + + if (refcount_dec_and_test(&p->refcnt)) { + /* + * Really good explanation why the magic things below + * need to be done, ordering and locking constraints, + * etc.. + */ + do; + lots; + of; + magic; + /* Needs to be the last operation because ... */ + things; + } + +Function documentation comments: + + To document functions and their arguments please use kernel-doc format + and not free form comments:: + + /** + * magic_function - Do lots of magic stuff + * @magic: Pointer to the magic data to operate on + * @offset: Offset in the data array of @magic + * + * Deep explanation of mysterious things done with @magic along + * with documentation of the return values. + * + * Note, that the argument descriptors above are arranged + * in a tabular fashion. + */ + + This applies especially to globally visible functions and inline + functions in public header files. It might be overkill to use kernel-doc + format for every (static) function which needs a tiny explanation. The + usage of descriptive function names often replaces these tiny comments. + Apply common sense as always. + + +Documenting locking requirements +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + Documenting locking requirements is a good thing, but comments are not + necessarily the best choice. Instead of writing:: + + /* Caller must hold foo->lock */ + void func(struct foo *foo) + { + ... + } + + Please use:: + + void func(struct foo *foo) + { + lockdep_assert_held(&foo->lock); + ... + } + + In PROVE_LOCKING kernels, lockdep_assert_held() emits a warning + if the caller doesn't hold the lock. Comments can't do that. + +Bracket rules +^^^^^^^^^^^^^ + +Brackets should be omitted only if the statement which follows 'if', 'for', +'while' etc. is truly a single line:: + + if (foo) + do_something(); + +The following is not considered to be a single line statement even +though C does not require brackets:: + + for (i = 0; i < end; i++) + if (foo[i]) + do_something(foo[i]); + +Adding brackets around the outer loop enhances the reading flow:: + + for (i = 0; i < end; i++) { + if (foo[i]) + do_something(foo[i]); + } + + +Variable declarations +^^^^^^^^^^^^^^^^^^^^^ + +The preferred ordering of variable declarations at the beginning of a +function is reverse fir tree order:: + + struct long_struct_name *descriptive_name; + unsigned long foo, bar; + unsigned int tmp; + int ret; + +The above is faster to parse than the reverse ordering:: + + int ret; + unsigned int tmp; + unsigned long foo, bar; + struct long_struct_name *descriptive_name; + +And even more so than random ordering:: + + unsigned long foo, bar; + int ret; + struct long_struct_name *descriptive_name; + unsigned int tmp; + +Also please try to aggregate variables of the same type into a single +line. There is no point in wasting screen space:: + + unsigned long a; + unsigned long b; + unsigned long c; + unsigned long d; + +It's really sufficient to do:: + + unsigned long a, b, c, d; + +Please also refrain from introducing line splits in variable declarations:: + + struct long_struct_name *descriptive_name = container_of(bar, + struct long_struct_name, + member); + struct foobar foo; + +It's way better to move the initialization to a separate line after the +declarations:: + + struct long_struct_name *descriptive_name; + struct foobar foo; + + descriptive_name = container_of(bar, struct long_struct_name, member); + + +Variable types +^^^^^^^^^^^^^^ + +Please use the proper u8, u16, u32, u64 types for variables which are meant +to describe hardware or are used as arguments for functions which access +hardware. These types are clearly defining the bit width and avoid +truncation, expansion and 32/64-bit confusion. + +u64 is also recommended in code which would become ambiguous for 32-bit +kernels when 'unsigned long' would be used instead. While in such +situations 'unsigned long long' could be used as well, u64 is shorter +and also clearly shows that the operation is required to be 64 bits wide +independent of the target CPU. + +Please use 'unsigned int' instead of 'unsigned'. + + +Constants +^^^^^^^^^ + +Please do not use literal (hexa)decimal numbers in code or initializers. +Either use proper defines which have descriptive names or consider using +an enum. + + +Struct declarations and initializers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Struct declarations should align the struct member names in a tabular +fashion:: + + struct bar_order { + unsigned int guest_id; + int ordered_item; + struct menu *menu; + }; + +Please avoid documenting struct members within the declaration, because +this often results in strangely formatted comments and the struct members +become obfuscated:: + + struct bar_order { + unsigned int guest_id; /* Unique guest id */ + int ordered_item; + /* Pointer to a menu instance which contains all the drinks */ + struct menu *menu; + }; + +Instead, please consider using the kernel-doc format in a comment preceding +the struct declaration, which is easier to read and has the added advantage +of including the information in the kernel documentation, for example, as +follows:: + + + /** + * struct bar_order - Description of a bar order + * @guest_id: Unique guest id + * @ordered_item: The item number from the menu + * @menu: Pointer to the menu from which the item + * was ordered + * + * Supplementary information for using the struct. + * + * Note, that the struct member descriptors above are arranged + * in a tabular fashion. + */ + struct bar_order { + unsigned int guest_id; + int ordered_item; + struct menu *menu; + }; + +Static struct initializers must use C99 initializers and should also be +aligned in a tabular fashion:: + + static struct foo statfoo = { + .a = 0, + .plain_integer = CONSTANT_DEFINE_OR_ENUM, + .bar = &statbar, + }; + +Note that while C99 syntax allows the omission of the final comma, +we recommend the use of a comma on the last line because it makes +reordering and addition of new lines easier, and makes such future +patches slightly easier to read as well. + +Line breaks +^^^^^^^^^^^ + +Restricting line length to 80 characters makes deeply indented code hard to +read. Consider breaking out code into helper functions to avoid excessive +line breaking. + +The 80 character rule is not a strict rule, so please use common sense when +breaking lines. Especially format strings should never be broken up. + +When splitting function declarations or function calls, then please align +the first argument in the second line with the first argument in the first +line:: + + static int long_function_name(struct foobar *barfoo, unsigned int id, + unsigned int offset) + { + + if (!id) { + ret = longer_function_name(barfoo, DEFAULT_BARFOO_ID, + offset); + ... + +Namespaces +^^^^^^^^^^ + +Function/variable namespaces improve readability and allow easy +grepping. These namespaces are string prefixes for globally visible +function and variable names, including inlines. These prefixes should +combine the subsystem and the component name such as 'x86_comp\_', +'sched\_', 'irq\_', and 'mutex\_'. + +This also includes static file scope functions that are immediately put +into globally visible driver templates - it's useful for those symbols +to carry a good prefix as well, for backtrace readability. + +Namespace prefixes may be omitted for local static functions and +variables. Truly local functions, only called by other local functions, +can have shorter descriptive names - our primary concern is greppability +and backtrace readability. + +Please note that 'xxx_vendor\_' and 'vendor_xxx_` prefixes are not +helpful for static functions in vendor-specific files. After all, it +is already clear that the code is vendor-specific. In addition, vendor +names should only be for truly vendor-specific functionality. + +As always apply common sense and aim for consistency and readability. + + +Commit notifications +-------------------- + +The tip tree is monitored by a bot for new commits. The bot sends an email +for each new commit to a dedicated mailing list +(``linux-tip-commits@vger.kernel.org``) and Cc's all people who are +mentioned in one of the commit tags. It uses the email message ID from the +Link tag at the end of the tag list to set the In-Reply-To email header so +the message is properly threaded with the patch submission email. + +The tip maintainers and submaintainers try to reply to the submitter +when merging a patch, but they sometimes forget or it does not fit the +workflow of the moment. While the bot message is purely mechanical, it +also implies a 'Thank you! Applied.'. diff --git a/Documentation/process/submitting-drivers.rst b/Documentation/process/submitting-drivers.rst index 3861887e0ca5..8413b693d10d 100644 --- a/Documentation/process/submitting-drivers.rst +++ b/Documentation/process/submitting-drivers.rst @@ -185,7 +185,7 @@ Linux USB project: http://www.linux-usb.org/ How to NOT write kernel driver by Arjan van de Ven: - http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf + https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf Kernel Janitor: https://kernelnewbies.org/KernelJanitors diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 8ad6b93f91e6..da085d63af9b 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -21,6 +21,10 @@ If you're unfamiliar with ``git``, you would be well-advised to learn how to use it, it will make your life as a kernel developer and in general much easier. +Some subsystems and maintainer trees have additional information about +their workflow and expectations, see +:ref:`Documentation/process/maintainer-handbooks.rst <maintainer_handbooks_main>`. + Obtain a current source tree ---------------------------- @@ -92,17 +96,6 @@ instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behaviour. -If the patch fixes a logged bug entry, refer to that bug entry by -number and URL. If the patch follows from a mailing list discussion, -give a URL to the mailing list archive; use the https://lkml.kernel.org/ -redirector with a ``Message-Id``, to ensure that the links cannot become -stale. - -However, try to make your explanation understandable without external -resources. In addition to giving a URL to a mailing list archive or -bug, summarize the relevant points of the discussion that led to the -patch as submitted. - If you want to refer to a specific commit, don't just refer to the SHA-1 ID of the commit. Please also include the oneline summary of the commit, to make it easier for reviewers to know what it is about. @@ -119,6 +112,28 @@ collisions with shorter IDs a real possibility. Bear in mind that, even if there is no collision with your six-character ID now, that condition may change five years from now. +If related discussions or any other background information behind the change +can be found on the web, add 'Link:' tags pointing to it. In case your patch +fixes a bug, for example, add a tag with a URL referencing the report in the +mailing list archives or a bug tracker; if the patch is a result of some +earlier mailing list discussion or something documented on the web, point to +it. + +When linking to mailing list archives, preferably use the lore.kernel.org +message archiver service. To create the link URL, use the contents of the +``Message-Id`` header of the message without the surrounding angle brackets. +For example:: + + Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/ + +Please check the link to make sure that it is actually working and points +to the relevant message. + +However, try to make your explanation understandable without external +resources. In addition to giving a URL to a mailing list archive or bug, +summarize the relevant points of the discussion that led to the +patch as submitted. + If your patch fixes a bug in a specific commit, e.g. you found an issue using ``git bisect``, please use the 'Fixes:' tag with the first 12 characters of the SHA-1 ID, and the one line summary. Do not split the tag across multiple @@ -326,6 +341,7 @@ politely and address the problems they have pointed out. See Documentation/process/email-clients.rst for recommendations on email clients and mailing list etiquette. +.. _resend_reminders: Don't get discouraged - or impatient ------------------------------------ @@ -711,6 +727,8 @@ patch:: See more details on the proper patch format in the following references. +.. _backtraces: + Backtraces in commit mesages ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -743,7 +761,7 @@ the bug report. However, for a multi-patch series, it is generally best to avoid using In-Reply-To: to link to older versions of the series. This way multiple versions of the patch don't become an unmanageable forest of references in email clients. If a link is -helpful, you can use the https://lkml.kernel.org/ redirector (e.g., in +helpful, you can use the https://lore.kernel.org/ redirector (e.g., in the cover email text) to link to an earlier version of the patch series. diff --git a/Documentation/scheduler/sched-bwc.rst b/Documentation/scheduler/sched-bwc.rst index 1fc73555f5c4..173c14110c85 100644 --- a/Documentation/scheduler/sched-bwc.rst +++ b/Documentation/scheduler/sched-bwc.rst @@ -22,9 +22,52 @@ cfs_quota units at each period boundary. As threads consume this bandwidth it is transferred to cpu-local "silos" on a demand basis. The amount transferred within each of these updates is tunable and described as the "slice". +Burst feature +------------- +This feature borrows time now against our future underrun, at the cost of +increased interference against the other system users. All nicely bounded. + +Traditional (UP-EDF) bandwidth control is something like: + + (U = \Sum u_i) <= 1 + +This guaranteeds both that every deadline is met and that the system is +stable. After all, if U were > 1, then for every second of walltime, +we'd have to run more than a second of program time, and obviously miss +our deadline, but the next deadline will be further out still, there is +never time to catch up, unbounded fail. + +The burst feature observes that a workload doesn't always executes the full +quota; this enables one to describe u_i as a statistical distribution. + +For example, have u_i = {x,e}_i, where x is the p(95) and x+e p(100) +(the traditional WCET). This effectively allows u to be smaller, +increasing the efficiency (we can pack more tasks in the system), but at +the cost of missing deadlines when all the odds line up. However, it +does maintain stability, since every overrun must be paired with an +underrun as long as our x is above the average. + +That is, suppose we have 2 tasks, both specify a p(95) value, then we +have a p(95)*p(95) = 90.25% chance both tasks are within their quota and +everything is good. At the same time we have a p(5)p(5) = 0.25% chance +both tasks will exceed their quota at the same time (guaranteed deadline +fail). Somewhere in between there's a threshold where one exceeds and +the other doesn't underrun enough to compensate; this depends on the +specific CDFs. + +At the same time, we can say that the worst case deadline miss, will be +\Sum e_i; that is, there is a bounded tardiness (under the assumption +that x+e is indeed WCET). + +The interferenece when using burst is valued by the possibilities for +missing the deadline and the average WCET. Test results showed that when +there many cgroups or CPU is under utilized, the interference is +limited. More details are shown in: +https://lore.kernel.org/lkml/5371BD36-55AE-4F71-B9D7-B86DC32E3D2B@linux.alibaba.com/ + Management ---------- -Quota and period are managed within the cpu subsystem via cgroupfs. +Quota, period and burst are managed within the cpu subsystem via cgroupfs. .. note:: The cgroupfs files described in this section are only applicable @@ -32,29 +75,37 @@ Quota and period are managed within the cpu subsystem via cgroupfs. :ref:`Documentation/admin-guide/cgroup-v2.rst <cgroup-v2-cpu>`. - cpu.cfs_quota_us: the total available run-time within a period (in - microseconds) +- cpu.cfs_quota_us: run-time replenished within a period (in microseconds) - cpu.cfs_period_us: the length of a period (in microseconds) - cpu.stat: exports throttling statistics [explained further below] +- cpu.cfs_burst_us: the maximum accumulated run-time (in microseconds) The default values are:: cpu.cfs_period_us=100ms - cpu.cfs_quota=-1 + cpu.cfs_quota_us=-1 + cpu.cfs_burst_us=0 A value of -1 for cpu.cfs_quota_us indicates that the group does not have any bandwidth restriction in place, such a group is described as an unconstrained bandwidth group. This represents the traditional work-conserving behavior for CFS. -Writing any (valid) positive value(s) will enact the specified bandwidth limit. -The minimum quota allowed for the quota or period is 1ms. There is also an -upper bound on the period length of 1s. Additional restrictions exist when -bandwidth limits are used in a hierarchical fashion, these are explained in -more detail below. +Writing any (valid) positive value(s) no smaller than cpu.cfs_burst_us will +enact the specified bandwidth limit. The minimum quota allowed for the quota or +period is 1ms. There is also an upper bound on the period length of 1s. +Additional restrictions exist when bandwidth limits are used in a hierarchical +fashion, these are explained in more detail below. Writing any negative value to cpu.cfs_quota_us will remove the bandwidth limit and return the group to an unconstrained state once more. +A value of 0 for cpu.cfs_burst_us indicates that the group can not accumulate +any unused bandwidth. It makes the traditional bandwidth control behavior for +CFS unchanged. Writing any (valid) positive value(s) no larger than +cpu.cfs_quota_us into cpu.cfs_burst_us will enact the cap on unused bandwidth +accumulation. + Any updates to a group's bandwidth specification will result in it becoming unthrottled if it is in a constrained state. @@ -74,7 +125,7 @@ for more fine-grained consumption. Statistics ---------- -A group's bandwidth statistics are exported via 3 fields in cpu.stat. +A group's bandwidth statistics are exported via 5 fields in cpu.stat. cpu.stat: @@ -82,6 +133,9 @@ cpu.stat: - nr_throttled: Number of times the group has been throttled/limited. - throttled_time: The total time duration (in nanoseconds) for which entities of the group have been throttled. +- nr_bursts: Number of periods burst occurs. +- burst_time: Cumulative wall-time (in nanoseconds) that any CPUs has used + above quota in respective periods This interface is read-only. @@ -179,3 +233,15 @@ Examples By using a small period here we are ensuring a consistent latency response at the expense of burst capacity. + +4. Limit a group to 40% of 1 CPU, and allow accumulate up to 20% of 1 CPU + additionally, in case accumulation has been done. + + With 50ms period, 20ms quota will be equivalent to 40% of 1 CPU. + And 10ms burst will be equivalent to 20% of 1 CPU. + + # echo 20000 > cpu.cfs_quota_us /* quota = 20ms */ + # echo 50000 > cpu.cfs_period_us /* period = 50ms */ + # echo 10000 > cpu.cfs_burst_us /* burst = 10ms */ + + Larger buffer setting (no larger than quota) allows greater burst capacity. diff --git a/Documentation/security/SCTP.rst b/Documentation/security/SCTP.rst index 0bcf6c1245ee..d5fd6ccc3dcb 100644 --- a/Documentation/security/SCTP.rst +++ b/Documentation/security/SCTP.rst @@ -26,11 +26,11 @@ described in the `SCTP SELinux Support`_ chapter. security_sctp_assoc_request() ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Passes the ``@ep`` and ``@chunk->skb`` of the association INIT packet to the +Passes the ``@asoc`` and ``@chunk->skb`` of the association INIT packet to the security module. Returns 0 on success, error on failure. :: - @ep - pointer to sctp endpoint structure. + @asoc - pointer to sctp association structure. @skb - pointer to skbuff of association packet. @@ -117,9 +117,9 @@ Called whenever a new socket is created by **accept**\(2) calls **sctp_peeloff**\(3). :: - @ep - pointer to current sctp endpoint structure. + @asoc - pointer to current sctp association structure. @sk - pointer to current sock structure. - @sk - pointer to new sock structure. + @newsk - pointer to new sock structure. security_inet_conn_established() @@ -151,9 +151,9 @@ establishing an association. INIT ---------------------------------------------> sctp_sf_do_5_1B_init() Respond to an INIT chunk. - SCTP peer endpoint "A" is - asking for an association. Call - security_sctp_assoc_request() + SCTP peer endpoint "A" is asking + for a temporary association. + Call security_sctp_assoc_request() to set the peer label if first association. If not first association, check @@ -163,9 +163,12 @@ establishing an association. | discard the packet. | COOKIE ECHO ------------------------------------------> - | - | - | + sctp_sf_do_5_1D_ce() + Respond to an COOKIE ECHO chunk. + Confirm the cookie and create a + permanent association. + Call security_sctp_assoc_request() to + do the same as for INIT chunk Response. <------------------------------------------- COOKIE ACK | | sctp_sf_do_5_1E_ca | @@ -200,22 +203,22 @@ hooks with the SELinux specifics expanded below:: security_sctp_assoc_request() ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Passes the ``@ep`` and ``@chunk->skb`` of the association INIT packet to the +Passes the ``@asoc`` and ``@chunk->skb`` of the association INIT packet to the security module. Returns 0 on success, error on failure. :: - @ep - pointer to sctp endpoint structure. + @asoc - pointer to sctp association structure. @skb - pointer to skbuff of association packet. The security module performs the following operations: - IF this is the first association on ``@ep->base.sk``, then set the peer + IF this is the first association on ``@asoc->base.sk``, then set the peer sid to that in ``@skb``. This will ensure there is only one peer sid - assigned to ``@ep->base.sk`` that may support multiple associations. + assigned to ``@asoc->base.sk`` that may support multiple associations. - ELSE validate the ``@ep->base.sk peer_sid`` against the ``@skb peer sid`` + ELSE validate the ``@asoc->base.sk peer_sid`` against the ``@skb peer sid`` to determine whether the association should be allowed or denied. - Set the sctp ``@ep sid`` to socket's sid (from ``ep->base.sk``) with + Set the sctp ``@asoc sid`` to socket's sid (from ``asoc->base.sk``) with MLS portion taken from ``@skb peer sid``. This will be used by SCTP TCP style sockets and peeled off connections as they cause a new socket to be generated. @@ -259,13 +262,13 @@ security_sctp_sk_clone() Called whenever a new socket is created by **accept**\(2) (i.e. a TCP style socket) or when a socket is 'peeled off' e.g userspace calls **sctp_peeloff**\(3). ``security_sctp_sk_clone()`` will set the new -sockets sid and peer sid to that contained in the ``@ep sid`` and -``@ep peer sid`` respectively. +sockets sid and peer sid to that contained in the ``@asoc sid`` and +``@asoc peer sid`` respectively. :: - @ep - pointer to current sctp endpoint structure. + @asoc - pointer to current sctp association structure. @sk - pointer to current sock structure. - @sk - pointer to new sock structure. + @newsk - pointer to new sock structure. security_inet_conn_established() diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst index 65f61695f561..34888d4fc4a8 100644 --- a/Documentation/sound/alsa-configuration.rst +++ b/Documentation/sound/alsa-configuration.rst @@ -100,6 +100,15 @@ amidi_map MIDI device number maps assigned to the 2st OSS device; Default: 1 +Module snd-soc-core +------------------- + +The soc core module. It is used by all ALSA card drivers. +It takes the following options which have global effects. + +prealloc_buffer_size_kbytes + Specify prealloc buffer size in kbytes (default: 512). + Common parameters for top sound card modules -------------------------------------------- diff --git a/Documentation/sound/soc/codec.rst b/Documentation/sound/soc/codec.rst index 8a9737eb7597..57df149acafc 100644 --- a/Documentation/sound/soc/codec.rst +++ b/Documentation/sound/soc/codec.rst @@ -40,7 +40,7 @@ e.g. .prepare = wm8731_pcm_prepare, .hw_params = wm8731_hw_params, .shutdown = wm8731_shutdown, - .digital_mute = wm8731_mute, + .mute_stream = wm8731_mute, .set_sysclk = wm8731_set_dai_sysclk, .set_fmt = wm8731_set_dai_fmt, }; @@ -60,7 +60,7 @@ e.g. .rates = WM8731_RATES, .formats = WM8731_FORMATS,}, .ops = &wm8731_dai_ops, - .symmetric_rates = 1, + .symmetric_rate = 1, }; @@ -177,10 +177,10 @@ when the mute is applied or freed. i.e. :: - static int wm8974_mute(struct snd_soc_dai *dai, int mute) + static int wm8974_mute(struct snd_soc_dai *dai, int mute, int direction) { struct snd_soc_component *component = dai->component; - u16 mute_reg = snd_soc_component_read32(component, WM8974_DAC) & 0xffbf; + u16 mute_reg = snd_soc_component_read(component, WM8974_DAC) & 0xffbf; if (mute) snd_soc_component_write(component, WM8974_DAC, mute_reg | 0x40); diff --git a/Documentation/timers/no_hz.rst b/Documentation/timers/no_hz.rst index 6cadad7c3aad..20ad23a6c618 100644 --- a/Documentation/timers/no_hz.rst +++ b/Documentation/timers/no_hz.rst @@ -70,6 +70,10 @@ interrupt. After all, the primary purpose of a scheduling-clock interrupt is to force a busy CPU to shift its attention among multiple duties, and an idle CPU has no duties to shift its attention among. +An idle CPU that is not receiving scheduling-clock interrupts is said to +be "dyntick-idle", "in dyntick-idle mode", "in nohz mode", or "running +tickless". The remainder of this document will use "dyntick-idle mode". + The CONFIG_NO_HZ_IDLE=y Kconfig option causes the kernel to avoid sending scheduling-clock interrupts to idle CPUs, which is critically important both to battery-powered devices and to highly virtualized mainframes. @@ -91,10 +95,6 @@ Therefore, systems with aggressive real-time response constraints often run CONFIG_HZ_PERIODIC=y kernels (or CONFIG_NO_HZ=n for older kernels) in order to avoid degrading from-idle transition latencies. -An idle CPU that is not receiving scheduling-clock interrupts is said to -be "dyntick-idle", "in dyntick-idle mode", "in nohz mode", or "running -tickless". The remainder of this document will use "dyntick-idle mode". - There is also a boot parameter "nohz=" that can be used to disable dyntick-idle mode in CONFIG_NO_HZ_IDLE=y kernels by specifying "nohz=off". By default, CONFIG_NO_HZ_IDLE=y kernels boot with "nohz=on", enabling diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index 4e5b26f03d5b..b3166c4a7867 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -2442,11 +2442,10 @@ Or this simple script! #!/bin/bash tracefs=`sed -ne 's/^tracefs \(.*\) tracefs.*/\1/p' /proc/mounts` - echo nop > $tracefs/tracing/current_tracer - echo 0 > $tracefs/tracing/tracing_on - echo $$ > $tracefs/tracing/set_ftrace_pid - echo function > $tracefs/tracing/current_tracer - echo 1 > $tracefs/tracing/tracing_on + echo 0 > $tracefs/tracing_on + echo $$ > $tracefs/set_ftrace_pid + echo function > $tracefs/current_tracer + echo 1 > $tracefs/tracing_on exec "$@" diff --git a/Documentation/trace/histogram.rst b/Documentation/trace/histogram.rst index 533415644c54..859fd1b76c63 100644 --- a/Documentation/trace/histogram.rst +++ b/Documentation/trace/histogram.rst @@ -1763,6 +1763,21 @@ using the same key and variable from yet another event:: # echo 'hist:key=pid:wakeupswitch_lat=$wakeup_lat+$switchtime_lat ...' >> event3/trigger +Expressions support the use of addition, subtraction, multiplication and +division operators (+-\*/). + +Note if division by zero cannot be detected at parse time (i.e. the +divisor is not a constant), the result will be -1. + +Numeric constants can also be used directly in an expression:: + + # echo 'hist:keys=next_pid:timestamp_secs=common_timestamp/1000000 ...' >> event/trigger + +or assigned to a variable and referenced in a subsequent expression:: + + # echo 'hist:keys=next_pid:us_per_sec=1000000 ...' >> event/trigger + # echo 'hist:keys=next_pid:timestamp_secs=common_timestamp/$us_per_sec ...' >> event/trigger + 2.2.2 Synthetic Events ---------------------- diff --git a/Documentation/trace/kprobes.rst b/Documentation/trace/kprobes.rst index 998149ce2fd9..f318bceda1e6 100644 --- a/Documentation/trace/kprobes.rst +++ b/Documentation/trace/kprobes.rst @@ -784,6 +784,6 @@ References For additional information on Kprobes, refer to the following URLs: -- https://www.ibm.com/developerworks/library/l-kprobes/index.html +- https://lwn.net/Articles/132196/ - https://www.kernel.org/doc/ols/2006/ols2006v2-pages-109-124.pdf diff --git a/Documentation/trace/timerlat-tracer.rst b/Documentation/trace/timerlat-tracer.rst index c7cbb557aee7..64d1fe6e9b93 100644 --- a/Documentation/trace/timerlat-tracer.rst +++ b/Documentation/trace/timerlat-tracer.rst @@ -3,7 +3,7 @@ Timerlat tracer ############### The timerlat tracer aims to help the preemptive kernel developers to -find souces of wakeup latencies of real-time threads. Like cyclictest, +find sources of wakeup latencies of real-time threads. Like cyclictest, the tracer sets a periodic timer that wakes up a thread. The thread then computes a *wakeup latency* value as the difference between the *current time* and the *absolute time* that the timer was set to expire. The main @@ -50,14 +50,14 @@ The second is the *timer latency* observed by the thread. The ACTIVATION ID field serves to relate the *irq* execution to its respective *thread* execution. -The *irq*/*thread* splitting is important to clarify at which context +The *irq*/*thread* splitting is important to clarify in which context the unexpected high value is coming from. The *irq* context can be -delayed by hardware related actions, such as SMIs, NMIs, IRQs -or by a thread masking interrupts. Once the timer happens, the delay +delayed by hardware-related actions, such as SMIs, NMIs, IRQs, +or by thread masking interrupts. Once the timer happens, the delay can also be influenced by blocking caused by threads. For example, by -postponing the scheduler execution via preempt_disable(), by the -scheduler execution, or by masking interrupts. Threads can -also be delayed by the interference from other threads and IRQs. +postponing the scheduler execution via preempt_disable(), scheduler +execution, or masking interrupts. Threads can also be delayed by the +interference from other threads and IRQs. Tracer options --------------------- @@ -68,14 +68,14 @@ directory. The timerlat configs are: - cpus: CPUs at which a timerlat thread will execute. - timerlat_period_us: the period of the timerlat thread. - - osnoise/stop_tracing_us: stop the system tracing if a + - stop_tracing_us: stop the system tracing if a timer latency at the *irq* context higher than the configured value happens. Writing 0 disables this option. - stop_tracing_total_us: stop the system tracing if a - timer latency at the *thread* context higher than the configured + timer latency at the *thread* context is higher than the configured value happens. Writing 0 disables this option. - - print_stack: save the stack of the IRQ ocurrence, and print - it afte the *thread context* event". + - print_stack: save the stack of the IRQ occurrence, and print + it after the *thread context* event". timerlat and osnoise ---------------------------- @@ -95,7 +95,7 @@ For example:: timerlat/5-1035 [005] ....... 548.771104: #402268 context thread timer_latency 39960 ns In this case, the root cause of the timer latency does not point to a -single cause, but to multiple ones. Firstly, the timer IRQ was delayed +single cause but to multiple ones. Firstly, the timer IRQ was delayed for 13 us, which may point to a long IRQ disabled section (see IRQ stacktrace section). Then the timer interrupt that wakes up the timerlat thread took 7597 ns, and the qxl:21 device IRQ took 7139 ns. Finally, diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst b/Documentation/translations/it_IT/doc-guide/sphinx.rst index 0046d75d9a70..9762452c584c 100644 --- a/Documentation/translations/it_IT/doc-guide/sphinx.rst +++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst @@ -35,7 +35,7 @@ Installazione Sphinx ==================== I marcatori ReST utilizzati nei file in Documentation/ sono pensati per essere -processati da ``Sphinx`` nella versione 1.3 o superiore. +processati da ``Sphinx`` nella versione 1.7 o superiore. Esiste uno script che verifica i requisiti Sphinx. Per ulteriori dettagli consultate :ref:`it_sphinx-pre-install`. @@ -53,11 +53,6 @@ pacchettizzato dalla vostra distribuzione. .. note:: - #) Le versioni di Sphinx inferiori alla 1.5 non funzionano bene - con il pacchetto Python docutils versione 0.13.1 o superiore. - Se volete usare queste versioni, allora dovere eseguire - ``pip install 'docutils==0.12'``. - #) Viene raccomandato l'uso del tema RTD per la documentazione in HTML. A seconda della versione di Sphinx, potrebbe essere necessaria l'installazione tramite il comando ``pip install sphinx_rtd_theme``. @@ -67,13 +62,13 @@ pacchettizzato dalla vostra distribuzione. utilizzando LaTeX. Per una corretta interpretazione, è necessario aver installato texlive con i pacchetti amdfonts e amsmath. -Riassumendo, se volete installare la versione 1.7.9 di Sphinx dovete eseguire:: +Riassumendo, se volete installare la versione 2.4.4 di Sphinx dovete eseguire:: - $ virtualenv sphinx_1.7.9 - $ . sphinx_1.7.9/bin/activate - (sphinx_1.7.9) $ pip install -r Documentation/sphinx/requirements.txt + $ virtualenv sphinx_2.4.4 + $ . sphinx_2.4.4/bin/activate + (sphinx_2.4.4) $ pip install -r Documentation/sphinx/requirements.txt -Dopo aver eseguito ``. sphinx_1.7.9/bin/activate``, il prompt cambierà per +Dopo aver eseguito ``. sphinx_2.4.4/bin/activate``, il prompt cambierà per indicare che state usando il nuovo ambiente. Se aprite un nuova sessione, prima di generare la documentazione, dovrete rieseguire questo comando per rientrare nell'ambiente virtuale. @@ -94,7 +89,7 @@ Generazione in PDF e LaTeX -------------------------- Al momento, la generazione di questi documenti è supportata solo dalle -versioni di Sphinx superiori alla 1.4. +versioni di Sphinx superiori alla 2.4. Per la generazione di PDF e LaTeX, avrete bisogno anche del pacchetto ``XeLaTeX`` nella versione 3.14159265 @@ -119,8 +114,8 @@ l'installazione:: You should run: sudo dnf install -y texlive-luatex85 - /usr/bin/virtualenv sphinx_1.7.9 - . sphinx_1.7.9/bin/activate + /usr/bin/virtualenv sphinx_2.4.4 + . sphinx_2.4.4/bin/activate pip install -r Documentation/sphinx/requirements.txt Can't build as 1 mandatory dependency is missing at ./scripts/sphinx-pre-install line 468. diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst index 1efb8293bf1f..163f1bd4e857 100644 --- a/Documentation/translations/it_IT/kernel-hacking/locking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst @@ -1396,7 +1396,19 @@ Riferimento per l'API dei Mutex Riferimento per l'API dei Futex =============================== -.. kernel-doc:: kernel/futex.c +.. kernel-doc:: kernel/futex/core.c + :internal: + +.. kernel-doc:: kernel/futex/futex.h + :internal: + +.. kernel-doc:: kernel/futex/pi.c + :internal: + +.. kernel-doc:: kernel/futex/requeue.c + :internal: + +.. kernel-doc:: kernel/futex/waitwake.c :internal: Approfondimenti diff --git a/Documentation/translations/it_IT/process/changes.rst b/Documentation/translations/it_IT/process/changes.rst index 87d081889bfc..dc7193377b7f 100644 --- a/Documentation/translations/it_IT/process/changes.rst +++ b/Documentation/translations/it_IT/process/changes.rst @@ -57,7 +57,7 @@ mcelog 0.6 mcelog --version iptables 1.4.2 iptables -V openssl & libcrypto 1.0.0 openssl version bc 1.06.95 bc --version -Sphinx\ [#f1]_ 1.3 sphinx-build --version +Sphinx\ [#f1]_ 1.7 sphinx-build --version ====================== ================= ======================================== .. [#f1] Sphinx è necessario solo per produrre la documentazione del Kernel diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst index 458d9d24b9c0..c2fb712a1377 100644 --- a/Documentation/translations/it_IT/process/submitting-patches.rst +++ b/Documentation/translations/it_IT/process/submitting-patches.rst @@ -107,7 +107,7 @@ comportamento. Se la patch corregge un baco conosciuto, fare riferimento a quel baco inserendo il suo numero o il suo URL. Se la patch è la conseguenza di una discussione su una lista di discussione, allora fornite l'URL all'archivio di quella -discussione; usate i collegamenti a https://lkml.kernel.org/ con il +discussione; usate i collegamenti a https://lore.kernel.org/ con il ``Message-Id``, in questo modo vi assicurerete che il collegamento non diventi invalido nel tempo. @@ -772,7 +772,7 @@ che lo riportava. Tuttavia, per serie di patch multiple è generalmente sconsigliato l'uso di In-Reply-To: per collegare precedenti versioni. In questo modo versioni multiple di una patch non diventeranno un'ingestibile giungla di riferimenti all'interno dei programmi di posta. Se un collegamento -è utile, potete usare https://lkml.kernel.org/ per ottenere i collegamenti +è utile, potete usare https://lore.kernel.org/ per ottenere i collegamenti ad una versione precedente di una serie di patch (per esempio, potete usarlo per l'email introduttiva alla serie). diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index 64d932f5dc77..75aa5531cc7d 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -1,6 +1,6 @@ NOTE: This is a version of Documentation/memory-barriers.txt translated into Korean. -This document is maintained by SeongJae Park <sj38.park@gmail.com>. +This document is maintained by SeongJae Park <sj@kernel.org>. If you find any difference between this document and the original file or a problem with the translation, please contact the maintainer of this file. @@ -10,13 +10,13 @@ a fork. So if you have any comments or updates for this file please update the original English file first. The English version is definitive, and readers should look there if they have any doubt. -=================================== +================================= 이 문서는 Documentation/memory-barriers.txt 의 한글 번역입니다. -역자： 박성재 <sj38.park@gmail.com> -=================================== +역자： 박성재 <sj@kernel.org> +================================= ========================= diff --git a/Documentation/translations/zh_CN/PCI/index.rst b/Documentation/translations/zh_CN/PCI/index.rst new file mode 100644 index 000000000000..5c96017e9f41 --- /dev/null +++ b/Documentation/translations/zh_CN/PCI/index.rst @@ -0,0 +1,36 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/PCI/index.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + + +.. _cn_PCI_index.rst: + +=================== +Linux PCI总线子系统 +=================== + +.. toctree:: + :maxdepth: 2 + :numbered: + + pci + +Todolist: + + pciebus-howto + pci-iov-howto + msi-howto + sysfs-pci + acpi-info + pci-error-recovery + pcieaer-howto + endpoint/index + boot-interrupts diff --git a/Documentation/translations/zh_CN/PCI/pci.rst b/Documentation/translations/zh_CN/PCI/pci.rst new file mode 100644 index 000000000000..520707787256 --- /dev/null +++ b/Documentation/translations/zh_CN/PCI/pci.rst @@ -0,0 +1,514 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/PCI/pci.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + + +.. _cn_PCI_pci.rst: + +=================== +如何写Linux PCI驱动 +=================== + +:作者: - Martin Mares <mj@ucw.cz> + - Grant Grundler <grundler@parisc-linux.org> + +PCI的世界是巨大的，而且充满了（大多数是不愉快的）惊喜。由于每个CPU架构实现了不同 +的芯片组，并且PCI设备有不同的要求（呃，“特性”），结果是Linux内核中的PCI支持并不 +像人们希望的那样简单。这篇短文试图向所有潜在的驱动程序作者介绍PCI设备驱动程序的 +Linux APIs。 + +更完整的资源是Jonathan Corbet、Alessandro Rubini和Greg Kroah-Hartman的 +《Linux设备驱动程序》第三版。LDD3可以免费获得（在知识共享许可下），网址是： +https://lwn.net/Kernel/LDD3/。 + + + +然而，请记住，所有的文档都会受到“维护不及时”的影响。如果事情没有按照这里描述的那 +样进行，请参考源代码。 + +请将有关Linux PCI API的问题/评论/补丁发送到“Linux PCI” +<linux-pci@atrey.karlin.mff.cuni.cz> 邮件列表。 + + +PCI驱动的结构体 +=============== +PCI驱动通过pci_register_driver()在系统中“发现”PCI设备。实际上，它是反过来的。 +当PCI通用代码发现一个新设备时，具有匹配“描述”的驱动程序将被通知。下面是这方面的细 +节。 + +pci_register_driver()将大部分探测设备的工作留给了PCI层，并支持设备的在线插入/移 +除[从而在一个驱动中支持可热插拔的PCI、CardBus和Express-Card]。 pci_register_driver() +调用需要传入一个函数指针表，从而决定了驱动的高层结构体。 + +一旦驱动探测到一个PCI设备并取得了所有权，驱动通常需要执行以下初始化： + + - 启用设备 + - 请求MMIO/IOP资源 + - 设置DMA掩码大小（对于流式和一致的DMA） + - 分配和初始化共享控制数据（pci_allocate_coherent()） + - 访问设备配置空间(如果需要) + - 注册IRQ处理程序(request_irq()) + - 初始化非PCI（即芯片的LAN/SCSI/等部分） + - 启用DMA/处理引擎 + +当使用完设备后，也许需要卸载模块，驱动需要采取以下步骤: + + - 禁用设备产生的IRQ + - 释放IRQ（free_irq()） + - 停止所有DMA活动 + - 释放DMA缓冲区（包括一致性和数据流式） + - 从其他子系统（例如scsi或netdev）上取消注册 + - 释放MMIO/IOP资源 + - 禁用设备 + +这些主题中的大部分都在下面的章节中有所涉及。其余的内容请参考LDD3或<linux/pci.h> 。 + +如果没有配置PCI子系统（没有设置 ``CONFIG_PCI`` ），下面描述的大多数PCI函数被定 +义为内联函数，要么完全为空，要么只是返回一个适当的错误代码，以避免在驱动程序中出现 +大量的 ``ifdef`` 。 + + +调用pci_register_driver() +========================= + +PCI设备驱动程序在初始化过程中调用 ``pci_register_driver()`` ，并提供一个指向 +描述驱动程序的结构体的指针（ ``struct pci_driver`` ）： + +该API在以下内核代码中: + +include/linux/pci.h +pci_driver + +ID表是一个由 ``struct pci_device_id`` 结构体成员组成的数组，以一个全零的成员 +结束。一般来说，带有静态常数的定义是首选。 + +该API在以下内核代码中: + +include/linux/mod_devicetable.h +pci_device_id + +大多数驱动程序只需要 ``PCI_DEVICE()`` 或 ``PCI_DEVICE_CLASS()`` 来设置一个 +pci_device_id表。 + +新的 ``PCI ID`` 可以在运行时被添加到设备驱动的 ``pci_ids`` 表中，如下所示:: + + echo "vendor device subvendor subdevice class class_mask driver_data" > \ + /sys/bus/pci/drivers/{driver}/new_id + +所有字段都以十六进制值传递（没有前置0x）。供应商和设备字段是强制性的，其他字段是可 +选的。用户只需要传递必要的可选字段： + + - subvendor和subdevice字段默认为PCI_ANY_ID (FFFFFFF)。 + - class和classmask字段默认为0 + - driver_data默认为0UL。 + - override_only字段默认为0。 + +请注意， ``driver_data`` 必须与驱动程序中定义的任何一个 ``pci_device_id`` 条 +目所使用的值相匹配。如果所有的 ``pci_device_id`` 成员都有一个非零的driver_data +值，这使得driver_data字段是强制性的。 + +一旦添加，驱动程序探测程序将被调用，以探测其（新更新的） ``pci_ids`` 列表中列出的 +任何无人认领的PCI设备。 + +当驱动退出时，它只是调用 ``pci_unregister_driver()`` ，PCI层会自动调用驱动处理 +的所有设备的移除钩子。 + + +驱动程序功能/数据的“属性” +------------------------- + +请在适当的地方标记初始化和清理函数（相应的宏在<linux/init.h>中定义）： + + ====== ============================================== + __init 初始化代码。在驱动程序初始化后被抛弃。 + __exit 退出代码。对于非模块化的驱动程序来说是忽略的。 + ====== ============================================== + +关于何时/何地使用上述属性的提示： + + - module_init()/module_exit()函数（以及所有仅由这些函数调用的初始化函数）应该被标记 + + - 为__init/__exit。 + + - 不要标记pci_driver结构体。 + + - 如果你不确定应该使用哪种标记，请不要标记一个函数。不标记函数比标记错误的函数更好。 + + +如何手动搜索PCI设备 +=================== + +PCI驱动最好有一个非常好的理由不使用 ``pci_register_driver()`` 接口来搜索PCI设备。 +PCI设备被多个驱动程序控制的主要原因是一个PCI设备实现了几个不同的HW服务。例如，组合的 +串行/并行端口/软盘控制器。 + +可以使用以下结构体进行手动搜索： + +通过供应商和设备ID进行搜索:: + + struct pci_dev *dev = NULL; + while (dev = pci_get_device(VENDOR_ID, DEVICE_ID, dev)) + configure_device(dev); + +按类别ID搜索（以类似的方式迭代）:: + + pci_get_class(CLASS_ID, dev) + +通过供应商/设备和子系统供应商/设备ID进行搜索:: + + pci_get_subsys(VENDOR_ID,DEVICE_ID, SUBSYS_VENDOR_ID, SUBSYS_DEVICE_ID, dev). + +你可以使用常数 ``PCI_ANY_ID`` 作为 ``VENDOR_ID`` 或 ``DEVICE_ID`` 的通 +配符替代。例如，这允许搜索来自一个特定供应商的任何设备。 + +这些函数是热拔插安全的。它们会增加它们所返回的 ``pci_dev`` 的参考计数。你最终 +必须通过调用 ``pci_dev_put()`` 来减少这些设备上的参考计数（可能在模块卸载时）。 + + +设备初始化步骤 +============== + +正如介绍中所指出的，大多数PCI驱动需要以下步骤进行设备初始化： + + - 启用设备 + - 请求MMIO/IOP资源 + - 设置DMA掩码大小（对于流式和一致的DMA） + - 分配和初始化共享控制数据（pci_allocate_coherent()） + - 访问设备配置空间(如果需要) + - 注册IRQ处理程序（request_irq()） + - 初始化non-PCI（即芯片的LAN/SCSI/等部分） + - 启用DMA/处理引擎 + +驱动程序可以在任何时候访问PCI配置空间寄存器。（嗯，几乎如此。当运行BIST时，配置 +空间可以消失......但这只会导致PCI总线主控中止，读取配置将返回垃圾值）。） + + +启用PCI设备 +----------- +在接触任何设备寄存器之前，驱动程序需要通过调用 ``pci_enable_device()`` 启用 +PCI设备。这将: + + - 唤醒处于暂停状态的设备。 + - 分配设备的I/O和内存区域（如果BIOS没有这样做）。 + - 分配一个IRQ（如果BIOS没有）。 + +.. note:: + pci_enable_device() 可能失败，检查返回值。 + +.. warning:: + OS BUG：在启用这些资源之前，我们没有检查资源分配情况。如果我们在调用 + 之前调用pci_request_resources()，这个顺序会更合理。目前，当两个设备被分配 + 了相同的范围时，设备驱动无法检测到这个错误。这不是一个常见的问题，不太可能很快 + 得到修复。 + + 这个问题之前已经讨论过了，但从2.6.19开始没有改变： + https://lore.kernel.org/r/20060302180025.GC28895@flint.arm.linux.org.uk/ + + +pci_set_master()将通过设置PCI_COMMAND寄存器中的总线主控位来启用DMA。 +``pci_clear_master()`` 将通过清除总线主控位来禁用DMA，它还修复了延迟计时器的 +值，如果它被BIOS设置成假的。 + +如果PCI设备可以使用 ``PCI Memory-Write-Invalidate`` 事务，请调用 ``pci_set_mwi()`` 。 +这将启用 ``Mem-Wr-Inval`` 的 ``PCI_COMMAND`` 位，也确保缓存行大小寄存器被正确设置。检 +查 ``pci_set_mwi()`` 的返回值，因为不是所有的架构或芯片组都支持 ``Memory-Write-Invalidate`` 。 +另外，如果 ``Mem-Wr-Inval`` 是好的，但不是必须的，可以调用 ``pci_try_set_mwi()`` ，让 +系统尽最大努力来启用 ``Mem-Wr-Inval`` 。 + + +请求MMIO/IOP资源 +---------------- +内存（MMIO）和I/O端口地址不应该直接从PCI设备配置空间中读取。使用 ``pci_dev`` 结构体 +中的值，因为PCI “总线地址”可能已经被arch/chip-set特定的内核支持重新映射为“主机物理” +地址。 + +参见io_mapping函数，了解如何访问设备寄存器或设备内存。 + +设备驱动需要调用 ``pci_request_region()`` 来确认没有其他设备已经在使用相同的地址 +资源。反之，驱动应该在调用 ``pci_disable_device()`` 之后调用 ``pci_release_region()`` 。 +这个想法是为了防止两个设备在同一地址范围内发生冲突。 + +.. tip:: + 见上面的操作系统BUG注释。目前(2.6.19)，驱动程序只能在调用pci_enable_device() + 后确定MMIO和IO端口资源的可用性。 + +``pci_request_region()`` 的通用风格是 ``request_mem_region()`` （用于MMIO +范围）和 ``request_region()`` （用于IO端口范围）。对于那些不被 "正常 "PCI BAR描 +述的地址资源，使用这些方法。 + +也请看下面的 ``pci_request_selected_regions()`` 。 + + +设置DMA掩码大小 +--------------- +.. note:: + 如果下面有什么不明白的地方，请参考使用通用设备的动态DMA映射。本节只是提醒大家， + 驱动程序需要说明设备的DMA功能，并不是DMA接口的权威来源。 + +虽然所有的驱动程序都应该明确指出PCI总线主控的DMA功能（如32位或64位），但对于流式 +数据来说，具有超过32位总线主站功能的设备需要驱动程序通过调用带有适当参数的 +``pci_set_dma_mask()`` 来“注册”这种功能。一般来说，在系统RAM高于4G物理地址的情 +况下，这允许更有效的DMA。 + +所有PCI-X和PCIe兼容设备的驱动程序必须调用 ``pci_set_dma_mask()`` ，因为它们 +是64位DMA设备。 + +同样，如果设备可以通过调用 ``pci_set_consistent_dma_mask()`` 直接寻址到 +4G物理地址以上的系统RAM中的“一致性内存”，那么驱动程序也必须“注册”这种功能。同 +样，这包括所有PCI-X和PCIe兼容设备的驱动程序。许多64位“PCI”设备（在PCI-X之前） +和一些PCI-X设备对有效载荷（“流式”）数据具有64位DMA功能，但对控制（“一致性”）数 +据则没有。 + + +设置共享控制数据 +---------------- +一旦DMA掩码设置完毕，驱动程序就可以分配“一致的”（又称共享的）内存。参见使用通 +用设备的动态DMA映射，了解DMA API的完整描述。本节只是提醒大家，需要在设备上启 +用DMA之前完成。 + + +初始化设备寄存器 +---------------- +一些驱动程序需要对特定的“功能”字段进行编程，或对其他“供应商专用”寄存器进行初始 +化或重置。例如，清除挂起的中断。 + + +注册IRQ处理函数 +--------------- +虽然调用 ``request_irq()`` 是这里描述的最后一步，但这往往只是初始化设备的另 +一个中间步骤。这一步通常可以推迟到设备被打开使用时进行。 + +所有IRQ线的中断处理程序都应该用 ``IRQF_SHARED`` 注册，并使用devid将IRQ映射 +到设备（记住，所有的PCI IRQ线都可以共享）。 + +``request_irq()`` 将把一个中断处理程序和设备句柄与一个中断号联系起来。历史上， +中断号码代表从PCI设备到中断控制器的IRQ线。在MSI和MSI-X中（更多内容见下文），中 +断号是CPU的一个“向量”。 + +``request_irq()`` 也启用中断。在注册中断处理程序之前，请确保设备是静止的，并且 +没有任何中断等待。 + +MSI和MSI-X是PCI功能。两者都是“消息信号中断”，通过向本地APIC的DMA写入来向CPU发 +送中断。MSI和MSI-X的根本区别在于如何分配多个“向量”。MSI需要连续的向量块，而 +MSI-X可以分配几个单独的向量。 + +在调用 ``request_irq()`` 之前，可以通过调用 ``pci_alloc_irq_vectors()`` +的PCI_IRQ_MSI和/或PCI_IRQ_MSIX标志来启用MSI功能。这将导致PCI支持将CPU向量数 +据编程到PCI设备功能寄存器中。许多架构、芯片组或BIOS不支持MSI或MSI-X，调用 +``pci_alloc_irq_vectors`` 时只使用PCI_IRQ_MSI和PCI_IRQ_MSIX标志会失败， +所以尽量也要指定 ``PCI_IRQ_LEGACY`` 。 + +对MSI/MSI-X和传统INTx有不同中断处理程序的驱动程序应该在调用 +``pci_alloc_irq_vectors`` 后根据 ``pci_dev``结构体中的 ``msi_enabled`` +和 ``msix_enabled`` 标志选择正确的处理程序。 + +使用MSI有（至少）两个真正好的理由： + +1) 根据定义，MSI是一个排他性的中断向量。这意味着中断处理程序不需要验证其设备是 + 否引起了中断。 + +2) MSI避免了DMA/IRQ竞争条件。到主机内存的DMA被保证在MSI交付时对主机CPU是可 + 见的。这对数据一致性和避 + +3) 免控制数据过期都很重要。这个保证允许驱动程序省略MMIO读取，以刷新DMA流。 + +参见drivers/infiniband/hw/mthca/或drivers/net/tg3.c了解MSI/MSI-X的使 +用实例。 + + +PCI设备关闭 +=========== + +当一个PCI设备驱动程序被卸载时，需要执行以下大部分步骤: + + - 禁用设备产生的IRQ + - 释放IRQ（free_irq()） + - 停止所有DMA活动 + - 释放DMA缓冲区（包括流式和一致的） + - 从其他子系统（例如scsi或netdev）上取消注册 + - 禁用设备对MMIO/IO端口地址的响应 + - 释放MMIO/IO端口资源 + + +停止设备上的IRQ +--------------- +如何做到这一点是针对芯片/设备的。如果不这样做，如果（也只有在）IRQ与另一个设备 +共享，就会出现“尖叫中断”的可能性。 + +当共享的IRQ处理程序被“解钩”时，使用同一IRQ线的其余设备仍然需要启用该IRQ。因此， +如果“脱钩”的设备断言IRQ线，假设它是其余设备中的一个断言IRQ线，系统将作出反应。 +由于其他设备都不会处理这个IRQ，系统将“挂起”，直到它决定这个IRQ不会被处理并屏蔽 +这个IRQ（100,000次之后）。一旦共享的IRQ被屏蔽，其余设备将停止正常工作。这不是 +一个好事情。 + +这是使用MSI或MSI-X的另一个原因，如果它可用的话。MSI和MSI-X被定义为独占中断， +因此不容易受到“尖叫中断”问题的影响。 + +释放IRQ +------- +一旦设备被静止（不再有IRQ），就可以调用free_irq()。这个函数将在任何待处理 +的IRQ被处理后返回控制，从该IRQ上“解钩”驱动程序的IRQ处理程序，最后如果没有人 +使用该IRQ，则释放它。 + + +停止所有DMA活动 +--------------- +在试图取消分配DMA控制数据之前，停止所有的DMA操作是非常重要的。如果不这样做， +可能会导致内存损坏、挂起，在某些芯片组上还会导致硬崩溃。 + +在停止IRQ后停止DMA可以避免IRQ处理程序可能重新启动DMA引擎的竞争。 + +虽然这个步骤听起来很明显，也很琐碎，但过去有几个“成熟”的驱动程序没有做好这个 +步骤。 + + +释放DMA缓冲区 +------------- +一旦DMA被停止，首先要清理流式DMA。即取消数据缓冲区的映射，如果有的话，将缓 +冲区返回给“上游”所有者。 + +然后清理包含控制数据的“一致的”缓冲区。 + +关于取消映射接口的细节，请参见Documentation/core-api/dma-api.rst。 + + +从其他子系统取消注册 +-------------------- +大多数低级别的PCI设备驱动程序支持其他一些子系统，如USB、ALSA、SCSI、NetDev、 +Infiniband等。请确保你的驱动程序没有从其他子系统中丢失资源。如果发生这种情况， +典型的症状是当子系统试图调用已经卸载的驱动程序时，会出现Oops（恐慌）。 + + +禁止设备对MMIO/IO端口地址做出响应 +--------------------------------- +io_unmap() MMIO或IO端口资源，然后调用pci_disable_device()。 +这与pci_enable_device()对称相反。 +在调用pci_disable_device()后不要访问设备寄存器。 + + +释放MMIO/IO端口资源 +------------------- +调用pci_release_region()来标记MMIO或IO端口范围为可用。 +如果不这样做，通常会导致无法重新加载驱动程序。 + + + + +如何访问PCI配置空间 +=================== + +你可以使用 `pci_(read|write)_config_(byte|word|dword)` 来访问由 +`struct pci_dev *` 表示的设备的配置空间。所有这些函数在成功时返回0，或者返回一个 +错误代码（ `PCIBIOS_...` ），这个错误代码可以通过pcibios_strerror翻译成文本字 +符串。大多数驱动程序希望对有效的PCI设备的访问不会失败。 + +如果你没有可用的pci_dev结构体，你可以调用 +`pci_bus_(read|write)_config_(byte|word|dword)` 来访问一个给定的设备和该总 +线上的功能。 + +如果你访问配置头的标准部分的字段，请使用<linux/pci.h>中声明的位置和位的符号名称。 + +如果你需要访问扩展的PCI功能寄存器，只要为特定的功能调用pci_find_capability()， +它就会为你找到相应的寄存器块。 + + +其它有趣的函数 +============== + +============================= ================================================= +pci_get_domain_bus_and_slot() 找到与给定的域、总线和槽以及编号相对应的pci_dev。 + 如果找到该设备，它的引用计数就会增加。 +pci_set_power_state() 设置PCI电源管理状态（0=D0 ... 3=D3 +pci_find_capability() 在设备的功能列表中找到指定的功能 +pci_resource_start() 返回一个给定的PCI区域的总线起始地址 +pci_resource_end() 返回给定PCI区域的总线末端地址 +pci_resource_len() 返回一个PCI区域的字节长度 +pci_set_drvdata() 为一个pci_dev设置私有驱动数据指针 +pci_get_drvdata() 返回一个pci_dev的私有驱动数据指针 +pci_set_mwi() 启用设备内存写无效 +pci_clear_mwi() 关闭设备内存写无效 +============================= ================================================= + + +杂项提示 +======== + +当向用户显示PCI设备名称时(例如，当驱动程序想告诉用户它找到了什么卡时)，请使 +用pci_name(pci_dev)。 + +始终通过对pci_dev结构体的指针来引用PCI设备。所有的PCI层函数都使用这个标识， +它是唯一合理的标识。除了非常特殊的目的，不要使用总线/插槽/功能号————在有多个 +主总线的系统上，它们的语义可能相当复杂。 + +不要试图在你的驱动程序中开启快速寻址周期写入功能。总线上的所有设备都需要有这样 +的功能，所以这需要由平台和通用代码来处理，而不是由单个驱动程序来处理。 + + +供应商和设备标识 +================ + +不要在include/linux/pci_ids.h中添加新的设备或供应商ID，除非它们是在多个驱 +动程序中共享。如果有需要的话，你可以在你的驱动程序中添加私有定义，或者直接使用 +普通的十六进制常量。 + +设备ID是任意的十六进制数字（厂商控制），通常只在一个地方使用，即pci_device_id +表。 + +请务必提交新的供应商/设备ID到https://pci-ids.ucw.cz/。在 +https://github.com/pciutils/pciids，有一个pci.ids文件的镜像。 + + +过时的函数 +========== + +当你试图将一个旧的驱动程序移植到新的PCI接口时，你可能会遇到几个函数。它们不再存 +在于内核中，因为它们与热插拔或PCI域或具有健全的锁不兼容。 + +================= =================================== +pci_find_device() 被pci_get_device()取代 +pci_find_subsys() 被pci_get_subsys()取代 +pci_find_slot() 被pci_get_domain_bus_and_slot()取代 +pci_get_slot() 被pci_get_domain_bus_and_slot()取代 +================= =================================== + +另一种方法是传统的PCI设备驱动，即走PCI设备列表。这仍然是可能的，但不鼓励这样做。 + + +MMIO空间和“写通知” +================== + +将驱动程序从使用I/O端口空间转换为使用MMIO空间，通常需要一些额外的改变。具体来说， +需要处理“写通知”。许多驱动程序（如tg3，acenic，sym53c8xx_2）已经做了这个。I/O +端口空间保证写事务在CPU继续之前到达PCI设备。对MMIO空间的写入允许CPU在事务到达PCI +设备之前继续。HW weenies称这为“写通知”，因为在事务到达目的地之前，写的完成被“通知” +给CPU。 + +因此，对时间敏感的代码应该添加readl()，CPU在做其他工作之前应该等待。经典的“位脉冲” +序列对I/O端口空间很有效:: + + for (i = 8; --i; val >>= 1) { + outb(val & 1, ioport_reg); /* 置位 */ + udelay(10); + } + +对MMIO空间来说，同样的顺序应该是:: + + for (i = 8; --i; val >>= 1) { + writeb(val & 1, mmio_reg); /* 置位 */ + readb(safe_mmio_reg); /* 刷新写通知 */ + udelay(10); + } + +重要的是， ``safe_mmio_reg`` 不能有任何干扰设备正确操作的副作用。 + +另一种需要注意的情况是在重置PCI设备时。使用PCI配置空间读数来刷新writeel()。如果预期 +PCI设备不响应readl()，这将在所有平台上优雅地处理PCI主控器的中止。大多数x86平台将允许 +MMIO读取主控中止（又称“软失败”），并返回垃圾（例如~0）。但许多RISC平台会崩溃（又称“硬失败”）。 diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst index 460034cbc2ab..83db84282562 100644 --- a/Documentation/translations/zh_CN/admin-guide/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/index.rst @@ -67,6 +67,7 @@ Todolist: cpu-load lockup-watchdogs unicode + sysrq Todolist: @@ -118,7 +119,6 @@ Todolist: rtc serial-console svga - sysrq thunderbolt ufs vga-softcursor diff --git a/Documentation/translations/zh_CN/admin-guide/sysrq.rst b/Documentation/translations/zh_CN/admin-guide/sysrq.rst new file mode 100644 index 000000000000..8276d70f3b40 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/sysrq.rst @@ -0,0 +1,280 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/sysrq.rst + +:翻译: + + 黄军华 Junhua Huang <huang.junhua@zte.com.cn> + +:校译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +.. _cn_admin-guide_sysrq: + +Linux 魔法系统请求键骇客 +======================== + +针对 sysrq.c 的文档说明 + +什么是魔法 SysRq 键？ +~~~~~~~~~~~~~~~~~~~~~ + +它是一个你可以输入的具有魔法般的组合键。 +无论内核在做什么，内核都会响应 SysRq 键的输入，除非内核完全卡死。 + +如何使能魔法 SysRq 键？ +~~~~~~~~~~~~~~~~~~~~~~~ + +在配置内核时，我们需要设置 'Magic SysRq key (CONFIG_MAGIC_SYSRQ)' 为 'Y'。 +当运行一个编译进 sysrq 功能的内核时，/proc/sys/kernel/sysrq 控制着被 +SysRq 键调用的功能许可。这个文件的默认值由 CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE +配置符号设定，文件本身默认设置为 1。以下是 /proc/sys/kernel/sysrq 中可能的 +值列表： + + - 0 - 完全不使能 SysRq 键 + - 1 - 使能 SysRq 键的全部功能 + - >1 - 对于允许的 SysRq 键功能的比特掩码（参见下面更详细的功能描述）:: + + 2 = 0x2 - 使能对控制台日志记录级别的控制 + 4 = 0x4 - 使能对键盘的控制 (SAK, unraw) + 8 = 0x8 - 使能对进程的调试导出等 + 16 = 0x10 - 使能同步命令 + 32 = 0x20 - 使能重新挂载只读 + 64 = 0x40 - 使能对进程的信号操作 (term, kill, oom-kill) + 128 = 0x80 - 允许重启、断电 + 256 = 0x100 - 允许让所有实时任务变普通任务 + +你可以通过如下命令把值设置到这个文件中:: + + echo "number" >/proc/sys/kernel/sysrq + +这里被写入的 number 可以是 10 进制数，或者是带着 0x 前缀的 16 进制数。 +CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE 必须是以 16 进制数写入。 + +注意，``/proc/sys/kernel/sysrq`` 的值只影响通过键盘触发 SySRq 的调用，对于 +通过 ``/proc/sysrq-trigger`` 的任何操作调用都是允许的 +（通过具有系统权限的用户）。 + +如何使用魔法 SysRq 键？ +~~~~~~~~~~~~~~~~~~~~~~~ + +在 x86 架构上 + 你可以按下键盘组合键 :kbd:`ALT-SysRq-<command key>`。 + + .. note:: + 一些键盘可能没有标识 'SySRq' 键。'SySRq' 键也被当做 'Print Screen'键。 + 同时有些键盘无法处理同时按下这么多键，因此你可以先按下键盘 :kbd:`Alt` 键， + 然后按下键盘 :kbd:`SysRq` 键，再释放键盘 :kbd:`SysRq` 键，之后按下键盘上命令键 + :kbd:`<command key>`，最后释放所有键。 + +在 SPARC 架构上 + 你可以按下键盘组合键 :kbd:`ALT-STOP-<command key>` 。 + +在串行控制台（只针对 PC 类型的标准串口） + 你可以发一个 ``BREAK`` ，然后在 5 秒内发送一个命令键， + 发送 ``BREAK`` 两次将被翻译为一个正常的 BREAK 操作。 + +在 PowerPC 架构上 + 按下键盘组合键 :kbd:`ALT - Print Screen` （或者 :kbd:`F13`） - :kbd:`<命令键>` 。 + :kbd:`Print Screen` （或者 :kbd:`F13`） - :kbd:`<命令键>` 或许也能实现。 + +在其他架构上 + 如果你知道其他架构的组合键，请告诉我，我可以把它们添加到这部分。 + +在所有架构上 + 写一个字符到 /proc/sysrq-trigger 文件，例如:: + + echo t > /proc/sysrq-trigger + +这个命令键 :kbd:`<command key>` 是区分大小写的。 + +什么是命令键？ +~~~~~~~~~~~~~~ + +=========== ================================================================ +命令键 功能 +=========== ================================================================ +``b`` 将立即重启系统，不会同步或者卸载磁盘。 + +``c`` 将执行系统 crash，如果配置了系统 crashdump，将执行 crashdump。 + +``d`` 显示所有持有的锁。 + +``e`` 发送 SIGTERM 信号给所有进程，除了 init 进程。 + +``f`` 将调用 oom killer 杀掉一个过度占用内存的进程，如果什么任务都没杀， + 也不会 panic。 + +``g`` kgdb 使用（内核调试器）。 + +``h`` 将会显示帮助。（实际上除了这里列举的键，其他的都将显示帮助， + 但是 ``h`` 容易记住）:-) + +``i`` 发送 SIGKILL 给所有进程，除了 init 进程。 + +``j`` 强制性的 “解冻它” - 用于被 FIFREEZE ioctl 操作冻住的文件系统。 + +``k`` 安全访问秘钥(SAK)杀掉在当前虚拟控制台的所有程序，注意：参考 + 下面 SAK 节重要论述。 + +``l`` 显示所有活动 cpu 的栈回溯。 + +``m`` 将导出当前内存信息到你的控制台。 + +``n`` 用于使所有实时任务变成普通任务。 + +``o`` 将关闭系统（如果配置和支持的话）。 + +``p`` 将导出当前寄存器和标志位到控制台。 + +``q`` 将导出每个 cpu 上所有已装备的高精度定时器（不是完整的 + time_list 文件显示的 timers）和所有时钟事件设备的详细信息。 + +``r`` 关闭键盘的原始模式，设置为转换模式。 + +``s`` 将尝试同步所有的已挂载文件系统。 + +``t`` 将导出当前所有任务列表和它们的信息到控制台。 + +``u`` 将尝试重新挂载已挂载文件系统为只读。 + +``v`` 强制恢复帧缓存控制台。 +``v`` 触发 ETM 缓存导出 [ARM 架构特有] + +``w`` 导出处于不可中断状态（阻塞）的任务。 + +``x`` 在 ppc/powerpc 架构上用于 xmon 接口。 + 在 sparc64 架构上用于显示全局的 PMU（性能监控单元）寄存器。 + 在 MIPS 架构上导出所有的 tlb 条目。 + +``y`` 显示全局 cpu 寄存器 [SPARC-64 架构特有] + +``z`` 导出 ftrace 缓存信息 + +``0``-``9`` 设置控制台日志级别，该级别控制什么样的内核信息将被打印到你的 + 控制台。（比如 ``0`` ，将使得只有紧急信息，像 PANICs or OOPSes + 才能到你的控制台。） +=========== ================================================================ + +好了，我能用他们做什么呢？ +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +嗯，当你的 X 服务端或者 svgalib 程序崩溃，unraw(r) 非原始模式命令键是非常 +方便的。 + +sak(k)（安全访问秘钥）在你尝试登陆的同时，又想确保当前控制台没有可以获取你的 +密码的特洛伊木马程序运行时是有用的。它会杀掉给定控制台的所有程序，这样你 +就可以确认当前的登陆提示程序是实际来自 init 进程的程序，而不是某些特洛伊 +木马程序。 + +.. important:: + + 在其实际的形式中，在兼容 C2 安全标准的系统上，它不是一个真正的 SAK， + 它也不应该误认为此。 + +似乎其他人发现其可以作为（系统终端联机键）当你想退出一个程序， +同时不会让你切换控制台的方法。（比如，X 服务端或者 svgalib 程序） + +``reboot(b)`` 是个好方法，当你不能关闭机器时，它等同于按下"复位"按钮。 + +``crash(c)`` 可以用于手动触发一个 crashdump，当系统卡住时。 +注意当 crashdump 机制不可用时，这个只是触发一个内核 crash。 + +``sync(s)`` 在拔掉可移动介质之前，或者在使用不提供优雅关机的 +救援 shell 之后很方便 -- 它将确保你的数据被安全地写入磁盘。注意，在你看到 +屏幕上出现 "OK" 和 "Done" 之前，同步还没有发生。 + +``umount(u)`` 可以用来标记文件系统正常卸载，从正在运行的系统角度来看，它们将 +被重新挂载为只读。这个重新挂载动作直到你看到 "OK" 和 "Done" 信息出现在屏幕上 +才算完成。 + +日志级别 ``0`` - ``9`` 用于当你的控制台被大量的内核信息冲击，你不想看见的时候。 +选择 ``0`` 将禁止除了最紧急的内核信息外的所有的内核信息输出到控制台。（但是如果 +syslogd/klogd 进程是运行的，它们仍将被记录。） + +``term(e)`` 和 ``kill(i)`` 用于当你有些有点失控的进程，你无法通过其他方式杀掉 +它们的时候，特别是它正在创建其他进程。 + +"just thaw ``it(j)`` " 用于当你的系统由于一个 FIFREEZE ioctl 调用而产生的文件 +系统冻结，而导致的不响应时。 + +有的时候 SysRq 键在使用它之后，看起来像是“卡住”了，我能做些什么？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +这也会发生在我这，我发现轻敲键盘两侧的 shift、alt 和 control 键，然后再次敲击 +一个无效的 SysRq 键序列可以解决问题。（比如，像键盘组合键 :kbd:`alt-sysrq-z` ） +切换到另一个虚拟控制台（键盘操作 :kbd:`ALT+Fn` ），然后再切回来应该也有帮助。 + +我敲击了 SysRq 键，但像是什么都没发生，发生了什么错误？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +有一些键盘对于 SysRq 键设置了不同的键值，而不是提前定义的 99 +(查看在 ``include/uapi/linux/input-event-codes.h`` 文件中 ``KEY_SYSRQ`` 的定义) +或者就根本没有 SysRq 键。在这些场景下，执行 ``showkey -s`` 命令来找到一个合适 +的扫描码序列，然后使用 ``setkeycodes <sequence> 99`` 命令映射这个序列值到通用 +的 SysRq 键编码上（比如 ``setkeycodes e05b 99`` ）。最好将这个命令放在启动脚本 +中。 +哦，顺便说一句，你十秒钟不输入任何东西就将退出 “showkey”。 + +我想添加一个 SysRq 键事件到一个模块中，如何去做呢？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +为了注册一个基础函数到这个表中，首先你必须包含 ``include/linux/sysrq.h`` 头 +文件，这个头文件定义了你所需要的所有东西。然后你必须创建一个 ``sysrq_key_op`` +结构体，然后初始化它，使用如下内容，A） 你将使用的这个键的处理函数， B） 一个 +help_msg 字符串，在 SysRq 键打印帮助信息时将打印出来，C） 一个 action_msg 字 +符串，就在你的处理函数调用前打印出来。你的处理函数必须符合在 'sysrq.h' 文件中 +的函数原型。 + +在 ``sysrq_key_op`` 结构体被创建后，你可以调用内核函数 +``register_sysrq_key(int key, const struct sysrq_key_op *op_p);``， +该函数在表中的 'key' 对应位置内容是空的情况下，将通过 ``op_p`` 指针注册这个操作 +函数到表中 'key' 对应位置上。在模块卸载的时候，你必须调用 +``unregister_sysrq_key(int key, const struct sysrq_key_op *op_p)`` 函数，该函数 +只有在当前该键对应的处理函数被注册到了 'key' 对应位置时，才会移除 'op_p' 指针 +对应的键值操作函数。这是为了防止在你注册之后，该位置被改写的情况。 + +魔法 SysRq 键系统的工作原理是将键对应操作函数注册到键的操作查找表， +该表定义在 'drivers/tty/sysrq.c' 文件中。 +该键表有许多在编译时候就注册进去的操作函数，但是是可变的。 +并且有两个函数作为操作该表的接口被导出:: + + register_sysrq_key 和 unregister_sysrq_key. + +当然，永远不要在表中留下无效指针，即，当你的模块存在调用 register_sysrq_key() +函数，它一定要调用 unregister_sysrq_key() 来清除它使用过的 SysRq 键表条目。 +表中的空指针是安全的。:) + +如果对于某种原因，在 handle_sysrq 调用的处理函数中，你认为有必要调用 +handle_sysrq 函数时，你必须意识到当前你处于一个锁中（你同时也处于一个中断处理 +函数中，这意味着不能睡眠）。所以这时你必须使用 ``__handle_sysrq_nolock`` 替代。 + +当我敲击一个 SysRq 组合键时，只有标题打印出现在控制台？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +SysRq 键的输出和所有其他控制台输出一样，受制于控制台日志级别控制。 +这意味着，如果内核以发行版内核中常见的 "quiet" 方式启动，则输出可能不会出现在实际 +的控制台上，即使它会出现在 dmesg 缓存中，也可以通过 dmesg 命令和 ``/proc/kmsg`` +文件的消费访问到。作为一个特例，来自 sysrq 命令的标题行将被传递给所有控制台 +使用者，就好像当前日志级别是最大的一样。如果只发出标题头，则几乎可以肯定内核日志 +级别太低。如果你需要控制台上的输出，那么你将需要临时提高控制台日志级别，通过使用 +键盘组合键 :kbd:`alt-sysrq-8` 或者:: + + echo 8 > /proc/sysrq-trigger + +在触发了你感兴趣的 SysRq 键命令后，记得恢复日志级别到正常情况。 + +我有很多问题时，可以请教谁？ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +请教在内核邮件列表上的人，邮箱： + linux-kernel@vger.kernel.org + +致谢 +~~~~ + +- Mydraal <vulpyne@vulpyne.net> 撰写了该文件 +- Adam Sulmicki <adam@cfar.umd.edu> 进行了更新 +- Jeremy M. Dolan <jmd@turbogeek.org> 在 2001/01/28 10:15:59 进行了更新 +- Crutcher Dunnavant <crutcher+kernel@datastacks.com> 添加键注册部分 diff --git a/Documentation/translations/zh_CN/core-api/assoc_array.rst b/Documentation/translations/zh_CN/core-api/assoc_array.rst new file mode 100644 index 000000000000..3649bf0d1488 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/assoc_array.rst @@ -0,0 +1,473 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/assoc_array.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + + +.. _cn_core-api_assoc_array: + +================== +通用关联数组的实现 +================== + +简介 +==== + +这个关联数组的实现是一个具有以下属性的对象容器: + +1. 对象是不透明的指针。该实现不关心它们指向哪里（如果有的话）或它们指向什么（如果有的 + 话）。 + + .. note:: + + 指向对象的指针 *必须* 在最小有效位为零。 + +2. 对象不需要包含供数组使用的链接块。这允许一个对象同时位于多个数组中。相反，数组是 + 由指向对象的元数据块组成的。 + +3. 对象需要索引键来定位它们在阵列中的位置。 + +4. 索引键必须是唯一的。插入一个与已经在数组中的且具有相同键值的对象将取代旧的对象。 + +5. 索引键可以是任何长度，也可以是不同的长度。 + +6. 索引键应该在早期就对长度进行编码，即在任何由于长度引起的变化出现之前。 + +7. 索引键可以包括一个哈希值，以便将对象分散到整个数组中。 + +8. 该数组可以迭代。对象不一定会按索引键的顺序出现。 + +9. 数组可以在被修改的时候进行迭代，只要RCU的读锁被迭代器持有。然而，请注意，在这种情 + 况下，一些对象可能会被看到不止一次。如果这是个问题，迭代器应该锁定以防止修改。然 + 而，除非删除，否则对象不会被错过。 + +10. 数组中的对象可以通过其索引键进行查询。 + +11. 当数组被修改时，对象可以被查询，前提是进行查询的线程持有RCU的读锁。 + +该实现在内部使用了一棵由16个指针节点组成的树，这些节点在每一层都由索引键的小数点进行索 +引，其方式与基数树相同。为了提高内存效率，可以放置快捷键，以跳过本来是一系列单占节点的地 +方。此外，节点将叶子对象指针打包到节点的空闲空间中，而不是做一个额外的分支，直到有对象 +需要被添加到一个完整的节点中。 + +公用API +======= + +公用API可以在 ``<linux/assoc_array.h>`` 中找到。关联数组的根是以下结构:: + + struct assoc_array { + ... + }; + +该代码是通过启用 ``CONFIG_ASSOCIATIVE_ARRAY`` 来选择的，以:: + + ./script/config -e ASSOCIATIVE_ARRAY + + +编辑脚本 +-------- + +插入和删除功能会产生一个“编辑脚本”，以后可以应用这个脚本来实现更改，而不会造成 ``ENOMEM`` +风险。这保留了将被安装在内部树中的预分配的元数据块，并跟踪应用脚本时将从树中删除的元数 +据块。 + +在脚本应用后，这也被用来跟踪死块和死对象，以便以后可以释放它们。释放是在RCU宽限期过后 +进行的--因此允许访问功能在RCU读锁下进行。 + +脚本在API之外显示为一个类型为:: + + struct assoc_array_edit; + +有两个处理脚本的功能: + +1. 应用一个编辑脚本:: + + void assoc_array_apply_edit(struct assoc_array_edit *edit); + +这将执行编辑功能，插值各种写屏障，以允许在RCU读锁下的访问继续进行。然后，编辑脚本将被 +传递给 ``call_rcu()`` ，以释放它和它所指向的任何死的东西。 + +2. Cancel an edit script:: + + void assoc_array_cancel_edit(struct assoc_array_edit *edit); + +这将立即释放编辑脚本和所有预分配的内存。如果这是为了插入，新的对象不会被这个函数释放， +而是必须由调用者释放。 + +这些函数保证不会失败。 + + +操作表 +------ + +各种功能采用了一个操作表:: + + struct assoc_array_ops { + ... + }; + +这指出了一些方法，所有这些方法都需要提供: + +1. 从调用者数据中获取索引键的一个块:: + + unsigned long (*get_key_chunk)(const void *index_key, int level); + +这应该返回一个由调用者提供的索引键的块，从level参数给出的 *比特* 位置开始。level参数将 +是 ``ASSOC_ARRAY_KEY_CHUNK_SIZE`` 的倍数，该函数应返回 ``ASSOC_ARRAY_KEY_CHUNK_SIZE`` +位。不可能出现错误。 + + +2. 获取一个对象的索引键的一个块:: + + unsigned long (*get_object_key_chunk)(const void *object, int level); + +和前面的函数一样，但是从数组中的一个对象而不是从调用者提供的索引键中获取数据。 + + +3. 看看这是否是我们要找的对象:: + + bool (*compare_object)(const void *object, const void *index_key); + +将对象与一个索引键进行比较，如果匹配则返回 ``true`` ，不匹配则返回 ``false`` 。 + + +4. 对两个对象的索引键进行比较:: + + int (*diff_objects)(const void *object, const void *index_key); + +返回指定对象的索引键与给定索引键不同的比特位置，如果它们相同，则返回-1。 + + +5. 释放一个对象:: + + void (*free_object)(void *object); + +释放指定的对象。注意，这可能是在调用 ``assoc_array_apply_edit()`` 后的一个RCU宽限期内 +调用的，所以在模块卸载时可能需要 ``synchronize_rcu()`` 。 + + +操控函数 +-------- + +有一些函数用于操控关联数组: + +1. 初始化一个关联数组:: + + void assoc_array_init(struct assoc_array *array); + +这将初始化一个关联数组的基础结构。它不会失败。 + + +2. 在一个关联数组中插入/替换一个对象:: + + struct assoc_array_edit * + assoc_array_insert(struct assoc_array *array, + const struct assoc_array_ops *ops, + const void *index_key, + void *object); + +这将把给定的对象插入数组中。注意，指针的最小有效位必须是0，因为它被用来在内部标记指针的类 +型。 + +如果该键已经存在一个对象，那么它将被新的对象所取代，旧的对象将被自动释放。 + +``index_key`` 参数应持有索引键信息，并在调用OPP表中的方法时传递给它们。 + +这个函数不对数组本身做任何改动，而是返回一个必须应用的编辑脚本。如果出现内存不足的错误，会 +返回 ``-ENOMEM`` 。 + +调用者应专门锁定数组的其他修改器。 + + +3. 从一个关联数组中删除一个对象:: + + struct assoc_array_edit * + assoc_array_delete(struct assoc_array *array, + const struct assoc_array_ops *ops, + const void *index_key); + +这将从数组中删除一个符合指定数据的对象。 + +``index_key`` 参数应持有索引键信息，并在调用OPP表中的方法时传递给它们。 + +这个函数不对数组本身做任何改动，而是返回一个必须应用的编辑脚本。 ``-ENOMEM`` 在出现内存不足 +的错误时返回。如果在数组中没有找到指定的对象，将返回 ``NULL`` 。 + +调用者应该对数组的其他修改者进行专门锁定。 + + +4. 从一个关联数组中删除所有对象:: + + struct assoc_array_edit * + assoc_array_clear(struct assoc_array *array, + const struct assoc_array_ops *ops); + +这个函数删除了一个关联数组中的所有对象，使其完全为空。 + +这个函数没有对数组本身做任何改动，而是返回一个必须应用的编辑脚本。如果出现内存不足 +的错误，则返回 ``-ENOMEM`` 。 + +调用者应专门锁定数组的其他修改者。 + + +5. 销毁一个关联数组，删除所有对象:: + + void assoc_array_destroy(struct assoc_array *array, + const struct assoc_array_ops *ops); + +这将破坏关联数组的内容，使其完全为空。在这个函数销毁数组的同时，不允许另一个线程在RCU读锁 +下遍历数组，因为在内存释放时不执行RCU延迟，这需要分配内存。 + +调用者应该专门针对数组的其他修改者和访问者进行锁定。 + + +6. 垃圾回收一个关联数组:: + + int assoc_array_gc(struct assoc_array *array, + const struct assoc_array_ops *ops, + bool (*iterator)(void *object, void *iterator_data), + void *iterator_data); + +这是对一个关联数组中的对象进行迭代，并将每个对象传递给 ``iterator()`` 。如果 ``iterator()`` 返回 +true，该对象被保留。如果它返回 ``false`` ，该对象将被释放。如果 ``iterator()`` 函数返回 ``true`` ，它必须 +在返回之前对该对象进行适当的 ``refcount`` 递增。 + +如果可能的话，内部树将被打包下来，作为迭代的一部分，以减少其中的节点数量。 + +``iterator_data`` 被直接传递给 ``iterator()`` ，否则会被函数忽略。 + +如果成功，该函数将返回 ``0`` ，如果没有足够的内存，则返回 ``-ENOMEM`` 。 + +在这个函数执行过程中，其他线程有可能在RCU读锁下迭代或搜索阵列。调用者应该专门针对数组的其他 +修改者进行锁定。 + + +访问函数 +-------- + +有两个函数用于访问一个关联数组: + +1. 遍历一个关联数组中的所有对象:: + + int assoc_array_iterate(const struct assoc_array *array, + int (*iterator)(const void *object, + void *iterator_data), + void *iterator_data); + +这将数组中的每个对象传递给迭代器回调函数。 ``iterator_data`` 是该函数的私有数据。 + +在数组被修改的同时，可以在数组上使用这个方法，前提是RCU读锁被持有。在这种情况下，迭代函数有 +可能两次看到某些对象。如果这是个问题，那么修改应该被锁定。然而，迭代算法不应该错过任何对象。 + +如果数组中没有对象，该函数将返回 ``0`` ，否则将返回最后一次调用的迭代器函数的结果。如果对迭代函数 +的任何调用导致非零返回，迭代立即停止。 + + +2. 在一个关联数组中寻找一个对象:: + + void *assoc_array_find(const struct assoc_array *array, + const struct assoc_array_ops *ops, + const void *index_key); + +这将直接穿过数组的内部树，到达索引键所指定的对象。 + +这个函数可以在修改数组的同时用在数组上，前提是RCU读锁被持有。 + +如果找到对象，该函数将返回对象（并将 ``*_type`` 设置为对象的类型），如果没有找到对象，将返回 ``NULL`` 。 + + +索引键形式 +---------- + +索引键可以是任何形式的，但是由于算法没有被告知键有多长，所以强烈建议在任何由于长度而产生的变化 +对比较产生影响之前，索引键应该很早就包括其长度。 + +这将导致具有不同长度键的叶子相互分散，而具有相同长度键的叶子则聚集在一起。 + +我们还建议索引键以键的其余部分的哈希值开始，以最大限度地提高整个键空间的散布情况。 + +分散性越好，内部树就越宽，越低。 + +分散性差并不是一个太大的问题，因为有快捷键，节点可以包含叶子和元数据指针的混合物。 + +索引键是以机器字的块状来读取的。每个块被细分为每层一个nibble（4比特），所以在32位CPU上这适合8层， +在64位CPU上适合16层。除非散布情况真的很差，否则不太可能有超过一个字的任何特定索引键需要被使用。 + + +内部工作机制 +============ + +关联数组数据结构有一个内部树。这个树由两种类型的元数据块构成：节点和快捷键。 + +一个节点是一个槽的数组。每个槽可以包含以下四种东西之一: + +* 一个NULL的指针，表示槽是空的。 +* 一个指向对象（叶子）的指针。 +* 一个指向下一级节点的指针。 +* 一个指向快捷键的指针。 + + +基本的内部树形布局 +------------------ + +暂时不考虑快捷键，节点形成一个多级树。索引键空间被树上的节点严格细分，节点出现在固定的层次上。例如:: + + Level: 0 1 2 3 + =============== =============== =============== =============== + NODE D + NODE B NODE C +------>+---+ + +------>+---+ +------>+---+ | | 0 | + NODE A | | 0 | | | 0 | | +---+ + +---+ | +---+ | +---+ | : : + | 0 | | : : | : : | +---+ + +---+ | +---+ | +---+ | | f | + | 1 |---+ | 3 |---+ | 7 |---+ +---+ + +---+ +---+ +---+ + : : : : | 8 |---+ + +---+ +---+ +---+ | NODE E + | e |---+ | f | : : +------>+---+ + +---+ | +---+ +---+ | 0 | + | f | | | f | +---+ + +---+ | +---+ : : + | NODE F +---+ + +------>+---+ | f | + | 0 | NODE G +---+ + +---+ +------>+---+ + : : | | 0 | + +---+ | +---+ + | 6 |---+ : : + +---+ +---+ + : : | f | + +---+ +---+ + | f | + +---+ + +在上述例子中，有7个节点（A-G），每个节点有16个槽（0-f）。假设树上没有其他元数据节点，那么密钥空间 +是这样划分的:: + + KEY PREFIX NODE + ========== ==== + 137* D + 138* E + 13[0-69-f]* C + 1[0-24-f]* B + e6* G + e[0-57-f]* F + [02-df]* A + +因此，例如，具有以下示例索引键的键将在适当的节点中被找到:: + + INDEX KEY PREFIX NODE + =============== ======= ==== + 13694892892489 13 C + 13795289025897 137 D + 13889dde88793 138 E + 138bbb89003093 138 E + 1394879524789 12 C + 1458952489 1 B + 9431809de993ba - A + b4542910809cd - A + e5284310def98 e F + e68428974237 e6 G + e7fffcbd443 e F + f3842239082 - A + +为了节省内存，如果一个节点可以容纳它的那部分键空间中的所有叶子，那么这个节点将有所有这些叶子，而不 +会有任何元数据指针——即使其中一些叶子想在同一个槽中。 + +一个节点可以包含叶子和元数据指针的异质性混合。元数据指针必须在与它们的关键空间的细分相匹配的槽中。 +叶子可以在任何没有被元数据指针占据的槽中。保证一个节点中没有一个叶子会与元数据指针占据的槽相匹配。 +如果元数据指针在那里，任何键与元数据键前缀相匹配的叶必须在元数据指针指向的子树中。 + +在上面的索引键的例子列表中，节点A将包含:: + + SLOT CONTENT INDEX KEY (PREFIX) + ==== =============== ================== + 1 PTR TO NODE B 1* + any LEAF 9431809de993ba + any LEAF b4542910809cd + e PTR TO NODE F e* + any LEAF f3842239082 + +和节点B:: + + 3 PTR TO NODE C 13* + any LEAF 1458952489 + + +快捷键 +--------- + +快捷键是跳过一块键空间的元数据记录。快捷键是一系列通过层次上升的单占节点的替代物。快捷键的存在是 +为了节省内存和加快遍历速度。 + +树的根部有可能是一个快捷键——比如说，树至少包含17个节点，都有键前缀 ``1111`` 。插入算法将插入一个快捷键， +以单次跳过 ``1111`` 的键位，并到达第四层，在这里，这些键位实际上变得不同。 + + +拆分和合并节点 +------------------------------ + +每个节点的最大容量为16个叶子和元数据指针。如果插入算法发现它正试图将一个第17个对象插入到一个节点中， +该节点将被拆分，使得至少两个在该层有一个共同的关键段的叶子最终在一个单独的节点中，该共同的关键段的根 +在该槽上。 + +如果一个完整的节点中的叶子和被插入的叶子足够相似，那么就会在树中插入一个快捷键。 + +当根植于某个节点的子树中的对象数量下降到16个或更少时，那么该子树将被合并成一个单独的节点——如果可能的 +话，这将向根部扩散。 + + +非递归式迭代 +------------ + +每个节点和快捷键都包含一个指向其父节点的后置指针，以及该父节点中指向它的槽数。非递归迭代使用这些来 +通过树的根部进行，前往父节点，槽N+1，以确保在没有堆栈的情况下取得进展。 + +然而，反向指针使得同时改变和迭代变得很棘手。 + + +同时改变和迭代 +-------------- + +有一些情况需要考虑: + +1. 简单的插入/替换。这涉及到简单地将一个NULL或旧的匹配叶子的指针替换为屏障后的新叶子的指针。否则元数 + 据块不会改变。一个旧的叶子直到RCU宽限期过后才会被释放。 + +2. 简单删除。这只是涉及到清除一个旧的匹配叶子。元数据块不会有其他变化。旧的叶子直到RCU宽限期之后才会 + 被释放。 + +3. 插入，替换我们还没有进入的子树的一部分。这可能涉及到替换该子树的一部分——但这不会影响迭代，因为我们 + 还没有到达它的指针，而且祖先块也不会被替换（这些块的布局不会改变）。 + +4. 插入替换了我们正在处理的节点。这不是一个问题，因为我们已经通过了锚定指针，直到我们跟随后面的指针才 + 会切换到新的布局上——这时我们已经检查了被替换节点的叶子（在跟随任何元数据指针之前，我们会迭代一个节 + 点的所有叶子）。 + + 然而，我们可能会重新看到一些叶子，这些叶子已经被分割成一个新的分支，而这个分支的位置比我们之前的位 + 置更远。 + +5. 插入替换了我们正在处理的依赖分支的节点。这不会影响到我们，直到我们跟随后面的指针。与（4）类似。 + +6. 删掉我们下面的一个分支。这不会影响我们，因为在我们看到新节点之前，回溯指针会让我们回到新节点的父节 + 点。整个崩溃的子树被扔掉了，没有任何变化——而且仍然会在同一个槽上生根，所以我们不应该第二次处理它， + 因为我们会回到槽+1。 + +.. note:: + + 在某些情况下，我们需要同时改变一个节点的父指针和父槽指针（比如说，我们在它之前插入了另一个节点， + 并把它往上移了一层）。我们不能在不锁定读取的情况下这样做——所以我们必须同时替换该节点。 + + 然而，当我们把一个快捷键改成一个节点时，这不是一个问题，因为快捷键只有一个槽，所以当向后遍 + 历一个槽时，不会使用父槽号。这意味着先改变槽位号是可以的——只要使用适当的屏障来确保父槽位号在后 + 退指针之后被读取。 + +过时的块和叶子在RCU宽限期过后会被释放，所以只要任何进行遍历或迭代的人持有RCU读锁，旧的上层建筑就不 +应该在他们身上消失。 diff --git a/Documentation/translations/zh_CN/core-api/boot-time-mm.rst b/Documentation/translations/zh_CN/core-api/boot-time-mm.rst new file mode 100644 index 000000000000..9e81dbec71f8 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/boot-time-mm.rst @@ -0,0 +1,49 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/boot-time-mm.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + 时奎亮 <alexs@kernel.org> + +.. _cn_core-api_boot-time-mm: + +================ +启动时的内存管理 +================ + +系统初始化早期“正常”的内存管理由于没有设置完毕无法使用。但是内核仍然需要 +为各种数据结构分配内存，例如物理页分配器。 + +一个叫做 ``memblock`` 的专用分配器执行启动时的内存管理。特定架构的初始化 +必须在setup_arch()中设置它，并在mem_init()函数中移除它。 + +一旦早期的内存管理可用，它就为内存分配提供了各种函数和宏。分配请求可以指向 +第一个（也可能是唯一的）节点或NUMA系统中的某个特定节点。有一些API变体在分 +配失败时panic，也有一些不会panic的。 + +Memblock还提供了各种控制其自身行为的API。 + +Memblock概述 +============ + +该API在以下内核代码中: + +mm/memblock.c + + +函数和结构体 +============ + +下面是关于memblock数据结构、函数和宏的描述。其中一些实际上是内部的，但由于 +它们被记录下来，漏掉它们是很愚蠢的。此外，阅读内部函数的注释可以帮助理解引 +擎盖下真正发生的事情。 + +该API在以下内核代码中: + +include/linux/memblock.h +mm/memblock.c diff --git a/Documentation/translations/zh_CN/core-api/genalloc.rst b/Documentation/translations/zh_CN/core-api/genalloc.rst new file mode 100644 index 000000000000..3c78452aaa7c --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/genalloc.rst @@ -0,0 +1,109 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/genalloc.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + 时奎亮 <alexs@kernel.org> + +.. _cn_core-api_genalloc: + +genalloc/genpool子系统 +====================== + +内核中有许多内存分配子系统，每一个都是针对特定的需求。然而，有时候，内核开发者需 +要为特定范围的特殊用途的内存实现一个新的分配器；通常这个内存位于某个设备上。该设 +备的驱动程序的作者当然可以写一个小的分配器来完成工作，但这是让内核充满几十个测试 +差劲的分配器的方法。早在2005年，Jes Sorensen从sym53c8xx_2驱动中提取了其中的一 +个分配器，并将其作为一个通用模块发布，用于创建特设的内存分配器。这段代码在2.6.13 +版本中被合并；此后它被大大地修改了。 + +.. _posted: https://lwn.net/Articles/125842/ + +使用这个分配器的代码应该包括<linux/genalloc.h>。这个动作从创建一个池开始，使用 +一个: + +该API在以下内核代码中: + +lib/genalloc.c + +对gen_pool_create()的调用将创建一个内存池。分配的粒度由min_alloc_order设置；它 +是一个log-base-2（以2为底的对数）的数字，就像页面分配器使用的数字一样，但它指的是 +字节而不是页面。因此，如果min_alloc_order被传递为3，那么所有的分配将是8字节的倍数。 +增加min_alloc_order可以减少跟踪池中内存所需的内存。nid参数指定哪一个NUMA节点应该被 +用于分配管家结构体；如果调用者不关心，它可以是-1。 + +“管理的”接口devm_gen_pool_create()将内存池与一个特定的设备联系起来。在其他方面， +当给定的设备被销毁时，它将自动清理内存池。 + +一个内存池池被关闭的方法是: + +该API在以下内核代码中: + +lib/genalloc.c + +值得注意的是，如果在给定的内存池中仍有未完成的分配，这个函数将采取相当极端的步骤，调用 +BUG()，使整个系统崩溃。你已经被警告了。 + +一个新创建的内存池没有内存可以分配。在这种状态下，它是相当无用的，所以首要任务之一通常 +是向内存池里添加内存。这可以通过以下方式完成: + +该API在以下内核代码中: + +include/linux/genalloc.h + +lib/genalloc.c + +对gen_pool_add()的调用将把从地址（在内核的虚拟地址空间）开始的内存的大小字节放入 +给定的池中，再次使用nid作为节点ID进行辅助内存分配。gen_pool_add_virt()变体将显式 +物理地址与内存联系起来；只有在内存池被用于DMA分配时，这才是必要的。 + +从内存池中分配内存（并将其放回）的函数是: + +该API在以下内核代码中: + +include/linux/genalloc.h + +lib/genalloc.c + +正如人们所期望的，gen_pool_alloc()将从给定的池中分配size<字节。gen_pool_dma_alloc() +变量分配内存用于DMA操作，返回dma所指向的空间中的相关物理地址。这只有在内存是用 +gen_pool_add_virt()添加的情况下才会起作用。请注意，这个函数偏离了genpool通常使用 +无符号长值来表示内核地址的模式；它返回一个void * 来代替。 + +这一切看起来都比较简单；事实上，一些开发者显然认为这太简单了。毕竟，上面的接口没有提 +供对分配函数如何选择返回哪块特定内存的控制。如果需要这样的控制，下面的函数将是有意义 +的: + +该API在以下内核代码中: + +lib/genalloc.c + +使用gen_pool_alloc_algo()进行的分配指定了一种用于选择要分配的内存的算法；默认算法可 +以用gen_pool_set_algo()来设置。数据值被传递给算法；大多数算法会忽略它，但偶尔也会需 +要它。当然，人们可以写一个特殊用途的算法，但是已经有一套公平的算法可用了: + +- gen_pool_first_fit是一个简单的初配分配器；如果没有指定其他算法，这是默认算法。 + +- gen_pool_first_fit_align强迫分配有一个特定的对齐方式（通过genpool_data_align结 + 构中的数据传递）。 + +- gen_pool_first_fit_order_align 按照大小的顺序排列分配。例如，一个60字节的分配将 + 以64字节对齐。 + +- gen_pool_best_fit，正如人们所期望的，是一个简单的最佳匹配分配器。 + +- gen_pool_fixed_alloc在池中的一个特定偏移量（通过数据参数在genpool_data_fixed结 + 构中传递）进行分配。如果指定的内存不可用，则分配失败。 + +还有一些其他的函数，主要是为了查询内存池中的可用空间或迭代内存块等目的。然而，大多数 +用户应该不需要以上描述的功能。如果幸运的话，对这个模块的广泛认识将有助于防止在未来编 +写特殊用途的内存分配器。 + +该API在以下内核代码中: + +lib/genalloc.c diff --git a/Documentation/translations/zh_CN/core-api/gfp_mask-from-fs-io.rst b/Documentation/translations/zh_CN/core-api/gfp_mask-from-fs-io.rst new file mode 100644 index 000000000000..75d2997e9bc3 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/gfp_mask-from-fs-io.rst @@ -0,0 +1,66 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/gfp_mask-from-fs-io.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + 时奎亮 <alexs@kernel.org> + +.. _cn_core-api_gfp_mask-from-fs-io: + +============================ +从FS/IO上下文中使用的GFP掩码 +============================ + +:日期: 2018年5月 +:作者: Michal Hocko <mhocko@kernel.org> + +简介 +==== + +文件系统和IO栈中的代码路径在分配内存时必须小心，以防止因直接调用FS或IO路径的内 +存回收和阻塞已经持有的资源（例如锁--最常见的是用于事务上下文的锁）而造成递归死 +锁。 + +避免这种死锁问题的传统方法是在调用分配器时，在gfp掩码中清除__GFP_FS和__GFP_IO +（注意后者意味着也要清除第一个）。GFP_NOFS和GFP_NOIO可以作为快捷方式使用。但事 +实证明，上述方法导致了滥用，当限制性的gfp掩码被用于“万一”时，没有更深入的考虑， +这导致了问题，因为过度使用GFP_NOFS/GFP_NOIO会导致内存过度回收或其他内存回收的问 +题。 + +新API +===== + +从4.12开始，我们为NOFS和NOIO上下文提供了一个通用的作用域API，分别是 +``memalloc_nofs_save`` , ``memalloc_nofs_restore`` 和 ``memalloc_noio_save`` , +``memalloc_noio_restore`` ，允许从文件系统或I/O的角度将一个作用域标记为一个 +关键部分。从该作用域的任何分配都将从给定的掩码中删除__GFP_FS和__GFP_IO，所以 +没有内存分配可以追溯到FS/IO中。 + + +该API在以下内核代码中: + +include/linux/sched/mm.h + +然后，FS/IO代码在任何与回收有关的关键部分开始之前简单地调用适当的保存函数 +——例如，与回收上下文共享的锁或当事务上下文嵌套可能通过回收进行时。恢复函数 +应该在关键部分结束时被调用。所有这一切最好都伴随着解释什么是回收上下文，以 +方便维护。 + +请注意，保存/恢复函数的正确配对允许嵌套，所以从现有的NOIO或NOFS范围分别调 +用 ``memalloc_noio_save`` 或 ``memalloc_noio_restore`` 是安全的。 + +那么__vmalloc(GFP_NOFS)呢？ +=========================== + +vmalloc不支持GFP_NOFS语义，因为在分配器的深处有硬编码的GFP_KERNEL分配，要修 +复这些分配是相当不容易的。这意味着用GFP_NOFS/GFP_NOIO调用 ``vmalloc`` 几乎 +总是一个错误。好消息是，NOFS/NOIO语义可以通过范围API实现。 + +在理想的世界中，上层应该已经标记了危险的上下文，因此不需要特别的照顾， ``vmalloc`` +的调用应该没有任何问题。有时，如果上下文不是很清楚，或者有叠加的违规行为，那么 +推荐的方法是用范围API包装vmalloc，并加上注释来解释问题。 diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index 72f0a36daa1c..d10191c45cf1 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -39,12 +39,14 @@ :maxdepth: 1 kobject - -Todolist: - kref assoc_array xarray + +Todolist: + + + idr circular-buffers rbtree @@ -101,19 +103,23 @@ Todolist: 如何在内核中分配和使用内存。请注意，在 :doc:`/vm/index` 中有更多的内存管理文档。 -Todolist: +.. toctree:: + :maxdepth: 1 memory-allocation unaligned-memory-access + mm-api + genalloc + boot-time-mm + gfp_mask-from-fs-io + +Todolist: + dma-api dma-api-howto dma-attributes dma-isa-lpc - mm-api - genalloc pin_user_pages - boot-time-mm - gfp_mask-from-fs-io 内核调试的接口 ============== diff --git a/Documentation/translations/zh_CN/core-api/irq/irq-affinity.rst b/Documentation/translations/zh_CN/core-api/irq/irq-affinity.rst index 7addd5f27a88..36b085226d0b 100644 --- a/Documentation/translations/zh_CN/core-api/irq/irq-affinity.rst +++ b/Documentation/translations/zh_CN/core-api/irq/irq-affinity.rst @@ -1,6 +1,6 @@ .. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/core-api/irq/irq-affinity +:Original: Documentation/core-api/irq/irq-affinity.rst :翻译: diff --git a/Documentation/translations/zh_CN/core-api/kref.rst b/Documentation/translations/zh_CN/core-api/kref.rst new file mode 100644 index 000000000000..b9902af310c5 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/kref.rst @@ -0,0 +1,311 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/kref.rst + +翻译: + +司延腾 Yanteng Si <siyanteng@loongson.cn> + +校译： + + <此处请校译员签名（自愿），我将在下一个版本添加> + +.. _cn_core_api_kref.rst: + +================================= +为内核对象添加引用计数器（krefs） +================================= + +:作者: Corey Minyard <minyard@acm.org> +:作者: Thomas Hellstrom <thellstrom@vmware.com> + +其中很多内容都是从Greg Kroah-Hartman2004年关于krefs的OLS论文和演讲中摘 +录的，可以在以下网址找到: + + - http://www.kroah.com/linux/talks/ols_2004_kref_paper/Reprint-Kroah-Hartman-OLS2004.pdf + - http://www.kroah.com/linux/talks/ols_2004_kref_talk/ + +简介 +==== + +krefs允许你为你的对象添加引用计数器。如果你有在多个地方使用和传递的对象， +而你没有refcounts，你的代码几乎肯定是坏的。如果你想要引用计数，krefs是个 +好办法。 + +要使用kref，请在你的数据结构中添加一个，如:: + + struct my_data + { + . + . + struct kref refcount; + . + . + }; + +kref可以出现在数据结构体中的任何地方。 + +初始化 +====== + +你必须在分配kref之后初始化它。 要做到这一点，可以这样调用kref_init:: + + struct my_data *data; + + data = kmalloc(sizeof(*data), GFP_KERNEL); + if (!data) + return -ENOMEM; + kref_init(&data->refcount); + +这将kref中的refcount设置为1。 + +Kref规则 +======== + +一旦你有一个初始化的kref，你必须遵循以下规则: + +1) 如果你对一个指针做了一个非临时性的拷贝，特别是如果它可以被传递给另一个执 + 行线程，你必须在传递之前用kref_get()增加refcount:: + + kref_get(&data->refcount); + + 如果你已经有了一个指向kref-ed结构体的有效指针（refcount不能为零），你 + 可以在没有锁的情况下这样做。 + +2) 当你完成对一个指针的处理时，你必须调用kref_put():: + + kref_put(&data->refcount, data_release); + + 如果这是对该指针的最后一次引用，释放程序将被调用。如果代码从来没有尝试过 + 在没有已经持有有效指针的情况下获得一个kref-ed结构体的有效指针，那么在没 + 有锁的情况下这样做是安全的。 + +3) 如果代码试图获得对一个kref-ed结构体的引用，而不持有一个有效的指针，它必 + 须按顺序访问，在kref_put()期间不能发生kref_get()，并且该结构体在kref_get() + 期间必须保持有效。 + +例如，如果你分配了一些数据，然后将其传递给另一个线程来处理:: + + void data_release(struct kref *ref) + { + struct my_data *data = container_of(ref, struct my_data, refcount); + kfree(data); + } + + void more_data_handling(void *cb_data) + { + struct my_data *data = cb_data; + . + . do stuff with data here + . + kref_put(&data->refcount, data_release); + } + + int my_data_handler(void) + { + int rv = 0; + struct my_data *data; + struct task_struct *task; + data = kmalloc(sizeof(*data), GFP_KERNEL); + if (!data) + return -ENOMEM; + kref_init(&data->refcount); + + kref_get(&data->refcount); + task = kthread_run(more_data_handling, data, "more_data_handling"); + if (task == ERR_PTR(-ENOMEM)) { + rv = -ENOMEM; + kref_put(&data->refcount, data_release); + goto out; + } + + . + . do stuff with data here + . + out: + kref_put(&data->refcount, data_release); + return rv; + } + +这样，两个线程处理数据的顺序并不重要，kref_put()处理知道数据不再被引用并释 +放它。kref_get()不需要锁，因为我们已经有了一个有效的指针，我们拥有一个 +refcount。put不需要锁，因为没有任何东西试图在没有持有指针的情况下获取数据。 + +在上面的例子中，kref_put()在成功和错误路径中都会被调用2次。这是必要的，因 +为引用计数被kref_init()和kref_get()递增了2次。 + +请注意，规则1中的 "before "是非常重要的。你不应该做类似于:: + + task = kthread_run(more_data_handling, data, "more_data_handling"); + if (task == ERR_PTR(-ENOMEM)) { + rv = -ENOMEM; + goto out; + } else + /* BAD BAD BAD - 在交接后得到 */ + kref_get(&data->refcount); + +不要以为你知道自己在做什么而使用上述构造。首先，你可能不知道自己在做什么。 +其次，你可能知道自己在做什么（有些情况下涉及到锁，上述做法可能是合法的）， +但其他不知道自己在做什么的人可能会改变代码或复制代码。这是很危险的作风。请 +不要这样做。 + +在有些情况下，你可以优化get和put。例如，如果你已经完成了一个对象，并且给其 +他对象排队，或者把它传递给其他对象，那么就没有理由先做一个get，然后再做一个 +put:: + + /* 糟糕的额外获取(get)和输出(put) */ + kref_get(&obj->ref); + enqueue(obj); + kref_put(&obj->ref, obj_cleanup); + +只要做enqueue就可以了。 我们随时欢迎对这个问题的评论:: + + enqueue(obj); + /* 我们已经完成了对obj的处理，所以我们把我们的refcount传给了队列。 + 在这之后不要再碰obj了! */ + +最后一条规则（规则3）是最难处理的一条。例如，你有一个每个项目都被krefed的列表， +而你希望得到第一个项目。你不能只是从列表中抽出第一个项目，然后kref_get()它。 +这违反了规则3，因为你还没有持有一个有效的指针。你必须添加一个mutex（或其他锁）。 +比如说:: + + static DEFINE_MUTEX(mutex); + static LIST_HEAD(q); + struct my_data + { + struct kref refcount; + struct list_head link; + }; + + static struct my_data *get_entry() + { + struct my_data *entry = NULL; + mutex_lock(&mutex); + if (!list_empty(&q)) { + entry = container_of(q.next, struct my_data, link); + kref_get(&entry->refcount); + } + mutex_unlock(&mutex); + return entry; + } + + static void release_entry(struct kref *ref) + { + struct my_data *entry = container_of(ref, struct my_data, refcount); + + list_del(&entry->link); + kfree(entry); + } + + static void put_entry(struct my_data *entry) + { + mutex_lock(&mutex); + kref_put(&entry->refcount, release_entry); + mutex_unlock(&mutex); + } + +如果你不想在整个释放操作过程中持有锁，kref_put()的返回值是有用的。假设你不想在 +上面的例子中在持有锁的情况下调用kfree()（因为这样做有点无意义）。你可以使用kref_put()， +如下所示:: + + static void release_entry(struct kref *ref) + { + /* 所有的工作都是在从kref_put()返回后完成的。*/ + } + + static void put_entry(struct my_data *entry) + { + mutex_lock(&mutex); + if (kref_put(&entry->refcount, release_entry)) { + list_del(&entry->link); + mutex_unlock(&mutex); + kfree(entry); + } else + mutex_unlock(&mutex); + } + +如果你必须调用其他程序作为释放操作的一部分，而这些程序可能需要很长的时间，或者可 +能要求相同的锁，那么这真的更有用。请注意，在释放例程中做所有的事情还是比较好的， +因为它比较整洁。 + +上面的例子也可以用kref_get_unless_zero()来优化，方法如下:: + + static struct my_data *get_entry() + { + struct my_data *entry = NULL; + mutex_lock(&mutex); + if (!list_empty(&q)) { + entry = container_of(q.next, struct my_data, link); + if (!kref_get_unless_zero(&entry->refcount)) + entry = NULL; + } + mutex_unlock(&mutex); + return entry; + } + + static void release_entry(struct kref *ref) + { + struct my_data *entry = container_of(ref, struct my_data, refcount); + + mutex_lock(&mutex); + list_del(&entry->link); + mutex_unlock(&mutex); + kfree(entry); + } + + static void put_entry(struct my_data *entry) + { + kref_put(&entry->refcount, release_entry); + } + +这对于在put_entry()中移除kref_put()周围的mutex锁是很有用的，但是重要的是 +kref_get_unless_zero被封装在查找表中的同一关键部分，否则kref_get_unless_zero +可能引用已经释放的内存。注意，在不检查其返回值的情况下使用kref_get_unless_zero +是非法的。如果你确信（已经有了一个有效的指针）kref_get_unless_zero()会返回true， +那么就用kref_get()代替。 + +Krefs和RCU +========== + +函数kref_get_unless_zero也使得在上述例子中使用rcu锁进行查找成为可能:: + + struct my_data + { + struct rcu_head rhead; + . + struct kref refcount; + . + . + }; + + static struct my_data *get_entry_rcu() + { + struct my_data *entry = NULL; + rcu_read_lock(); + if (!list_empty(&q)) { + entry = container_of(q.next, struct my_data, link); + if (!kref_get_unless_zero(&entry->refcount)) + entry = NULL; + } + rcu_read_unlock(); + return entry; + } + + static void release_entry_rcu(struct kref *ref) + { + struct my_data *entry = container_of(ref, struct my_data, refcount); + + mutex_lock(&mutex); + list_del_rcu(&entry->link); + mutex_unlock(&mutex); + kfree_rcu(entry, rhead); + } + + static void put_entry(struct my_data *entry) + { + kref_put(&entry->refcount, release_entry_rcu); + } + +但要注意的是，在调用release_entry_rcu后，结构kref成员需要在有效内存中保留一个rcu +宽限期。这可以通过使用上面的kfree_rcu(entry, rhead)来实现，或者在使用kfree之前 +调用synchronize_rcu()，但注意synchronize_rcu()可能会睡眠相当长的时间。 diff --git a/Documentation/translations/zh_CN/core-api/memory-allocation.rst b/Documentation/translations/zh_CN/core-api/memory-allocation.rst new file mode 100644 index 000000000000..e17b87dfd1c8 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/memory-allocation.rst @@ -0,0 +1,138 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/memory-allocation.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + 时奎亮 <alexs@kernel.org> + +.. _cn_core-api_memory-allocation: + +============ +内存分配指南 +============ + +Linux为内存分配提供了多种API。你可以使用 `kmalloc` 或 `kmem_cache_alloc` +系列分配小块内存，使用 `vmalloc` 及其派生产品分配大的几乎连续的区域，或者 +你可以用 alloc_pages 直接向页面分配器请求页面。也可以使用更专业的分配器， +例如 `cma_alloc` 或 `zs_malloc` 。 + +大多数的内存分配API使用GFP标志来表达该内存应该如何分配。GFP的缩写代表 +“(get free pages)获取空闲页”，是底层的内存分配功能。 + +（内存）分配API的多样性与众多的GFP标志相结合，使得“我应该如何分配内存？”这个问 +题不那么容易回答，尽管很可能你应该使用 + +:: + + kzalloc(<size>, GFP_KERNEL); + +当然，有些情况下必须使用其他分配API和不同的GFP标志。 + +获取空闲页标志 +============== +GFP标志控制分配器的行为。它们告诉我们哪些内存区域可以被使用，分配器应该多努力寻 +找空闲的内存，这些内存是否可以被用户空间访问等等。内存管理API为GFP标志和它们的 +组合提供了参考文件，这里我们简要介绍一下它们的推荐用法: + + * 大多数时候， ``GFP_KERNEL`` 是你需要的。内核数据结构的内存，DMA可用内存，inode + 缓存，所有这些和其他许多分配类型都可以使用 ``GFP_KERNEL`` 。注意，使用 ``GFP_KERNEL`` + 意味着 ``GFP_RECLAIM`` ，这意味着在有内存压力的情况下可能会触发直接回收；调用上 + 下文必须允许睡眠。 + + * 如果分配是从一个原子上下文中进行的，例如中断处理程序，使用 ``GFP_NOWAIT`` 。这个 + 标志可以防止直接回收和IO或文件系统操作。因此，在内存压力下， ``GFP_NOWAIT`` 分配 + 可能会失败。有合理退路的分配应该使用 ``GFP_NOWARN`` 。 + + * 如果你认为访问保留内存区是合理的，并且除非分配成功，否则内核会有压力，你可以使用 ``GFP_ATOMIC`` 。 + + * 从用户空间触发的不可信任的分配应该是kmem核算的对象，必须设置 ``__GFP_ACCOUNT`` 位。 + 有一个方便的用于 ``GFP_KERNEL`` 分配的 ``GFP_KERNEL_ACCOUNT`` 快捷键，其应该被核 + 算。 + + * 用户空间的分配应该使用 ``GFP_USER`` 、 ``GFP_HIGHUSER`` 或 ``GFP_HIGHUSER_MOVABLE`` + 中的一个标志。标志名称越长，限制性越小。 + + ``GFP_HIGHUSER_MOVABLE`` 不要求分配的内存将被内核直接访问，并意味着数据是可迁移的。 + + ``GFP_HIGHUSER`` 意味着所分配的内存是不可迁移的，但也不要求它能被内核直接访问。举个 + 例子就是一个硬件分配内存，这些数据直接映射到用户空间，但没有寻址限制。 + + ``GFP_USER`` 意味着分配的内存是不可迁移的，它必须被内核直接访问。 + +你可能会注意到，在现有的代码中，有相当多的分配指定了 ``GFP_NOIO`` 或 ``GFP_NOFS`` 。 +从历史上看，它们被用来防止递归死锁，这种死锁是由直接内存回收调用到FS或IO路径以及对已 +经持有的资源进行阻塞引起的。从4.12开始，解决这个问题的首选方法是使用新的范围API，即 +:ref:`Documentation/core-api/gfp_mask-from-fs-io.rst <gfp_mask_from_fs_io>`. + +其他传统的GFP标志是 ``GFP_DMA`` 和 ``GFP_DMA32`` 。它们用于确保分配的内存可以被寻 +址能力有限的硬件访问。因此，除非你正在为一个有这种限制的设备编写驱动程序，否则要避免 +使用这些标志。而且，即使是有限制的硬件，也最好使用dma_alloc* APIs。 + +GFP标志和回收行为 +----------------- +内存分配可能会触发直接或后台回收，了解页面分配器将如何努力满足该请求或其他请求是非常 +有用的。 + + * ``GFP_KERNEL & ~__GFP_RECLAIM`` - 乐观分配，完全不尝试释放内存。最轻量级的模 + 式，甚至不启动后台回收。应该小心使用，因为它可能会耗尽内存，而下一个用户可能会启 + 动更积极的回收。 + + * ``GFP_KERNEL & ~__GFP_DIRECT_RECLAIM`` (or ``GFP_NOWAIT`` ) - 乐观分配，不 + 试图从当前上下文中释放内存，但如果该区域低于低水位，可以唤醒kswapd来回收内存。可 + 以从原子上下文中使用，或者当请求是一个性能优化，并且有另一个慢速路径的回退。 + + * ``(GFP_KERNEL|__GFP_HIGH) & ~__GFP_DIRECT_RECLAIM`` (aka ``GFP_ATOMIC`` ) - 非 + 睡眠分配，有一个昂贵的回退，所以它可以访问某些部分的内存储备。通常从中断/底层上下 + 文中使用，有一个昂贵的慢速路径回退。 + + * ``GFP_KERNEL`` - 允许后台和直接回收，并使用默认的页面分配器行为。这意味着廉价 + 的分配请求基本上是不会失败的，但不能保证这种行为，所以失败必须由调用者适当检查（例 + 如，目前允许OOM杀手失败）。 + + * ``GFP_KERNEL | __GFP_NORETRY`` - 覆盖默认的分配器行为，所有的分配请求都会提前 + 失败，而不是导致破坏性的回收（在这个实现中是一轮的回收）。OOM杀手不被调用。 + + * ``GFP_KERNEL | __GFP_RETRY_MAYFAIL`` - 覆盖 **默认** 的分配器行为，所有分配请求都非 + 常努力。如果回收不能取得任何进展，该请求将失败。OOM杀手不会被触发。 + + * ``GFP_KERNEL | __GFP_NOFAIL`` - 覆盖默认的分配器行为，所有分配请求将无休止地循 + 环，直到成功。这可能真的很危险，特别是对于较大的需求。 + +选择内存分配器 +============== + +分配内存的最直接的方法是使用kmalloc()系列的函数。而且，为了安全起见，最好使用将内存 +设置为零的例程，如kzalloc()。如果你需要为一个数组分配内存，有kmalloc_array()和kcalloc() +辅助程序。辅助程序struct_size()、array_size()和array3_size()可以用来安全地计算对 +象的大小而不会溢出。 + +可以用 `kmalloc` 分配的块的最大尺寸是有限的。实际的限制取决于硬件和内核配置，但是对于 +小于页面大小的对象，使用 `kmalloc` 是一个好的做法。 + +用 `kmalloc` 分配的块的地址至少要对齐到ARCH_KMALLOC_MINALIGN字节。对于2的幂的大小， +对齐方式也被保证为至少是各自的大小。 + +用kmalloc()分配的块可以用krealloc()调整大小。与kmalloc_array()类似：以krealloc_array() +的形式提供了一个用于调整数组大小的辅助工具。 + +对于大量的分配，你可以使用vmalloc()和vzalloc()，或者直接向页面分配器请求页面。由vmalloc +和相关函数分配的内存在物理上是不连续的。 + +如果你不确定分配的大小对 `kmalloc` 来说是否太大，可以使用kvmalloc()及其派生函数。它将尝 +试用kmalloc分配内存，如果分配失败，将用 `vmalloc` 重新尝试。对于哪些GFP标志可以与 `kvmalloc` +一起使用是有限制的；请看kvmalloc_node()参考文档。注意， `kvmalloc` 可能会返回物理上不连 +续的内存。 + +如果你需要分配许多相同的对象，你可以使用slab缓存分配器。在使用缓存之前，应该用 +kmem_cache_create()或kmem_cache_create_usercopy()来设置缓存。如果缓存的一部分可能被复 +制到用户空间，应该使用第二个函数。在缓存被创建后，kmem_cache_alloc()和它的封装可以从该缓 +存中分配内存。 + +当分配的内存不再需要时，它必须被释放。你可以使用kvfree()来处理用 `kmalloc` 、 `vmalloc` +和 `kvmalloc` 分配的内存。slab缓存应该用kmem_cache_free()来释放。不要忘记用 +kmem_cache_destroy()来销毁缓存。 diff --git a/Documentation/translations/zh_CN/core-api/memory-hotplug.rst b/Documentation/translations/zh_CN/core-api/memory-hotplug.rst index 161f4d2c18cc..9b2841fb9a5f 100644 --- a/Documentation/translations/zh_CN/core-api/memory-hotplug.rst +++ b/Documentation/translations/zh_CN/core-api/memory-hotplug.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: Documentation/core-api/memory_hotplug.rst +:Original: Documentation/core-api/memory-hotplug.rst :翻译: @@ -63,7 +63,6 @@ memory_notify结构体的指针:: unsigned long start_pfn; unsigned long nr_pages; int status_change_nid_normal; - int status_change_nid_high; int status_change_nid; } @@ -74,9 +73,6 @@ memory_notify结构体的指针:: - status_change_nid_normal是当nodemask的N_NORMAL_MEMORY被设置/清除时设置节 点id，如果是-1，则nodemask状态不改变。 -- status_change_nid_high是当nodemask的N_HIGH_MEMORY被设置/清除时设置的节点 - id，如果这个值为-1，那么nodemask状态不会改变。 - - status_change_nid是当nodemask的N_MEMORY被（将）设置/清除时设置的节点id。这 意味着一个新的（没上线的）节点通过联机获得新的内存，而一个节点失去了所有的内 存。如果这个值为-1，那么nodemask的状态就不会改变。 diff --git a/Documentation/translations/zh_CN/core-api/mm-api.rst b/Documentation/translations/zh_CN/core-api/mm-api.rst new file mode 100644 index 000000000000..0ea43dc67953 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/mm-api.rst @@ -0,0 +1,110 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/mm-api.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + 时奎亮<alexs@kernel.org> + +.. _cn_core-api_mm-api: + +============ +内存管理APIs +============ + +API（Application Programming Interface，应用程序接口） + +用户空间内存访问 +================ + +该API在以下内核代码中: + +arch/x86/include/asm/uaccess.h + +arch/x86/lib/usercopy_32.c + +mm/gup.c + +.. _cn_mm-api-gfp-flags: + +内存分配控制 +============ + +该API在以下内核代码中: + +include/linux/gfp.h + +Slab缓存 +======== + +此缓存非cpu片上缓存，请读者自行查阅资料。 + +该API在以下内核代码中: + +include/linux/slab.h + +mm/slab.c + +mm/slab_common.c + +mm/util.c + +虚拟连续（内存页）映射 +====================== + +该API在以下内核代码中: + +mm/vmalloc.c + + +文件映射和页面缓存 +================== + +该API在以下内核代码中: + +mm/readahead.c + +mm/filemap.c + +mm/page-writeback.c + +mm/truncate.c + +include/linux/pagemap.h + +内存池 +====== + +该API在以下内核代码中: + +mm/mempool.c + +DMA池 +===== + +DMA(Direct Memory Access，直接存储器访问) + +该API在以下内核代码中: + +mm/dmapool.c + +更多的内存管理函数 +================== + +该API在以下内核代码中: + +mm/memory.c + +mm/page_alloc.c + +mm/mempolicy.c + +include/linux/mm_types.h + +include/linux/mm.h + +include/linux/mmzone.h diff --git a/Documentation/translations/zh_CN/core-api/unaligned-memory-access.rst b/Documentation/translations/zh_CN/core-api/unaligned-memory-access.rst new file mode 100644 index 000000000000..29c33e7e0855 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/unaligned-memory-access.rst @@ -0,0 +1,229 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/unaligned-memory-access.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + 时奎亮 <alexs@kernel.org> + +.. _cn_core-api_unaligned-memory-access: + +============== +非对齐内存访问 +============== + +:作者: Daniel Drake <dsd@gentoo.org>, +:作者: Johannes Berg <johannes@sipsolutions.net> + +:感谢他们的帮助: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt, + Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz, + Vadim Lobanov + + +Linux运行在各种各样的架构上，这些架构在内存访问方面有不同的表现。本文介绍了一些 +关于不对齐访问的细节，为什么你需要编写不引起不对齐访问的代码，以及如何编写这样的 +代码 + + +非对齐访问的定义 +================ + +当你试图从一个不被N偶数整除的地址（即addr % N != 0）开始读取N字节的数据时，就 +会发生无对齐内存访问。例如，从地址0x10004读取4个字节的数据是可以的，但从地址 +0x10005读取4个字节的数据将是一个不对齐的内存访问。 + +上述内容可能看起来有点模糊，因为内存访问可以以不同的方式发生。这里的背景是在机器 +码层面上：某些指令在内存中读取或写入一些字节（例如x86汇编中的movb、movw、movl）。 +正如将变得清晰的那样，相对容易发现那些将编译为多字节内存访问指令的C语句，即在处理 +u16、u32和u64等类型时。 + + +自然对齐 +======== + +上面提到的规则构成了我们所说的自然对齐。当访问N个字节的内存时，基础内存地址必须被 +N平均分割，即addr % N == 0。 + +在编写代码时，假设目标架构有自然对齐的要求。 + +在现实中，只有少数架构在所有大小的内存访问上都要求自然对齐。然而，我们必须考虑所 +有支持的架构；编写满足自然对齐要求的代码是实现完全可移植性的最简单方法。 + + +为什么非对齐访问时坏事 +====================== + +执行非对齐内存访问的效果因架构不同而不同。在这里写一整篇关于这些差异的文档是很容 +易的；下面是对常见情况的总结: + + - 一些架构能够透明地执行非对齐内存访问，但通常会有很大的性能代价。 + - 当不对齐的访问发生时，一些架构会引发处理器异常。异常处理程序能够纠正不对齐的 + 访问，但要付出很大的性能代价。 + - 一些架构在发生不对齐访问时，会引发处理器异常，但异常中并没有包含足够的信息来 + 纠正不对齐访问。 + - 有些架构不能进行无对齐内存访问，但会默默地执行与请求不同的内存访问，从而导致 + 难以发现的微妙的代码错误! + +从上文可以看出，如果你的代码导致不对齐的内存访问发生，那么你的代码在某些平台上将无 +法正常工作，在其他平台上将导致性能问题。 + +不会导致非对齐访问的代码 +======================== + +起初，上面的概念似乎有点难以与实际编码实践联系起来。毕竟，你对某些变量的内存地址没 +有很大的控制权，等等。 + +幸运的是事情并不复杂，因为在大多数情况下，编译器会确保代码工作正常。例如，以下面的 +结构体为例:: + + struct foo { + u16 field1; + u32 field2; + u8 field3; + }; + +让我们假设上述结构体的一个实例驻留在从地址0x10000开始的内存中。根据基本的理解，访问 +field2会导致非对齐访问，这并不是不合理的。你会期望field2位于该结构体的2个字节的偏移 +量，即地址0x10002，但该地址不能被4平均整除（注意，我们在这里读一个4字节的值）。 + +幸运的是，编译器理解对齐约束，所以在上述情况下，它会在field1和field2之间插入2个字节 +的填充。因此，对于标准的结构体类型，你总是可以依靠编译器来填充结构体，以便对字段的访 +问可以适当地对齐（假设你没有将字段定义不同长度的类型）。 + +同样，你也可以依靠编译器根据变量类型的大小，将变量和函数参数对齐到一个自然对齐的方案。 + +在这一点上，应该很清楚，访问单个字节（u8或char）永远不会导致无对齐访问，因为所有的内 +存地址都可以被1均匀地整除。 + +在一个相关的话题上，考虑到上述因素，你可以观察到，你可以对结构体中的字段进行重新排序， +以便将字段放在不重排就会插入填充物的地方，从而减少结构体实例的整体常驻内存大小。上述 +例子的最佳布局是:: + + struct foo { + u32 field2; + u16 field1; + u8 field3; + }; + +对于一个自然对齐方案，编译器只需要在结构的末尾添加一个字节的填充。添加这种填充是为了满 +足这些结构的数组的对齐约束。 + +另一点值得一提的是在结构体类型上使用__attribute__((packed))。这个GCC特有的属性告诉编 +译器永远不要在结构体中插入任何填充，当你想用C结构体来表示一些“off the wire”的固定排列 +的数据时，这个属性很有用。 + +你可能会倾向于认为，在访问不满足架构对齐要求的字段时，使用这个属性很容易导致不对齐的访 +问。然而，编译器也意识到了对齐的限制，并且会产生额外的指令来执行内存访问，以避免造成不 +对齐的访问。当然，与non-packed的情况相比，额外的指令显然会造成性能上的损失，所以packed +属性应该只在避免结构填充很重要的时候使用。 + + +导致非对齐访问的代码 +==================== + +考虑到上述情况，让我们来看看一个现实生活中可能导致非对齐内存访问的函数的例子。下面这个 +函数取自include/linux/etherdevice.h，是一个优化的例程，用于比较两个以太网MAC地址是否 +相等:: + + bool ether_addr_equal(const u8 *addr1, const u8 *addr2) + { + #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS + u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2)) | + ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4))); + + return fold == 0; + #else + const u16 *a = (const u16 *)addr1; + const u16 *b = (const u16 *)addr2; + return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) == 0; + #endif + } + +在上述函数中，当硬件具有高效的非对齐访问能力时，这段代码没有问题。但是当硬件不能在任意 +边界上访问内存时，对a[0]的引用导致从地址addr1开始的2个字节（16位）被读取。 + +想一想，如果addr1是一个奇怪的地址，如0x10003，会发生什么？(提示：这将是一个非对齐访 +问。) + +尽管上述函数存在潜在的非对齐访问问题，但它还是被包含在内核中，但被理解为只在16位对齐 +的地址上正常工作。调用者应该确保这种对齐方式或者根本不使用这个函数。这个不对齐的函数 +仍然是有用的，因为它是在你能确保对齐的情况下的一个很好的优化，这在以太网网络环境中几 +乎是一直如此。 + + +下面是另一个可能导致非对齐访问的代码的例子:: + + void myfunc(u8 *data, u32 value) + { + [...] + *((u32 *) data) = cpu_to_le32(value); + [...] + } + +每当数据参数指向的地址不被4均匀整除时，这段代码就会导致非对齐访问。 + +综上所述，你可能遇到非对齐访问问题的两种主要情况包括: + + 1. 将变量定义不同长度的类型 + 2. 指针运算后访问至少2个字节的数据 + + +避免非对齐访问 +============== + +避免非对齐访问的最简单方法是使用<asm/unaligned.h>头文件提供的get_unaligned()和 +put_unaligned()宏。 + +回到前面的一个可能导致非对齐访问的代码例子:: + + void myfunc(u8 *data, u32 value) + { + [...] + *((u32 *) data) = cpu_to_le32(value); + [...] + } + +为了避免非对齐的内存访问，你可以将其改写如下:: + + void myfunc(u8 *data, u32 value) + { + [...] + value = cpu_to_le32(value); + put_unaligned(value, (u32 *) data); + [...] + } + +get_unaligned()宏的工作原理与此类似。假设'data'是一个指向内存的指针，并且你希望避免 +非对齐访问，其用法如下:: + + u32 value = get_unaligned((u32 *) data); + +这些宏适用于任何长度的内存访问（不仅仅是上面例子中的32位）。请注意，与标准的对齐内存 +访问相比，使用这些宏来访问非对齐内存可能会在性能上付出代价。 + +如果使用这些宏不方便，另一个选择是使用memcpy()，其中源或目标（或两者）的类型为u8*或 +非对齐char*。由于这种操作的字节性质，避免了非对齐访问。 + + +对齐 vs. 网络 +============= + +在需要对齐负载的架构上，网络要求IP头在四字节边界上对齐，以优化IP栈。对于普通的以太网 +硬件，常数NET_IP_ALIGN被使用。在大多数架构上，这个常数的值是2，因为正常的以太网头是 +14个字节，所以为了获得适当的对齐，需要DMA到一个可以表示为4*n+2的地址。一个值得注意的 +例外是powerpc，它将NET_IP_ALIGN定义为0，因为DMA到未对齐的地址可能非常昂贵，与未对齐 +的负载的成本相比相形见绌。 + +对于一些不能DMA到未对齐地址的以太网硬件，如4*n+2或非以太网硬件，这可能是一个问题，这 +时需要将传入的帧复制到一个对齐的缓冲区。因为这在可以进行非对齐访问的架构上是不必要的， +所以可以使代码依赖于CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS，像这样:: + + #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS + skb = original skb + #else + skb = copy skb + #endif diff --git a/Documentation/translations/zh_CN/core-api/xarray.rst b/Documentation/translations/zh_CN/core-api/xarray.rst new file mode 100644 index 000000000000..ff2d9bcb7c34 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/xarray.rst @@ -0,0 +1,371 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/xarray.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + + +.. _cn_core-api_xarray: + +====== +XArray +====== + +:作者: Matthew Wilcox + +概览 +==== + +XArray是一个抽象的数据类型，它的行为就像一个非常大的指针数组。它满足了许多与哈 +希或传统可调整大小的数组相同的需求。与哈希不同的是，它允许你以一种高效的缓存方 +式合理地转到下一个或上一个条目。与可调整大小的数组相比，不需要复制数据或改变MMU +的映射来增加数组。与双链表相比，它的内存效率更高，可并行，对缓存更友好。它利用 +RCU的优势来执行查找而不需要锁定。 + +当使用的索引是密集聚集的时候，XArray的实现是有效的；而哈希对象并使用哈希作为索引 +将不会有好的表现。XArray对小的索引进行了优化，不过对大的索引仍有良好的性能。如果 +你的索引可以大于 ``ULONG_MAX`` ，那么XArray就不适合你的数据类型。XArray最重要 +的用户是页面高速缓存。 + +普通指针可以直接存储在XArray中。它们必须是4字节对齐的，这对任何从kmalloc()和 +alloc_page()返回的指针来说都是如此。这对任意的用户空间指针和函数指针来说都不是 +真的。你可以存储指向静态分配对象的指针，只要这些对象的对齐方式至少是4（字节）。 + +你也可以在XArray中存储0到 ``LONG_MAX`` 之间的整数。你必须首先使用xa_mk_value() +将其转换为一个条目。当你从XArray中检索一个条目时，你可以通过调用xa_is_value()检 +查它是否是一个值条目，并通过调用xa_to_value()将它转换回一个整数。 + +一些用户希望对他们存储在XArray中的指针进行标记。你可以调用xa_tag_pointer()来创建 +一个带有标签的条目，xa_untag_pointer()将一个有标签的条目转回一个无标签的指针， +xa_pointer_tag()来检索一个条目的标签。标签指针使用相同的位，用于区分值条目和普通 +指针，所以你必须决定他们是否要在任何特定的XArray中存储值条目或标签指针。 + +XArray不支持存储IS_ERR()指针，因为有些指针与值条目或内部条目冲突。 + +XArray的一个不寻常的特点是能够创建占据一系列索引的条目。一旦存储到其中，查询该范围 +内的任何索引将返回与查询该范围内任何其他索引相同的条目。存储到任何索引都会存储所有 +的索引条目。多索引条目可以明确地分割成更小的条目，或者将其存储 ``NULL`` 到任何条目中 +都会使XArray忘记范围。 + +普通API +======= + +首先初始化一个XArray，对于静态分配的XArray可以用DEFINE_XARRAY()，对于动态分配的 +XArray可以用xa_init()。一个新初始化的XArray在每个索引处都包含一个 ``NULL`` 指针。 + +然后你可以用xa_store()来设置条目，用xa_load()来获取条目。xa_store将用新的条目覆盖任 +何条目，并返回存储在该索引的上一个条目。你可以使用xa_erase()来代替调用xa_store()的 +``NULL`` 条目。一个从未被存储过的条目、一个被擦除的条目和一个最近被存储过 ``NULL`` 的 +条目之间没有区别。 + +你可以通过使用xa_cmpxchg()有条件地替换一个索引中的条目。和cmpxchg()一样，它只有在该索 +引的条目有 ‘旧‘ 值时才会成功。它也会返回该索引上的条目；如果它返回与传递的 ‘旧‘ 相同的条 +目，那么xa_cmpxchg()就成功了。 + +如果你只想在某个索引的当前条目为 ``NULL`` 时将一个新条目存储到该索引，你可以使用xa_insert()， +如果该条目不是空的，则返回 ``-EBUSY`` 。 + +你可以通过调用xa_extract()将条目从XArray中复制到一个普通数组中。或者你可以通过调用 +xa_for_each()、xa_for_each_start()或xa_for_each_range()来遍历XArray中的现有条目。你 +可能更喜欢使用xa_find()或xa_find_after()来移动到XArray中的下一个当前条目。 + +调用xa_store_range()可以在一个索引范围内存储同一个条目。如果你这样做，其他的一些操作将以 +一种稍微奇怪的方式进行。例如，在一个索引上标记条目可能会导致该条目在一些，但不是所有其他索 +引上被标记。储存到一个索引中可能会导致由一些，但不是所有其他索引检索的条目发生变化。 + +有时你需要确保对xa_store()的后续调用将不需要分配内存。xa_reserve()函数将在指定索引处存储 +一个保留条目。普通API的用户将看到这个条目包含 ``NULL`` 。如果你不需要使用保留的条目，你可 +以调用xa_release()来删除这个未使用的条目。如果在此期间有其他用户存储到该条目，xa_release() +将不做任何事情；相反，如果你想让该条目变成 ``NULL`` ，你应该使用xa_erase()。在一个保留的条 +目上使用xa_insert()将会失败。 + +如果数组中的所有条目都是 ``NULL`` ，xa_empty()函数将返回 ``true`` 。 + +最后，你可以通过调用xa_destroy()删除XArray中的所有条目。如果XArray的条目是指针，你可能希望 +先释放这些条目。你可以通过使用xa_for_each()迭代器遍历XArray中所有存在的条目来实现这一目的。 + +搜索标记 +-------- + +数组中的每个条目都有三个与之相关的位，称为标记。每个标记可以独立于其他标记被设置或清除。你可以 +通过使用xa_for_each_marked()迭代器来迭代有标记的条目。 + +你可以通过使用xa_get_mark()来查询某个条目是否设置了标记。如果该条目不是 ``NULL`` ，你可以通过 +使用xa_set_mark()来设置一个标记，并通过调用xa_clear_mark()来删除条目上的标记。你可以通过调用 +xa_marked()来询问XArray中的任何条目是否有一个特定的标记被设置。从XArray中删除一个条目会导致与 +该条目相关的所有标记被清除。 + +在一个多索引条目的任何索引上设置或清除标记将影响该条目所涵盖的所有索引。查询任何索引上的标记将返 +回相同的结果。 + +没有办法对没有标记的条目进行迭代；数据结构不允许有效地实现这一点。目前没有迭代器来搜索比特的逻辑 +组合（例如迭代所有同时设置了 ``XA_MARK_1`` 和 ``XA_MARK_2`` 的条目，或者迭代所有设置了 +``XA_MARK_0`` 或 ``XA_MARK_2`` 的条目）。如果有用户需要，可以增加这些内容。 + +分配XArrays +----------- + +如果你使用DEFINE_XARRAY_ALLOC()来定义XArray，或者通过向xa_init_flags()传递 ``XA_FLAGS_ALLOC`` +来初始化它，XArray会改变以跟踪条目是否被使用。 + +你可以调用xa_alloc()将条目存储在XArray中一个未使用的索引上。如果你需要从中断上下文中修改数组，你 +可以使用xa_alloc_bh()或xa_alloc_irq()，在分配ID的同时禁用中断。 + +使用xa_store()、xa_cmpxchg()或xa_insert()也将标记该条目为正在分配。与普通的XArray不同，存储 ``NULL`` +将标记该条目为正在使用中，就像xa_reserve()。要释放一个条目，请使用xa_erase()（或者xa_release()， +如果你只想释放一个 ``NULL`` 的条目）。 + +默认情况下，最低的空闲条目从0开始分配。如果你想从1开始分配条目，使用DEFINE_XARRAY_ALLOC1()或 +``XA_FLAGS_ALLOC1`` 会更有效。如果你想分配ID到一个最大值，然后绕回最低的空闲ID，你可以使用 +xa_alloc_cyclic()。 + +你不能在分配的XArray中使用 ``XA_MARK_0`` ，因为这个标记是用来跟踪一个条目是否是空闲的。其他的 +标记可以供你使用。 + +内存分配 +-------- + +xa_store(), xa_cmpxchg(), xa_alloc(), xa_reserve()和xa_insert()函数接受一个gfp_t参数，以 +防XArray需要分配内存来存储这个条目。如果该条目被删除，则不需要进行内存分配，指定的GFP标志将被忽 +略。 + +没有内存可供分配是可能的，特别是如果你传递了一组限制性的GFP标志。在这种情况下，这些函数会返回一 +个特殊的值，可以用xa_err()把它变成一个错误值。如果你不需要确切地知道哪个错误发生，使用xa_is_err() +会更有效一些。 + +锁 +-- + +当使用普通API时，你不必担心锁的问题。XArray使用RCU和一个内部自旋锁来同步访问: + +不需要锁: + * xa_empty() + * xa_marked() + +采取RCU读锁: + * xa_load() + * xa_for_each() + * xa_for_each_start() + * xa_for_each_range() + * xa_find() + * xa_find_after() + * xa_extract() + * xa_get_mark() + +内部使用xa_lock: + * xa_store() + * xa_store_bh() + * xa_store_irq() + * xa_insert() + * xa_insert_bh() + * xa_insert_irq() + * xa_erase() + * xa_erase_bh() + * xa_erase_irq() + * xa_cmpxchg() + * xa_cmpxchg_bh() + * xa_cmpxchg_irq() + * xa_store_range() + * xa_alloc() + * xa_alloc_bh() + * xa_alloc_irq() + * xa_reserve() + * xa_reserve_bh() + * xa_reserve_irq() + * xa_destroy() + * xa_set_mark() + * xa_clear_mark() + +假设进入时持有xa_lock: + * __xa_store() + * __xa_insert() + * __xa_erase() + * __xa_cmpxchg() + * __xa_alloc() + * __xa_set_mark() + * __xa_clear_mark() + +如果你想利用锁来保护你存储在XArray中的数据结构，你可以在调用xa_load()之前调用xa_lock()，然后在 +调用xa_unlock()之前对你找到的对象进行一个引用计数。这将防止存储操作在查找对象和增加refcount期间 +从数组中删除对象。你也可以使用RCU来避免解除对已释放内存的引用，但对这一点的解释已经超出了本文的范 +围。 + +在修改数组时，XArray不会禁用中断或softirqs。从中断或softirq上下文中读取XArray是安全的，因为RCU锁 +提供了足够的保护。 + +例如，如果你想在进程上下文中存储XArray中的条目，然后在softirq上下文中擦除它们，你可以这样做:: + + void foo_init(struct foo *foo) + { + xa_init_flags(&foo->array, XA_FLAGS_LOCK_BH); + } + + int foo_store(struct foo *foo, unsigned long index, void *entry) + { + int err; + + xa_lock_bh(&foo->array); + err = xa_err(__xa_store(&foo->array, index, entry, GFP_KERNEL)); + if (!err) + foo->count++; + xa_unlock_bh(&foo->array); + return err; + } + + /* foo_erase()只在软中断上下文中调用 */ + void foo_erase(struct foo *foo, unsigned long index) + { + xa_lock(&foo->array); + __xa_erase(&foo->array, index); + foo->count--; + xa_unlock(&foo->array); + } + +如果你要从中断或softirq上下文中修改XArray，你需要使用xa_init_flags()初始化数组，传递 +``XA_FLAGS_LOCK_IRQ`` 或 ``XA_FLAGS_LOCK_BH`` （参数）。 + +上面的例子还显示了一个常见的模式，即希望在存储端扩展xa_lock的覆盖范围，以保护与数组相关的一些统计 +数据。 + +与中断上下文共享XArray也是可能的，可以在中断处理程序和进程上下文中都使用xa_lock_irqsave()，或者 +在进程上下文中使用xa_lock_irq()，在中断处理程序中使用xa_lock()。一些更常见的模式有一些辅助函数， +如xa_store_bh()、xa_store_irq()、xa_erase_bh()、xa_erase_irq()、xa_cmpxchg_bh() 和xa_cmpxchg_irq()。 + +有时你需要用一个mutex来保护对XArray的访问，因为这个锁在锁的层次结构中位于另一个mutex之上。这并不 +意味着你有权使用像__xa_erase()这样的函数而不占用xa_lock；xa_lock是用来进行lockdep验证的，将来也 +会用于其他用途。 + +__xa_set_mark() 和 __xa_clear_mark() 函数也适用于你查找一个条目并想原子化地设置或清除一个标记的 +情况。在这种情况下，使用高级API可能更有效，因为它将使你免于走两次树。 + +高级API +======= + +高级API提供了更多的灵活性和更好的性能，但代价是接口可能更难使用，保障措施更少。高级API没有为你加锁， +你需要在修改数组的时候使用xa_lock。在对数组进行只读操作时，你可以选择使用xa_lock或RCU锁。你可以在 +同一个数组上混合使用高级和普通操作；事实上，普通API是以高级API的形式实现的。高级API只对具有GPL兼容 +许可证的模块可用。 + +高级API是基于xa_state的。这是一个不透明的数据结构，你使用XA_STATE()宏在堆栈中声明。这个宏初始化了 +xa_state，准备开始在XArray上移动。它被用作一个游标来保持在XArray中的位置，并让你把各种操作组合在一 +起，而不必每次都从头开始。 + +xa_state也被用来存储错误(store errors)。你可以调用xas_error()来检索错误。所有的操作在进行之前都 +会检查xa_state是否处于错误状态，所以你没有必要在每次调用之后检查错误；你可以连续进行多次调用，只在 +方便的时候检查。目前XArray代码本身产生的错误只有 ``ENOMEM`` 和 ``EINVAL`` ，但它支持任意的错误， +以防你想自己调用xas_set_err()。 + +如果xa_state持有 ``ENOMEM`` 错误，调用xas_nomem()将尝试使用指定的gfp标志分配更多的内存，并将其缓 +存在xa_state中供下一次尝试。这个想法是，你拿着xa_lock，尝试操作，然后放弃锁。该操作试图在持有锁的情 +况下分配内存，但它更有可能失败。一旦你放弃了锁，xas_nomem()可以更努力地尝试分配更多内存。如果值得重 +试该操作，它将返回 ``true`` （即出现了内存错误，分配了更多的内存）。如果它之前已经分配了内存，并且 +该内存没有被使用，也没有错误（或者一些不是 ``ENOMEM`` 的错误），那么它将释放之前分配的内存。 + +内部条目 +-------- + +XArray为它自己的目的保留了一些条目。这些条目从未通过正常的API暴露出来，但是当使用高级API时，有可能看 +到它们。通常，处理它们的最好方法是把它们传递给xas_retry()，如果它返回 ``true`` ，就重试操作。 + +.. flat-table:: + :widths: 1 1 6 + + * - 名称 + - 检测 + - 用途 + + * - Node + - xa_is_node() + - 一个XArray节点。 在使用多索引xa_state时可能是可见的。 + + * - Sibling + - xa_is_sibling() + - 一个多索引条目的非典型条目。该值表示该节点中的哪个槽有典型条目。 + + * - Retry + - xa_is_retry() + - 这个条目目前正在被一个拥有xa_lock的线程修改。在这个RCU周期结束时，包含该条目的节点可能会被释放。 + 你应该从数组的头部重新开始查找。 + + * - Zero + - xa_is_zero() + - Zero条目通过普通API显示为 ``NULL`` ，但在XArray中占有一个条目，可用于保留索引供将来使用。这是 + 通过为分配的条目分配XArrays来使用的，这些条目是 ``NULL`` 。 + +其他内部条目可能会在未来被添加。在可能的情况下，它们将由xas_retry()处理。 + +附加函数 +-------- + +xas_create_range()函数分配了所有必要的内存来存储一个范围内的每一个条目。如果它不能分配内存，它将在 +xa_state中设置ENOMEM。 + +你可以使用xas_init_marks()将一个条目上的标记重置为默认状态。这通常是清空所有标记，除非XArray被标记 +为 ``XA_FLAGS_TRACK_FREE`` ，在这种情况下，标记0被设置，所有其他标记被清空。使用xas_store()将一个 +条目替换为另一个条目不会重置该条目上的标记；如果你想重置标记，你应该明确地这样做。 + +xas_load()会尽可能地将xa_state移动到该条目附近。如果你知道xa_state已经移动到了该条目，并且需要检查 +该条目是否有变化，你可以使用xas_reload()来保存一个函数调用。 + +如果你需要移动到XArray中的不同索引，可以调用xas_set()。这可以将光标重置到树的顶端，这通常会使下一个 +操作将光标移动到树中想要的位置。如果你想移动到下一个或上一个索引，调用xas_next()或xas_prev()。设置 +索引不会使光标在数组中移动，所以不需要锁，而移动到下一个或上一个索引则需要锁。 + +你可以使用xas_find()搜索下一个当前条目。这相当于xa_find()和xa_find_after()；如果光标已经移动到了 +一个条目，那么它将找到当前引用的条目之后的下一个条目。如果没有，它将返回xa_state索引处的条目。使用 +xas_next_entry()而不是xas_find()来移动到下一个当前条目，在大多数情况下会节省一个函数调用，但代价 +是发出更多内联代码。 + +xas_find_marked()函数也是如此。如果xa_state没有被移动过，它将返回xa_state的索引处的条目，如果它 +被标记了。否则，它将返回xa_state所引用的条目之后的第一个被标记的条目。xas_next_marked()函数等同 +于xas_next_entry()。 + +当使用xas_for_each()或xas_for_each_marked()在XArray的某个范围内进行迭代时，可能需要暂时停止迭代。 +xas_pause()函数的存在就是为了这个目的。在你完成了必要的工作并希望恢复后，xa_state处于适当的状态，在 +你最后处理的条目后继续迭代。如果你在迭代时禁用了中断，那么暂停迭代并在每一个 ``XA_CHECK_SCHED`` 条目 +中重新启用中断是很好的做法。 + +xas_get_mark(), xas_set_mark()和xas_clear_mark()函数要求xa_state光标已经被移动到XArray中的适当位 +置；如果你在之前调用了xas_pause()或xas_set()，它们将不会有任何作用。 + +你可以调用xas_set_update()，让XArray每次更新一个节点时都调用一个回调函数。这被页面缓存的workingset +代码用来维护其只包含阴影项的节点列表。 + +多索引条目 +---------- + +XArray有能力将多个索引联系在一起，因此对一个索引的操作会影响到所有的索引。例如，存储到任何索引将改变 +从任何索引检索的条目的值。在任何索引上设置或清除一个标记，都会在每个被绑在一起的索引上设置或清除该标 +记。目前的实现只允许将2的整数倍的范围绑在一起；例如指数64-127可以绑在一起，但2-6不能。这可以节省大量 +的内存；例如，将512个条目绑在一起可以节省4kB以上的内存。 + +你可以通过使用XA_STATE_ORDER()或xas_set_order()，然后调用xas_store()来创建一个多索引条目。用一个 +多索引的xa_state调用xas_load()会把xa_state移动到树中的正确位置，但是返回值没有意义，有可能是一个内 +部条目或 ``NULL`` ，即使在范围内有一个条目存储。调用xas_find_conflict()将返回该范围内的第一个条目， +如果该范围内没有条目，则返回 ``NULL`` 。xas_for_each_conflict()迭代器将遍历每个与指定范围重叠的条目。 + +如果xas_load()遇到一个多索引条目，xa_state中的xa_index将不会被改变。当遍历一个XArray或者调用xas_find() +时，如果初始索引在一个多索引条目的中间，它将不会被改变。随后的调用或迭代将把索引移到范围内的第一个索引。 +每个条目只会被返回一次，不管它占据了多少个索引。 + +不支持使用xas_next()或xas_prev()来处理一个多索引的xa_state。在一个多索引的条目上使用这两个函数中的任 +何一个都会显示出同级的条目；这些条目应该被调用者跳过。 + +在一个多索引条目的任何一个索引中存储 ``NULL`` ，将把每个索引的条目设置为 ``NULL`` ，并解除绑定。通过调 +用xas_split_alloc()，在没有xa_lock的情况下，可以将一个多索引条目分割成占据较小范围的条目，然后再取锁并 +调用xas_split()。 + +函数和结构体 +============ + +该API在以下内核代码中: + +include/linux/xarray.h + +lib/xarray.c diff --git a/Documentation/translations/zh_CN/doc-guide/sphinx.rst b/Documentation/translations/zh_CN/doc-guide/sphinx.rst index 951595c7d599..23eac67fbc30 100644 --- a/Documentation/translations/zh_CN/doc-guide/sphinx.rst +++ b/Documentation/translations/zh_CN/doc-guide/sphinx.rst @@ -26,7 +26,7 @@ reStructuredText文件可能包含包含来自源文件的结构化文档注释 安装Sphinx ========== -Documentation/ 下的ReST文件现在使用sphinx1.3或更高版本构建。 +Documentation/ 下的ReST文件现在使用sphinx1.7或更高版本构建。 这有一个脚本可以检查Sphinx的依赖项。更多详细信息见 :ref:`sphinx-pre-install_zh` 。 @@ -40,22 +40,19 @@ Documentation/ 下的ReST文件现在使用sphinx1.3或更高版本构建。 .. note:: - #) 低于1.5版本的Sphinx无法与Python的0.13.1或更高版本docutils一起正常工作。 - 如果您想使用这些版本，那么应该运行 ``pip install 'docutils==0.12'`` 。 - #) html输出建议使用RTD主题。根据Sphinx版本的不同，它应该用 ``pip install sphinx_rtd_theme`` 单独安装。 #) 一些ReST页面包含数学表达式。由于Sphinx的工作方式，这些表达式是使用 LaTeX 编写的。它需要安装amsfonts和amsmath宏包，以便显示。 -总之，如您要安装Sphinx 1.7.9版本，应执行:: +总之，如您要安装Sphinx 2.4.4版本，应执行:: - $ virtualenv sphinx_1.7.9 - $ . sphinx_1.7.9/bin/activate - (sphinx_1.7.9) $ pip install -r Documentation/sphinx/requirements.txt + $ virtualenv sphinx_2.4.4 + $ . sphinx_2.4.4/bin/activate + (sphinx_2.4.4) $ pip install -r Documentation/sphinx/requirements.txt -在运行 ``. sphinx_1.7.9/bin/activate`` 之后，提示符将变化，以指示您正在使用新 +在运行 ``. sphinx_2.4.4/bin/activate`` 之后，提示符将变化，以指示您正在使用新 环境。如果您打开了一个新的shell，那么在构建文档之前，您需要重新运行此命令以再 次进入虚拟环境中。 @@ -71,7 +68,7 @@ Documentation/ 下的ReST文件现在使用sphinx1.3或更高版本构建。 PDF和LaTeX构建 -------------- -目前只有Sphinx 1.4及更高版本才支持这种构建。 +目前只有Sphinx 2.4及更高版本才支持这种构建。 对于PDF和LaTeX输出，还需要 ``XeLaTeX`` 3.14159265版本。（译注：此版本号真实 存在） @@ -93,8 +90,8 @@ PDF和LaTeX构建 You should run: sudo dnf install -y texlive-luatex85 - /usr/bin/virtualenv sphinx_1.7.9 - . sphinx_1.7.9/bin/activate + /usr/bin/virtualenv sphinx_2.4.4 + . sphinx_2.4.4/bin/activate pip install -r Documentation/sphinx/requirements.txt Can't build as 1 mandatory dependency is missing at ./scripts/sphinx-pre-install line 468. diff --git a/Documentation/translations/zh_CN/maintainer/pull-requests.rst b/Documentation/translations/zh_CN/maintainer/pull-requests.rst index f46d6f3f2498..ce9725f4674c 100644 --- a/Documentation/translations/zh_CN/maintainer/pull-requests.rst +++ b/Documentation/translations/zh_CN/maintainer/pull-requests.rst @@ -21,7 +21,7 @@ Harding <me@tobin.cc>。 原始邮件线程:: - http://lkml.kernel.org/r/20171114110500.GA21175@kroah.com + https://lore.kernel.org/r/20171114110500.GA21175@kroah.com 创建分支 diff --git a/Documentation/translations/zh_CN/process/5.Posting.rst b/Documentation/translations/zh_CN/process/5.Posting.rst index b0c65614844d..4ee7de13f373 100644 --- a/Documentation/translations/zh_CN/process/5.Posting.rst +++ b/Documentation/translations/zh_CN/process/5.Posting.rst @@ -23,7 +23,7 @@ :ref:`Documentation/translations/zh_CN/process/submitting-drivers.rst <cn_submittingdrivers>` 和 :ref:`Documentation/translations/zh_CN/process/submit-checklist.rst <cn_submitchecklist>`。 -何时邮寄 +何时寄送 -------- 在补丁完全“准备好”之前，避免发布补丁是一种持续的诱惑。对于简单的补丁，这 @@ -142,7 +142,7 @@ 一般来说，你越把自己放在每个阅读你变更日志的人的位置上，变更日志（和内核 作为一个整体）就越好。 -不消说，变更日志是将变更提交到版本控制系统时使用的文本。接下来将是： +不需要说，变更日志是将变更提交到版本控制系统时使用的文本。接下来将是： - 补丁本身，采用统一的（“-u”）补丁格式。使用“-p”选项来diff将使函数名与 更改相关联，从而使结果补丁更容易被其他人读取。 @@ -186,10 +186,10 @@ 在补丁中添加标签时要小心：只有Cc:才适合在没有指定人员明确许可的情况下添加。 -发送补丁 +寄送补丁 -------- -在寄出补丁之前，您还需要注意以下几点： +在寄送补丁之前，您还需要注意以下几点： - 您确定您的邮件发送程序不会损坏补丁吗？被邮件客户端更改空白或修饰了行的补丁 无法被另一端接受，并且通常不会进行任何详细检查。如果有任何疑问，先把补丁寄 diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst index ee3dee476d57..2903d7161bc8 100644 --- a/Documentation/translations/zh_CN/process/howto.rst +++ b/Documentation/translations/zh_CN/process/howto.rst @@ -381,7 +381,7 @@ MAINTAINERS文件中可以找到不同话题对应的邮件列表。 内核社区的工作模式同大多数传统公司开发队伍的工作模式并不相同。下面这些例 子，可以帮助你避免某些可能发生问题： -用这些话介绍你的修改提案会有好处： +用这些话介绍你的修改提案会有好处：（在任何时候你都不应该用中文写提案） - 它同时解决了多个问题 - 它删除了2000行代码 @@ -448,8 +448,8 @@ Linux内核社区并不喜欢一下接收大段的代码。修改需要被恰当 保证修改分成很多小块，这样在整个项目都准备好被包含进内核之前，其中的一部 分可能会先被接收。 -必须了解这样做是不可接受的：试图将未完成的工作提交进内核，然后再找时间修 -复。 +你必须明白这么做是无法令人接受的：试图将不完整的代码提交进内核，然后再找 +时间修复。 证明修改的必要性 @@ -475,8 +475,8 @@ Linux内核社区并不喜欢一下接收大段的代码。修改需要被恰当 https://www.ozlabs.org/~akpm/stuff/tpp.txt -这些事情有时候做起来很难。要在任何方面都做到完美可能需要好几年时间。这是 -一个持续提高的过程，它需要大量的耐心和决心。只要不放弃，你一定可以做到。 +这些事情有时候做起来很难。想要在任何方面都做到完美可能需要好几年时间。这 +是一个持续提高的过程，它需要大量的耐心和决心。只要不放弃，你一定可以做到。 很多人已经做到了，而他们都曾经和现在的你站在同样的起点上。 diff --git a/Documentation/translations/zh_CN/process/management-style.rst b/Documentation/translations/zh_CN/process/management-style.rst index c6a5bb285797..8053ae474328 100644 --- a/Documentation/translations/zh_CN/process/management-style.rst +++ b/Documentation/translations/zh_CN/process/management-style.rst @@ -36,14 +36,14 @@ Linux内核管理风格 每个人都认为管理者做决定，而且决策很重要。决定越大越痛苦，管理者就必须越高级。 这很明显，但事实并非如此。 -游戏的名字是 **避免** 做出决定。尤其是，如果有人告诉你“选择（a）或（b）， +最重要的是 **避免** 做出决定。尤其是，如果有人告诉你“选择（a）或（b）， 我们真的需要你来做决定”，你就是陷入麻烦的管理者。你管理的人比你更了解细节， 所以如果他们来找你做技术决策，你完蛋了。你显然没有能力为他们做这个决定。 （推论：如果你管理的人不比你更了解细节，你也会被搞砸，尽管原因完全不同。 也就是说，你的工作是错的，他们应该管理你的才智） -所以游戏的名字是 **避免** 做出决定，至少是那些大而痛苦的决定。做一些小的 +所以最重要的是 **避免** 做出决定，至少是那些大而痛苦的决定。做一些小的 和非结果性的决定是很好的，并且使您看起来好像知道自己在做什么，所以内核管理者 需要做的是将那些大的和痛苦的决定变成那些没有人真正关心的小事情。 diff --git a/Documentation/translations/zh_CN/process/submitting-patches.rst b/Documentation/translations/zh_CN/process/submitting-patches.rst index 4fc6d16f5196..3f1683cd4727 100644 --- a/Documentation/translations/zh_CN/process/submitting-patches.rst +++ b/Documentation/translations/zh_CN/process/submitting-patches.rst @@ -127,13 +127,13 @@ URL来查找补丁描述并将其放入补丁中。也就是说，补丁（系列）及其描述应该是独立的。 这对维护人员和审查人员都有好处。一些评审者可能甚至没有收到补丁的早期版本。 -描述你在命令语气中的变化，例如“make xyzzy do frotz”而不是“[这个补丁]make -xyzzy do frotz”或“[我]changed xyzzy to do frotz”，就好像你在命令代码库改变 +描述你在命令语气中的变化，例如“make xyzzy do frotz”而不是“[This patch]make +xyzzy do frotz”或“[I]changed xyzzy to do frotz”，就好像你在命令代码库改变 它的行为一样。 如果修补程序修复了一个记录的bug条目，请按编号和URL引用该bug条目。如果补丁来 自邮件列表讨论，请给出邮件列表存档的URL；使用带有 ``Message-ID`` 的 -https://lkml.kernel.org/ 重定向，以确保链接不会过时。 +https://lore.kernel.org/ 重定向，以确保链接不会过时。 但是，在没有外部资源的情况下，尽量让你的解释可理解。除了提供邮件列表存档或 bug的URL之外，还要总结需要提交补丁的相关讨论要点。 @@ -599,7 +599,7 @@ e-mail 标题中的“一句话概述”扼要的描述 e-mail 中的补丁。 将补丁与以前的相关讨论关联起来，例如，将bug修复程序链接到电子邮件和bug报告。 但是，对于多补丁系列，最好避免在回复时使用链接到该系列的旧版本。这样， 补丁的多个版本就不会成为电子邮件客户端中无法管理的引用序列。如果链接有用， -可以使用 https://lkml.kernel.org/ 重定向器（例如，在封面电子邮件文本中） +可以使用 https://lore.kernel.org/ 重定向器（例如，在封面电子邮件文本中） 链接到补丁系列的早期版本。 16) 发送git pull请求 diff --git a/Documentation/translations/zh_TW/index.rst b/Documentation/translations/zh_TW/index.rst index 2a281036c406..f56f78ba7860 100644 --- a/Documentation/translations/zh_TW/index.rst +++ b/Documentation/translations/zh_TW/index.rst @@ -140,11 +140,6 @@ TODOList: 體系結構無關文檔 ---------------- -.. toctree:: - :maxdepth: 2 - - arm64/index - TODOList: * asm-annotations @@ -152,6 +147,11 @@ TODOList: 特定體系結構文檔 ---------------- +.. toctree:: + :maxdepth: 2 + + arm64/index + TODOList: * arch diff --git a/Documentation/translations/zh_TW/process/submitting-patches.rst b/Documentation/translations/zh_TW/process/submitting-patches.rst index cdf0b52e4a98..37eccf9e2746 100644 --- a/Documentation/translations/zh_TW/process/submitting-patches.rst +++ b/Documentation/translations/zh_TW/process/submitting-patches.rst @@ -136,7 +136,7 @@ xyzzy do frotz」或「[我]changed xyzzy to do frotz」，就好像你在命令 如果修補程序修復了一個記錄的bug條目，請按編號和URL引用該bug條目。如果補丁來 自郵件列表討論，請給出郵件列表存檔的URL；使用帶有 ``Message-ID`` 的 -https://lkml.kernel.org/ 重定向，以確保連結不會過時。 +https://lore.kernel.org/ 重定向，以確保連結不會過時。 但是，在沒有外部資源的情況下，儘量讓你的解釋可理解。除了提供郵件列表存檔或 bug的URL之外，還要總結需要提交補丁的相關討論要點。 @@ -602,7 +602,7 @@ e-mail 標題中的「一句話概述」扼要的描述 e-mail 中的補丁。 將補丁與以前的相關討論關聯起來，例如，將bug修復程序連結到電子郵件和bug報告。 但是，對於多補丁系列，最好避免在回復時使用連結到該系列的舊版本。這樣， 補丁的多個版本就不會成爲電子郵件客戶端中無法管理的引用序列。如果連結有用， -可以使用 https://lkml.kernel.org/ 重定向器（例如，在封面電子郵件文本中） +可以使用 https://lore.kernel.org/ 重定向器（例如，在封面電子郵件文本中） 連結到補丁系列的早期版本。 16) 發送git pull請求 diff --git a/Documentation/userspace-api/futex2.rst b/Documentation/userspace-api/futex2.rst new file mode 100644 index 000000000000..9693f47a7e62 --- /dev/null +++ b/Documentation/userspace-api/futex2.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====== +futex2 +====== + +:Author: André Almeida <andrealmeid@collabora.com> + +futex, or fast user mutex, is a set of syscalls to allow userspace to create +performant synchronization mechanisms, such as mutexes, semaphores and +conditional variables in userspace. C standard libraries, like glibc, uses it +as a means to implement more high level interfaces like pthreads. + +futex2 is a followup version of the initial futex syscall, designed to overcome +limitations of the original interface. + +User API +======== + +``futex_waitv()`` +----------------- + +Wait on an array of futexes, wake on any:: + + futex_waitv(struct futex_waitv *waiters, unsigned int nr_futexes, + unsigned int flags, struct timespec *timeout, clockid_t clockid) + + struct futex_waitv { + __u64 val; + __u64 uaddr; + __u32 flags; + __u32 __reserved; + }; + +Userspace sets an array of struct futex_waitv (up to a max of 128 entries), +using ``uaddr`` for the address to wait for, ``val`` for the expected value +and ``flags`` to specify the type (e.g. private) and size of futex. +``__reserved`` needs to be 0, but it can be used for future extension. The +pointer for the first item of the array is passed as ``waiters``. An invalid +address for ``waiters`` or for any ``uaddr`` returns ``-EFAULT``. + +If userspace has 32-bit pointers, it should do a explicit cast to make sure +the upper bits are zeroed. ``uintptr_t`` does the tricky and it works for +both 32/64-bit pointers. + +``nr_futexes`` specifies the size of the array. Numbers out of [1, 128] +interval will make the syscall return ``-EINVAL``. + +The ``flags`` argument of the syscall needs to be 0, but it can be used for +future extension. + +For each entry in ``waiters`` array, the current value at ``uaddr`` is compared +to ``val``. If it's different, the syscall undo all the work done so far and +return ``-EAGAIN``. If all tests and verifications succeeds, syscall waits until +one of the following happens: + +- The timeout expires, returning ``-ETIMEOUT``. +- A signal was sent to the sleeping task, returning ``-ERESTARTSYS``. +- Some futex at the list was woken, returning the index of some waked futex. + +An example of how to use the interface can be found at ``tools/testing/selftests/futex/functional/futex_waitv.c``. + +Timeout +------- + +``struct timespec *timeout`` argument is an optional argument that points to an +absolute timeout. You need to specify the type of clock being used at +``clockid`` argument. ``CLOCK_MONOTONIC`` and ``CLOCK_REALTIME`` are supported. +This syscall accepts only 64bit timespec structs. + +Types of futex +-------------- + +A futex can be either private or shared. Private is used for processes that +shares the same memory space and the virtual address of the futex will be the +same for all processes. This allows for optimizations in the kernel. To use +private futexes, it's necessary to specify ``FUTEX_PRIVATE_FLAG`` in the futex +flag. For processes that doesn't share the same memory space and therefore can +have different virtual addresses for the same futex (using, for instance, a +file-backed shared memory) requires different internal mechanisms to be get +properly enqueued. This is the default behavior, and it works with both private +and shared futexes. + +Futexes can be of different sizes: 8, 16, 32 or 64 bits. Currently, the only +supported one is 32 bit sized futex, and it need to be specified using +``FUTEX_32`` flag. diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst index c432be070f67..a61eac0c73f8 100644 --- a/Documentation/userspace-api/index.rst +++ b/Documentation/userspace-api/index.rst @@ -28,6 +28,7 @@ place where this information is gathered. media/index sysfs-platform_profile vduse + futex2 .. only:: subproject and html diff --git a/Documentation/userspace-api/ioctl/cdrom.rst b/Documentation/userspace-api/ioctl/cdrom.rst index 3b4c0506de46..682948fc88a3 100644 --- a/Documentation/userspace-api/ioctl/cdrom.rst +++ b/Documentation/userspace-api/ioctl/cdrom.rst @@ -13,61 +13,64 @@ in drivers/cdrom/cdrom.c and drivers/block/scsi_ioctl.c ioctl values are listed in <linux/cdrom.h>. As of this writing, they are as follows: - ====================== =============================================== - CDROMPAUSE Pause Audio Operation - CDROMRESUME Resume paused Audio Operation - CDROMPLAYMSF Play Audio MSF (struct cdrom_msf) - CDROMPLAYTRKIND Play Audio Track/index (struct cdrom_ti) - CDROMREADTOCHDR Read TOC header (struct cdrom_tochdr) - CDROMREADTOCENTRY Read TOC entry (struct cdrom_tocentry) - CDROMSTOP Stop the cdrom drive - CDROMSTART Start the cdrom drive - CDROMEJECT Ejects the cdrom media - CDROMVOLCTRL Control output volume (struct cdrom_volctrl) - CDROMSUBCHNL Read subchannel data (struct cdrom_subchnl) - CDROMREADMODE2 Read CDROM mode 2 data (2336 Bytes) - (struct cdrom_read) - CDROMREADMODE1 Read CDROM mode 1 data (2048 Bytes) - (struct cdrom_read) - CDROMREADAUDIO (struct cdrom_read_audio) - CDROMEJECT_SW enable(1)/disable(0) auto-ejecting - CDROMMULTISESSION Obtain the start-of-last-session - address of multi session disks - (struct cdrom_multisession) - CDROM_GET_MCN Obtain the "Universal Product Code" - if available (struct cdrom_mcn) - CDROM_GET_UPC Deprecated, use CDROM_GET_MCN instead. - CDROMRESET hard-reset the drive - CDROMVOLREAD Get the drive's volume setting - (struct cdrom_volctrl) - CDROMREADRAW read data in raw mode (2352 Bytes) - (struct cdrom_read) - CDROMREADCOOKED read data in cooked mode - CDROMSEEK seek msf address - CDROMPLAYBLK scsi-cd only, (struct cdrom_blk) - CDROMREADALL read all 2646 bytes - CDROMGETSPINDOWN return 4-bit spindown value - CDROMSETSPINDOWN set 4-bit spindown value - CDROMCLOSETRAY pendant of CDROMEJECT - CDROM_SET_OPTIONS Set behavior options - CDROM_CLEAR_OPTIONS Clear behavior options - CDROM_SELECT_SPEED Set the CD-ROM speed - CDROM_SELECT_DISC Select disc (for juke-boxes) - CDROM_MEDIA_CHANGED Check is media changed - CDROM_DRIVE_STATUS Get tray position, etc. - CDROM_DISC_STATUS Get disc type, etc. - CDROM_CHANGER_NSLOTS Get number of slots - CDROM_LOCKDOOR lock or unlock door - CDROM_DEBUG Turn debug messages on/off - CDROM_GET_CAPABILITY get capabilities - CDROMAUDIOBUFSIZ set the audio buffer size - DVD_READ_STRUCT Read structure - DVD_WRITE_STRUCT Write structure - DVD_AUTH Authentication - CDROM_SEND_PACKET send a packet to the drive - CDROM_NEXT_WRITABLE get next writable block - CDROM_LAST_WRITTEN get last block written on disc - ====================== =============================================== + ======================== =============================================== + CDROMPAUSE Pause Audio Operation + CDROMRESUME Resume paused Audio Operation + CDROMPLAYMSF Play Audio MSF (struct cdrom_msf) + CDROMPLAYTRKIND Play Audio Track/index (struct cdrom_ti) + CDROMREADTOCHDR Read TOC header (struct cdrom_tochdr) + CDROMREADTOCENTRY Read TOC entry (struct cdrom_tocentry) + CDROMSTOP Stop the cdrom drive + CDROMSTART Start the cdrom drive + CDROMEJECT Ejects the cdrom media + CDROMVOLCTRL Control output volume (struct cdrom_volctrl) + CDROMSUBCHNL Read subchannel data (struct cdrom_subchnl) + CDROMREADMODE2 Read CDROM mode 2 data (2336 Bytes) + (struct cdrom_read) + CDROMREADMODE1 Read CDROM mode 1 data (2048 Bytes) + (struct cdrom_read) + CDROMREADAUDIO (struct cdrom_read_audio) + CDROMEJECT_SW enable(1)/disable(0) auto-ejecting + CDROMMULTISESSION Obtain the start-of-last-session + address of multi session disks + (struct cdrom_multisession) + CDROM_GET_MCN Obtain the "Universal Product Code" + if available (struct cdrom_mcn) + CDROM_GET_UPC Deprecated, use CDROM_GET_MCN instead. + CDROMRESET hard-reset the drive + CDROMVOLREAD Get the drive's volume setting + (struct cdrom_volctrl) + CDROMREADRAW read data in raw mode (2352 Bytes) + (struct cdrom_read) + CDROMREADCOOKED read data in cooked mode + CDROMSEEK seek msf address + CDROMPLAYBLK scsi-cd only, (struct cdrom_blk) + CDROMREADALL read all 2646 bytes + CDROMGETSPINDOWN return 4-bit spindown value + CDROMSETSPINDOWN set 4-bit spindown value + CDROMCLOSETRAY pendant of CDROMEJECT + CDROM_SET_OPTIONS Set behavior options + CDROM_CLEAR_OPTIONS Clear behavior options + CDROM_SELECT_SPEED Set the CD-ROM speed + CDROM_SELECT_DISC Select disc (for juke-boxes) + CDROM_MEDIA_CHANGED Check is media changed + CDROM_TIMED_MEDIA_CHANGE Check if media changed + since given time + (struct cdrom_timed_media_change_info) + CDROM_DRIVE_STATUS Get tray position, etc. + CDROM_DISC_STATUS Get disc type, etc. + CDROM_CHANGER_NSLOTS Get number of slots + CDROM_LOCKDOOR lock or unlock door + CDROM_DEBUG Turn debug messages on/off + CDROM_GET_CAPABILITY get capabilities + CDROMAUDIOBUFSIZ set the audio buffer size + DVD_READ_STRUCT Read structure + DVD_WRITE_STRUCT Write structure + DVD_AUTH Authentication + CDROM_SEND_PACKET send a packet to the drive + CDROM_NEXT_WRITABLE get next writable block + CDROM_LAST_WRITTEN get last block written on disc + ======================== =============================================== The information that follows was determined from reading kernel source diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 2e8134059c87..cfe6cccf0f44 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -88,6 +88,7 @@ Code Seq# Include File Comments <http://infiniband.sourceforge.net/> 0x20 all drivers/cdrom/cm206.h 0x22 all scsi/sg.h +0x3E 00-0F linux/counter.h <mailto:linux-iio@vger.kernel.org> '!' 00-1F uapi/linux/seccomp.h '#' 00-3F IEEE 1394 Subsystem Block for the entire subsystem @@ -104,6 +105,7 @@ Code Seq# Include File Comments '8' all SNP8023 advanced NIC card <mailto:mcr@solidum.com> ';' 64-7F linux/vfio.h +'=' 00-3f uapi/linux/ptp_clock.h <mailto:richardcochran@gmail.com> '@' 00-0F linux/radeonfb.h conflict! '@' 00-0F drivers/video/aty/aty128fb.c conflict! 'A' 00-1F linux/apm_bios.h conflict! diff --git a/Documentation/userspace-api/media/drivers/cx2341x-uapi.rst b/Documentation/userspace-api/media/drivers/cx2341x-uapi.rst index 8a7977af79d5..debde65fb8cd 100644 --- a/Documentation/userspace-api/media/drivers/cx2341x-uapi.rst +++ b/Documentation/userspace-api/media/drivers/cx2341x-uapi.rst @@ -7,9 +7,7 @@ Non-compressed file format -------------------------- The cx23416 can produce (and the cx23415 can also read) raw YUV output. The -format of a YUV frame is specific to this chip and is called HM12. 'HM' stands -for 'Hauppauge Macroblock', which is a misnomer as 'Conexant Macroblock' would -be more accurate. +format of a YUV frame is 16x16 linear tiled NV12 (V4L2_PIX_FMT_NV12_16L16). The format is YUV 4:2:0 which uses 1 Y byte per pixel and 1 U and V byte per four pixels. @@ -34,8 +32,8 @@ second line of 8 UV pairs of the top-left block, etc. After transmitting this block the first line of the block on the right to the first block is transmitted, etc. -The code below is given as an example on how to convert HM12 to separate -Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels. +The code below is given as an example on how to convert V4L2_PIX_FMT_NV12_16L16 +to separate Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels. The width of a frame is always 720 pixels, regardless of the actual specified width. diff --git a/Documentation/userspace-api/media/v4l/buffer.rst b/Documentation/userspace-api/media/v4l/buffer.rst index e991ba73d873..4638ec64db00 100644 --- a/Documentation/userspace-api/media/v4l/buffer.rst +++ b/Documentation/userspace-api/media/v4l/buffer.rst @@ -676,8 +676,6 @@ Buffer Flags \normalsize -.. _memory-flags: - enum v4l2_memory ================ @@ -701,6 +699,44 @@ enum v4l2_memory - 4 - The buffer is used for :ref:`DMA shared buffer <dmabuf>` I/O. +.. _memory-flags: + +Memory Consistency Flags +------------------------ + +.. raw:: latex + + \small + +.. tabularcolumns:: |p{7.0cm}|p{2.1cm}|p{8.4cm}| + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + * .. _`V4L2-MEMORY-FLAG-NON-COHERENT`: + + - ``V4L2_MEMORY_FLAG_NON_COHERENT`` + - 0x00000001 + - A buffer is allocated either in coherent (it will be automatically + coherent between the CPU and the bus) or non-coherent memory. The + latter can provide performance gains, for instance the CPU cache + sync/flush operations can be avoided if the buffer is accessed by the + corresponding device only and the CPU does not read/write to/from that + buffer. However, this requires extra care from the driver -- it must + guarantee memory consistency by issuing a cache flush/sync when + consistency is needed. If this flag is set V4L2 will attempt to + allocate the buffer in non-coherent memory. The flag takes effect + only if the buffer is used for :ref:`memory mapping <mmap>` I/O and the + queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS + <V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability. + +.. raw:: latex + + \normalsize Timecodes ========= diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index 976d34445a24..e141f0e4eec9 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -3088,6 +3088,63 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - \normalsize +``V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX (struct)`` + Specifies the HEVC scaling matrix parameters used for the scaling process + for transform coefficients. + These matrix and parameters are defined according to :ref:`hevc`. + They are described in section 7.4.5 "Scaling list data semantics" of + the specification. + +.. c:type:: v4l2_ctrl_hevc_scaling_matrix + +.. raw:: latex + + \scriptsize + +.. tabularcolumns:: |p{5.4cm}|p{6.8cm}|p{5.1cm}| + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_hevc_scaling_matrix + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``scaling_list_4x4[6][16]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_8x8[6][64]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_16x16[6][64]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_32x32[2][64]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_dc_coef_16x16[6]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + * - __u8 + - ``scaling_list_dc_coef_32x32[2]`` + - Scaling list is used for the scaling process for transform + coefficients. The values on each scaling list are expected + in raster scan order. + +.. raw:: latex + + \normalsize + .. c:type:: v4l2_hevc_dpb_entry .. raw:: latex diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst index de43f5c8486d..71f23f131f97 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst @@ -72,3 +72,23 @@ Image Source Control IDs * - __u32 - ``height`` - Height of the area. + +``V4L2_CID_NOTIFY_GAINS (integer array)`` + The sensor is notified what gains will be applied to the different + colour channels by subsequent processing (such as by an ISP). The + sensor is merely informed of these values in case it performs + processing that requires them, but it does not apply them itself to + the output pixels. + + Currently it is defined only for Bayer sensors, and is an array + control taking 4 gain values, being the gains for each of the + Bayer channels. The gains are always in the order B, Gb, Gr and R, + irrespective of the exact Bayer order of the sensor itself. + + The use of an array allows this control to be extended to sensors + with, for example, non-Bayer CFAs (colour filter arrays). + + The units for the gain values are linear, with the default value + representing a gain of exactly 1.0. For example, if this default value + is reported as being (say) 128, then a value of 192 would represent + a gain of exactly 1.5. diff --git a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst index 0b879c0da713..2f2133b4cd9c 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst @@ -48,14 +48,6 @@ please make a proposal on the linux-media mailing list. - ``V4L2_PIX_FMT_HI240`` - 'HI24' - 8 bit RGB format used by the BTTV driver. - * .. _V4L2-PIX-FMT-HM12: - - - ``V4L2_PIX_FMT_HM12`` - - 'HM12' - - YUV 4:2:0 format used by the IVTV driver. - - The format is documented in the kernel sources in the file - ``Documentation/userspace-api/media/drivers/cx2341x-uapi.rst`` * .. _V4L2-PIX-FMT-CPIA1: - ``V4L2_PIX_FMT_CPIA1`` @@ -246,20 +238,13 @@ please make a proposal on the linux-media mailing list. It is an opaque intermediate format and the MDP hardware must be used to convert ``V4L2_PIX_FMT_MT21C`` to ``V4L2_PIX_FMT_NV12M``, ``V4L2_PIX_FMT_YUV420M`` or ``V4L2_PIX_FMT_YVU420``. - * .. _V4L2-PIX-FMT-SUNXI-TILED-NV12: - - - ``V4L2_PIX_FMT_SUNXI_TILED_NV12`` - - 'ST12' - - Two-planar NV12-based format used by the video engine found on Allwinner - (codenamed sunxi) platforms, with 32x32 tiles for the luminance plane - and 32x64 tiles for the chrominance plane. The data in each tile is - stored in linear order, within the tile bounds. Each tile follows the - previous one linearly in memory (from left to right, top to bottom). - - The associated buffer dimensions are aligned to match an integer number - of tiles, resulting in 32-aligned resolutions for the luminance plane - and 16-aligned resolutions for the chrominance plane (with 2x2 - subsampling). + * .. _V4L2-PIX-FMT-MM21: + + - ``V4L2_PIX_FMT_MM21`` + - 'MM21' + - Non-compressed, tiled two-planar format used by Mediatek MT8183. + This is an opaque intermediate format and the MDP3 hardware can be + used to convert it to other formats. .. raw:: latex diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst index 090c091affd2..3a09d93d405b 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst @@ -99,7 +99,7 @@ All components are stored with the same number of bits per component. - 4:2:0 - Cb, Cr - No - - 64x32 macroblocks + - 64x32 tiles Horizontal Z order * - V4L2_PIX_FMT_NV12MT_16X16 @@ -108,7 +108,7 @@ All components are stored with the same number of bits per component. - 4:2:2 - Cb, Cr - No - - 16x16 macroblocks + - 16x16 tiles * - V4L2_PIX_FMT_NV16 - 'NV16' - 8 @@ -254,27 +254,47 @@ of the luma plane. .. _V4L2-PIX-FMT-NV12MT: .. _V4L2-PIX-FMT-NV12MT-16X16: +.. _V4L2-PIX-FMT-NV12-4L4: +.. _V4L2-PIX-FMT-NV12-16L16: +.. _V4L2-PIX-FMT-NV12-32L32: -NV12MT and MV12MT_16X16 ------------------------ +Tiled NV12 +---------- Semi-planar YUV 4:2:0 formats, using macroblock tiling. The chroma plane is subsampled by 2 in each direction. Chroma lines contain half the number of pixels and the same number of bytes as luma lines, and the chroma plane -contains half the number of lines of the luma plane. +contains half the number of lines of the luma plane. Each tile follows the +previous one linearly in memory (from left to right, top to bottom). + +``V4L2_PIX_FMT_NV12MT_16X16`` is similar to ``V4L2_PIX_FMT_NV12M`` but stores +pixels in 2D 16x16 tiles, and stores tiles linearly in memory. +The line stride and image height must be aligned to a multiple of 16. +The layouts of the luma and chroma planes are identical. + +``V4L2_PIX_FMT_NV12MT`` is similar to ``V4L2_PIX_FMT_NV12M`` but stores +pixels in 2D 64x32 tiles, and stores 2x2 groups of tiles in +Z-order in memory, alternating Z and mirrored Z shapes horizontally. +The line stride must be a multiple of 128 pixels to ensure an +integer number of Z shapes. The image height must be a multiple of 32 pixels. +If the vertical resolution is an odd number of tiles, the last row of +tiles is stored in linear order. The layouts of the luma and chroma +planes are identical. + +``V4L2_PIX_FMT_NV12_4L4`` stores pixel in 4x4 tiles, and stores +tiles linearly in memory. The line stride and image height must be +aligned to a multiple of 4. The layouts of the luma and chroma planes are +identical. -``V4L2_PIX_FMT_NV12MT_16X16`` stores pixel in 2D 16x16 macroblocks, and stores -macroblocks linearly in memory. The line stride and image height must be +``V4L2_PIX_FMT_NV12_16L16`` stores pixel in 16x16 tiles, and stores +tiles linearly in memory. The line stride and image height must be aligned to a multiple of 16. The layouts of the luma and chroma planes are identical. -``V4L2_PIX_FMT_NV12MT`` stores pixels in 2D 64x32 macroblocks, and stores 2x2 -groups of macroblocks in Z-order in memory, alternating Z and mirrored Z shapes -horizontally. The line stride must be a multiple of 128 pixels to ensure an -integer number of Z shapes. The image height must be a multiple of 32 pixels. -If the vertical resolution is an odd number of macroblocks, the last row of -macroblocks is stored in linear order. The layouts of the luma and chroma -planes are identical. +``V4L2_PIX_FMT_NV12_32L32`` stores pixel in 32x32 tiles, and stores +tiles linearly in memory. The line stride and image height must be +aligned to a multiple of 32. The layouts of the luma and chroma planes are +identical. .. _nv12mt: @@ -290,7 +310,7 @@ planes are identical. :alt: nv12mt_example.svg :align: center - Example V4L2_PIX_FMT_NV12MT memory layout of macroblocks + Example V4L2_PIX_FMT_NV12MT memory layout of tiles .. _V4L2-PIX-FMT-NV16: diff --git a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst index f98f18c9e91c..a048a9f6b7b6 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst @@ -113,7 +113,12 @@ than the number requested. ``V4L2_MEMORY_MMAP`` and ``format.type`` to the buffer type. * - __u32 - - ``reserved``\ [7] + - ``flags`` + - Specifies additional buffer management attributes. + See :ref:`memory-flags`. + + * - __u32 + - ``reserved``\ [6] - A place holder for future extensions. Drivers and applications must set the array to zero. diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst index 80e8c63d530f..fd09677f64f8 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst @@ -95,3 +95,6 @@ EBUSY EACCES Attempt to set a read-only control or to get a write-only control. + + Or if there is an attempt to set an inactive control and the driver is + not capable of caching the new value until the control is active again. diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst index 2d6bc8d94380..fdde0ae6d521 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst @@ -470,3 +470,6 @@ EACCES Or the ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but the device does not support requests. + + Or if there is an attempt to set an inactive control and the driver is + not capable of caching the new value until the control is active again. diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst index f9ecf6276129..2f491c17dd5d 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst @@ -495,6 +495,12 @@ See also the examples in :ref:`control`. - n/a - A struct :c:type:`v4l2_ctrl_hevc_slice_params`, containing HEVC slice parameters for stateless video decoders. + * - ``V4L2_CTRL_TYPE_HEVC_SCALING_MATRIX`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_ctrl_hevc_scaling_matrix`, containing HEVC + scaling matrix for stateless video decoders. * - ``V4L2_CTRL_TYPE_VP8_FRAME`` - n/a - n/a diff --git a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst index 50ea72043bb0..099fa6695167 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst @@ -104,10 +104,13 @@ aborting or finishing any DMA in progress, an implicit ``V4L2_MEMORY_MMAP`` and ``type`` set to the buffer type. This will free any previously allocated buffers, so this is typically something that will be done at the start of the application. - * - __u32 - - ``reserved``\ [1] - - A place holder for future extensions. Drivers and applications - must set the array to zero. + * - __u8 + - ``flags`` + - Specifies additional buffer management attributes. + See :ref:`memory-flags`. + * - __u8 + - ``reserved``\ [3] + - Reserved for future extensions. .. _v4l2-buf-capabilities: .. _V4L2-BUF-CAP-SUPPORTS-MMAP: @@ -158,8 +161,9 @@ aborting or finishing any DMA in progress, an implicit - This capability is set by the driver to indicate that the queue supports cache and memory management hints. However, it's only valid when the queue is used for :ref:`memory mapping <mmap>` streaming I/O. See - :ref:`V4L2_BUF_FLAG_NO_CACHE_INVALIDATE <V4L2-BUF-FLAG-NO-CACHE-INVALIDATE>` and - :ref:`V4L2_BUF_FLAG_NO_CACHE_CLEAN <V4L2-BUF-FLAG-NO-CACHE-CLEAN>`. + :ref:`V4L2_BUF_FLAG_NO_CACHE_INVALIDATE <V4L2-BUF-FLAG-NO-CACHE-INVALIDATE>`, + :ref:`V4L2_BUF_FLAG_NO_CACHE_CLEAN <V4L2-BUF-FLAG-NO-CACHE-CLEAN>` and + :ref:`V4L2_MEMORY_FLAG_NON_COHERENT <V4L2-MEMORY-FLAG-NON-COHERENT>`. .. raw:: latex diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions index 2217b56c2686..eb0b1cd37abd 100644 --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions @@ -187,6 +187,8 @@ replace define V4L2_CAP_IO_MC device-capabilities # V4L2 pix flags replace define V4L2_PIX_FMT_PRIV_MAGIC :c:type:`v4l2_pix_format` replace define V4L2_PIX_FMT_FLAG_PREMUL_ALPHA format-flags +replace define V4L2_PIX_FMT_HM12 :c:type:`v4l2_pix_format` +replace define V4L2_PIX_FMT_SUNXI_TILED_NV12 :c:type:`v4l2_pix_format` # V4L2 format flags replace define V4L2_FMT_FLAG_COMPRESSED fmtdesc-flags diff --git a/Documentation/userspace-api/vduse.rst b/Documentation/userspace-api/vduse.rst index 42ef59ea5314..bdb880e01132 100644 --- a/Documentation/userspace-api/vduse.rst +++ b/Documentation/userspace-api/vduse.rst @@ -18,7 +18,7 @@ types can be added after the security issue of corresponding device driver is clarified or fixed in the future. Create/Destroy VDUSE devices ------------------------- +---------------------------- VDUSE devices are created as follows: diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index a6729c8cf063..aeeb071c7688 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -532,7 +532,7 @@ translation mode. ------------------ :Capability: basic -:Architectures: x86, ppc, mips +:Architectures: x86, ppc, mips, riscv :Type: vcpu ioctl :Parameters: struct kvm_interrupt (in) :Returns: 0 on success, negative on failure. @@ -601,6 +601,23 @@ interrupt number dequeues the interrupt. This is an asynchronous vcpu ioctl and can be invoked from any thread. +RISC-V: +^^^^^^^ + +Queues an external interrupt to be injected into the virutal CPU. This ioctl +is overloaded with 2 different irq values: + +a) KVM_INTERRUPT_SET + + This sets external interrupt for a virtual CPU and it will receive + once it is ready. + +b) KVM_INTERRUPT_UNSET + + This clears pending external interrupt for a virtual CPU. + +This is an asynchronous vcpu ioctl and can be invoked from any thread. + 4.17 KVM_DEBUG_GUEST -------------------- @@ -993,20 +1010,37 @@ such as migration. When KVM_CAP_ADJUST_CLOCK is passed to KVM_CHECK_EXTENSION, it returns the set of bits that KVM can return in struct kvm_clock_data's flag member. -The only flag defined now is KVM_CLOCK_TSC_STABLE. If set, the returned -value is the exact kvmclock value seen by all VCPUs at the instant -when KVM_GET_CLOCK was called. If clear, the returned value is simply -CLOCK_MONOTONIC plus a constant offset; the offset can be modified -with KVM_SET_CLOCK. KVM will try to make all VCPUs follow this clock, -but the exact value read by each VCPU could differ, because the host -TSC is not stable. +The following flags are defined: + +KVM_CLOCK_TSC_STABLE + If set, the returned value is the exact kvmclock + value seen by all VCPUs at the instant when KVM_GET_CLOCK was called. + If clear, the returned value is simply CLOCK_MONOTONIC plus a constant + offset; the offset can be modified with KVM_SET_CLOCK. KVM will try + to make all VCPUs follow this clock, but the exact value read by each + VCPU could differ, because the host TSC is not stable. + +KVM_CLOCK_REALTIME + If set, the `realtime` field in the kvm_clock_data + structure is populated with the value of the host's real time + clocksource at the instant when KVM_GET_CLOCK was called. If clear, + the `realtime` field does not contain a value. + +KVM_CLOCK_HOST_TSC + If set, the `host_tsc` field in the kvm_clock_data + structure is populated with the value of the host's timestamp counter (TSC) + at the instant when KVM_GET_CLOCK was called. If clear, the `host_tsc` field + does not contain a value. :: struct kvm_clock_data { __u64 clock; /* kvmclock current value */ __u32 flags; - __u32 pad[9]; + __u32 pad0; + __u64 realtime; + __u64 host_tsc; + __u32 pad[4]; }; @@ -1023,12 +1057,25 @@ Sets the current timestamp of kvmclock to the value specified in its parameter. In conjunction with KVM_GET_CLOCK, it is used to ensure monotonicity on scenarios such as migration. +The following flags can be passed: + +KVM_CLOCK_REALTIME + If set, KVM will compare the value of the `realtime` field + with the value of the host's real time clocksource at the instant when + KVM_SET_CLOCK was called. The difference in elapsed time is added to the final + kvmclock value that will be provided to guests. + +Other flags returned by ``KVM_GET_CLOCK`` are accepted but ignored. + :: struct kvm_clock_data { __u64 clock; /* kvmclock current value */ __u32 flags; - __u32 pad[9]; + __u32 pad0; + __u64 realtime; + __u64 host_tsc; + __u32 pad[4]; }; @@ -1399,7 +1446,7 @@ for vm-wide capabilities. --------------------- :Capability: KVM_CAP_MP_STATE -:Architectures: x86, s390, arm, arm64 +:Architectures: x86, s390, arm, arm64, riscv :Type: vcpu ioctl :Parameters: struct kvm_mp_state (out) :Returns: 0 on success; -1 on error @@ -1416,7 +1463,8 @@ uniprocessor guests). Possible values are: ========================== =============================================== - KVM_MP_STATE_RUNNABLE the vcpu is currently running [x86,arm/arm64] + KVM_MP_STATE_RUNNABLE the vcpu is currently running + [x86,arm/arm64,riscv] KVM_MP_STATE_UNINITIALIZED the vcpu is an application processor (AP) which has not yet received an INIT signal [x86] KVM_MP_STATE_INIT_RECEIVED the vcpu has received an INIT signal, and is @@ -1425,7 +1473,7 @@ Possible values are: is waiting for an interrupt [x86] KVM_MP_STATE_SIPI_RECEIVED the vcpu has just received a SIPI (vector accessible via KVM_GET_VCPU_EVENTS) [x86] - KVM_MP_STATE_STOPPED the vcpu is stopped [s390,arm/arm64] + KVM_MP_STATE_STOPPED the vcpu is stopped [s390,arm/arm64,riscv] KVM_MP_STATE_CHECK_STOP the vcpu is in a special error state [s390] KVM_MP_STATE_OPERATING the vcpu is operating (running or halted) [s390] @@ -1437,8 +1485,8 @@ On x86, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel irqchip, the multiprocessing state must be maintained by userspace on these architectures. -For arm/arm64: -^^^^^^^^^^^^^^ +For arm/arm64/riscv: +^^^^^^^^^^^^^^^^^^^^ The only states that are valid are KVM_MP_STATE_STOPPED and KVM_MP_STATE_RUNNABLE which reflect if the vcpu is paused or not. @@ -1447,7 +1495,7 @@ KVM_MP_STATE_RUNNABLE which reflect if the vcpu is paused or not. --------------------- :Capability: KVM_CAP_MP_STATE -:Architectures: x86, s390, arm, arm64 +:Architectures: x86, s390, arm, arm64, riscv :Type: vcpu ioctl :Parameters: struct kvm_mp_state (in) :Returns: 0 on success; -1 on error @@ -1459,8 +1507,8 @@ On x86, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel irqchip, the multiprocessing state must be maintained by userspace on these architectures. -For arm/arm64: -^^^^^^^^^^^^^^ +For arm/arm64/riscv: +^^^^^^^^^^^^^^^^^^^^ The only states that are valid are KVM_MP_STATE_STOPPED and KVM_MP_STATE_RUNNABLE which reflect if the vcpu should be paused or not. @@ -2577,6 +2625,144 @@ following id bit patterns:: 0x7020 0000 0003 02 <0:3> <reg:5> +RISC-V registers are mapped using the lower 32 bits. The upper 8 bits of +that is the register group type. + +RISC-V config registers are meant for configuring a Guest VCPU and it has +the following id bit patterns:: + + 0x8020 0000 01 <index into the kvm_riscv_config struct:24> (32bit Host) + 0x8030 0000 01 <index into the kvm_riscv_config struct:24> (64bit Host) + +Following are the RISC-V config registers: + +======================= ========= ============================================= + Encoding Register Description +======================= ========= ============================================= + 0x80x0 0000 0100 0000 isa ISA feature bitmap of Guest VCPU +======================= ========= ============================================= + +The isa config register can be read anytime but can only be written before +a Guest VCPU runs. It will have ISA feature bits matching underlying host +set by default. + +RISC-V core registers represent the general excution state of a Guest VCPU +and it has the following id bit patterns:: + + 0x8020 0000 02 <index into the kvm_riscv_core struct:24> (32bit Host) + 0x8030 0000 02 <index into the kvm_riscv_core struct:24> (64bit Host) + +Following are the RISC-V core registers: + +======================= ========= ============================================= + Encoding Register Description +======================= ========= ============================================= + 0x80x0 0000 0200 0000 regs.pc Program counter + 0x80x0 0000 0200 0001 regs.ra Return address + 0x80x0 0000 0200 0002 regs.sp Stack pointer + 0x80x0 0000 0200 0003 regs.gp Global pointer + 0x80x0 0000 0200 0004 regs.tp Task pointer + 0x80x0 0000 0200 0005 regs.t0 Caller saved register 0 + 0x80x0 0000 0200 0006 regs.t1 Caller saved register 1 + 0x80x0 0000 0200 0007 regs.t2 Caller saved register 2 + 0x80x0 0000 0200 0008 regs.s0 Callee saved register 0 + 0x80x0 0000 0200 0009 regs.s1 Callee saved register 1 + 0x80x0 0000 0200 000a regs.a0 Function argument (or return value) 0 + 0x80x0 0000 0200 000b regs.a1 Function argument (or return value) 1 + 0x80x0 0000 0200 000c regs.a2 Function argument 2 + 0x80x0 0000 0200 000d regs.a3 Function argument 3 + 0x80x0 0000 0200 000e regs.a4 Function argument 4 + 0x80x0 0000 0200 000f regs.a5 Function argument 5 + 0x80x0 0000 0200 0010 regs.a6 Function argument 6 + 0x80x0 0000 0200 0011 regs.a7 Function argument 7 + 0x80x0 0000 0200 0012 regs.s2 Callee saved register 2 + 0x80x0 0000 0200 0013 regs.s3 Callee saved register 3 + 0x80x0 0000 0200 0014 regs.s4 Callee saved register 4 + 0x80x0 0000 0200 0015 regs.s5 Callee saved register 5 + 0x80x0 0000 0200 0016 regs.s6 Callee saved register 6 + 0x80x0 0000 0200 0017 regs.s7 Callee saved register 7 + 0x80x0 0000 0200 0018 regs.s8 Callee saved register 8 + 0x80x0 0000 0200 0019 regs.s9 Callee saved register 9 + 0x80x0 0000 0200 001a regs.s10 Callee saved register 10 + 0x80x0 0000 0200 001b regs.s11 Callee saved register 11 + 0x80x0 0000 0200 001c regs.t3 Caller saved register 3 + 0x80x0 0000 0200 001d regs.t4 Caller saved register 4 + 0x80x0 0000 0200 001e regs.t5 Caller saved register 5 + 0x80x0 0000 0200 001f regs.t6 Caller saved register 6 + 0x80x0 0000 0200 0020 mode Privilege mode (1 = S-mode or 0 = U-mode) +======================= ========= ============================================= + +RISC-V csr registers represent the supervisor mode control/status registers +of a Guest VCPU and it has the following id bit patterns:: + + 0x8020 0000 03 <index into the kvm_riscv_csr struct:24> (32bit Host) + 0x8030 0000 03 <index into the kvm_riscv_csr struct:24> (64bit Host) + +Following are the RISC-V csr registers: + +======================= ========= ============================================= + Encoding Register Description +======================= ========= ============================================= + 0x80x0 0000 0300 0000 sstatus Supervisor status + 0x80x0 0000 0300 0001 sie Supervisor interrupt enable + 0x80x0 0000 0300 0002 stvec Supervisor trap vector base + 0x80x0 0000 0300 0003 sscratch Supervisor scratch register + 0x80x0 0000 0300 0004 sepc Supervisor exception program counter + 0x80x0 0000 0300 0005 scause Supervisor trap cause + 0x80x0 0000 0300 0006 stval Supervisor bad address or instruction + 0x80x0 0000 0300 0007 sip Supervisor interrupt pending + 0x80x0 0000 0300 0008 satp Supervisor address translation and protection +======================= ========= ============================================= + +RISC-V timer registers represent the timer state of a Guest VCPU and it has +the following id bit patterns:: + + 0x8030 0000 04 <index into the kvm_riscv_timer struct:24> + +Following are the RISC-V timer registers: + +======================= ========= ============================================= + Encoding Register Description +======================= ========= ============================================= + 0x8030 0000 0400 0000 frequency Time base frequency (read-only) + 0x8030 0000 0400 0001 time Time value visible to Guest + 0x8030 0000 0400 0002 compare Time compare programmed by Guest + 0x8030 0000 0400 0003 state Time compare state (1 = ON or 0 = OFF) +======================= ========= ============================================= + +RISC-V F-extension registers represent the single precision floating point +state of a Guest VCPU and it has the following id bit patterns:: + + 0x8020 0000 05 <index into the __riscv_f_ext_state struct:24> + +Following are the RISC-V F-extension registers: + +======================= ========= ============================================= + Encoding Register Description +======================= ========= ============================================= + 0x8020 0000 0500 0000 f[0] Floating point register 0 + ... + 0x8020 0000 0500 001f f[31] Floating point register 31 + 0x8020 0000 0500 0020 fcsr Floating point control and status register +======================= ========= ============================================= + +RISC-V D-extension registers represent the double precision floating point +state of a Guest VCPU and it has the following id bit patterns:: + + 0x8020 0000 06 <index into the __riscv_d_ext_state struct:24> (fcsr) + 0x8030 0000 06 <index into the __riscv_d_ext_state struct:24> (non-fcsr) + +Following are the RISC-V D-extension registers: + +======================= ========= ============================================= + Encoding Register Description +======================= ========= ============================================= + 0x8030 0000 0600 0000 f[0] Floating point register 0 + ... + 0x8030 0000 0600 001f f[31] Floating point register 31 + 0x8020 0000 0600 0020 fcsr Floating point control and status register +======================= ========= ============================================= + 4.69 KVM_GET_ONE_REG -------------------- @@ -5850,6 +6036,25 @@ Valid values for 'type' are: :: + /* KVM_EXIT_RISCV_SBI */ + struct { + unsigned long extension_id; + unsigned long function_id; + unsigned long args[6]; + unsigned long ret[2]; + } riscv_sbi; +If exit reason is KVM_EXIT_RISCV_SBI then it indicates that the VCPU has +done a SBI call which is not handled by KVM RISC-V kernel module. The details +of the SBI call are available in 'riscv_sbi' member of kvm_run structure. The +'extension_id' field of 'riscv_sbi' represents SBI extension ID whereas the +'function_id' field represents function ID of given SBI extension. The 'args' +array field of 'riscv_sbi' represents parameters for the SBI call and 'ret' +array field represents return values. The userspace should update the return +values of SBI call before resuming the VCPU. For more details on RISC-V SBI +spec refer, https://github.com/riscv/riscv-sbi-doc. + +:: + /* Fix the size of the union. */ char padding[256]; }; @@ -6706,6 +6911,20 @@ MAP_SHARED mmap will result in an -EINVAL return. When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to perform a bulk copy of tags to/from the guest. +7.29 KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM +------------------------------------- + +Architectures: x86 SEV enabled +Type: vm +Parameters: args[0] is the fd of the source vm +Returns: 0 on success + +This capability enables userspace to migrate the encryption context from the VM +indicated by the fd to the VM this is called on. + +This is intended to support intra-host migration of VMs between userspace VMMs, +upgrading the VMM process without interrupting the guest. + 8. Other capabilities. ====================== diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst index 2acec3b9ef65..60a29972d3f1 100644 --- a/Documentation/virt/kvm/devices/vcpu.rst +++ b/Documentation/virt/kvm/devices/vcpu.rst @@ -161,3 +161,73 @@ Specifies the base address of the stolen time structure for this VCPU. The base address must be 64 byte aligned and exist within a valid guest memory region. See Documentation/virt/kvm/arm/pvtime.rst for more information including the layout of the stolen time structure. + +4. GROUP: KVM_VCPU_TSC_CTRL +=========================== + +:Architectures: x86 + +4.1 ATTRIBUTE: KVM_VCPU_TSC_OFFSET + +:Parameters: 64-bit unsigned TSC offset + +Returns: + + ======= ====================================== + -EFAULT Error reading/writing the provided + parameter address. + -ENXIO Attribute not supported + ======= ====================================== + +Specifies the guest's TSC offset relative to the host's TSC. The guest's +TSC is then derived by the following equation: + + guest_tsc = host_tsc + KVM_VCPU_TSC_OFFSET + +This attribute is useful to adjust the guest's TSC on live migration, +so that the TSC counts the time during which the VM was paused. The +following describes a possible algorithm to use for this purpose. + +From the source VMM process: + +1. Invoke the KVM_GET_CLOCK ioctl to record the host TSC (tsc_src), + kvmclock nanoseconds (guest_src), and host CLOCK_REALTIME nanoseconds + (host_src). + +2. Read the KVM_VCPU_TSC_OFFSET attribute for every vCPU to record the + guest TSC offset (ofs_src[i]). + +3. Invoke the KVM_GET_TSC_KHZ ioctl to record the frequency of the + guest's TSC (freq). + +From the destination VMM process: + +4. Invoke the KVM_SET_CLOCK ioctl, providing the source nanoseconds from + kvmclock (guest_src) and CLOCK_REALTIME (host_src) in their respective + fields. Ensure that the KVM_CLOCK_REALTIME flag is set in the provided + structure. + + KVM will advance the VM's kvmclock to account for elapsed time since + recording the clock values. Note that this will cause problems in + the guest (e.g., timeouts) unless CLOCK_REALTIME is synchronized + between the source and destination, and a reasonably short time passes + between the source pausing the VMs and the destination executing + steps 4-7. + +5. Invoke the KVM_GET_CLOCK ioctl to record the host TSC (tsc_dest) and + kvmclock nanoseconds (guest_dest). + +6. Adjust the guest TSC offsets for every vCPU to account for (1) time + elapsed since recording state and (2) difference in TSCs between the + source and destination machine: + + ofs_dst[i] = ofs_src[i] - + (guest_src - guest_dest) * freq + + (tsc_src - tsc_dest) + + ("ofs[i] + tsc - guest * freq" is the guest TSC value corresponding to + a time of 0 in kvmclock. The above formula ensures that it is the + same on the destination as it was on the source). + +7. Write the KVM_VCPU_TSC_OFFSET attribute for every vCPU with the + respective value derived in the previous step. diff --git a/Documentation/virt/kvm/devices/xics.rst b/Documentation/virt/kvm/devices/xics.rst index 2d6927e0b776..bf32c77174ab 100644 --- a/Documentation/virt/kvm/devices/xics.rst +++ b/Documentation/virt/kvm/devices/xics.rst @@ -22,7 +22,7 @@ Groups: Errors: ======= ========================================== - -EINVAL Value greater than KVM_MAX_VCPU_ID. + -EINVAL Value greater than KVM_MAX_VCPU_IDS. -EFAULT Invalid user pointer for attr->addr. -EBUSY A vcpu is already connected to the device. ======= ========================================== diff --git a/Documentation/virt/kvm/devices/xive.rst b/Documentation/virt/kvm/devices/xive.rst index 8bdf3dc38f01..8b5e7b40bdf8 100644 --- a/Documentation/virt/kvm/devices/xive.rst +++ b/Documentation/virt/kvm/devices/xive.rst @@ -91,7 +91,7 @@ the legacy interrupt mode, referred as XICS (POWER7/8). Errors: ======= ========================================== - -EINVAL Value greater than KVM_MAX_VCPU_ID. + -EINVAL Value greater than KVM_MAX_VCPU_IDS. -EFAULT Invalid user pointer for attr->addr. -EBUSY A vCPU is already connected to the device. ======= ========================================== diff --git a/Documentation/virt/ne_overview.rst b/Documentation/virt/ne_overview.rst index 39b0c8fe2654..74c2f5919c88 100644 --- a/Documentation/virt/ne_overview.rst +++ b/Documentation/virt/ne_overview.rst @@ -14,12 +14,15 @@ instances [1]. For example, an application that processes sensitive data and runs in a VM, can be separated from other applications running in the same VM. This application then runs in a separate VM than the primary VM, namely an enclave. +It runs alongside the VM that spawned it. This setup matches low latency +applications needs. -An enclave runs alongside the VM that spawned it. This setup matches low latency -applications needs. The resources that are allocated for the enclave, such as -memory and CPUs, are carved out of the primary VM. Each enclave is mapped to a -process running in the primary VM, that communicates with the NE driver via an -ioctl interface. +The current supported architectures for the NE kernel driver, available in the +upstream Linux kernel, are x86 and ARM64. + +The resources that are allocated for the enclave, such as memory and CPUs, are +carved out of the primary VM. Each enclave is mapped to a process running in the +primary VM, that communicates with the NE kernel driver via an ioctl interface. In this sense, there are two components: @@ -43,8 +46,8 @@ for the enclave VM. An enclave does not have persistent storage attached. The memory regions carved out of the primary VM and given to an enclave need to be aligned 2 MiB / 1 GiB physically contiguous memory regions (or multiple of this size e.g. 8 MiB). The memory can be allocated e.g. by using hugetlbfs from -user space [2][3]. The memory size for an enclave needs to be at least 64 MiB. -The enclave memory and CPUs need to be from the same NUMA node. +user space [2][3][7]. The memory size for an enclave needs to be at least +64 MiB. The enclave memory and CPUs need to be from the same NUMA node. An enclave runs on dedicated cores. CPU 0 and its CPU siblings need to remain available for the primary VM. A CPU pool has to be set for NE purposes by an @@ -61,7 +64,7 @@ device is placed in memory below the typical 4 GiB. The application that runs in the enclave needs to be packaged in an enclave image together with the OS ( e.g. kernel, ramdisk, init ) that will run in the enclave VM. The enclave VM has its own kernel and follows the standard Linux -boot protocol [6]. +boot protocol [6][8]. The kernel bzImage, the kernel command line, the ramdisk(s) are part of the Enclave Image Format (EIF); plus an EIF header including metadata such as magic @@ -93,3 +96,5 @@ enclave process can exit. [4] https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html [5] https://man7.org/linux/man-pages/man7/vsock.7.html [6] https://www.kernel.org/doc/html/latest/x86/boot.html +[7] https://www.kernel.org/doc/html/latest/arm64/hugetlbpage.html +[8] https://www.kernel.org/doc/html/latest/arm64/booting.html diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst index 312e431695d9..2cafd3c3c6cb 100644 --- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst +++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst @@ -128,7 +128,7 @@ Create a minimal OS installation on the mounted filesystem:: debootstrap does not set up the root password, fstab, hostname or anything related to networking. It is up to the user to do that. -Set the root password -t he easiest way to do that is to chroot into the +Set the root password - the easiest way to do that is to chroot into the mounted image:: # chroot /mnt @@ -144,7 +144,7 @@ will be empty and it needs an entry for the root file system:: /dev/ubd0 ext4 discard,errors=remount-ro 0 1 The image hostname will be set to the same as the host on which you -are creating it image. It is a good idea to change that to avoid +are creating its image. It is a good idea to change that to avoid "Oh, bummer, I rebooted the wrong machine". UML supports two classes of network devices - the older uml_net ones @@ -162,7 +162,7 @@ need entries like:: # vector UML network devices auto vec0 - iface eth0 inet dhcp + iface vec0 inet dhcp We now have a UML image which is nearly ready to run, all we need is a UML kernel and modules for it. @@ -179,7 +179,12 @@ directory to the mounted UML filesystem:: If you have compiled your own kernel, you need to use the usual "install modules to a location" procedure by running:: - # make install MODULES_DIR=/mnt/lib/modules + # make INSTALL_MOD_PATH=/mnt/lib/modules modules_install + +This will install modules into /mnt/lib/modules/$(KERNELRELEASE). +To specify the full module installation path, use:: + + # make MODLIB=/mnt/lib/modules modules_install At this point the image is ready to be brought up. @@ -188,7 +193,7 @@ Setting Up UML Networking ************************* UML networking is designed to emulate an Ethernet connection. This -connection may be either a point-to-point (similar to a connection +connection may be either point-to-point (similar to a connection between machines using a back-to-back cable) or a connection to a switch. UML supports a wide variety of means to build these connections to all of: local machine, remote machine(s), local and @@ -231,7 +236,7 @@ remote UML and other VM instances. * All transports which have multi-packet rx and/or tx can deliver pps rates of up to 1Mps or more. -* All legacy transports are generally limited to ~600-700MBit and 0.05Mps +* All legacy transports are generally limited to ~600-700MBit and 0.05Mps. * GRE and L2TPv3 allow connections to all of: local machine, remote machines, remote network devices and remote UML instances. @@ -255,7 +260,7 @@ raw sockets where needed. This can be achieved by granting the user a particular capability instead of running UML as root. In case of vector transport, a user can add the -capability ``CAP_NET_ADMIN`` or ``CAP_NET_RAW``, to the uml binary. +capability ``CAP_NET_ADMIN`` or ``CAP_NET_RAW`` to the uml binary. Thenceforth, UML can be run with normal user privilges, along with full networking. @@ -286,7 +291,7 @@ These options are common for all transports: * ``mac=XX:XX:XX:XX:XX`` - sets the interface MAC address value. -* ``gro=[0,1]`` - sets GRO on or off. Enables receive/transmit offloads. +* ``gro=[0,1]`` - sets GRO off or on. Enables receive/transmit offloads. The effect of this option depends on the host side support in the transport which is being configured. In most cases it will enable TCP segmentation and RX/TX checksumming offloads. The setting must be identical on the host side @@ -301,7 +306,7 @@ These options are common for all transports: * ``headroom=int`` - adjusts the default headroom (32 bytes) reserved if a packet will need to be re-encapsulated into for instance VXLAN. -* ``vec=0`` - disable multipacket io and fall back to packet at a +* ``vec=0`` - disable multipacket IO and fall back to packet at a time mode Shared Options @@ -331,7 +336,7 @@ Example:: This will connect vec0 to tap0 on the host. Tap0 must already exist (for example created using tunctl) and UP. -tap0 can be configured as a point-to-point interface and given an ip +tap0 can be configured as a point-to-point interface and given an IP address so that UML can talk to the host. Alternatively, it is possible to connect UML to a tap interface which is connected to a bridge. @@ -358,7 +363,7 @@ Example:: This is an experimental/demo transport which couples tap for transmit and a raw socket for receive. The raw socket allows multi-packet -receive resulting in significantly higher packet rates than normal tap +receive resulting in significantly higher packet rates than normal tap. Privileges required: hybrid requires ``CAP_NET_RAW`` capability by the UML user as well as the requirements for the tap transport. @@ -426,10 +431,10 @@ This will configure an Ethernet over ``GRE`` (aka ``GRETAP`` or endpoint at host dst_host. ``GRE`` supports the following additional options: -* ``rx_key=int`` - GRE 32 bit integer key for rx packets, if set, +* ``rx_key=int`` - GRE 32-bit integer key for rx packets, if set, ``txkey`` must be set too -* ``tx_key=int`` - GRE 32 bit integer key for tx packets, if set +* ``tx_key=int`` - GRE 32-bit integer key for tx packets, if set ``rx_key`` must be set too * ``sequence=[0,1]`` - enable GRE sequence @@ -444,12 +449,12 @@ options: GRE has a number of caveats: -* You can use only one GRE connection per ip address. There is no way to +* You can use only one GRE connection per IP address. There is no way to multiplex connections as each GRE tunnel is terminated directly on the UML instance. * The key is not really a security feature. While it was intended as such - it's "security" is laughable. It is, however, a useful feature to + its "security" is laughable. It is, however, a useful feature to ensure that the tunnel is not misconfigured. An example configuration for a Linux host with a local address of @@ -489,22 +494,22 @@ the L2TPv3 UDP flavour and UDP destination port $dst_port. L2TPv3 always requires the following additional options: -* ``rx_session=int`` - l2tpv3 32 bit integer session for rx packets +* ``rx_session=int`` - l2tpv3 32-bit integer session for rx packets -* ``tx_session=int`` - l2tpv3 32 bit integer session for tx packets +* ``tx_session=int`` - l2tpv3 32-bit integer session for tx packets As the tunnel is fixed these are not negotiated and they are preconfigured on both ends. -Additionally, L2TPv3 supports the following optional parameters +Additionally, L2TPv3 supports the following optional parameters. -* ``rx_cookie=int`` - l2tpv3 32 bit integer cookie for rx packets - same +* ``rx_cookie=int`` - l2tpv3 32-bit integer cookie for rx packets - same functionality as GRE key, more to prevent misconfiguration than provide actual security -* ``tx_cookie=int`` - l2tpv3 32 bit integer cookie for tx packets +* ``tx_cookie=int`` - l2tpv3 32-bit integer cookie for tx packets -* ``cookie64=[0,1]`` - use 64 bit cookies instead of 32 bit. +* ``cookie64=[0,1]`` - use 64-bit cookies instead of 32-bit. * ``counter=[0,1]`` - enable l2tpv3 counter @@ -518,12 +523,12 @@ Additionally, L2TPv3 supports the following optional parameters L2TPv3 has a number of caveats: -* you can use only one connection per ip address in raw mode. There is +* you can use only one connection per IP address in raw mode. There is no way to multiplex connections as each L2TPv3 tunnel is terminated directly on the UML instance. UDP mode can use different ports for this purpose. -Here is an example of how to configure a linux host to connect to UML +Here is an example of how to configure a Linux host to connect to UML via L2TPv3: **/etc/network/interfaces**:: @@ -586,7 +591,7 @@ distribution or a custom built kernel has been installed on the host. These add an executable called linux to the system. This is the UML kernel. It can be run just like any other executable. It will take most normal linux kernel arguments as command line -arguments. Additionally, it will need some UML specific arguments +arguments. Additionally, it will need some UML-specific arguments in order to do something useful. Arguments @@ -595,7 +600,7 @@ Arguments Mandatory Arguments: -------------------- -* ``mem=int[K,M,G]`` - amount of memory. By default bytes. It will +* ``mem=int[K,M,G]`` - amount of memory. By default in bytes. It will also accept K, M or G qualifiers. * ``ubdX[s,d,c,t]=`` virtual disk specification. This is not really @@ -603,7 +608,7 @@ Mandatory Arguments: specify a root file system. The simplest possible image specification is the name of the image file for the filesystem (created using one of the methods described - in `Creating an image`_) + in `Creating an image`_). * UBD devices support copy on write (COW). The changes are kept in a separate file which can be discarded allowing a rollback to the @@ -613,15 +618,15 @@ Mandatory Arguments: * UBD devices can be set to use synchronous IO. Any writes are immediately flushed to disk. This is done by adding ``s`` after - the ``ubdX`` specification + the ``ubdX`` specification. - * UBD performs some euristics on devices specified as a single + * UBD performs some heuristics on devices specified as a single filename to make sure that a COW file has not been specified as - the image. To turn them off, use the ``d`` flag after ``ubdX`` + the image. To turn them off, use the ``d`` flag after ``ubdX``. * UBD supports TRIM - asking the Host OS to reclaim any unused blocks in the image. To turn it off, specify the ``t`` flag after - ``ubdX`` + ``ubdX``. * ``root=`` root device - most likely ``/dev/ubd0`` (this is a Linux filesystem image) @@ -631,7 +636,7 @@ Important Optional Arguments If UML is run as "linux" with no extra arguments, it will try to start an xterm for every console configured inside the image (up to 6 in most -linux distributions). Each console is started inside an +Linux distributions). Each console is started inside an xterm. This makes it nice and easy to use UML on a host with a GUI. It is, however, the wrong approach if UML is to be used as a testing harness or run in a text-only environment. @@ -656,10 +661,10 @@ one is input, the second one output. * The null channel - Discard all input or output. Example ``con=null`` will set all consoles to null by default. -* The fd channel - use file descriptor numbers for input/out. Example: +* The fd channel - use file descriptor numbers for input/output. Example: ``con1=fd:0,fd:1.`` -* The port channel - listen on tcp port number. Example: ``con1=port:4321`` +* The port channel - listen on TCP port number. Example: ``con1=port:4321`` * The pty and pts channels - use system pty/pts. @@ -667,7 +672,7 @@ one is input, the second one output. will make UML use the host 8th console (usually unused). * The xterm channel - this is the default - bring up an xterm on this channel - and direct IO to it. Note, that in order for xterm to work, the host must + and direct IO to it. Note that in order for xterm to work, the host must have the UML distribution package installed. This usually contains the port-helper and other utilities needed for UML to communicate with the xterm. Alternatively, these need to be complied and installed from source. All @@ -685,7 +690,7 @@ We can now run UML. vec0:transport=tap,ifname=tap0,depth=128,gro=1 \ root=/dev/ubda con=null con0=null,fd:2 con1=fd:0,fd:1 -This will run an instance with ``2048M RAM``, try to use the image file +This will run an instance with ``2048M RAM`` and try to use the image file called ``Filesystem.img`` as root. It will connect to the host using tap0. All consoles except ``con1`` will be disabled and console 1 will use standard input/output making it appear in the same terminal it was started. @@ -702,7 +707,7 @@ The UML Management Console ============================ In addition to managing the image from "the inside" using normal sysadmin tools, -it is possible to perform a number of low level operations using the UML +it is possible to perform a number of low-level operations using the UML management console. The UML management console is a low-level interface to the kernel on a running UML instance, somewhat like the i386 SysRq interface. Since there is a full-blown operating system under UML, there is much greater @@ -726,7 +731,7 @@ kernel. When you boot UML, you'll see a line like:: mconsole initialized on /home/jdike/.uml/umlNJ32yL/mconsole -If you specify a unique machine id one the UML command line, i.e. +If you specify a unique machine id on the UML command line, i.e. ``umid=debian``, you'll see this:: mconsole initialized on /home/jdike/.uml/debian/mconsole @@ -881,11 +886,11 @@ be able to cache the shared data using a much smaller amount of memory, so UML disk requests will be served from the host's memory rather than its disks. There is a major caveat in doing this on multisocket NUMA machines. On such hardware, running many UML instances with a shared -master image and COW changes may caise issues like NMIs from excess of +master image and COW changes may cause issues like NMIs from excess of inter-socket traffic. -If you are running UML on high end hardware like this, make sure to -bind UML to a set of logical cpus residing on the same socket using the +If you are running UML on high-end hardware like this, make sure to +bind UML to a set of logical CPUs residing on the same socket using the ``taskset`` command or have a look at the "tuning" section. To add a copy-on-write layer to an existing block device file, simply @@ -986,7 +991,7 @@ specify a subdirectory to mount with the -o switch to mount:: # mount none /mnt/home -t hostfs -o /home -will mount the hosts's /home on the virtual machine's /mnt/home. +will mount the host's /home on the virtual machine's /mnt/home. hostfs as the root filesystem ----------------------------- @@ -1035,7 +1040,7 @@ The UBD driver, SIGIO and the MMU emulation do that. If the system is idle, these threads will be migrated to other processors on a SMP host. This, unfortunately, will usually result in LOWER performance because of all of the cache/memory synchronization traffic between cores. As a -result, UML will usually benefit from being pinned on a single CPU +result, UML will usually benefit from being pinned on a single CPU, especially on a large system. This can result in performance differences of 5 times or higher on some benchmarks. @@ -1061,7 +1066,7 @@ filesystems, devices, virtualization, etc. It provides unrivalled opportunities to create and test them without being constrained to emulating specific hardware. -Example - want to try how linux will work with 4096 "proper" network +Example - want to try how Linux will work with 4096 "proper" network devices? Not an issue with UML. At the same time, this is something which @@ -1070,10 +1075,10 @@ constrained by the number of devices allowed on the hardware bus they are trying to emulate (for example 16 on a PCI bus in qemu). If you have something to contribute such as a patch, a bugfix, a -new feature, please send it to ``linux-um@lists.infradead.org`` +new feature, please send it to ``linux-um@lists.infradead.org``. Please follow all standard Linux patch guidelines such as cc-ing -relevant maintainers and run ``./sripts/checkpatch.pl`` on your patch. +relevant maintainers and run ``./scripts/checkpatch.pl`` on your patch. For more details see ``Documentation/process/submitting-patches.rst`` Note - the list does not accept HTML or attachments, all emails must @@ -1082,21 +1087,21 @@ be formatted as plain text. Developing always goes hand in hand with debugging. First of all, you can always run UML under gdb and there will be a whole section later on on how to do that. That, however, is not the only way to -debug a linux kernel. Quite often adding tracing statements and/or +debug a Linux kernel. Quite often adding tracing statements and/or using UML specific approaches such as ptracing the UML kernel process are significantly more informative. Tracing UML ============= -When running UML consists of a main kernel thread and a number of +When running, UML consists of a main kernel thread and a number of helper threads. The ones of interest for tracing are NOT the ones that are already ptraced by UML as a part of its MMU emulation. These are usually the first three threads visible in a ps display. The one with the lowest PID number and using most CPU is usually the kernel thread. The other threads are the disk -(ubd) device helper thread and the sigio helper thread. +(ubd) device helper thread and the SIGIO helper thread. Running ptrace on this thread usually results in the following picture:: host$ strace -p 16566 @@ -1121,21 +1126,21 @@ Running ptrace on this thread usually results in the following picture:: --- SIGALRM {si_signo=SIGALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=1631716592, ptr=0x614204f0}} --- rt_sigreturn({mask=[PIPE]}) = -1 EINTR (Interrupted system call) -This is a typical picture from a mostly idle UML instance +This is a typical picture from a mostly idle UML instance. * UML interrupt controller uses epoll - this is UML waiting for IO interrupts: epoll_wait(4, [{EPOLLIN, {u32=3721159424, u64=3721159424}}], 64, 0) = 1 -* The sequence of ptrace calls is part of MMU emulation and runnin the - UML userspace +* The sequence of ptrace calls is part of MMU emulation and running the + UML userspace. * ``timer_settime`` is part of the UML high res timer subsystem mapping - timer requests from inside UML onto the host high resultion timers. + timer requests from inside UML onto the host high resolution timers. * ``clock_nanosleep`` is UML going into idle (similar to the way a PC will execute an ACPI idle). -As you can see UML will generate quite a bit of output even in idle.The output +As you can see UML will generate quite a bit of output even in idle. The output can be very informative when observing IO. It shows the actual IO calls, their arguments and returns values. @@ -1164,14 +1169,14 @@ in order to really leverage UML, one needs to write a piece of userspace code which maps driver concepts onto actual userspace host calls. -This forms the so called "user" portion of the driver. While it can +This forms the so-called "user" portion of the driver. While it can reuse a lot of kernel concepts, it is generally just another piece of userspace code. This portion needs some matching "kernel" code which resides inside the UML image and which implements the Linux kernel part. *Note: There are very few limitations in the way "kernel" and "user" interact*. -UML does not have a strictly defined kernel to host API. It does not +UML does not have a strictly defined kernel-to-host API. It does not try to emulate a specific architecture or bus. UML's "kernel" and "user" can share memory, code and interact as needed to implement whatever design the software developer has in mind. The only @@ -1180,7 +1185,7 @@ variables having the same names, the developer should be careful which includes and libraries they are trying to refer to. As a result a lot of userspace code consists of simple wrappers. -F.e. ``os_close_file()`` is just a wrapper around ``close()`` +E.g. ``os_close_file()`` is just a wrapper around ``close()`` which ensures that the userspace function close does not clash with similarly named function(s) in the kernel part. @@ -1188,7 +1193,7 @@ Security Considerations ----------------------- Drivers or any new functionality should default to not -accepting arbitrary filename, bpf code or other parameters +accepting arbitrary filename, bpf code or other parameters which can affect the host from inside the UML instance. For example, specifying the socket used for IPC communication between a driver and the host at the UML command line is OK diff --git a/Documentation/vm/damon/design.rst b/Documentation/vm/damon/design.rst index b05159c295f4..210f0f50efd8 100644 --- a/Documentation/vm/damon/design.rst +++ b/Documentation/vm/damon/design.rst @@ -35,13 +35,17 @@ two parts: 1. Identification of the monitoring target address range for the address space. 2. Access check of specific address range in the target space. -DAMON currently provides the implementation of the primitives for only the -virtual address spaces. Below two subsections describe how it works. +DAMON currently provides the implementations of the primitives for the physical +and virtual address spaces. Below two subsections describe how those work. VMA-based Target Address Range Construction ------------------------------------------- +This is only for the virtual address space primitives implementation. That for +the physical address space simply asks users to manually set the monitoring +target address ranges. + Only small parts in the super-huge virtual address space of the processes are mapped to the physical memory and accessed. Thus, tracking the unmapped address regions is just wasteful. However, because DAMON can deal with some @@ -71,15 +75,18 @@ to make a reasonable trade-off. Below shows this in detail:: PTE Accessed-bit Based Access Check ----------------------------------- -The implementation for the virtual address space uses PTE Accessed-bit for -basic access checks. It finds the relevant PTE Accessed bit from the address -by walking the page table for the target task of the address. In this way, the -implementation finds and clears the bit for next sampling target address and -checks whether the bit set again after one sampling period. This could disturb -other kernel subsystems using the Accessed bits, namely Idle page tracking and -the reclaim logic. To avoid such disturbances, DAMON makes it mutually -exclusive with Idle page tracking and uses ``PG_idle`` and ``PG_young`` page -flags to solve the conflict with the reclaim logic, as Idle page tracking does. +Both of the implementations for physical and virtual address spaces use PTE +Accessed-bit for basic access checks. Only one difference is the way of +finding the relevant PTE Accessed bit(s) from the address. While the +implementation for the virtual address walks the page table for the target task +of the address, the implementation for the physical address walks every page +table having a mapping to the address. In this way, the implementations find +and clear the bit(s) for next sampling target address and checks whether the +bit(s) set again after one sampling period. This could disturb other kernel +subsystems using the Accessed bits, namely Idle page tracking and the reclaim +logic. To avoid such disturbances, DAMON makes it mutually exclusive with Idle +page tracking and uses ``PG_idle`` and ``PG_young`` page flags to solve the +conflict with the reclaim logic, as Idle page tracking does. Address Space Independent Core Mechanisms diff --git a/Documentation/vm/damon/faq.rst b/Documentation/vm/damon/faq.rst index cb3d8b585a8b..11aea40eb328 100644 --- a/Documentation/vm/damon/faq.rst +++ b/Documentation/vm/damon/faq.rst @@ -36,10 +36,9 @@ constructions and actual access checks can be implemented and configured on the DAMON core by the users. In this way, DAMON users can monitor any address space with any access check technique. -Nonetheless, DAMON provides vma tracking and PTE Accessed bit check based +Nonetheless, DAMON provides vma/rmap tracking and PTE Accessed bit check based implementations of the address space dependent functions for the virtual memory -by default, for a reference and convenient use. In near future, we will -provide those for physical memory address space. +and the physical memory by default, for a reference and convenient use. Can I simply monitor page granularity? diff --git a/Documentation/vm/damon/index.rst b/Documentation/vm/damon/index.rst index a2858baf3bf1..48c0bbff98b2 100644 --- a/Documentation/vm/damon/index.rst +++ b/Documentation/vm/damon/index.rst @@ -27,4 +27,3 @@ workloads and systems. faq design api - plans diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst index a14c2938e7af..f2a59ed82ed3 100644 --- a/Documentation/vm/hmm.rst +++ b/Documentation/vm/hmm.rst @@ -360,7 +360,7 @@ between device driver specific code and shared common code: system memory page, locks the page with ``lock_page()``, and fills in the ``dst`` array entry with:: - dst[i] = migrate_pfn(page_to_pfn(dpage)) | MIGRATE_PFN_LOCKED; + dst[i] = migrate_pfn(page_to_pfn(dpage)); Now that the driver knows that this page is being migrated, it can invalidate device private MMU mappings and copy device private memory diff --git a/Documentation/vm/index.rst b/Documentation/vm/index.rst index b51f0d8992f8..6f5ffef4b716 100644 --- a/Documentation/vm/index.rst +++ b/Documentation/vm/index.rst @@ -3,27 +3,11 @@ Linux Memory Management Documentation ===================================== This is a collection of documents about the Linux memory management (mm) -subsystem. If you are looking for advice on simply allocating memory, -see the :ref:`memory_allocation`. - -User guides for MM features -=========================== - -The following documents provide guides for controlling and tuning -various features of the Linux memory management - -.. toctree:: - :maxdepth: 1 - - swap_numa - zswap - -Kernel developers MM documentation -================================== - -The below documents describe MM internals with different level of -details ranging from notes and mailing list responses to elaborate -descriptions of data structures and algorithms. +subsystem internals with different level of details ranging from notes and +mailing list responses for elaborating descriptions of data structures and +algorithms. If you are looking for advice on simply allocating memory, see the +:ref:`memory_allocation`. For controlling and tuning guides, see the +:doc:`admin guide <../admin-guide/mm/index>`. .. toctree:: :maxdepth: 1 diff --git a/Documentation/vm/page_migration.rst b/Documentation/vm/page_migration.rst index db9d7e5539cb..08810f549f70 100644 --- a/Documentation/vm/page_migration.rst +++ b/Documentation/vm/page_migration.rst @@ -205,7 +205,7 @@ which are function pointers of struct address_space_operations. In this function, the driver should put the isolated page back into its own data structure. -4. non-LRU movable page flags +Non-LRU movable page flags There are two page flags for supporting non-LRU movable page. diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 2175465c9bf2..9837fc8147dd 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -85,5 +85,26 @@ Usage cat /sys/kernel/debug/page_owner > page_owner_full.txt ./page_owner_sort page_owner_full.txt sorted_page_owner.txt + The general output of ``page_owner_full.txt`` is as follows: + + Page allocated via order XXX, ... + PFN XXX ... + // Detailed stack + + Page allocated via order XXX, ... + PFN XXX ... + // Detailed stack + + The ``page_owner_sort`` tool ignores ``PFN`` rows, puts the remaining rows + in buf, uses regexp to extract the page order value, counts the times + and pages of buf, and finally sorts them according to the times. + See the result about who allocated each page - in the ``sorted_page_owner.txt``. + in the ``sorted_page_owner.txt``. General output: + + XXX times, XXX pages: + Page allocated via order XXX, ... + // Detailed stack + + By default, ``page_owner_sort`` is sorted according to the times of buf. + If you want to sort by the pages nums of buf, use the ``-m`` parameter. diff --git a/Documentation/w1/masters/w1-gpio.rst b/Documentation/w1/masters/w1-gpio.rst index 18fdb7366372..15236605503b 100644 --- a/Documentation/w1/masters/w1-gpio.rst +++ b/Documentation/w1/masters/w1-gpio.rst @@ -11,7 +11,7 @@ Description GPIO 1-wire bus master driver. The driver uses the GPIO API to control the wire and the GPIO pin can be specified using GPIO machine descriptor tables. It is also possible to define the master using device tree, see -Documentation/devicetree/bindings/w1/w1-gpio.txt +Documentation/devicetree/bindings/w1/w1-gpio.yaml Example (mach-at91) diff --git a/Documentation/x86/entry_64.rst b/Documentation/x86/entry_64.rst index a48b3f6ebbe8..e433e08f7018 100644 --- a/Documentation/x86/entry_64.rst +++ b/Documentation/x86/entry_64.rst @@ -8,7 +8,7 @@ This file documents some of the kernel entries in arch/x86/entry/entry_64.S. A lot of this explanation is adapted from an email from Ingo Molnar: -http://lkml.kernel.org/r/<20110529191055.GC9835%40elte.hu> +https://lore.kernel.org/r/20110529191055.GC9835%40elte.hu The x86 architecture has quite a few different ways to jump into kernel code. Most of these entry points are registered in diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index 383048396336..f498f1d36cd3 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -37,3 +37,4 @@ x86-specific Documentation sgx features elf_auxvec + xstate diff --git a/Documentation/x86/orc-unwinder.rst b/Documentation/x86/orc-unwinder.rst index d811576c1f3e..9a66a88be765 100644 --- a/Documentation/x86/orc-unwinder.rst +++ b/Documentation/x86/orc-unwinder.rst @@ -177,6 +177,6 @@ brutal, unyielding efficiency. ORC stands for Oops Rewind Capability. -.. [1] https://lkml.kernel.org/r/20170602104048.jkkzssljsompjdwy@suse.de -.. [2] https://lkml.kernel.org/r/d2ca5435-6386-29b8-db87-7f227c2b713a@suse.cz +.. [1] https://lore.kernel.org/r/20170602104048.jkkzssljsompjdwy@suse.de +.. [2] https://lore.kernel.org/r/d2ca5435-6386-29b8-db87-7f227c2b713a@suse.cz .. [3] http://dustin.wikidot.com/half-orcs-and-orcs diff --git a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst index dd0ac96ff9ef..a608f667fb95 100644 --- a/Documentation/x86/sgx.rst +++ b/Documentation/x86/sgx.rst @@ -250,3 +250,38 @@ user wants to deploy SGX applications both on the host and in guests on the same machine, the user should reserve enough EPC (by taking out total virtual EPC size of all SGX VMs from the physical EPC size) for host SGX applications so they can run with acceptable performance. + +Architectural behavior is to restore all EPC pages to an uninitialized +state also after a guest reboot. Because this state can be reached only +through the privileged ``ENCLS[EREMOVE]`` instruction, ``/dev/sgx_vepc`` +provides the ``SGX_IOC_VEPC_REMOVE_ALL`` ioctl to execute the instruction +on all pages in the virtual EPC. + +``EREMOVE`` can fail for three reasons. Userspace must pay attention +to expected failures and handle them as follows: + +1. Page removal will always fail when any thread is running in the + enclave to which the page belongs. In this case the ioctl will + return ``EBUSY`` independent of whether it has successfully removed + some pages; userspace can avoid these failures by preventing execution + of any vcpu which maps the virtual EPC. + +2. Page removal will cause a general protection fault if two calls to + ``EREMOVE`` happen concurrently for pages that refer to the same + "SECS" metadata pages. This can happen if there are concurrent + invocations to ``SGX_IOC_VEPC_REMOVE_ALL``, or if a ``/dev/sgx_vepc`` + file descriptor in the guest is closed at the same time as + ``SGX_IOC_VEPC_REMOVE_ALL``; it will also be reported as ``EBUSY``. + This can be avoided in userspace by serializing calls to the ioctl() + and to close(), but in general it should not be a problem. + +3. Finally, page removal will fail for SECS metadata pages which still + have child pages. Child pages can be removed by executing + ``SGX_IOC_VEPC_REMOVE_ALL`` on all ``/dev/sgx_vepc`` file descriptors + mapped into the guest. This means that the ioctl() must be called + twice: an initial set of calls to remove child pages and a subsequent + set of calls to remove SECS pages. The second set of calls is only + required for those mappings that returned a nonzero value from the + first call. It indicates a bug in the kernel or the userspace client + if any of the second round of ``SGX_IOC_VEPC_REMOVE_ALL`` calls has + a return code other than 0. diff --git a/Documentation/x86/x86_64/machinecheck.rst b/Documentation/x86/x86_64/machinecheck.rst index b402e04bee60..cea12ee97200 100644 --- a/Documentation/x86/x86_64/machinecheck.rst +++ b/Documentation/x86/x86_64/machinecheck.rst @@ -21,60 +21,8 @@ from /dev/mcelog. Normally mcelog should be run regularly from a cronjob. Each CPU has a directory in /sys/devices/system/machinecheck/machinecheckN (N = CPU number). -The directory contains some configurable entries: - -bankNctl - (N bank number) - - 64bit Hex bitmask enabling/disabling specific subevents for bank N - When a bit in the bitmask is zero then the respective - subevent will not be reported. - By default all events are enabled. - Note that BIOS maintain another mask to disable specific events - per bank. This is not visible here - -The following entries appear for each CPU, but they are truly shared -between all CPUs. - -check_interval - How often to poll for corrected machine check errors, in seconds - (Note output is hexadecimal). Default 5 minutes. When the poller - finds MCEs it triggers an exponential speedup (poll more often) on - the polling interval. When the poller stops finding MCEs, it - triggers an exponential backoff (poll less often) on the polling - interval. The check_interval variable is both the initial and - maximum polling interval. 0 means no polling for corrected machine - check errors (but some corrected errors might be still reported - in other ways) - -tolerant - Tolerance level. When a machine check exception occurs for a non - corrected machine check the kernel can take different actions. - Since machine check exceptions can happen any time it is sometimes - risky for the kernel to kill a process because it defies - normal kernel locking rules. The tolerance level configures - how hard the kernel tries to recover even at some risk of - deadlock. Higher tolerant values trade potentially better uptime - with the risk of a crash or even corruption (for tolerant >= 3). - - 0: always panic on uncorrected errors, log corrected errors - 1: panic or SIGBUS on uncorrected errors, log corrected errors - 2: SIGBUS or log uncorrected errors, log corrected errors - 3: never panic or SIGBUS, log all errors (for testing only) - - Default: 1 - - Note this only makes a difference if the CPU allows recovery - from a machine check exception. Current x86 CPUs generally do not. - -trigger - Program to run when a machine check event is detected. - This is an alternative to running mcelog regularly from cron - and allows to detect events faster. -monarch_timeout - How long to wait for the other CPUs to machine check too on a - exception. 0 to disable waiting for other CPUs. - Unit: us +The directory contains some configurable entries. See +Documentation/ABI/testing/sysfs-mce for more details. TBD document entries for AMD threshold interrupt configuration diff --git a/Documentation/x86/xstate.rst b/Documentation/x86/xstate.rst new file mode 100644 index 000000000000..5cec7fb558d6 --- /dev/null +++ b/Documentation/x86/xstate.rst @@ -0,0 +1,74 @@ +Using XSTATE features in user space applications +================================================ + +The x86 architecture supports floating-point extensions which are +enumerated via CPUID. Applications consult CPUID and use XGETBV to +evaluate which features have been enabled by the kernel XCR0. + +Up to AVX-512 and PKRU states, these features are automatically enabled by +the kernel if available. Features like AMX TILE_DATA (XSTATE component 18) +are enabled by XCR0 as well, but the first use of related instruction is +trapped by the kernel because by default the required large XSTATE buffers +are not allocated automatically. + +Using dynamically enabled XSTATE features in user space applications +-------------------------------------------------------------------- + +The kernel provides an arch_prctl(2) based mechanism for applications to +request the usage of such features. The arch_prctl(2) options related to +this are: + +-ARCH_GET_XCOMP_SUPP + + arch_prctl(ARCH_GET_XCOMP_SUPP, &features); + + ARCH_GET_XCOMP_SUPP stores the supported features in userspace storage of + type uint64_t. The second argument is a pointer to that storage. + +-ARCH_GET_XCOMP_PERM + + arch_prctl(ARCH_GET_XCOMP_PERM, &features); + + ARCH_GET_XCOMP_PERM stores the features for which the userspace process + has permission in userspace storage of type uint64_t. The second argument + is a pointer to that storage. + +-ARCH_REQ_XCOMP_PERM + + arch_prctl(ARCH_REQ_XCOMP_PERM, feature_nr); + + ARCH_REQ_XCOMP_PERM allows to request permission for a dynamically enabled + feature or a feature set. A feature set can be mapped to a facility, e.g. + AMX, and can require one or more XSTATE components to be enabled. + + The feature argument is the number of the highest XSTATE component which + is required for a facility to work. + +When requesting permission for a feature, the kernel checks the +availability. The kernel ensures that sigaltstacks in the process's tasks +are large enough to accommodate the resulting large signal frame. It +enforces this both during ARCH_REQ_XCOMP_SUPP and during any subsequent +sigaltstack(2) calls. If an installed sigaltstack is smaller than the +resulting sigframe size, ARCH_REQ_XCOMP_SUPP results in -ENOSUPP. Also, +sigaltstack(2) results in -ENOMEM if the requested altstack is too small +for the permitted features. + +Permission, when granted, is valid per process. Permissions are inherited +on fork(2) and cleared on exec(3). + +The first use of an instruction related to a dynamically enabled feature is +trapped by the kernel. The trap handler checks whether the process has +permission to use the feature. If the process has no permission then the +kernel sends SIGILL to the application. If the process has permission then +the handler allocates a larger xstate buffer for the task so the large +state can be context switched. In the unlikely cases that the allocation +fails, the kernel sends SIGSEGV. + +Dynamic features in signal frames +--------------------------------- + +Dynamcally enabled features are not written to the signal frame upon signal +entry if the feature is in its initial configuration. This differs from +non-dynamic features which are always written regardless of their +configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV +field to determine if a features was written. |