Merge tag 'media/v5.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull more media updates from Mauro Carvalho Chehab: - a set of atomisp patches. They remove several abstraction layers, and fixes clang and gcc warnings (that were hidden via some macros that were disabling 4 or 5 types of warnings there). There are also some important fixes and sensor auto-detection on newer BIOSes via ACPI _DCM tables. - some fixes * tag 'media/v5.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (95 commits) media: rkvdec: Fix H264 scaling list order media: v4l2-ctrls: Unset correct HEVC loop filter flag media: videobuf2-dma-contig: fix bad kfree in vb2_dma_contig_clear_max_seg_size media: v4l2-subdev.rst: correct information about v4l2 events media: s5p-mfc: Properly handle dma_parms for the allocated devices media: medium: cec: Make MEDIA_CEC_SUPPORT default to n if !MEDIA_SUPPORT media: cedrus: Implement runtime PM media: cedrus: Program output format during each run media: atomisp: improve ACPI/DMI detection logs media: Revert "media: atomisp: add Asus Transform T101HA ACPI vars" media: Revert "media: atomisp: Add some ACPI detection info" media: atomisp: improve sensor detection code to use _DSM table media: atomisp: get rid of an iomem abstraction layer media: atomisp: get rid of a string_support.h abstraction layer media: atomisp: use strscpy() instead of less secure variants media: atomisp: set DFS to MAX if sensor doesn't report fps media: atomisp: use different dfs failed messages media: atomisp: change the detection of ISP2401 at runtime media: atomisp: use macros from intel-family.h media: atomisp: don't set hpll_freq twice with different values ...
diff --git a/.clang-format b/.clang-format index 6ec5558..a0a9608 100644 --- a/.clang-format +++ b/.clang-format
@@ -80,6 +80,7 @@ - 'ax25_uid_for_each' - '__bio_for_each_bvec' - 'bio_for_each_bvec' + - 'bio_for_each_bvec_all' - 'bio_for_each_integrity_vec' - '__bio_for_each_segment' - 'bio_for_each_segment' @@ -142,10 +143,13 @@ - 'for_each_card_auxs' - 'for_each_card_auxs_safe' - 'for_each_card_components' + - 'for_each_card_dapms' - 'for_each_card_pre_auxs' - 'for_each_card_prelinks' - 'for_each_card_rtds' - 'for_each_card_rtds_safe' + - 'for_each_card_widgets' + - 'for_each_card_widgets_safe' - 'for_each_cgroup_storage_type' - 'for_each_child_of_node' - 'for_each_clear_bit' @@ -160,6 +164,7 @@ - 'for_each_cpu_and' - 'for_each_cpu_not' - 'for_each_cpu_wrap' + - 'for_each_dapm_widgets' - 'for_each_dev_addr' - 'for_each_dev_scope' - 'for_each_displayid_db' @@ -170,7 +175,6 @@ - 'for_each_dpcm_fe' - 'for_each_drhd_unit' - 'for_each_dss_dev' - - 'for_each_efi_handle' - 'for_each_efi_memory_desc' - 'for_each_efi_memory_desc_in_map' - 'for_each_element' @@ -191,6 +195,7 @@ - 'for_each_ip_tunnel_rcu' - 'for_each_irq_nr' - 'for_each_link_codecs' + - 'for_each_link_cpus' - 'for_each_link_platforms' - 'for_each_lru' - 'for_each_matching_node' @@ -250,6 +255,7 @@ - 'for_each_pci_bridge' - 'for_each_pci_dev' - 'for_each_pci_msi_entry' + - 'for_each_pcm_streams' - 'for_each_populated_zone' - 'for_each_possible_cpu' - 'for_each_present_cpu' @@ -260,9 +266,12 @@ - 'for_each_property_of_node' - 'for_each_registered_fb' - 'for_each_reserved_mem_region' - - 'for_each_rtd_codec_dai' - - 'for_each_rtd_codec_dai_rollback' + - 'for_each_rtd_codec_dais' + - 'for_each_rtd_codec_dais_rollback' - 'for_each_rtd_components' + - 'for_each_rtd_cpu_dais' + - 'for_each_rtd_cpu_dais_rollback' + - 'for_each_rtd_dais' - 'for_each_set_bit' - 'for_each_set_bit_from' - 'for_each_set_clump8' @@ -334,6 +343,7 @@ - 'klp_for_each_object' - 'klp_for_each_object_safe' - 'klp_for_each_object_static' + - 'kunit_suite_for_each_test_case' - 'kvm_for_each_memslot' - 'kvm_for_each_vcpu' - 'list_for_each' @@ -387,6 +397,7 @@ - 'of_property_for_each_string' - 'of_property_for_each_u32' - 'pci_bus_for_each_resource' + - 'pcm_for_each_format' - 'ping_portaddr_for_each_entry' - 'plist_for_each' - 'plist_for_each_continue' @@ -482,7 +493,7 @@ MacroBlockBegin: '' MacroBlockEnd: '' MaxEmptyLinesToKeep: 1 -NamespaceIndentation: Inner +NamespaceIndentation: None #ObjCBinPackProtocolList: Auto # Unknown to clang-format-5.0 ObjCBlockIndentWidth: 8 ObjCSpaceAfterProperty: true
diff --git a/.gitignore b/.gitignore index 2258e90..87b9dd8 100644 --- a/.gitignore +++ b/.gitignore
@@ -56,6 +56,7 @@ /linux /vmlinux /vmlinux.32 +/vmlinux.symvers /vmlinux-gdb.py /vmlinuz /System.map
diff --git a/.mailmap b/.mailmap index db3754a4..c69d9c7 100644 --- a/.mailmap +++ b/.mailmap
@@ -152,6 +152,7 @@ Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Leon Romanovsky <leon@kernel.org> <leon@leon.nu> Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com> +Leonardo Bras <leobras.c@gmail.com> <leonardo@linux.ibm.com> Leonid I Ananiev <leonid.i.ananiev@intel.com> Linas Vepstas <linas@austin.ibm.com> Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de> @@ -234,7 +235,9 @@ Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Randy Dunlap <rdunlap@infradead.org> <rdunlap@xenotime.net> Rémi Denis-Courmont <rdenis@simphalempin.com> -Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> +Ricardo Ribalda <ribalda@kernel.org> <ricardo.ribalda@gmail.com> +Ricardo Ribalda <ribalda@kernel.org> <ricardo@ribalda.com> +Ricardo Ribalda <ribalda@kernel.org> Ricardo Ribalda Delgado <ribalda@kernel.org> Ross Zwisler <zwisler@kernel.org> <ross.zwisler@linux.intel.com> Rudolf Marek <R.Marek@sh.cvut.cz> Rui Saraiva <rmps@joel.ist.utl.pt> @@ -288,6 +291,8 @@ Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@parallels.com> Takashi YOSHII <takashi.yoshii.zj@renesas.com> Will Deacon <will@kernel.org> <will.deacon@arm.com> +Wolfram Sang <wsa@kernel.org> <wsa@the-dreams.de> +Wolfram Sang <wsa@kernel.org> <w.sang@pengutronix.de> Yakir Yang <kuankuan.y@gmail.com> <ykk@rock-chips.com> Yusuke Goda <goda.yusuke@renesas.com> Gustavo Padovan <gustavo@las.ic.unicamp.br>
diff --git a/CREDITS b/CREDITS index 032b599..0787b5872 100644 --- a/CREDITS +++ b/CREDITS
@@ -3104,14 +3104,16 @@ D: Generic Z8530 driver, AX.25 DAMA slave implementation D: Several AX.25 hacks -N: Ricardo Ribalda Delgado -E: ricardo.ribalda@gmail.com +N: Ricardo Ribalda +E: ribalda@kernel.org W: http://ribalda.com D: PLX USB338x driver D: PCA9634 driver D: Option GTM671WFS D: Fintek F81216A D: AD5761 iio driver +D: TI DAC7612 driver +D: Sony IMX214 driver D: Various kernel hacks S: Qtechnology A/S S: Valby Langgade 142
diff --git a/Documentation/ABI/obsolete/sysfs-cpuidle b/Documentation/ABI/obsolete/sysfs-cpuidle new file mode 100644 index 0000000..e398fb5 --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-cpuidle
@@ -0,0 +1,9 @@ +What: /sys/devices/system/cpu/cpuidle/current_governor_ro +Date: April, 2020 +Contact: linux-pm@vger.kernel.org +Description: + current_governor_ro shows current using cpuidle governor, but read only. + with the update that cpuidle governor can be changed at runtime in default, + both current_governor and current_governor_ro co-exist under + /sys/devices/system/cpu/cpuidle/ file, it's duplicate so make + current_governor_ro obselete.
diff --git a/Documentation/ABI/obsolete/sysfs-driver-intel_pmc_bxt b/Documentation/ABI/obsolete/sysfs-driver-intel_pmc_bxt new file mode 100644 index 0000000..39d5659 --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-driver-intel_pmc_bxt
@@ -0,0 +1,22 @@ +These files allow sending arbitrary IPC commands to the PMC/SCU which +may be dangerous. These will be removed eventually and should not be +used in any new applications. + +What: /sys/bus/platform/devices/INT34D2:00/simplecmd +Date: Jun 2015 +KernelVersion: 4.1 +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> +Description: This interface allows userspace to send an arbitrary + IPC command to the PMC/SCU. + + Format: %d %d where first number is command and + second number is subcommand. + +What: /sys/bus/platform/devices/INT34D2:00/northpeak +Date: Jun 2015 +KernelVersion: 4.1 +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> +Description: This interface allows userspace to enable and disable + Northpeak through the PMC/SCU. + + Format: %u.
diff --git a/Documentation/ABI/stable/sysfs-devices-node b/Documentation/ABI/stable/sysfs-devices-node index df8413c..484fc04 100644 --- a/Documentation/ABI/stable/sysfs-devices-node +++ b/Documentation/ABI/stable/sysfs-devices-node
@@ -54,7 +54,7 @@ Contact: Linux Memory Management list <linux-mm@kvack.org> Description: Provides information about the node's distribution and memory - utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.txt + utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.rst What: /sys/devices/system/node/nodeX/numastat Date: October 2002
diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd index f4be46cc..b5bebf6 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd
@@ -1,3 +1,9 @@ +What: sys/bus/dsa/devices/dsa<m>/version +Date: Apr 15, 2020 +KernelVersion: 5.8.0 +Contact: dmaengine@vger.kernel.org +Description: The hardware version number. + What: sys/bus/dsa/devices/dsa<m>/cdev_major Date: Oct 25, 2019 KernelVersion: 5.6.0
diff --git a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp new file mode 100644 index 0000000..00fa04c --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp
@@ -0,0 +1,103 @@ +What: /sys/devices/platform/firmware\:zynqmp-firmware/ggs* +Date: March 2020 +KernelVersion: 5.6 +Contact: "Jolly Shah" <jollys@xilinx.com> +Description: + Read/Write PMU global general storage register value, + GLOBAL_GEN_STORAGE{0:3}. + Global general storage register that can be used + by system to pass information between masters. + + The register is reset during system or power-on + resets. Three registers are used by the FSBL and + other Xilinx software products: GLOBAL_GEN_STORAGE{4:6}. + + Usage: + # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0 + # echo <value> > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0 + + Example: + # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0 + # echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0 + +Users: Xilinx + +What: /sys/devices/platform/firmware\:zynqmp-firmware/pggs* +Date: March 2020 +KernelVersion: 5.6 +Contact: "Jolly Shah" <jollys@xilinx.com> +Description: + Read/Write PMU persistent global general storage register + value, PERS_GLOB_GEN_STORAGE{0:3}. + Persistent global general storage register that + can be used by system to pass information between + masters. + + This register is only reset by the power-on reset + and maintains its value through a system reset. + Four registers are used by the FSBL and other Xilinx + software products: PERS_GLOB_GEN_STORAGE{4:7}. + Register is reset only by a POR reset. + + Usage: + # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0 + # echo <value> > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0 + + Example: + # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0 + # echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0 + +Users: Xilinx + +What: /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope +Date: March 2020 +KernelVersion: 5.6 +Contact: "Jolly Shah" <jollys@xilinx.com> +Description: + This sysfs interface allows to set the shutdown scope for the + next shutdown request. When the next shutdown is performed, the + platform specific portion of PSCI-system_off can use the chosen + shutdown scope. + + Following are available shutdown scopes(subtypes): + + subsystem: Only the APU along with all of its peripherals + not used by other processing units will be + shut down. This may result in the FPD power + domain being shut down provided that no other + processing unit uses FPD peripherals or DRAM. + ps_only: The complete PS will be shut down, including the + RPU, PMU, etc. Only the PL domain (FPGA) + remains untouched. + system: The complete system/device is shut down. + + Usage: + # cat /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope + # echo <scope> > /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope + + Example: + # cat /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope + # echo "subsystem" > /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope + +Users: Xilinx + +What: /sys/devices/platform/firmware\:zynqmp-firmware/health_status +Date: March 2020 +KernelVersion: 5.6 +Contact: "Jolly Shah" <jollys@xilinx.com> +Description: + This sysfs interface allows to set the health status. If PMUFW + is compiled with CHECK_HEALTHY_BOOT, it will check the healthy + bit on FPD WDT expiration. If healthy bit is set by a user + application running in Linux, PMUFW will do APU only restart. If + healthy bit is not set during FPD WDT expiration, PMUFW will do + system restart. + + Usage: + Set healthy bit + # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status + + Unset healthy bit + # echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status + +Users: Xilinx
diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index a73601c..f6d9c2a 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs
@@ -8,6 +8,16 @@ only when the IOMMU is disabled. The acceptable value is a string that starts with "0x" +What: /sys/kernel/debug/habanalabs/hl<n>/clk_gate +Date: May 2020 +KernelVersion: 5.8 +Contact: oded.gabbay@gmail.com +Description: Allow the root user to disable/enable in runtime the clock + gating mechanism in Gaudi. Due to how Gaudi is built, the + clock gating needs to be disabled in order to access the + registers of the TPC and MME engines. This is sometimes needed + during debug by the user and hence the user needs this option + What: /sys/kernel/debug/habanalabs/hl<n>/command_buffers Date: Jan 2019 KernelVersion: 5.1 @@ -150,3 +160,10 @@ Contact: oded.gabbay@gmail.com Description: Displays a list with information about all the active virtual address mappings per ASID + +What: /sys/kernel/debug/habanalabs/hl<n>/stop_on_err +Date: Mar 2020 +KernelVersion: 5.6 +Contact: oded.gabbay@gmail.com +Description: Sets the stop-on_error option for the device engines. Value of + "0" is for disable, otherwise enable.
diff --git a/Documentation/ABI/testing/debugfs-hisi-hpre b/Documentation/ABI/testing/debugfs-hisi-hpre index ec4a79e..b4be5f1 100644 --- a/Documentation/ABI/testing/debugfs-hisi-hpre +++ b/Documentation/ABI/testing/debugfs-hisi-hpre
@@ -33,7 +33,7 @@ Description: Dump debug registers from the HPRE. Only available for PF. -What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/qm_regs +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/regs Date: Sep 2019 Contact: linux-crypto@vger.kernel.org Description: Dump debug registers from the QM. @@ -44,14 +44,97 @@ Date: Sep 2019 Contact: linux-crypto@vger.kernel.org Description: One QM may contain multiple queues. Select specific queue to - show its debug registers in above qm_regs. + show its debug registers in above regs. Only available for PF. What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/clear_enable Date: Sep 2019 Contact: linux-crypto@vger.kernel.org -Description: QM debug registers(qm_regs) read clear control. 1 means enable +Description: QM debug registers(regs) read clear control. 1 means enable register read clear, otherwise 0. Writing to this file has no functional effect, only enable or disable counters clear after reading of these registers. Only available for PF. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/err_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of invalid interrupts for + QM task completion. + Available for both PF and VF, and take no other effect on HPRE. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/aeq_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of QM async event queue interrupts. + Available for both PF and VF, and take no other effect on HPRE. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/abnormal_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of interrupts for QM abnormal event. + Available for both PF and VF, and take no other effect on HPRE. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/create_qp_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of queue allocation errors. + Available for both PF and VF, and take no other effect on HPRE. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/mb_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of failed QM mailbox commands. + Available for both PF and VF, and take no other effect on HPRE. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/status +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the status of the QM. + Four states: initiated, started, stopped and closed. + Available for both PF and VF, and take no other effect on HPRE. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of sent requests. + Available for both PF and VF, and take no other effect on HPRE. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/recv_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of received requests. + Available for both PF and VF, and take no other effect on HPRE. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_busy_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of requests sent + with returning busy. + Available for both PF and VF, and take no other effect on HPRE. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_fail_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of completed but error requests. + Available for both PF and VF, and take no other effect on HPRE. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/invalid_req_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of invalid requests being received. + Available for both PF and VF, and take no other effect on HPRE. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/overtime_thrhld +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Set the threshold time for counting the request which is + processed longer than the threshold. + 0: disable(default), 1: 1 microsecond. + Available for both PF and VF, and take no other effect on HPRE. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/over_thrhld_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of time out requests. + Available for both PF and VF, and take no other effect on HPRE.
diff --git a/Documentation/ABI/testing/debugfs-hisi-sec b/Documentation/ABI/testing/debugfs-hisi-sec index 06adb89..85feb44 100644 --- a/Documentation/ABI/testing/debugfs-hisi-sec +++ b/Documentation/ABI/testing/debugfs-hisi-sec
@@ -1,10 +1,4 @@ -What: /sys/kernel/debug/hisi_sec/<bdf>/sec_dfx -Date: Oct 2019 -Contact: linux-crypto@vger.kernel.org -Description: Dump the debug registers of SEC cores. - Only available for PF. - -What: /sys/kernel/debug/hisi_sec/<bdf>/clear_enable +What: /sys/kernel/debug/hisi_sec2/<bdf>/clear_enable Date: Oct 2019 Contact: linux-crypto@vger.kernel.org Description: Enabling/disabling of clear action after reading @@ -12,7 +6,7 @@ 0: disable, 1: enable. Only available for PF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec/<bdf>/current_qm +What: /sys/kernel/debug/hisi_sec2/<bdf>/current_qm Date: Oct 2019 Contact: linux-crypto@vger.kernel.org Description: One SEC controller has one PF and multiple VFs, each function @@ -20,24 +14,100 @@ qm refers to. Only available for PF. -What: /sys/kernel/debug/hisi_sec/<bdf>/qm/qm_regs +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/qm_regs Date: Oct 2019 Contact: linux-crypto@vger.kernel.org Description: Dump of QM related debug registers. Available for PF and VF in host. VF in guest currently only has one debug register. -What: /sys/kernel/debug/hisi_sec/<bdf>/qm/current_q +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/current_q Date: Oct 2019 Contact: linux-crypto@vger.kernel.org Description: One QM of SEC may contain multiple queues. Select specific - queue to show its debug registers in above 'qm_regs'. + queue to show its debug registers in above 'regs'. Only available for PF. -What: /sys/kernel/debug/hisi_sec/<bdf>/qm/clear_enable +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/clear_enable Date: Oct 2019 Contact: linux-crypto@vger.kernel.org Description: Enabling/disabling of clear action after reading the SEC's QM debug registers. 0: disable, 1: enable. Only available for PF, and take no other effect on SEC. + +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/err_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of invalid interrupts for + QM task completion. + Available for both PF and VF, and take no other effect on SEC. + +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/aeq_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of QM async event queue interrupts. + Available for both PF and VF, and take no other effect on SEC. + +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/abnormal_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of interrupts for QM abnormal event. + Available for both PF and VF, and take no other effect on SEC. + +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/create_qp_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of queue allocation errors. + Available for both PF and VF, and take no other effect on SEC. + +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/mb_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of failed QM mailbox commands. + Available for both PF and VF, and take no other effect on SEC. + +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/status +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the status of the QM. + Four states: initiated, started, stopped and closed. + Available for both PF and VF, and take no other effect on SEC. + +What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of sent requests. + Available for both PF and VF, and take no other effect on SEC. + +What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/recv_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of received requests. + Available for both PF and VF, and take no other effect on SEC. + +What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_busy_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of requests sent with returning busy. + Available for both PF and VF, and take no other effect on SEC. + +What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/err_bd_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of BD type error requests + to be received. + Available for both PF and VF, and take no other effect on SEC. + +What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/invalid_req_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of invalid requests being received. + Available for both PF and VF, and take no other effect on SEC. + +What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/done_flag_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of completed but marked error requests + to be received. + Available for both PF and VF, and take no other effect on SEC.
diff --git a/Documentation/ABI/testing/debugfs-hisi-zip b/Documentation/ABI/testing/debugfs-hisi-zip index a7c63e6..3034a2b 100644 --- a/Documentation/ABI/testing/debugfs-hisi-zip +++ b/Documentation/ABI/testing/debugfs-hisi-zip
@@ -26,7 +26,7 @@ has a QM. Select the QM which below qm refers to. Only available for PF. -What: /sys/kernel/debug/hisi_zip/<bdf>/qm/qm_regs +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/regs Date: Nov 2018 Contact: linux-crypto@vger.kernel.org Description: Dump of QM related debug registers. @@ -37,14 +37,78 @@ Date: Nov 2018 Contact: linux-crypto@vger.kernel.org Description: One QM may contain multiple queues. Select specific queue to - show its debug registers in above qm_regs. + show its debug registers in above regs. Only available for PF. What: /sys/kernel/debug/hisi_zip/<bdf>/qm/clear_enable Date: Nov 2018 Contact: linux-crypto@vger.kernel.org -Description: QM debug registers(qm_regs) read clear control. 1 means enable +Description: QM debug registers(regs) read clear control. 1 means enable register read clear, otherwise 0. Writing to this file has no functional effect, only enable or disable counters clear after reading of these registers. Only available for PF. + +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/err_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of invalid interrupts for + QM task completion. + Available for both PF and VF, and take no other effect on ZIP. + +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/aeq_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of QM async event queue interrupts. + Available for both PF and VF, and take no other effect on ZIP. + +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/abnormal_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of interrupts for QM abnormal event. + Available for both PF and VF, and take no other effect on ZIP. + +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/create_qp_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of queue allocation errors. + Available for both PF and VF, and take no other effect on ZIP. + +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/mb_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of failed QM mailbox commands. + Available for both PF and VF, and take no other effect on ZIP. + +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/status +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the status of the QM. + Four states: initiated, started, stopped and closed. + Available for both PF and VF, and take no other effect on ZIP. + +What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of sent requests. + Available for both PF and VF, and take no other effect on ZIP. + +What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/recv_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of received requests. + Available for both PF and VF, and take no other effect on ZIP. + +What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_busy_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of requests received + with returning busy. + Available for both PF and VF, and take no other effect on ZIP. + +What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/err_bd_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of BD type error requests + to be received. + Available for both PF and VF, and take no other effect on ZIP.
diff --git a/Documentation/ABI/testing/dev-kmsg b/Documentation/ABI/testing/dev-kmsg index f307506e..1e6c28b 100644 --- a/Documentation/ABI/testing/dev-kmsg +++ b/Documentation/ABI/testing/dev-kmsg
@@ -56,6 +56,11 @@ seek after the last record available at the time the last SYSLOG_ACTION_CLEAR was issued. + Due to the record nature of this interface with a "read all" + behavior and the specific positions each seek operation sets, + SEEK_CUR is not supported, returning -ESPIPE (invalid seek) to + errno whenever requested. + The output format consists of a prefix carrying the syslog prefix including priority and facility, the 64 bit message sequence number and the monotonic timestamp in microseconds,
diff --git a/Documentation/ABI/testing/procfs-smaps_rollup b/Documentation/ABI/testing/procfs-smaps_rollup index 274df44..0469781 100644 --- a/Documentation/ABI/testing/procfs-smaps_rollup +++ b/Documentation/ABI/testing/procfs-smaps_rollup
@@ -11,7 +11,7 @@ Additionally, the fields Pss_Anon, Pss_File and Pss_Shmem are not present in /proc/pid/smaps. These fields represent the sum of the Pss field of each type (anon, file, shmem). - For more details, see Documentation/filesystems/proc.txt + For more details, see Documentation/filesystems/proc.rst and the procfs man page. Typical output looks like this:
diff --git a/Documentation/ABI/testing/sysfs-block-rnbd b/Documentation/ABI/testing/sysfs-block-rnbd new file mode 100644 index 0000000..8f070b4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-block-rnbd
@@ -0,0 +1,46 @@ +What: /sys/block/rnbd<N>/rnbd/unmap_device +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: To unmap a volume, "normal" or "force" has to be written to: + /sys/block/rnbd<N>/rnbd/unmap_device + + When "normal" is used, the operation will fail with EBUSY if any process + is using the device. When "force" is used, the device is also unmapped + when device is in use. All I/Os that are in progress will fail. + + Example: + + # echo "normal" > /sys/block/rnbd0/rnbd/unmap_device + +What: /sys/block/rnbd<N>/rnbd/state +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: The file contains the current state of the block device. The state file + returns "open" when the device is successfully mapped from the server + and accepting I/O requests. When the connection to the server gets + disconnected in case of an error (e.g. link failure), the state file + returns "closed" and all I/O requests submitted to it will fail with -EIO. + +What: /sys/block/rnbd<N>/rnbd/session +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: RNBD uses RTRS session to transport the data between client and + server. The entry "session" contains the name of the session, that + was used to establish the RTRS session. It's the same name that + was passed as server parameter to the map_device entry. + +What: /sys/block/rnbd<N>/rnbd/mapping_path +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Contains the path that was passed as "device_path" to the map_device + operation. + +What: /sys/block/rnbd<N>/rnbd/access_mode +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Contains the device access mode: ro, rw or migration.
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-dfl_fme b/Documentation/ABI/testing/sysfs-bus-event_source-devices-dfl_fme new file mode 100644 index 0000000..c9278a3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-dfl_fme
@@ -0,0 +1,104 @@ +What: /sys/bus/event_source/devices/dfl_fmeX/format +Date: April 2020 +KernelVersion: 5.8 +Contact: Wu Hao <hao.wu@intel.com> +Description: Read-only. Attribute group to describe the magic bits + that go into perf_event_attr.config for a particular pmu. + (See ABI/testing/sysfs-bus-event_source-devices-format). + + Each attribute under this group defines a bit range of the + perf_event_attr.config. All supported attributes are listed + below. + + event = "config:0-11" - event ID + evtype = "config:12-15" - event type + portid = "config:16-23" - event source + + For example, + + fab_mmio_read = "event=0x06,evtype=0x02,portid=0xff" + + It shows this fab_mmio_read is a fabric type (0x02) event with + 0x06 local event id for overall monitoring (portid=0xff). + +What: /sys/bus/event_source/devices/dfl_fmeX/cpumask +Date: April 2020 +KernelVersion: 5.8 +Contact: Wu Hao <hao.wu@intel.com> +Description: Read-only. This file always returns cpu which the PMU is bound + for access to all fme pmu performance monitoring events. + +What: /sys/bus/event_source/devices/dfl_fmeX/events +Date: April 2020 +KernelVersion: 5.8 +Contact: Wu Hao <hao.wu@intel.com> +Description: Read-only. Attribute group to describe performance monitoring + events specific to fme. Each attribute in this group describes + a single performance monitoring event supported by this fme pmu. + The name of the file is the name of the event. + (See ABI/testing/sysfs-bus-event_source-devices-events). + + All supported performance monitoring events are listed below. + + Basic events (evtype=0x00) + + clock = "event=0x00,evtype=0x00,portid=0xff" + + Cache events (evtype=0x01) + + cache_read_hit = "event=0x00,evtype=0x01,portid=0xff" + cache_read_miss = "event=0x01,evtype=0x01,portid=0xff" + cache_write_hit = "event=0x02,evtype=0x01,portid=0xff" + cache_write_miss = "event=0x03,evtype=0x01,portid=0xff" + cache_hold_request = "event=0x05,evtype=0x01,portid=0xff" + cache_data_write_port_contention = + "event=0x06,evtype=0x01,portid=0xff" + cache_tag_write_port_contention = + "event=0x07,evtype=0x01,portid=0xff" + cache_tx_req_stall = "event=0x08,evtype=0x01,portid=0xff" + cache_rx_req_stall = "event=0x09,evtype=0x01,portid=0xff" + cache_eviction = "event=0x0a,evtype=0x01,portid=0xff" + + Fabric events (evtype=0x02) + + fab_pcie0_read = "event=0x00,evtype=0x02,portid=0xff" + fab_pcie0_write = "event=0x01,evtype=0x02,portid=0xff" + fab_pcie1_read = "event=0x02,evtype=0x02,portid=0xff" + fab_pcie1_write = "event=0x03,evtype=0x02,portid=0xff" + fab_upi_read = "event=0x04,evtype=0x02,portid=0xff" + fab_upi_write = "event=0x05,evtype=0x02,portid=0xff" + fab_mmio_read = "event=0x06,evtype=0x02,portid=0xff" + fab_mmio_write = "event=0x07,evtype=0x02,portid=0xff" + fab_port_pcie0_read = "event=0x00,evtype=0x02,portid=?" + fab_port_pcie0_write = "event=0x01,evtype=0x02,portid=?" + fab_port_pcie1_read = "event=0x02,evtype=0x02,portid=?" + fab_port_pcie1_write = "event=0x03,evtype=0x02,portid=?" + fab_port_upi_read = "event=0x04,evtype=0x02,portid=?" + fab_port_upi_write = "event=0x05,evtype=0x02,portid=?" + fab_port_mmio_read = "event=0x06,evtype=0x02,portid=?" + fab_port_mmio_write = "event=0x07,evtype=0x02,portid=?" + + VTD events (evtype=0x03) + + vtd_port_read_transaction = "event=0x00,evtype=0x03,portid=?" + vtd_port_write_transaction = "event=0x01,evtype=0x03,portid=?" + vtd_port_devtlb_read_hit = "event=0x02,evtype=0x03,portid=?" + vtd_port_devtlb_write_hit = "event=0x03,evtype=0x03,portid=?" + vtd_port_devtlb_4k_fill = "event=0x04,evtype=0x03,portid=?" + vtd_port_devtlb_2m_fill = "event=0x05,evtype=0x03,portid=?" + vtd_port_devtlb_1g_fill = "event=0x06,evtype=0x03,portid=?" + + VTD SIP events (evtype=0x04) + + vtd_sip_iotlb_4k_hit = "event=0x00,evtype=0x04,portid=0xff" + vtd_sip_iotlb_2m_hit = "event=0x01,evtype=0x04,portid=0xff" + vtd_sip_iotlb_1g_hit = "event=0x02,evtype=0x04,portid=0xff" + vtd_sip_slpwc_l3_hit = "event=0x03,evtype=0x04,portid=0xff" + vtd_sip_slpwc_l4_hit = "event=0x04,evtype=0x04,portid=0xff" + vtd_sip_rcc_hit = "event=0x05,evtype=0x04,portid=0xff" + vtd_sip_iotlb_4k_miss = "event=0x06,evtype=0x04,portid=0xff" + vtd_sip_iotlb_2m_miss = "event=0x07,evtype=0x04,portid=0xff" + vtd_sip_iotlb_1g_miss = "event=0x08,evtype=0x04,portid=0xff" + vtd_sip_slpwc_l3_miss = "event=0x09,evtype=0x04,portid=0xff" + vtd_sip_slpwc_l4_miss = "event=0x0a,evtype=0x04,portid=0xff" + vtd_sip_rcc_miss = "event=0x0b,evtype=0x04,portid=0xff"
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 index ec27c6c..e8698af 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
@@ -22,6 +22,27 @@ Exposes the "version" field of the 24x7 catalog. This is also extractable from the provided binary "catalog" sysfs entry. +What: /sys/devices/hv_24x7/interface/sockets +Date: May 2020 +Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org> +Description: read only + This sysfs interface exposes the number of sockets present in the + system. + +What: /sys/devices/hv_24x7/interface/chipspersocket +Date: May 2020 +Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org> +Description: read only + This sysfs interface exposes the number of chips per socket + present in the system. + +What: /sys/devices/hv_24x7/interface/coresperchip +Date: May 2020 +Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org> +Description: read only + This sysfs interface exposes the number of cores per chip + present in the system. + What: /sys/bus/event_source/devices/hv_24x7/event_descs/<event-name> Date: February 2014 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-proximity b/Documentation/ABI/testing/sysfs-bus-iio-proximity new file mode 100644 index 0000000..2172f3b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-proximity
@@ -0,0 +1,10 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_proximity_nearlevel +Date: March 2020 +KernelVersion: 5.7 +Contact: linux-iio@vger.kernel.org +Description: + Near level for proximity sensors. This is a single integer + value that tells user space when an object should be + considered close to the device. If the value read from the + sensor is above or equal to the value in this file an object + should typically be considered near.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-sx9310 b/Documentation/ABI/testing/sysfs-bus-iio-sx9310 new file mode 100644 index 0000000..3ac7759 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-sx9310
@@ -0,0 +1,10 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_proximity3_comb_raw +Date: February 2019 +KernelVersion: 5.6 +Contact: Daniel Campello <campello@chromium.org> +Description: + Proximity measurement indicating that some object is + near the combined sensor. The combined sensor presents + proximity measurements constructed by hardware by + combining measurements taken from a given set of + physical sensors.
diff --git a/Documentation/ABI/testing/sysfs-bus-most b/Documentation/ABI/testing/sysfs-bus-most index 6b1d06e..ec0a603 100644 --- a/Documentation/ABI/testing/sysfs-bus-most +++ b/Documentation/ABI/testing/sysfs-bus-most
@@ -1,14 +1,14 @@ -What: /sys/bus/most/devices/.../description +What: /sys/bus/most/devices/<dev>/description Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - Provides information about the interface type and the physical - location of the device. Hardware attached via USB, for instance, + Provides information about the physical location of the + device. Hardware attached via USB, for instance, might return <1-1.1:1.0> Users: -What: /sys/bus/most/devices/.../interface +What: /sys/bus/most/devices/<dev>/interface Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -16,7 +16,7 @@ Indicates the type of peripheral interface the device uses. Users: -What: /sys/bus/most/devices/.../dci +What: /sys/bus/most/devices/<dev>/dci Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -26,7 +26,7 @@ write the controller's DCI registers. Users: -What: /sys/bus/most/devices/.../dci/arb_address +What: /sys/bus/most/devices/<dev>/dci/arb_address Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -35,7 +35,7 @@ application wants to read from or write to. Users: -What: /sys/bus/most/devices/.../dci/arb_value +What: /sys/bus/most/devices/<dev>/dci/arb_value Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -44,7 +44,7 @@ is stored in arb_address. Users: -What: /sys/bus/most/devices/.../dci/mep_eui48_hi +What: /sys/bus/most/devices/<dev>/dci/mep_eui48_hi Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -52,7 +52,7 @@ This is used to check and configure the MAC address. Users: -What: /sys/bus/most/devices/.../dci/mep_eui48_lo +What: /sys/bus/most/devices/<dev>/dci/mep_eui48_lo Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -60,7 +60,7 @@ This is used to check and configure the MAC address. Users: -What: /sys/bus/most/devices/.../dci/mep_eui48_mi +What: /sys/bus/most/devices/<dev>/dci/mep_eui48_mi Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -68,7 +68,7 @@ This is used to check and configure the MAC address. Users: -What: /sys/bus/most/devices/.../dci/mep_filter +What: /sys/bus/most/devices/<dev>/dci/mep_filter Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -76,7 +76,7 @@ This is used to check and configure the MEP filter address. Users: -What: /sys/bus/most/devices/.../dci/mep_hash0 +What: /sys/bus/most/devices/<dev>/dci/mep_hash0 Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -84,7 +84,7 @@ This is used to check and configure the MEP hash table. Users: -What: /sys/bus/most/devices/.../dci/mep_hash1 +What: /sys/bus/most/devices/<dev>/dci/mep_hash1 Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -92,7 +92,7 @@ This is used to check and configure the MEP hash table. Users: -What: /sys/bus/most/devices/.../dci/mep_hash2 +What: /sys/bus/most/devices/<dev>/dci/mep_hash2 Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -100,7 +100,7 @@ This is used to check and configure the MEP hash table. Users: -What: /sys/bus/most/devices/.../dci/mep_hash3 +What: /sys/bus/most/devices/<dev>/dci/mep_hash3 Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -108,7 +108,7 @@ This is used to check and configure the MEP hash table. Users: -What: /sys/bus/most/devices/.../dci/ni_state +What: /sys/bus/most/devices/<dev>/dci/ni_state Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -116,7 +116,7 @@ Indicates the current network interface state. Users: -What: /sys/bus/most/devices/.../dci/node_address +What: /sys/bus/most/devices/<dev>/dci/node_address Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -124,7 +124,7 @@ Indicates the current node address. Users: -What: /sys/bus/most/devices/.../dci/node_position +What: /sys/bus/most/devices/<dev>/dci/node_position Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -132,7 +132,7 @@ Indicates the current node position. Users: -What: /sys/bus/most/devices/.../dci/packet_bandwidth +What: /sys/bus/most/devices/<dev>/dci/packet_bandwidth Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -140,7 +140,7 @@ Indicates the configured packet bandwidth. Users: -What: /sys/bus/most/devices/.../dci/sync_ep +What: /sys/bus/most/devices/<dev>/dci/sync_ep Date: June 2016 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -149,7 +149,7 @@ endpoint. Users: -What: /sys/bus/most/devices/.../<channel>/ +What: /sys/bus/most/devices/<dev>/<channel>/ Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> @@ -160,91 +160,92 @@ configure it. Users: -What: /sys/bus/most/devices/.../<channel>/available_datatypes +What: /sys/bus/most/devices/<dev>/<channel>/available_datatypes Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - Indicates the data types the current channel can transport. + Indicates the data types the channel can transport. Users: -What: /sys/bus/most/devices/.../<channel>/available_directions +What: /sys/bus/most/devices/<dev>/<channel>/available_directions Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - Indicates the directions the current channel is capable of. + Indicates the directions the channel is capable of. Users: -What: /sys/bus/most/devices/.../<channel>/number_of_packet_buffers +What: /sys/bus/most/devices/<dev>/<channel>/number_of_packet_buffers Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - Indicates the number of packet buffers the current channel can + Indicates the number of packet buffers the channel can handle. Users: -What: /sys/bus/most/devices/.../<channel>/number_of_stream_buffers +What: /sys/bus/most/devices/<dev>/<channel>/number_of_stream_buffers Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - Indicates the number of streaming buffers the current channel can + Indicates the number of streaming buffers the channel can handle. Users: -What: /sys/bus/most/devices/.../<channel>/size_of_packet_buffer +What: /sys/bus/most/devices/<dev>/<channel>/size_of_packet_buffer Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - Indicates the size of a packet buffer the current channel can + Indicates the size of a packet buffer the channel can handle. Users: -What: /sys/bus/most/devices/.../<channel>/size_of_stream_buffer +What: /sys/bus/most/devices/<dev>/<channel>/size_of_stream_buffer Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - Indicates the size of a streaming buffer the current channel can + Indicates the size of a streaming buffer the channel can handle. Users: -What: /sys/bus/most/devices/.../<channel>/set_number_of_buffers +What: /sys/bus/most/devices/<dev>/<channel>/set_number_of_buffers Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - This is to configure the number of buffers of the current channel. + This is to read back the configured number of buffers of + the channel. Users: -What: /sys/bus/most/devices/.../<channel>/set_buffer_size +What: /sys/bus/most/devices/<dev>/<channel>/set_buffer_size Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - This is to configure the size of a buffer of the current channel. + This is to read back the configured buffer size of the channel. Users: -What: /sys/bus/most/devices/.../<channel>/set_direction +What: /sys/bus/most/devices/<dev>/<channel>/set_direction Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - This is to configure the direction of the current channel. + This is to read back the configured direction of the channel. The following strings will be accepted: - 'dir_tx', - 'dir_rx' + 'tx', + 'rx' Users: -What: /sys/bus/most/devices/.../<channel>/set_datatype +What: /sys/bus/most/devices/<dev>/<channel>/set_datatype Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - This is to configure the data type of the current channel. + This is to read back the configured data type of the channel. The following strings will be accepted: 'control', 'async', @@ -252,30 +253,31 @@ 'isoc_avp' Users: -What: /sys/bus/most/devices/.../<channel>/set_subbuffer_size +What: /sys/bus/most/devices/<dev>/<channel>/set_subbuffer_size Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - This is to configure the subbuffer size of the current channel. + This is to read back the configured subbuffer size of + the channel. Users: -What: /sys/bus/most/devices/.../<channel>/set_packets_per_xact +What: /sys/bus/most/devices/<dev>/<channel>/set_packets_per_xact Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - This is to configure the number of packets per transaction of - the current channel. This is only needed network interface - controller is attached via USB. + This is to read back the configured number of packets per + transaction of the channel. This is only applicable when + connected via USB. Users: -What: /sys/bus/most/devices/.../<channel>/channel_starving +What: /sys/bus/most/devices/<dev>/<channel>/channel_starving Date: March 2017 KernelVersion: 4.15 Contact: Christian Gromm <christian.gromm@microchip.com> Description: - Indicates whether current channel ran out of buffers. + Indicates whether channel ran out of buffers. Users: What: /sys/bus/most/drivers/most_core/components
diff --git a/Documentation/ABI/testing/sysfs-bus-soundwire-master b/Documentation/ABI/testing/sysfs-bus-soundwire-master new file mode 100644 index 0000000..46ef038 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-soundwire-master
@@ -0,0 +1,23 @@ +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 + +Contact: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> + Bard Liao <yung-chuan.liao@linux.intel.com> + Vinod Koul <vkoul@kernel.org> + +Description: SoundWire Master-N DisCo properties. + These properties are defined by MIPI DisCo Specification + for SoundWire. They define various properties of the Master + and are used by the bus to configure the Master. clk_stop_modes + is a bitmask for simplifications and combines the + clock-stop-mode0 and clock-stop-mode1 properties.
diff --git a/Documentation/ABI/testing/sysfs-bus-soundwire-slave b/Documentation/ABI/testing/sysfs-bus-soundwire-slave new file mode 100644 index 0000000..db4c951 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-soundwire-slave
@@ -0,0 +1,91 @@ +What: /sys/bus/soundwire/devices/sdw:.../dev-properties/mipi_revision + /sys/bus/soundwire/devices/sdw:.../dev-properties/wake_capable + /sys/bus/soundwire/devices/sdw:.../dev-properties/test_mode_capable + /sys/bus/soundwire/devices/sdw:.../dev-properties/clk_stop_mode1 + /sys/bus/soundwire/devices/sdw:.../dev-properties/simple_clk_stop_capable + /sys/bus/soundwire/devices/sdw:.../dev-properties/clk_stop_timeout + /sys/bus/soundwire/devices/sdw:.../dev-properties/ch_prep_timeout + /sys/bus/soundwire/devices/sdw:.../dev-properties/reset_behave + /sys/bus/soundwire/devices/sdw:.../dev-properties/high_PHY_capable + /sys/bus/soundwire/devices/sdw:.../dev-properties/paging_support + /sys/bus/soundwire/devices/sdw:.../dev-properties/bank_delay_support + /sys/bus/soundwire/devices/sdw:.../dev-properties/p15_behave + /sys/bus/soundwire/devices/sdw:.../dev-properties/master_count + /sys/bus/soundwire/devices/sdw:.../dev-properties/source_ports + /sys/bus/soundwire/devices/sdw:.../dev-properties/sink_ports + +Date: May 2020 + +Contact: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> + Bard Liao <yung-chuan.liao@linux.intel.com> + Vinod Koul <vkoul@kernel.org> + +Description: SoundWire Slave DisCo properties. + These properties are defined by MIPI DisCo Specification + for SoundWire. They define various properties of the + SoundWire Slave and are used by the bus to configure + the Slave + + +What: /sys/bus/soundwire/devices/sdw:.../dp0/max_word + /sys/bus/soundwire/devices/sdw:.../dp0/min_word + /sys/bus/soundwire/devices/sdw:.../dp0/words + /sys/bus/soundwire/devices/sdw:.../dp0/BRA_flow_controlled + /sys/bus/soundwire/devices/sdw:.../dp0/simple_ch_prep_sm + /sys/bus/soundwire/devices/sdw:.../dp0/imp_def_interrupts + +Date: May 2020 + +Contact: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> + Bard Liao <yung-chuan.liao@linux.intel.com> + Vinod Koul <vkoul@kernel.org> + +Description: SoundWire Slave Data Port-0 DisCo properties. + These properties are defined by MIPI DisCo Specification + for the SoundWire. They define various properties of the + 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 + +Date: May 2020 + +Contact: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> + Bard Liao <yung-chuan.liao@linux.intel.com> + Vinod Koul <vkoul@kernel.org> + +Description: SoundWire Slave Data Source/Sink Port-N DisCo properties. + These properties are defined by MIPI DisCo Specification + for SoundWire. They define various properties of the + Source/Sink Data port N and are used by the bus to configure + the Data Port N.
diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net index 664a8f6..3b40457 100644 --- a/Documentation/ABI/testing/sysfs-class-net +++ b/Documentation/ABI/testing/sysfs-class-net
@@ -124,6 +124,19 @@ authentication is performed (e.g: 802.1x). 'link_mode' attribute will also reflect the dormant state. +What: /sys/class/net/<iface>/testing +Date: April 2002 +KernelVersion: 5.8 +Contact: netdev@vger.kernel.org +Description: + Indicates whether the interface is under test. Possible + values are: + 0: interface is not being tested + 1: interface is being tested + + When an interface is under test, it cannot be expected + to pass packets as normal. + What: /sys/clas/net/<iface>/duplex Date: October 2009 KernelVersion: 2.6.33
diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power index bf3b48f..216d61a 100644 --- a/Documentation/ABI/testing/sysfs-class-power +++ b/Documentation/ABI/testing/sysfs-class-power
@@ -74,6 +74,21 @@ Access: Read, Write Valid values: 0 - 100 (percent) +What: /sys/class/power_supply/<supply_name>/capacity_error_margin +Date: April 2019 +Contact: linux-pm@vger.kernel.org +Description: + Battery capacity measurement becomes unreliable without + recalibration. This values provides the maximum error + margin expected to exist by the fuel gauge in percent. + Values close to 0% will be returned after (re-)calibration + has happened. Over time the error margin will increase. + 100% means, that the capacity related values are basically + completely useless. + + Access: Read + Valid values: 0 - 100 (percent) + What: /sys/class/power_supply/<supply_name>/capacity_level Date: June 2009 Contact: linux-pm@vger.kernel.org @@ -190,7 +205,7 @@ Valid values: "Unknown", "Good", "Overheat", "Dead", "Over voltage", "Unspecified failure", "Cold", "Watchdog timer expire", "Safety timer expire", - "Over current" + "Over current", "Calibration required" What: /sys/class/power_supply/<supply_name>/precharge_current Date: June 2017 @@ -665,3 +680,31 @@ Valid values: - 1: enabled - 0: disabled + +What: /sys/class/power_supply/<supply_name>/manufacture_year +Date: January 2020 +Contact: linux-pm@vger.kernel.org +Description: + Reports the year (following Gregorian calendar) when the device has been + manufactured. + + Access: Read + Valid values: Reported as integer + +What: /sys/class/power_supply/<supply_name>/manufacture_month +Date: January 2020 +Contact: linux-pm@vger.kernel.org +Description: + Reports the month when the device has been manufactured. + + Access: Read + Valid values: 1-12 + +What: /sys/class/power_supply/<supply_name>/manufacture_day +Date: January 2020 +Contact: linux-pm@vger.kernel.org +Description: + Reports the day of month when the device has been manufactured. + + Access: Read + Valid values: 1-31
diff --git a/Documentation/ABI/testing/sysfs-class-power-mp2629 b/Documentation/ABI/testing/sysfs-class-power-mp2629 new file mode 100644 index 0000000..327a07e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-power-mp2629
@@ -0,0 +1,8 @@ +What: /sys/class/power_supply/mp2629_battery/batt_impedance_compen +Date: April 2020 +KernelVersion: 5.7 +Description: + Represents a battery impedance compensation to accelerate charging. + + Access: Read, Write + Valid values: Represented in milli-ohms. Valid range is [0, 140].
diff --git a/Documentation/ABI/testing/sysfs-class-rnbd-client b/Documentation/ABI/testing/sysfs-class-rnbd-client new file mode 100644 index 0000000..c084f20 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-rnbd-client
@@ -0,0 +1,111 @@ +What: /sys/class/rnbd-client +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Provide information about RNBD-client. + All sysfs files that are not read-only provide the usage information on read: + + Example: + # cat /sys/class/rnbd-client/ctl/map_device + + > Usage: echo "sessname=<name of the rtrs session> path=<[srcaddr,]dstaddr> + > [path=<[srcaddr,]dstaddr>] device_path=<full path on remote side> + > [access_mode=<ro|rw|migration>] > map_device + > + > addr ::= [ ip:<ipv4> | ip:<ipv6> | gid:<gid> ] + +What: /sys/class/rnbd-client/ctl/map_device +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Expected format is the following: + + sessname=<name of the rtrs session> + path=<[srcaddr,]dstaddr> [path=<[srcaddr,]dstaddr> ...] + device_path=<full path on remote side> + [access_mode=<ro|rw|migration>] + + Where: + + sessname: accepts a string not bigger than 256 chars, which identifies + a given session on the client and on the server. + I.e. "clt_hostname-srv_hostname" could be a natural choice. + + path: describes a connection between the client and the server by + specifying destination and, when required, the source address. + The addresses are to be provided in the following format: + + ip:<IPv6> + ip:<IPv4> + gid:<GID> + + for example: + + path=ip:10.0.0.66 + The single addr is treated as the destination. + The connection will be established to this server from any client IP address. + + path=ip:10.0.0.66,ip:10.0.1.66 + First addr is the source address and the second is the destination. + + If multiple "path=" options are specified multiple connection + will be established and data will be sent according to + the selected multipath policy (see RTRS mp_policy sysfs entry description). + + device_path: Path to the block device on the server side. Path is specified + relative to the directory on server side configured in the + 'dev_search_path' module parameter of the rnbd_server. + The rnbd_server prepends the <device_path> received from client + with <dev_search_path> and tries to open the + <dev_search_path>/<device_path> block device. On success, + a /dev/rnbd<N> device file, a /sys/block/rnbd_client/rnbd<N>/ + directory and an entry in /sys/class/rnbd-client/ctl/devices + will be created. + + If 'dev_search_path' contains '%SESSNAME%', then each session can + have different devices namespace, e.g. server was configured with + the following parameter "dev_search_path=/run/rnbd-devs/%SESSNAME%", + client has this string "sessname=blya device_path=sda", then server + will try to open: /run/rnbd-devs/blya/sda. + + access_mode: the access_mode parameter specifies if the device is to be + mapped as "ro" read-only or "rw" read-write. The server allows + a device to be exported in rw mode only once. The "migration" + access mode has to be specified if a second mapping in read-write + mode is desired. + + By default "rw" is used. + + Exit Codes: + + If the device is already mapped it will fail with EEXIST. If the input + has an invalid format it will return EINVAL. If the device path cannot + be found on the server, it will fail with ENOENT. + + Finding device file after mapping + --------------------------------- + + After mapping, the device file can be found by: + o The symlink /sys/class/rnbd-client/ctl/devices/<device_id> + points to /sys/block/<dev-name>. The last part of the symlink destination + is the same as the device name. By extracting the last part of the + path the path to the device /dev/<dev-name> can be build. + + o /dev/block/$(cat /sys/class/rnbd-client/ctl/devices/<device_id>/dev) + + How to find the <device_id> of the device is described on the next + section. + +What: /sys/class/rnbd-client/ctl/devices/ +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: For each device mapped on the client a new symbolic link is created as + /sys/class/rnbd-client/ctl/devices/<device_id>, which points + to the block device created by rnbd (/sys/block/rnbd<N>/). + The <device_id> of each device is created as follows: + + - If the 'device_path' provided during mapping contains slashes ("/"), + they are replaced by exclamation mark ("!") and used as as the + <device_id>. Otherwise, the <device_id> will be the same as the + "device_path" provided.
diff --git a/Documentation/ABI/testing/sysfs-class-rnbd-server b/Documentation/ABI/testing/sysfs-class-rnbd-server new file mode 100644 index 0000000..ba60a90 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-rnbd-server
@@ -0,0 +1,50 @@ +What: /sys/class/rnbd-server +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: provide information about RNBD-server. + +What: /sys/class/rnbd-server/ctl/ +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: When a client maps a device, a directory entry with the name of the + block device is created under /sys/class/rnbd-server/ctl/devices/. + +What: /sys/class/rnbd-server/ctl/devices/<device_name>/block_dev +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Is a symlink to the sysfs entry of the exported device. + + Example: + block_dev -> ../../../../class/block/ram0 + +What: /sys/class/rnbd-server/ctl/devices/<device_name>/sessions/ +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: For each client a particular device is exported to, following directory will be + created: + + /sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/ + + When the device is unmapped by that client, the directory will be removed. + +What: /sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/read_only +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Contains '1' if device is mapped read-only, otherwise '0'. + +What: /sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/mapping_path +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Contains the relative device path provided by the user during mapping. + +What: /sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/access_mode +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Contains the device access mode: ro, rw or migration.
diff --git a/Documentation/ABI/testing/sysfs-class-rtrs-client b/Documentation/ABI/testing/sysfs-class-rtrs-client new file mode 100644 index 0000000..e7e718d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-rtrs-client
@@ -0,0 +1,131 @@ +What: /sys/class/rtrs-client +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: When a user of RTRS API creates a new session, a directory entry with + the name of that session is created under /sys/class/rtrs-client/<session-name>/ + +What: /sys/class/rtrs-client/<session-name>/add_path +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: RW, adds a new path (connection) to an existing session. Expected format is the + following: + + <[source addr,]destination addr> + *addr ::= [ ip:<ipv4|ipv6> | gid:<gid> ] + +What: /sys/class/rtrs-client/<session-name>/max_reconnect_attempts +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Maximum number reconnect attempts the client should make before giving up + after connection breaks unexpectedly. + +What: /sys/class/rtrs-client/<session-name>/mp_policy +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Multipath policy specifies which path should be selected on each IO: + + round-robin (0): + select path in per CPU round-robin manner. + + min-inflight (1): + select path with minimum inflights. + +What: /sys/class/rtrs-client/<session-name>/paths/ +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Each path belonging to a given session is listed here by its source and + destination address. When a new path is added to a session by writing to + the "add_path" entry, a directory <src@dst> is created. + +What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/state +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: RO, Contains "connected" if the session is connected to the peer and fully + functional. Otherwise the file contains "disconnected" + +What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/reconnect +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Write "1" to the file in order to reconnect the path. + Operation is blocking and returns 0 if reconnect was successful. + +What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/disconnect +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Write "1" to the file in order to disconnect the path. + Operation blocks until RTRS path is disconnected. + +What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/remove_path +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Write "1" to the file in order to disconnected and remove the path + from the session. Operation blocks until the path is disconnected + and removed from the session. + +What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/hca_name +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: RO, Contains the the name of HCA the connection established on. + +What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/hca_port +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: RO, Contains the port number of active port traffic is going through. + +What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/src_addr +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: RO, Contains the source address of the path + +What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/dst_addr +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: RO, Contains the destination address of the path + +What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/reset_all +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: RW, Read will return usage help, write 0 will clear all the statistics. + +What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/cpu_migration +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: RTRS expects that each HCA IRQ is pinned to a separate CPU. If it's + not the case, the processing of an I/O response could be processed on a + different CPU than where it was originally submitted. This file shows + how many interrupts where generated on a non expected CPU. + "from:" is the CPU on which the IRQ was expected, but not generated. + "to:" is the CPU on which the IRQ was generated, but not expected. + +What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/reconnects +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Contains 2 unsigned int values, the first one records number of successful + reconnects in the path lifetime, the second one records number of failed + reconnects in the path lifetime. + +What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/rdma +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Contains statistics regarding rdma operations and inflight operations. + The output consists of 6 values: + + <read-count> <read-total-size> <write-count> <write-total-size> \ + <inflights> <failovered>
diff --git a/Documentation/ABI/testing/sysfs-class-rtrs-server b/Documentation/ABI/testing/sysfs-class-rtrs-server new file mode 100644 index 0000000..3b6d5b0 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-rtrs-server
@@ -0,0 +1,53 @@ +What: /sys/class/rtrs-server +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: When a user of RTRS API creates a new session on a client side, a + directory entry with the name of that session is created in here. + +What: /sys/class/rtrs-server/<session-name>/paths/ +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: When new path is created by writing to "add_path" entry on client side, + a directory entry named as <source address>@<destination address> is created + on server. + +What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/disconnect +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: When "1" is written to the file, the RTRS session is being disconnected. + Operations is non-blocking and returns control immediately to the caller. + +What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/hca_name +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: RO, Contains the the name of HCA the connection established on. + +What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/hca_port +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: RO, Contains the port number of active port traffic is going through. + +What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/src_addr +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: RO, Contains the source address of the path + +What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/dst_addr +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: RO, Contains the destination address of the path + +What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/stats/rdma +Date: Feb 2020 +KernelVersion: 5.7 +Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com> +Description: Contains statistics regarding rdma operations and inflight operations. + The output consists of 5 values: + <read-count> <read-total-size> <write-count> <write-total-size> <inflights>
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 2e0e3b4..b555df8 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -106,10 +106,10 @@ See Documentation/admin-guide/cputopology.rst for more information. -What: /sys/devices/system/cpu/cpuidle/current_driver - /sys/devices/system/cpu/cpuidle/current_governer_ro - /sys/devices/system/cpu/cpuidle/available_governors +What: /sys/devices/system/cpu/cpuidle/available_governors + /sys/devices/system/cpu/cpuidle/current_driver /sys/devices/system/cpu/cpuidle/current_governor + /sys/devices/system/cpu/cpuidle/current_governer_ro Date: September 2007 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> Description: Discover cpuidle policy and mechanism @@ -119,24 +119,18 @@ consumption during idle. Idle policy (governor) is differentiated from idle mechanism - (driver) - - current_driver: (RO) displays current idle mechanism - - current_governor_ro: (RO) displays current idle policy - - With the cpuidle_sysfs_switch boot option enabled (meant for - developer testing), the following three attributes are visible - instead: - - current_driver: same as described above + (driver). available_governors: (RO) displays a space separated list of - available governors + available governors. + + current_driver: (RO) displays current idle mechanism. current_governor: (RW) displays current idle policy. Users can switch the governor at runtime by writing to this file. + current_governor_ro: (RO) displays current idle policy. + See Documentation/admin-guide/pm/cpuidle.rst and Documentation/driver-api/pm/cpuidle.rst for more information. @@ -492,6 +486,7 @@ /sys/devices/system/cpu/vulnerabilities/spec_store_bypass /sys/devices/system/cpu/vulnerabilities/l1tf /sys/devices/system/cpu/vulnerabilities/mds + /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit Date: January 2018 @@ -580,3 +575,42 @@ If 1, it means the system is using the Protected Execution Facility in POWER9 and newer processors. i.e., it is a Secure Virtual Machine. + +What: /sys/devices/system/cpu/cpuX/purr +Date: Apr 2005 +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> +Description: PURR ticks for this CPU since the system boot. + + The Processor Utilization Resources Register (PURR) is + a 64-bit counter which provides an estimate of the + resources used by the CPU thread. The contents of this + register increases monotonically. This sysfs interface + exposes the number of PURR ticks for cpuX. + +What: /sys/devices/system/cpu/cpuX/spurr +Date: Dec 2006 +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> +Description: SPURR ticks for this CPU since the system boot. + + The Scaled Processor Utilization Resources Register + (SPURR) is a 64-bit counter that provides a frequency + invariant estimate of the resources used by the CPU + thread. The contents of this register increases + monotonically. This sysfs interface exposes the number + of SPURR ticks for cpuX. + +What: /sys/devices/system/cpu/cpuX/idle_purr +Date: Apr 2020 +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> +Description: PURR ticks for cpuX when it was idle. + + This sysfs interface exposes the number of PURR ticks + for cpuX when it was idle. + +What: /sys/devices/system/cpu/cpuX/idle_spurr +Date: Apr 2020 +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> +Description: SPURR ticks for cpuX when it was idle. + + This sysfs interface exposes the number of SPURR ticks + for cpuX when it was idle.
diff --git a/Documentation/ABI/testing/sysfs-driver-habanalabs b/Documentation/ABI/testing/sysfs-driver-habanalabs index 782df74..1a14bf9 100644 --- a/Documentation/ABI/testing/sysfs-driver-habanalabs +++ b/Documentation/ABI/testing/sysfs-driver-habanalabs
@@ -10,6 +10,23 @@ Contact: oded.gabbay@gmail.com Description: Version of the application running on the device's CPU +What: /sys/class/habanalabs/hl<n>/clk_max_freq_mhz +Date: Jun 2019 +KernelVersion: not yet upstreamed +Contact: oded.gabbay@gmail.com +Description: Allows the user to set the maximum clock frequency, in MHz. + The device clock might be set to lower value than the maximum. + The user should read the clk_cur_freq_mhz to see the actual + frequency value of the device clock. This property is valid + only for the Gaudi ASIC family + +What: /sys/class/habanalabs/hl<n>/clk_cur_freq_mhz +Date: Jun 2019 +KernelVersion: not yet upstreamed +Contact: oded.gabbay@gmail.com +Description: Displays the current frequency, in MHz, of the device clock. + This property is valid only for the Gaudi ASIC family + What: /sys/class/habanalabs/hl<n>/cpld_ver Date: Jan 2019 KernelVersion: 5.1
diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm new file mode 100644 index 0000000..076659d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm
@@ -0,0 +1,116 @@ +What: /sys/bus/w1/devices/.../alarms +Date: May 2020 +Contact: Akira Shimahara <akira215corp@gmail.com> +Description: + (RW) read or write TH and TL (Temperature High an Low) alarms. + Values shall be space separated and in the device range + (typical -55 degC to 125 degC), if not values will be trimmed + to device min/max capabilities. Values are integer as they are + stored in a 8bit register in the device. Lowest value is + automatically put to TL. Once set, alarms could be search at + master level, refer to Documentation/w1/w1_generic.rst for + detailed information +Users: any user space application which wants to communicate with + w1_term device + + +What: /sys/bus/w1/devices/.../eeprom +Date: May 2020 +Contact: Akira Shimahara <akira215corp@gmail.com> +Description: + (WO) writing that file will either trigger a save of the + device data to its embedded EEPROM, either restore data + embedded in device EEPROM. Be aware that devices support + limited EEPROM writing cycles (typical 50k) + * 'save': save device RAM to EEPROM + * 'restore': restore EEPROM data in device RAM +Users: any user space application which wants to communicate with + w1_term device + + +What: /sys/bus/w1/devices/.../ext_power +Date: May 2020 +Contact: Akira Shimahara <akira215corp@gmail.com> +Description: + (RO) return the power status by asking the device + * '0': device parasite powered + * '1': device externally powered + * '-xx': xx is kernel error when reading power status +Users: any user space application which wants to communicate with + w1_term device + + +What: /sys/bus/w1/devices/.../resolution +Date: May 2020 +Contact: Akira Shimahara <akira215corp@gmail.com> +Description: + (RW) get or set the device resolution (on supported devices, + if not, this entry is not present). Note that the resolution + will be changed only in device RAM, so it will be cleared when + power is lost. Trigger a 'save' to EEPROM command to keep + values after power-on. Read or write are : + * '9..12': device resolution in bit + or resolution to set in bit + * '-xx': xx is kernel error when reading the resolution + * Anything else: do nothing +Users: any user space application which wants to communicate with + w1_term device + + +What: /sys/bus/w1/devices/.../temperature +Date: May 2020 +Contact: Akira Shimahara <akira215corp@gmail.com> +Description: + (RO) return the temperature in 1/1000 degC. + * If a bulk read has been triggered, it will directly + return the temperature computed when the bulk read + occurred, if available. If not yet available, nothing + is returned (a debug kernel message is sent), you + should retry later on. + * If no bulk read has been triggered, it will trigger + a conversion and send the result. Note that the + conversion duration depend on the resolution (if + device support this feature). It takes 94ms in 9bits + resolution, 750ms for 12bits. +Users: any user space application which wants to communicate with + w1_term device + + +What: /sys/bus/w1/devices/.../w1_slave +Date: May 2020 +Contact: Akira Shimahara <akira215corp@gmail.com> +Description: + (RW) return the temperature in 1/1000 degC. + *read*: return 2 lines with the hexa output data sent on the + bus, return the CRC check and temperature in 1/1000 degC + *write* : + * '0' : save the 2 or 3 bytes to the device EEPROM + (i.e. TH, TL and config register) + * '9..12' : set the device resolution in RAM + (if supported) + * Anything else: do nothing + refer to Documentation/w1/slaves/w1_therm.rst for detailed + information. +Users: any user space application which wants to communicate with + w1_term device + + +What: /sys/bus/w1/devices/w1_bus_masterXX/therm_bulk_read +Date: May 2020 +Contact: Akira Shimahara <akira215corp@gmail.com> +Description: + (RW) trigger a bulk read conversion. read the status + *read*: + * '-1': conversion in progress on at least 1 sensor + * '1' : conversion complete but at least one sensor + value has not been read yet + * '0' : no bulk operation. Reading temperature will + trigger a conversion on each device + *write*: 'trigger': trigger a bulk read on all supporting + devices on the bus + Note that if a bulk read is sent but one sensor is not read + immediately, the next access to temperature on this device + will return the temperature measured at the time of issue + of the bulk read command (not the current temperature). +Users: any user space application which wants to communicate with + w1_term device
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index bd8a0d1..4bb93a0 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -323,3 +323,27 @@ Date: February 2020 Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> Description: Show the mounted time in secs of this partition. + +What: /sys/fs/f2fs/<disk>/data_io_flag +Date: April 2020 +Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> +Description: Give a way to attach REQ_META|FUA to data writes + given temperature-based bits. Now the bits indicate: + * REQ_META | REQ_FUA | + * 5 | 4 | 3 | 2 | 1 | 0 | + * Cold | Warm | Hot | Cold | Warm | Hot | + +What: /sys/fs/f2fs/<disk>/node_io_flag +Date: June 2020 +Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> +Description: Give a way to attach REQ_META|FUA to node writes + given temperature-based bits. Now the bits indicate: + * REQ_META | REQ_FUA | + * 5 | 4 | 3 | 2 | 1 | 0 | + * Cold | Warm | Hot | Cold | Warm | Hot | + +What: /sys/fs/f2fs/<disk>/iostat_period_ms +Date: April 2020 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: Give a way to change iostat_period time. 3secs by default. + The new iostat trace gives stats gap given the period.
diff --git a/Documentation/ABI/testing/sysfs-platform-dptf b/Documentation/ABI/testing/sysfs-platform-dptf index 325dc06..eeed81c 100644 --- a/Documentation/ABI/testing/sysfs-platform-dptf +++ b/Documentation/ABI/testing/sysfs-platform-dptf
@@ -27,10 +27,12 @@ Contact: linux-acpi@vger.kernel.org Description: (RO) Display the platform power source - 0x00 = DC - 0x01 = AC - 0x02 = USB - 0x03 = Wireless Charger + bits[3:0] Current power source + 0x00 = DC + 0x01 = AC + 0x02 = USB + 0x03 = Wireless Charger + bits[7:4] Power source sequence number What: /sys/bus/platform/devices/INT3407:00/dptf_power/battery_steady_power Date: Jul, 2016 @@ -38,3 +40,55 @@ Contact: linux-acpi@vger.kernel.org Description: (RO) The maximum sustained power for battery in milliwatts. + +What: /sys/bus/platform/devices/INT3407:00/dptf_power/rest_of_platform_power_mw +Date: June, 2020 +KernelVersion: v5.8 +Contact: linux-acpi@vger.kernel.org +Description: + (RO) Shows the rest (outside of SoC) of worst-case platform power. + +What: /sys/bus/platform/devices/INT3407:00/dptf_power/prochot_confirm +Date: June, 2020 +KernelVersion: v5.8 +Contact: linux-acpi@vger.kernel.org +Description: + (WO) Confirm embedded controller about a prochot notification. + +What: /sys/bus/platform/devices/INT3532:00/dptf_battery/max_platform_power_mw +Date: June, 2020 +KernelVersion: v5.8 +Contact: linux-acpi@vger.kernel.org +Description: + (RO) The maximum platform power that can be supported by the battery in milli watts. + +What: /sys/bus/platform/devices/INT3532:00/dptf_battery/max_steady_state_power_mw +Date: June, 2020 +KernelVersion: v5.8 +Contact: linux-acpi@vger.kernel.org +Description: + (RO) The maximum sustained power for battery in milli watts. + +What: /sys/bus/platform/devices/INT3532:00/dptf_battery/high_freq_impedance_mohm +Date: June, 2020 +KernelVersion: v5.8 +Contact: linux-acpi@vger.kernel.org +Description: + (RO) The high frequency impedance value that can be obtained from battery + fuel gauge in milli Ohms. + +What: /sys/bus/platform/devices/INT3532:00/dptf_battery/no_load_voltage_mv +Date: June, 2020 +KernelVersion: v5.8 +Contact: linux-acpi@vger.kernel.org +Description: + (RO) The no-load voltage that can be obtained from battery fuel gauge in + milli volts. + +What: /sys/bus/platform/devices/INT3532:00/dptf_battery/current_discharge_capbility_ma +Date: June, 2020 +KernelVersion: v5.8 +Contact: linux-acpi@vger.kernel.org +Description: + (RO) The battery discharge current capability obtained from battery fuel gauge in + milli Amps.
diff --git a/Documentation/ABI/testing/sysfs-platform-intel-wmi-sbl-fw-update b/Documentation/ABI/testing/sysfs-platform-intel-wmi-sbl-fw-update new file mode 100644 index 0000000..5aa6189 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-intel-wmi-sbl-fw-update
@@ -0,0 +1,12 @@ +What: /sys/bus/wmi/devices/44FADEB1-B204-40F2-8581-394BBDC1B651/firmware_update_request +Date: April 2020 +KernelVersion: 5.7 +Contact: "Jithu Joseph" <jithu.joseph@intel.com> +Description: + Allow user space entities to trigger update of Slim + Bootloader (SBL). This attribute normally has a value + of 0 and userspace can signal SBL to update firmware, + on next reboot, by writing a value of 1. + There are two available states: + * 0 -> Skip firmware update while rebooting + * 1 -> Attempt firmware update on next reboot
diff --git a/Documentation/COPYING-logo b/Documentation/COPYING-logo index 296f0f7..b21c7cf 100644 --- a/Documentation/COPYING-logo +++ b/Documentation/COPYING-logo
@@ -9,5 +9,5 @@ you want to use it for: for the full range of logos take a look at Larry's web-page: - http://www.isc.tamu.edu/~lewing/linux/ + https://www.isc.tamu.edu/~lewing/linux/
diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt deleted file mode 100644 index 507775c..0000000 --- a/Documentation/IRQ-domain.txt +++ /dev/null
@@ -1,269 +0,0 @@ -=============================================== -The irq_domain interrupt number mapping library -=============================================== - -The current design of the Linux kernel uses a single large number -space where each separate IRQ source is assigned a different number. -This is simple when there is only one interrupt controller, but in -systems with multiple interrupt controllers the kernel must ensure -that each one gets assigned non-overlapping allocations of Linux -IRQ numbers. - -The number of interrupt controllers registered as unique irqchips -show a rising tendency: for example subdrivers of different kinds -such as GPIO controllers avoid reimplementing identical callback -mechanisms as the IRQ core system by modelling their interrupt -handlers as irqchips, i.e. in effect cascading interrupt controllers. - -Here the interrupt number loose all kind of correspondence to -hardware interrupt numbers: whereas in the past, IRQ numbers could -be chosen so they matched the hardware IRQ line into the root -interrupt controller (i.e. the component actually fireing the -interrupt line to the CPU) nowadays this number is just a number. - -For this reason we need a mechanism to separate controller-local -interrupt numbers, called hardware irq's, from Linux IRQ numbers. - -The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of -irq numbers, but they don't provide any support for reverse mapping of -the controller-local IRQ (hwirq) number into the Linux IRQ number -space. - -The irq_domain library adds mapping between hwirq and IRQ numbers on -top of the irq_alloc_desc*() API. An irq_domain to manage mapping is -preferred over interrupt controller drivers open coding their own -reverse mapping scheme. - -irq_domain also implements translation from an abstract irq_fwspec -structure to hwirq numbers (Device Tree and ACPI GSI so far), and can -be easily extended to support other IRQ topology data sources. - -irq_domain usage -================ - -An interrupt controller driver creates and registers an irq_domain by -calling one of the irq_domain_add_*() functions (each mapping method -has a different allocator function, more on that later). The function -will return a pointer to the irq_domain on success. The caller must -provide the allocator function with an irq_domain_ops structure. - -In most cases, the irq_domain will begin empty without any mappings -between hwirq and IRQ numbers. Mappings are added to the irq_domain -by calling irq_create_mapping() which accepts the irq_domain and a -hwirq number as arguments. If a mapping for the hwirq doesn't already -exist then it will allocate a new Linux irq_desc, associate it with -the hwirq, and call the .map() callback so the driver can perform any -required hardware setup. - -When an interrupt is received, irq_find_mapping() function should -be used to find the Linux IRQ number from the hwirq number. - -The irq_create_mapping() function must be called *atleast once* -before any call to irq_find_mapping(), lest the descriptor will not -be allocated. - -If the driver has the Linux IRQ number or the irq_data pointer, and -needs to know the associated hwirq number (such as in the irq_chip -callbacks) then it can be directly obtained from irq_data->hwirq. - -Types of irq_domain mappings -============================ - -There are several mechanisms available for reverse mapping from hwirq -to Linux irq, and each mechanism uses a different allocation function. -Which reverse map type should be used depends on the use case. Each -of the reverse map types are described below: - -Linear ------- - -:: - - irq_domain_add_linear() - irq_domain_create_linear() - -The linear reverse map maintains a fixed size table indexed by the -hwirq number. When a hwirq is mapped, an irq_desc is allocated for -the hwirq, and the IRQ number is stored in the table. - -The Linear map is a good choice when the maximum number of hwirqs is -fixed and a relatively small number (~ < 256). The advantages of this -map are fixed time lookup for IRQ numbers, and irq_descs are only -allocated for in-use IRQs. The disadvantage is that the table must be -as large as the largest possible hwirq number. - -irq_domain_add_linear() and irq_domain_create_linear() are functionally -equivalent, except for the first argument is different - the former -accepts an Open Firmware specific 'struct device_node', while the latter -accepts a more general abstraction 'struct fwnode_handle'. - -The majority of drivers should use the linear map. - -Tree ----- - -:: - - irq_domain_add_tree() - irq_domain_create_tree() - -The irq_domain maintains a radix tree map from hwirq numbers to Linux -IRQs. When an hwirq is mapped, an irq_desc is allocated and the -hwirq is used as the lookup key for the radix tree. - -The tree map is a good choice if the hwirq number can be very large -since it doesn't need to allocate a table as large as the largest -hwirq number. The disadvantage is that hwirq to IRQ number lookup is -dependent on how many entries are in the table. - -irq_domain_add_tree() and irq_domain_create_tree() are functionally -equivalent, except for the first argument is different - the former -accepts an Open Firmware specific 'struct device_node', while the latter -accepts a more general abstraction 'struct fwnode_handle'. - -Very few drivers should need this mapping. - -No Map ------- - -:: - - irq_domain_add_nomap() - -The No Map mapping is to be used when the hwirq number is -programmable in the hardware. In this case it is best to program the -Linux IRQ number into the hardware itself so that no mapping is -required. Calling irq_create_direct_mapping() will allocate a Linux -IRQ number and call the .map() callback so that driver can program the -Linux IRQ number into the hardware. - -Most drivers cannot use this mapping. - -Legacy ------- - -:: - - irq_domain_add_simple() - irq_domain_add_legacy() - irq_domain_add_legacy_isa() - -The Legacy mapping is a special case for drivers that already have a -range of irq_descs allocated for the hwirqs. It is used when the -driver cannot be immediately converted to use the linear mapping. For -example, many embedded system board support files use a set of #defines -for IRQ numbers that are passed to struct device registrations. In that -case the Linux IRQ numbers cannot be dynamically assigned and the legacy -mapping should be used. - -The legacy map assumes a contiguous range of IRQ numbers has already -been allocated for the controller and that the IRQ number can be -calculated by adding a fixed offset to the hwirq number, and -visa-versa. The disadvantage is that it requires the interrupt -controller to manage IRQ allocations and it requires an irq_desc to be -allocated for every hwirq, even if it is unused. - -The legacy map should only be used if fixed IRQ mappings must be -supported. For example, ISA controllers would use the legacy map for -mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ -numbers. - -Most users of legacy mappings should use irq_domain_add_simple() which -will use a legacy domain only if an IRQ range is supplied by the -system and will otherwise use a linear domain mapping. The semantics -of this call are such that if an IRQ range is specified then -descriptors will be allocated on-the-fly for it, and if no range is -specified it will fall through to irq_domain_add_linear() which means -*no* irq descriptors will be allocated. - -A typical use case for simple domains is where an irqchip provider -is supporting both dynamic and static IRQ assignments. - -In order to avoid ending up in a situation where a linear domain is -used and no descriptor gets allocated it is very important to make sure -that the driver using the simple domain call irq_create_mapping() -before any irq_find_mapping() since the latter will actually work -for the static IRQ assignment case. - -Hierarchy IRQ domain --------------------- - -On some architectures, there may be multiple interrupt controllers -involved in delivering an interrupt from the device to the target CPU. -Let's look at a typical interrupt delivering path on x86 platforms:: - - Device --> IOAPIC -> Interrupt remapping Controller -> Local APIC -> CPU - -There are three interrupt controllers involved: - -1) IOAPIC controller -2) Interrupt remapping controller -3) Local APIC controller - -To support such a hardware topology and make software architecture match -hardware architecture, an irq_domain data structure is built for each -interrupt controller and those irq_domains are organized into hierarchy. -When building irq_domain hierarchy, the irq_domain near to the device is -child and the irq_domain near to CPU is parent. So a hierarchy structure -as below will be built for the example above:: - - CPU Vector irq_domain (root irq_domain to manage CPU vectors) - ^ - | - Interrupt Remapping irq_domain (manage irq_remapping entries) - ^ - | - IOAPIC irq_domain (manage IOAPIC delivery entries/pins) - -There are four major interfaces to use hierarchy irq_domain: - -1) irq_domain_alloc_irqs(): allocate IRQ descriptors and interrupt - controller related resources to deliver these interrupts. -2) irq_domain_free_irqs(): free IRQ descriptors and interrupt controller - related resources associated with these interrupts. -3) irq_domain_activate_irq(): activate interrupt controller hardware to - deliver the interrupt. -4) irq_domain_deactivate_irq(): deactivate interrupt controller hardware - to stop delivering the interrupt. - -Following changes are needed to support hierarchy irq_domain: - -1) a new field 'parent' is added to struct irq_domain; it's used to - maintain irq_domain hierarchy information. -2) a new field 'parent_data' is added to struct irq_data; it's used to - build hierarchy irq_data to match hierarchy irq_domains. The irq_data - is used to store irq_domain pointer and hardware irq number. -3) new callbacks are added to struct irq_domain_ops to support hierarchy - irq_domain operations. - -With support of hierarchy irq_domain and hierarchy irq_data ready, an -irq_domain structure is built for each interrupt controller, and an -irq_data structure is allocated for each irq_domain associated with an -IRQ. Now we could go one step further to support stacked(hierarchy) -irq_chip. That is, an irq_chip is associated with each irq_data along -the hierarchy. A child irq_chip may implement a required action by -itself or by cooperating with its parent irq_chip. - -With stacked irq_chip, interrupt controller driver only needs to deal -with the hardware managed by itself and may ask for services from its -parent irq_chip when needed. So we could achieve a much cleaner -software architecture. - -For an interrupt controller driver to support hierarchy irq_domain, it -needs to: - -1) Implement irq_domain_ops.alloc and irq_domain_ops.free -2) Optionally implement irq_domain_ops.activate and - irq_domain_ops.deactivate. -3) Optionally implement an irq_chip to manage the interrupt controller - hardware. -4) No need to implement irq_domain_ops.map and irq_domain_ops.unmap, - they are unused with hierarchy irq_domain. - -Hierarchy irq_domain is in no way x86 specific, and is heavily used to -support other architectures, such as ARM, ARM64 etc. - -=== Debugging === - -Most of the internals of the IRQ subsystem are exposed in debugfs by -turning CONFIG_GENERIC_IRQ_DEBUGFS on.
diff --git a/Documentation/Makefile b/Documentation/Makefile index 7e12d10..6b12dd8 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile
@@ -98,7 +98,11 @@ pdfdocs: latexdocs @$(srctree)/scripts/sphinx-pre-install --version-check - $(foreach var,$(SPHINXDIRS), $(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit;) + $(foreach var,$(SPHINXDIRS), \ + $(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit; \ + mkdir -p $(BUILDDIR)/$(var)/pdf; \ + mv $(subst .tex,.pdf,$(wildcard $(BUILDDIR)/$(var)/latex/*.tex)) $(BUILDDIR)/$(var)/pdf/; \ + ) endif # HAVE_PDFLATEX
diff --git a/Documentation/PCI/boot-interrupts.rst b/Documentation/PCI/boot-interrupts.rst index d078ef3..2ec7012 100644 --- a/Documentation/PCI/boot-interrupts.rst +++ b/Documentation/PCI/boot-interrupts.rst
@@ -32,12 +32,13 @@ Spurious Interrupts. The IRQ will be disabled by the Linux kernel after it reaches a specific count with the error "nobody cared". This disabled IRQ now prevents valid usage by an existing interrupt which may happen to share -the IRQ line. +the IRQ line:: irq 19: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 2988 Comm: irq/34-nipalk Tainted: 4.14.87-rt49-02410-g4a640ec-dirty #1 Hardware name: National Instruments NI PXIe-8880/NI PXIe-8880, BIOS 2.1.5f1 01/09/2020 Call Trace: + <IRQ> ? dump_stack+0x46/0x5e ? __report_bad_irq+0x2e/0xb0 @@ -85,15 +86,18 @@ The mitigations take the form of PCI quirks. The preference has been to first identify and make use of a means to disable the routing to the PCH. In such a case a quirk to disable boot interrupt generation can be -added.[1] +added. [1]_ - Intel® 6300ESB I/O Controller Hub +Intel® 6300ESB I/O Controller Hub Alternate Base Address Register: BIE: Boot Interrupt Enable - 0 = Boot interrupt is enabled. - 1 = Boot interrupt is disabled. - Intel® Sandy Bridge through Sky Lake based Xeon servers: + == =========================== + 0 Boot interrupt is enabled. + 1 Boot interrupt is disabled. + == =========================== + +Intel® Sandy Bridge through Sky Lake based Xeon servers: Coherent Interface Protocol Interrupt Control dis_intx_route2pch/dis_intx_route2ich/dis_intx_route2dmi2: When this bit is set. Local INTx messages received from the @@ -109,12 +113,12 @@ disabled, the Linux kernel will reroute the valid interrupt to its legacy interrupt. This redirection of the handler will prevent the occurrence of the spurious interrupt detection which would ordinarily disable the IRQ -line due to excessive unhandled counts.[2] +line due to excessive unhandled counts. [2]_ The config option X86_REROUTE_FOR_BROKEN_BOOT_IRQS exists to enable (or disable) the redirection of the interrupt handler to the PCH interrupt line. The option can be overridden by either pci=ioapicreroute or -pci=noioapicreroute.[3] +pci=noioapicreroute. [3]_ More Documentation @@ -127,19 +131,19 @@ Example of disabling of the boot interrupt ------------------------------------------ -Intel® 6300ESB I/O Controller Hub (Document # 300641-004US) + - Intel® 6300ESB I/O Controller Hub (Document # 300641-004US) 5.7.3 Boot Interrupt https://www.intel.com/content/dam/doc/datasheet/6300esb-io-controller-hub-datasheet.pdf -Intel® Xeon® Processor E5-1600/2400/2600/4600 v3 Product Families -Datasheet - Volume 2: Registers (Document # 330784-003) + - Intel® Xeon® Processor E5-1600/2400/2600/4600 v3 Product Families + Datasheet - Volume 2: Registers (Document # 330784-003) 6.6.41 cipintrc Coherent Interface Protocol Interrupt Control https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e5-v3-datasheet-vol-2.pdf Example of handler rerouting ---------------------------- -Intel® 6700PXH 64-bit PCI Hub (Document # 302628) + - Intel® 6700PXH 64-bit PCI Hub (Document # 302628) 2.15.2 PCI Express Legacy INTx Support and Boot Interrupt https://www.intel.com/content/dam/doc/datasheet/6700pxh-64-bit-pci-hub-datasheet.pdf @@ -150,6 +154,6 @@ Sean V Kelley sean.v.kelley@linux.intel.com -[1] https://lore.kernel.org/r/12131949181903-git-send-email-sassmann@suse.de/ -[2] https://lore.kernel.org/r/12131949182094-git-send-email-sassmann@suse.de/ -[3] https://lore.kernel.org/r/487C8EA7.6020205@suse.de/ +.. [1] https://lore.kernel.org/r/12131949181903-git-send-email-sassmann@suse.de/ +.. [2] https://lore.kernel.org/r/12131949182094-git-send-email-sassmann@suse.de/ +.. [3] https://lore.kernel.org/r/487C8EA7.6020205@suse.de/
diff --git a/Documentation/PCI/endpoint/pci-endpoint.rst b/Documentation/PCI/endpoint/pci-endpoint.rst index 0e2311b..7536be44 100644 --- a/Documentation/PCI/endpoint/pci-endpoint.rst +++ b/Documentation/PCI/endpoint/pci-endpoint.rst
@@ -78,8 +78,8 @@ Cleanup the pci_epc_mem structure allocated during pci_epc_mem_init(). -APIs for the PCI Endpoint Function Driver -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +EPC APIs for the PCI Endpoint Function Driver +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This section lists the APIs that the PCI Endpoint core provides to be used by the PCI endpoint function driver. @@ -117,8 +117,8 @@ The PCI endpoint function driver should use pci_epc_mem_free_addr() to free the memory space allocated using pci_epc_mem_alloc_addr(). -Other APIs -~~~~~~~~~~ +Other EPC APIs +~~~~~~~~~~~~~~ There are other APIs provided by the EPC library. These are used for binding the EPF device with EPC device. pci-ep-cfs.c can be used as reference for @@ -160,8 +160,8 @@ The EPF library provides APIs to be used by the function driver and the EPC library to provide endpoint mode functionality. -APIs for the PCI Endpoint Function Driver -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +EPF APIs for the PCI Endpoint Function Driver +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This section lists the APIs that the PCI Endpoint core provides to be used by the PCI endpoint function driver. @@ -204,8 +204,8 @@ The PCI endpoint controller library invokes pci_epf_linkup() when the EPC device has established the connection to the host. -Other APIs -~~~~~~~~~~ +Other EPF APIs +~~~~~~~~~~~~~~ There are other APIs provided by the EPF library. These are used to notify the function driver when the EPF device is bound to the EPC device.
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index fd5e2cb..75b8ca0 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -1943,56 +1943,27 @@ Scheduler and RCU ~~~~~~~~~~~~~~~~~ -RCU depends on the scheduler, and the scheduler uses RCU to protect some -of its data structures. The preemptible-RCU ``rcu_read_unlock()`` -implementation must therefore be written carefully to avoid deadlocks -involving the scheduler's runqueue and priority-inheritance locks. In -particular, ``rcu_read_unlock()`` must tolerate an interrupt where the -interrupt handler invokes both ``rcu_read_lock()`` and -``rcu_read_unlock()``. This possibility requires ``rcu_read_unlock()`` -to use negative nesting levels to avoid destructive recursion via -interrupt handler's use of RCU. - -This scheduler-RCU requirement came as a `complete -surprise <https://lwn.net/Articles/453002/>`__. - -As noted above, RCU makes use of kthreads, and it is necessary to avoid -excessive CPU-time accumulation by these kthreads. This requirement was -no surprise, but RCU's violation of it when running context-switch-heavy -workloads when built with ``CONFIG_NO_HZ_FULL=y`` `did come as a -surprise +RCU makes use of kthreads, and it is necessary to avoid excessive CPU-time +accumulation by these kthreads. This requirement was no surprise, but +RCU's violation of it when running context-switch-heavy workloads when +built with ``CONFIG_NO_HZ_FULL=y`` `did come as a surprise [PDF] <http://www.rdrop.com/users/paulmck/scalability/paper/BareMetal.2015.01.15b.pdf>`__. RCU has made good progress towards meeting this requirement, even for context-switch-heavy ``CONFIG_NO_HZ_FULL=y`` workloads, but there is room for further improvement. -It is forbidden to hold any of scheduler's runqueue or -priority-inheritance spinlocks across an ``rcu_read_unlock()`` unless -interrupts have been disabled across the entire RCU read-side critical -section, that is, up to and including the matching ``rcu_read_lock()``. -Violating this restriction can result in deadlocks involving these -scheduler spinlocks. There was hope that this restriction might be -lifted when interrupt-disabled calls to ``rcu_read_unlock()`` started -deferring the reporting of the resulting RCU-preempt quiescent state -until the end of the corresponding interrupts-disabled region. -Unfortunately, timely reporting of the corresponding quiescent state to -expedited grace periods requires a call to ``raise_softirq()``, which -can acquire these scheduler spinlocks. In addition, real-time systems -using RCU priority boosting need this restriction to remain in effect -because deferred quiescent-state reporting would also defer deboosting, -which in turn would degrade real-time latencies. +There is no longer any prohibition against holding any of +scheduler's runqueue or priority-inheritance spinlocks across an +``rcu_read_unlock()``, even if interrupts and preemption were enabled +somewhere within the corresponding RCU read-side critical section. +Therefore, it is now perfectly legal to execute ``rcu_read_lock()`` +with preemption enabled, acquire one of the scheduler locks, and hold +that lock across the matching ``rcu_read_unlock()``. -In theory, if a given RCU read-side critical section could be guaranteed -to be less than one second in duration, holding a scheduler spinlock -across that critical section's ``rcu_read_unlock()`` would require only -that preemption be disabled across the entire RCU read-side critical -section, not interrupts. Unfortunately, given the possibility of vCPU -preemption, long-running interrupts, and so on, it is not possible in -practice to guarantee that a given RCU read-side critical section will -complete in less than one second. Therefore, as noted above, if -scheduler spinlocks are held across a given call to -``rcu_read_unlock()``, interrupts must be disabled across the entire RCU -read-side critical section. +Similarly, the RCU flavor consolidation has removed the need for negative +nesting. The fact that interrupt-disabled regions of code act as RCU +read-side critical sections implicitly avoids earlier issues that used +to result in destructive recursion via interrupt handler's use of RCU. Tracing and RCU ~~~~~~~~~~~~~~~
diff --git a/Documentation/admin-guide/LSM/tomoyo.rst b/Documentation/admin-guide/LSM/tomoyo.rst index e2d6b6e..4bc9c2b 100644 --- a/Documentation/admin-guide/LSM/tomoyo.rst +++ b/Documentation/admin-guide/LSM/tomoyo.rst
@@ -27,29 +27,29 @@ ======================= User <-> Kernel interface documentation is available at -http://tomoyo.osdn.jp/2.5/policy-specification/index.html . +https://tomoyo.osdn.jp/2.5/policy-specification/index.html . Materials we prepared for seminars and symposiums are available at -http://osdn.jp/projects/tomoyo/docs/?category_id=532&language_id=1 . +https://osdn.jp/projects/tomoyo/docs/?category_id=532&language_id=1 . Below lists are chosen from three aspects. What is TOMOYO? TOMOYO Linux Overview - http://osdn.jp/projects/tomoyo/docs/lca2009-takeda.pdf + https://osdn.jp/projects/tomoyo/docs/lca2009-takeda.pdf TOMOYO Linux: pragmatic and manageable security for Linux - http://osdn.jp/projects/tomoyo/docs/freedomhectaipei-tomoyo.pdf + https://osdn.jp/projects/tomoyo/docs/freedomhectaipei-tomoyo.pdf TOMOYO Linux: A Practical Method to Understand and Protect Your Own Linux Box - http://osdn.jp/projects/tomoyo/docs/PacSec2007-en-no-demo.pdf + https://osdn.jp/projects/tomoyo/docs/PacSec2007-en-no-demo.pdf What can TOMOYO do? Deep inside TOMOYO Linux - http://osdn.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf + https://osdn.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf The role of "pathname based access control" in security. - http://osdn.jp/projects/tomoyo/docs/lfj2008-bof.pdf + https://osdn.jp/projects/tomoyo/docs/lfj2008-bof.pdf History of TOMOYO? Realities of Mainlining - http://osdn.jp/projects/tomoyo/docs/lfj2008.pdf + https://osdn.jp/projects/tomoyo/docs/lfj2008.pdf What is future plan? ====================
diff --git a/Documentation/admin-guide/README.rst b/Documentation/admin-guide/README.rst index cc6151f..5fb5269 100644 --- a/Documentation/admin-guide/README.rst +++ b/Documentation/admin-guide/README.rst
@@ -209,15 +209,22 @@ store the lsmod of that machine into a file and pass it in as a LSMOD parameter. + Also, you can preserve modules in certain folders + or kconfig files by specifying their paths in + parameter LMC_KEEP. + target$ lsmod > /tmp/mylsmod target$ scp /tmp/mylsmod host:/tmp - host$ make LSMOD=/tmp/mylsmod localmodconfig + host$ make LSMOD=/tmp/mylsmod \ + LMC_KEEP="drivers/usb:drivers/gpu:fs" \ + localmodconfig The above also works when cross compiling. "make localyesconfig" Similar to localmodconfig, except it will convert - all module options to built in (=y) options. + all module options to built in (=y) options. You can + also preserve modules by LMC_KEEP. "make kvmconfig" Enable additional options for kvm guest kernel support.
diff --git a/Documentation/admin-guide/acpi/initrd_table_override.rst b/Documentation/admin-guide/acpi/initrd_table_override.rst index cbd7682..bb24fa6 100644 --- a/Documentation/admin-guide/acpi/initrd_table_override.rst +++ b/Documentation/admin-guide/acpi/initrd_table_override.rst
@@ -102,7 +102,7 @@ ================================= iasl and acpixtract are part of Intel's ACPICA project: -http://acpica.org/ +https://acpica.org/ and should be packaged by distributions (for example in the acpica package on SUSE).
diff --git a/Documentation/admin-guide/acpi/ssdt-overlays.rst b/Documentation/admin-guide/acpi/ssdt-overlays.rst index da37455..5d7e259 100644 --- a/Documentation/admin-guide/acpi/ssdt-overlays.rst +++ b/Documentation/admin-guide/acpi/ssdt-overlays.rst
@@ -63,7 +63,7 @@ ASL Input: minnomax.asl - 30 lines, 614 bytes, 7 keywords AML Output: minnowmax.aml - 165 bytes, 6 named objects, 1 executable opcodes -[1] http://wiki.minnowboard.org/MinnowBoard_MAX#Low_Speed_Expansion_Connector_.28Top.29 +[1] https://www.elinux.org/Minnowboard:MinnowMax#Low_Speed_Expansion_.28Top.29 The resulting AML code can then be loaded by the kernel using one of the methods below.
diff --git a/Documentation/admin-guide/bcache.rst b/Documentation/admin-guide/bcache.rst index c0ce64d..1eccf95 100644 --- a/Documentation/admin-guide/bcache.rst +++ b/Documentation/admin-guide/bcache.rst
@@ -7,9 +7,9 @@ Wiki and git repositories are at: - - http://bcache.evilpiepirate.org + - https://bcache.evilpiepirate.org - http://evilpiepirate.org/git/linux-bcache.git - - http://evilpiepirate.org/git/bcache-tools.git + - https://evilpiepirate.org/git/bcache-tools.git It's designed around the performance characteristics of SSDs - it only allocates in erase block sized buckets, and it uses a hybrid btree/log to track cached
diff --git a/Documentation/admin-guide/bug-hunting.rst b/Documentation/admin-guide/bug-hunting.rst index 44b8a4e..f7c80f4 100644 --- a/Documentation/admin-guide/bug-hunting.rst +++ b/Documentation/admin-guide/bug-hunting.rst
@@ -49,15 +49,19 @@ Despite being an **Oops** or some other sort of stack trace, the offended line is usually required to identify and handle the bug. Along this chapter, -we'll refer to "Oops" for all kinds of stack traces that need to be analized. +we'll refer to "Oops" for all kinds of stack traces that need to be analyzed. -.. note:: +If the kernel is compiled with ``CONFIG_DEBUG_INFO``, you can enhance the +quality of the stack trace by using file:`scripts/decode_stacktrace.sh`. - ``ksymoops`` is useless on 2.6 or upper. Please use the Oops in its original - format (from ``dmesg``, etc). Ignore any references in this or other docs to - "decoding the Oops" or "running it through ksymoops". - If you post an Oops from 2.6+ that has been run through ``ksymoops``, - people will just tell you to repost it. +Modules linked in +----------------- + +Modules that are tainted or are being loaded or unloaded are marked with +"(...)", where the taint flags are described in +file:`Documentation/admin-guide/tainted-kernels.rst`, "being loaded" is +annotated with "+", and "being unloaded" is annotated with "-". + Where is the Oops message is located? ------------------------------------- @@ -71,7 +75,7 @@ Sometimes ``klogd`` dies, in which case you can run ``dmesg > file`` to read the data from the kernel buffers and save it. Or you can ``cat /proc/kmsg > file``, however you have to break in to stop the transfer, -``kmsg`` is a "never ending file". +since ``kmsg`` is a "never ending file". If the machine has crashed so badly that you cannot enter commands or the disk is not available then you have three options: @@ -81,9 +85,9 @@ planned for a crash. Alternatively, you can take a picture of the screen with a digital camera - not nice, but better than nothing. If the messages scroll off the top of the console, you - may find that booting with a higher resolution (eg, ``vga=791``) + may find that booting with a higher resolution (e.g., ``vga=791``) will allow you to read more of the text. (Caveat: This needs ``vesafb``, - so won't help for 'early' oopses) + so won't help for 'early' oopses.) (2) Boot with a serial console (see :ref:`Documentation/admin-guide/serial-console.rst <serial_console>`), @@ -104,7 +108,7 @@ gdb ^^^ -The GNU debug (``gdb``) is the best way to figure out the exact file and line +The GNU debugger (``gdb``) is the best way to figure out the exact file and line number of the OOPS from the ``vmlinux`` file. The usage of gdb works best on a kernel compiled with ``CONFIG_DEBUG_INFO``. @@ -165,7 +169,7 @@ [<ffffffff8802770b>] :jbd:journal_stop+0x1be/0x1ee ... -this shows the problem likely in the :jbd: module. You can load that module +this shows the problem likely is in the :jbd: module. You can load that module in gdb and list the relevant code:: $ gdb fs/jbd/jbd.ko @@ -199,8 +203,9 @@ You need to be at the top level of the kernel tree for this to pick up your C files. -If you don't have access to the code you can also debug on some crash dumps -e.g. crash dump output as shown by Dave Miller:: +If you don't have access to the source code you can still debug some crash +dumps using the following method (example crash dump output as shown by +Dave Miller):: EIP is at +0x14/0x4c0 ... @@ -230,6 +235,9 @@ mov 0x8(%ebp), %ebx ! %ebx = skb->sk mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt +file:`scripts/decodecode` can be used to automate most of this, depending +on what CPU architecture is being debugged. + Reporting the bug ----------------- @@ -241,7 +249,7 @@ the ``get_maintainer.pl`` script. For example, if you find a bug at the gspca's sonixj.c file, you can get -their maintainers with:: +its maintainers with:: $ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c Hans Verkuil <hverkuil@xs4all.nl> (odd fixer:GSPCA USB WEBCAM DRIVER,commit_signer:1/1=100%) @@ -253,16 +261,17 @@ Please notice that it will point to: -- The last developers that touched on the source code. On the above example, - Tejun and Bhaktipriya (in this specific case, none really envolved on the - development of this file); +- The last developers that touched the source code (if this is done inside + a git tree). On the above example, Tejun and Bhaktipriya (in this + specific case, none really envolved on the development of this file); - The driver maintainer (Hans Verkuil); - The subsystem maintainer (Mauro Carvalho Chehab); - The driver and/or subsystem mailing list (linux-media@vger.kernel.org); - the Linux Kernel mailing list (linux-kernel@vger.kernel.org). Usually, the fastest way to have your bug fixed is to report it to mailing -list used for the development of the code (linux-media ML) copying the driver maintainer (Hans). +list used for the development of the code (linux-media ML) copying the +driver maintainer (Hans). If you are totally stumped as to whom to send the report, and ``get_maintainer.pl`` didn't provide you anything useful, send it to @@ -303,9 +312,9 @@ and forwarded to the kernel developers. Two types of address resolution are performed by ``klogd``. The first is -static translation and the second is dynamic translation. Static -translation uses the System.map file in much the same manner that -ksymoops does. In order to do static translation the ``klogd`` daemon +static translation and the second is dynamic translation. +Static translation uses the System.map file. +In order to do static translation the ``klogd`` daemon must be able to find a system map file at daemon initialization time. See the klogd man page for information on how ``klogd`` searches for map files.
diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index 0ae4f56..12757e6 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst
@@ -199,11 +199,11 @@ unaccounted when it's removed from radix-tree. Even if RSS pages are fully unmapped (by kswapd), they may exist as SwapCache in the system until they are really freed. Such SwapCaches are also accounted. -A swapped-in page is not accounted until it's mapped. +A swapped-in page is accounted after adding into swapcache. Note: The kernel does swapin-readahead and reads multiple swaps at once. -This means swapped-in pages may contain pages for other tasks than a task -causing page fault. So, we avoid accounting at swap-in I/O. +Since page's memcg recorded into swap whatever memsw enabled, the page will +be accounted after swapin. At page migration, accounting information is kept. @@ -222,18 +222,13 @@ But see section 8.2: when moving a task to another cgroup, its pages may be recharged to the new cgroup, if move_charge_at_immigrate has been chosen. -Exception: If CONFIG_MEMCG_SWAP is not used. -When you do swapoff and make swapped-out pages of shmem(tmpfs) to -be backed into memory in force, charges for pages are accounted against the -caller of swapoff rather than the users of shmem. - -2.4 Swap Extension (CONFIG_MEMCG_SWAP) +2.4 Swap Extension -------------------------------------- -Swap Extension allows you to record charge for swap. A swapped-in page is -charged back to original page allocator if possible. +Swap usage is always recorded for each of cgroup. Swap Extension allows you to +read and limit it. -When swap is accounted, following files are added. +When CONFIG_SWAP is enabled, following files are added. - memory.memsw.usage_in_bytes. - memory.memsw.limit_in_bytes.
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index bcc80269..ce3e05e 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -714,9 +714,7 @@ - Settings for a single feature should be contained in a single file. - The root cgroup should be exempt from resource control and thus - shouldn't have resource control interface files. Also, - informational files on the root cgroup which end up showing global - information available elsewhere shouldn't exist. + shouldn't have resource control interface files. - The default time unit is microseconds. If a different unit is ever used, an explicit unit suffix must be present. @@ -985,7 +983,7 @@ All time durations are in microseconds. cpu.stat - A read-only flat-keyed file which exists on non-root cgroups. + A read-only flat-keyed file. This file exists whether the controller is enabled or not. It always reports the following three stats: @@ -1172,6 +1170,13 @@ Under certain circumstances, the usage may go over the limit temporarily. + In default configuration regular 0-order allocations always + succeed unless OOM killer chooses current task as a victim. + + Some kinds of allocations don't invoke the OOM killer. + Caller could retry them differently, return into userspace + as -ENOMEM or silently ignore in cases like disk readahead. + This is the ultimate protection mechanism. As long as the high limit is used and monitored properly, this limit's utility is limited to providing the final safety net. @@ -1228,17 +1233,9 @@ The number of time the cgroup's memory usage was reached the limit and allocation was about to fail. - Depending on context result could be invocation of OOM - killer and retrying allocation or failing allocation. - - Failed allocation in its turn could be returned into - userspace as -ENOMEM or silently ignored in cases like - disk readahead. For now OOM in memory cgroup kills - tasks iff shortage has happened inside page fault. - This event is not raised if the OOM killer is not considered as an option, e.g. for failed high-order - allocations. + allocations or if caller asked to not retry attempts. oom_kill The number of processes belonging to this cgroup @@ -1329,6 +1326,10 @@ workingset_activate Number of refaulted pages that were immediately activated + workingset_restore + Number of restored pages which have been detected as an active + workingset before they got reclaimed. + workingset_nodereclaim Number of times a shadow node has been reclaimed @@ -1370,6 +1371,22 @@ The total amount of swap currently being used by the cgroup and its descendants. + memory.swap.high + A read-write single value file which exists on non-root + cgroups. The default is "max". + + Swap usage throttle limit. If a cgroup's swap usage exceeds + this limit, all its further allocations will be throttled to + allow userspace to implement custom out-of-memory procedures. + + This limit marks a point of no return for the cgroup. It is NOT + designed to manage the amount of swapping a workload does + during regular operation. Compare to memory.swap.max, which + prohibits swapping past a set amount, but lets the cgroup + continue unimpeded as long as other memory can be reclaimed. + + Healthy workloads are not expected to reach this limit. + memory.swap.max A read-write single value file which exists on non-root cgroups. The default is "max". @@ -1383,6 +1400,10 @@ otherwise, a value change in this file generates a file modified event. + high + The number of times the cgroup's swap usage was over + the high threshold. + max The number of times the cgroup's swap usage was about to go over the max boundary and swap allocation
diff --git a/Documentation/admin-guide/cpu-load.rst b/Documentation/admin-guide/cpu-load.rst index 2d01ce4..ebdecf8 100644 --- a/Documentation/admin-guide/cpu-load.rst +++ b/Documentation/admin-guide/cpu-load.rst
@@ -105,7 +105,7 @@ ---------- - http://lkml.org/lkml/2007/2/12/6 -- Documentation/filesystems/proc.txt (1.8) +- Documentation/filesystems/proc.rst (1.8) Thanks
diff --git a/Documentation/admin-guide/device-mapper/dm-ebs.rst b/Documentation/admin-guide/device-mapper/dm-ebs.rst new file mode 100644 index 0000000..534fa38 --- /dev/null +++ b/Documentation/admin-guide/device-mapper/dm-ebs.rst
@@ -0,0 +1,51 @@ +====== +dm-ebs +====== + + +This target is similar to the linear target except that it emulates +a smaller logical block size on a device with a larger logical block +size. Its main purpose is to provide emulation of 512 byte sectors on +devices that do not provide this emulation (i.e. 4K native disks). + +Supported emulated logical block sizes 512, 1024, 2048 and 4096. + +Underlying block size can be set to > 4K to test buffering larger units. + + +Table parameters +---------------- + <dev path> <offset> <emulated sectors> [<underlying sectors>] + +Mandatory parameters: + + <dev path>: + Full pathname to the underlying block-device, + or a "major:minor" device-number. + <offset>: + Starting sector within the device; + has to be a multiple of <emulated sectors>. + <emulated sectors>: + Number of sectors defining the logical block size to be emulated; + 1, 2, 4, 8 sectors of 512 bytes supported. + +Optional parameter: + + <underyling sectors>: + Number of sectors defining the logical block size of <dev path>. + 2^N supported, e.g. 8 = emulate 8 sectors of 512 bytes = 4KiB. + If not provided, the logical block size of <dev path> will be used. + + +Examples: + +Emulate 1 sector = 512 bytes logical block size on /dev/sda starting at +offset 1024 sectors with underlying devices block size automatically set: + +ebs /dev/sda 1024 1 + +Emulate 2 sector = 1KiB logical block size on /dev/sda starting at +offset 128 sectors, enforce 2KiB underlying device block size. +This presumes 2KiB logical blocksize on /dev/sda or less to work: + +ebs /dev/sda 128 2 4
diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst b/Documentation/admin-guide/device-mapper/dm-integrity.rst index c00f9f1..9edd455 100644 --- a/Documentation/admin-guide/device-mapper/dm-integrity.rst +++ b/Documentation/admin-guide/device-mapper/dm-integrity.rst
@@ -182,12 +182,23 @@ space-efficient. If this option is not present, large padding is used - that is for compatibility with older kernels. +allow_discards + Allow block discard requests (a.k.a. TRIM) for the integrity device. + Discards are only allowed to devices using internal hash. -The journal mode (D/J), buffer_sectors, journal_watermark, commit_time can -be changed when reloading the target (load an inactive table and swap the -tables with suspend and resume). The other arguments should not be changed -when reloading the target because the layout of disk data depend on them -and the reloaded target would be non-functional. +The journal mode (D/J), buffer_sectors, journal_watermark, commit_time and +allow_discards can be changed when reloading the target (load an inactive +table and swap the tables with suspend and resume). The other arguments +should not be changed when reloading the target because the layout of disk +data depend on them and the reloaded target would be non-functional. + + +Status line: + +1. the number of integrity mismatches +2. provided data sectors - that is the number of sectors that the user + could use +3. the current recalculating position (or '-' if we didn't recalculate) The layout of the formatted block device:
diff --git a/Documentation/admin-guide/device-mapper/dm-zoned.rst b/Documentation/admin-guide/device-mapper/dm-zoned.rst index 07f56eb..553752e 100644 --- a/Documentation/admin-guide/device-mapper/dm-zoned.rst +++ b/Documentation/admin-guide/device-mapper/dm-zoned.rst
@@ -37,9 +37,13 @@ dm-zoned implements an on-disk buffering scheme to handle non-sequential write accesses to the sequential zones of a zoned block device. Conventional zones are used for caching as well as for storing internal -metadata. +metadata. It can also use a regular block device together with the zoned +block device; in that case the regular block device will be split logically +in zones with the same size as the zoned block device. These zones will be +placed in front of the zones from the zoned block device and will be handled +just like conventional zones. -The zones of the device are separated into 2 types: +The zones of the device(s) are separated into 2 types: 1) Metadata zones: these are conventional zones used to store metadata. Metadata zones are not reported as useable capacity to the user. @@ -127,6 +131,13 @@ discard requests. Read requests can be processed concurrently while metadata flush is being executed. +If a regular device is used in conjunction with the zoned block device, +a third set of metadata (without the zone bitmaps) is written to the +start of the zoned block device. This metadata has a generation counter of +'0' and will never be updated during normal operation; it just serves for +identification purposes. The first and second copy of the metadata +are located at the start of the regular block device. + Usage ===== @@ -138,9 +149,46 @@ dmzadm --format /dev/sdxx -For a formatted device, the target can be created normally with the -dmsetup utility. The only parameter that dm-zoned requires is the -underlying zoned block device name. Ex:: - echo "0 `blockdev --getsize ${dev}` zoned ${dev}" | \ - dmsetup create dmz-`basename ${dev}` +If two drives are to be used, both devices must be specified, with the +regular block device as the first device. + +Ex:: + + dmzadm --format /dev/sdxx /dev/sdyy + + +Fomatted device(s) can be started with the dmzadm utility, too.: + +Ex:: + + dmzadm --start /dev/sdxx /dev/sdyy + + +Information about the internal layout and current usage of the zones can +be obtained with the 'status' callback from dmsetup: + +Ex:: + + dmsetup status /dev/dm-X + +will return a line + + 0 <size> zoned <nr_zones> zones <nr_unmap_rnd>/<nr_rnd> random <nr_unmap_seq>/<nr_seq> sequential + +where <nr_zones> is the total number of zones, <nr_unmap_rnd> is the number +of unmapped (ie free) random zones, <nr_rnd> the total number of zones, +<nr_unmap_seq> the number of unmapped sequential zones, and <nr_seq> the +total number of sequential zones. + +Normally the reclaim process will be started once there are less than 50 +percent free random zones. In order to start the reclaim process manually +even before reaching this threshold the 'dmsetup message' function can be +used: + +Ex:: + + dmsetup message /dev/dm-X 0 reclaim + +will start the reclaim process and random zones will be moved to sequential +zones.
diff --git a/Documentation/admin-guide/devices.rst b/Documentation/admin-guide/devices.rst index d41671a..035275f 100644 --- a/Documentation/admin-guide/devices.rst +++ b/Documentation/admin-guide/devices.rst
@@ -17,7 +17,7 @@ to involve for character and block devices. This document is included by reference into the Filesystem Hierarchy -Standard (FHS). The FHS is available from http://www.pathname.com/fhs/. +Standard (FHS). The FHS is available from https://www.pathname.com/fhs/. Allocations marked (68k/Amiga) apply to Linux/68k on the Amiga platform only. Allocations marked (68k/Atari) apply to Linux/68k on
diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index 0dc2eb8..1012bd9 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst
@@ -13,6 +13,11 @@ ``print_hex_dump_debug()``/``print_hex_dump_bytes()`` calls can be dynamically enabled per-callsite. +If you do not want to enable dynamic debug globally (i.e. in some embedded +system), you may set ``CONFIG_DYNAMIC_DEBUG_CORE`` as basic support of dynamic +debug and add ``ccflags := -DDYNAMIC_DEBUG_MODULE`` into the Makefile of any +modules which you'd like to dynamically debug later. + If ``CONFIG_DYNAMIC_DEBUG`` is not set, ``print_hex_dump_debug()`` is just shortcut for ``print_hex_dump(KERN_DEBUG)``.
diff --git a/Documentation/admin-guide/gpio/gpio-aggregator.rst b/Documentation/admin-guide/gpio/gpio-aggregator.rst new file mode 100644 index 0000000..5cd1e72 --- /dev/null +++ b/Documentation/admin-guide/gpio/gpio-aggregator.rst
@@ -0,0 +1,111 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +GPIO Aggregator +=============== + +The GPIO Aggregator provides a mechanism to aggregate GPIOs, and expose them as +a new gpio_chip. This supports the following use cases. + + +Aggregating GPIOs using Sysfs +----------------------------- + +GPIO controllers are exported to userspace using /dev/gpiochip* character +devices. Access control to these devices is provided by standard UNIX file +system permissions, on an all-or-nothing basis: either a GPIO controller is +accessible for a user, or it is not. + +The GPIO Aggregator provides access control for a set of one or more GPIOs, by +aggregating them into a new gpio_chip, which can be assigned to a group or user +using standard UNIX file ownership and permissions. Furthermore, this +simplifies and hardens exporting GPIOs to a virtual machine, as the VM can just +grab the full GPIO controller, and no longer needs to care about which GPIOs to +grab and which not, reducing the attack surface. + +Aggregated GPIO controllers are instantiated and destroyed by writing to +write-only attribute files in sysfs. + + /sys/bus/platform/drivers/gpio-aggregator/ + + "new_device" ... + Userspace may ask the kernel to instantiate an aggregated GPIO + controller by writing a string describing the GPIOs to + aggregate to the "new_device" file, using the format + + .. code-block:: none + + [<gpioA>] [<gpiochipB> <offsets>] ... + + Where: + + "<gpioA>" ... + is a GPIO line name, + + "<gpiochipB>" ... + is a GPIO chip label, and + + "<offsets>" ... + is a comma-separated list of GPIO offsets and/or + GPIO offset ranges denoted by dashes. + + Example: Instantiate a new GPIO aggregator by aggregating GPIO + line 19 of "e6052000.gpio" and GPIO lines 20-21 of + "e6050000.gpio" into a new gpio_chip: + + .. code-block:: sh + + $ echo 'e6052000.gpio 19 e6050000.gpio 20-21' > new_device + + "delete_device" ... + Userspace may ask the kernel to destroy an aggregated GPIO + controller after use by writing its device name to the + "delete_device" file. + + Example: Destroy the previously-created aggregated GPIO + controller, assumed to be "gpio-aggregator.0": + + .. code-block:: sh + + $ echo gpio-aggregator.0 > delete_device + + +Generic GPIO Driver +------------------- + +The GPIO Aggregator can also be used as a generic driver for a simple +GPIO-operated device described in DT, without a dedicated in-kernel driver. +This is useful in industrial control, and is not unlike e.g. spidev, which +allows the user to communicate with an SPI device from userspace. + +Binding a device to the GPIO Aggregator is performed either by modifying the +gpio-aggregator driver, or by writing to the "driver_override" file in Sysfs. + +Example: If "door" is a GPIO-operated device described in DT, using its own +compatible value:: + + door { + compatible = "myvendor,mydoor"; + + gpios = <&gpio2 19 GPIO_ACTIVE_HIGH>, + <&gpio2 20 GPIO_ACTIVE_LOW>; + gpio-line-names = "open", "lock"; + }; + +it can be bound to the GPIO Aggregator by either: + +1. Adding its compatible value to ``gpio_aggregator_dt_ids[]``, +2. Binding manually using "driver_override": + +.. code-block:: sh + + $ echo gpio-aggregator > /sys/bus/platform/devices/door/driver_override + $ echo door > /sys/bus/platform/drivers/gpio-aggregator/bind + +After that, a new gpiochip "door" has been created: + +.. code-block:: sh + + $ gpioinfo door + gpiochip12 - 2 lines: + line 0: "open" unused input active-high + line 1: "lock" unused input active-high
diff --git a/Documentation/admin-guide/gpio/index.rst b/Documentation/admin-guide/gpio/index.rst index a244ba4..ef28386 100644 --- a/Documentation/admin-guide/gpio/index.rst +++ b/Documentation/admin-guide/gpio/index.rst
@@ -7,6 +7,7 @@ .. toctree:: :maxdepth: 1 + gpio-aggregator sysfs .. only:: subproject and html
diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index 0795e3c..ca4dbdd 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst
@@ -14,3 +14,4 @@ mds tsx_async_abort multihit.rst + special-register-buffer-data-sampling.rst
diff --git a/Documentation/admin-guide/hw-vuln/l1tf.rst b/Documentation/admin-guide/hw-vuln/l1tf.rst index f83212f..3eeeb48 100644 --- a/Documentation/admin-guide/hw-vuln/l1tf.rst +++ b/Documentation/admin-guide/hw-vuln/l1tf.rst
@@ -268,7 +268,7 @@ /proc/irq/$NR/smp_affinity[_list] files. Limited documentation is available at: - https://www.kernel.org/doc/Documentation/IRQ-affinity.txt + https://www.kernel.org/doc/Documentation/core-api/irq/irq-affinity.rst .. _smt_control:
diff --git a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file mode 100644 index 0000000..47b1b3a --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
@@ -0,0 +1,149 @@ +.. SPDX-License-Identifier: GPL-2.0 + +SRBDS - Special Register Buffer Data Sampling +============================================= + +SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to +infer values returned from special register accesses. Special register +accesses are accesses to off core registers. According to Intel's evaluation, +the special register reads that have a security expectation of privacy are +RDRAND, RDSEED and SGX EGETKEY. + +When RDRAND, RDSEED and EGETKEY instructions are used, the data is moved +to the core through the special register mechanism that is susceptible +to MDS attacks. + +Affected processors +-------------------- +Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may +be affected. + +A processor is affected by SRBDS if its Family_Model and stepping is +in the following list, with the exception of the listed processors +exporting MDS_NO while Intel TSX is available yet not enabled. The +latter class of processors are only affected when Intel TSX is enabled +by software using TSX_CTRL_MSR otherwise they are not affected. + + ============= ============ ======== + common name Family_Model Stepping + ============= ============ ======== + IvyBridge 06_3AH All + + Haswell 06_3CH All + Haswell_L 06_45H All + Haswell_G 06_46H All + + Broadwell_G 06_47H All + Broadwell 06_3DH All + + Skylake_L 06_4EH All + Skylake 06_5EH All + + Kabylake_L 06_8EH <= 0xC + Kabylake 06_9EH <= 0xD + ============= ============ ======== + +Related CVEs +------------ + +The following CVE entry is related to this SRBDS issue: + + ============== ===== ===================================== + CVE-2020-0543 SRBDS Special Register Buffer Data Sampling + ============== ===== ===================================== + +Attack scenarios +---------------- +An unprivileged user can extract values returned from RDRAND and RDSEED +executed on another core or sibling thread using MDS techniques. + + +Mitigation mechanism +------------------- +Intel will release microcode updates that modify the RDRAND, RDSEED, and +EGETKEY instructions to overwrite secret special register data in the shared +staging buffer before the secret data can be accessed by another logical +processor. + +During execution of the RDRAND, RDSEED, or EGETKEY instructions, off-core +accesses from other logical processors will be delayed until the special +register read is complete and the secret data in the shared staging buffer is +overwritten. + +This has three effects on performance: + +#. RDRAND, RDSEED, or EGETKEY instructions have higher latency. + +#. Executing RDRAND at the same time on multiple logical processors will be + serialized, resulting in an overall reduction in the maximum RDRAND + bandwidth. + +#. Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other + logical processors that miss their core caches, with an impact similar to + legacy locked cache-line-split accesses. + +The microcode updates provide an opt-out mechanism (RNGDS_MITG_DIS) to disable +the mitigation for RDRAND and RDSEED instructions executed outside of Intel +Software Guard Extensions (Intel SGX) enclaves. On logical processors that +disable the mitigation using this opt-out mechanism, RDRAND and RDSEED do not +take longer to execute and do not impact performance of sibling logical +processors memory accesses. The opt-out mechanism does not affect Intel SGX +enclaves (including execution of RDRAND or RDSEED inside an enclave, as well +as EGETKEY execution). + +IA32_MCU_OPT_CTRL MSR Definition +-------------------------------- +Along with the mitigation for this issue, Intel added a new thread-scope +IA32_MCU_OPT_CTRL MSR, (address 0x123). The presence of this MSR and +RNGDS_MITG_DIS (bit 0) is enumerated by CPUID.(EAX=07H,ECX=0).EDX[SRBDS_CTRL = +9]==1. This MSR is introduced through the microcode update. + +Setting IA32_MCU_OPT_CTRL[0] (RNGDS_MITG_DIS) to 1 for a logical processor +disables the mitigation for RDRAND and RDSEED executed outside of an Intel SGX +enclave on that logical processor. Opting out of the mitigation for a +particular logical processor does not affect the RDRAND and RDSEED mitigations +for other logical processors. + +Note that inside of an Intel SGX enclave, the mitigation is applied regardless +of the value of RNGDS_MITG_DS. + +Mitigation control on the kernel command line +--------------------------------------------- +The kernel command line allows control over the SRBDS mitigation at boot time +with the option "srbds=". The option for this is: + + ============= ============================================================= + off This option disables SRBDS mitigation for RDRAND and RDSEED on + affected platforms. + ============= ============================================================= + +SRBDS System Information +----------------------- +The Linux kernel provides vulnerability status information through sysfs. For +SRBDS this can be accessed by the following sysfs file: +/sys/devices/system/cpu/vulnerabilities/srbds + +The possible values contained in this file are: + + ============================== ============================================= + Not affected Processor not vulnerable + Vulnerable Processor vulnerable and mitigation disabled + Vulnerable: No microcode Processor vulnerable and microcode is missing + mitigation + Mitigation: Microcode Processor is vulnerable and mitigation is in + effect. + Mitigation: TSX disabled Processor is only vulnerable when TSX is + enabled while this system was booted with TSX + disabled. + Unknown: Dependent on + hypervisor status Running on virtual guest processor that is + affected but with no way to know if host + processor is mitigated or vulnerable. + ============================== ============================================= + +SRBDS Default mitigation +------------------------ +This new microcode serializes processor access during execution of RDRAND, +RDSEED ensures that the shared buffer is overwritten before it is released for +reuse. Use the "srbds=off" kernel command line to disable the mitigation for +RDRAND and RDSEED.
diff --git a/Documentation/admin-guide/init.rst b/Documentation/admin-guide/init.rst index e89d97f..41f06a0 100644 --- a/Documentation/admin-guide/init.rst +++ b/Documentation/admin-guide/init.rst
@@ -1,52 +1,48 @@ -Explaining the dreaded "No init found." boot hang message +Explaining the "No working init found." boot hang message ========================================================= +:Authors: Andreas Mohr <andi at lisas period de> + Cristian Souza <cristianmsbr at gmail period com> -OK, so you've got this pretty unintuitive message (currently located -in init/main.c) and are wondering what the H*** went wrong. -Some high-level reasons for failure (listed roughly in order of execution) -to load the init binary are: +This document provides some high-level reasons for failure +(listed roughly in order of execution) to load the init binary. -A) Unable to mount root FS -B) init binary doesn't exist on rootfs -C) broken console device -D) binary exists but dependencies not available -E) binary cannot be loaded +1) **Unable to mount root FS**: Set "debug" kernel parameter (in bootloader + config file or CONFIG_CMDLINE) to get more detailed kernel messages. -Detailed explanations: +2) **init binary doesn't exist on rootfs**: Make sure you have the correct + root FS type (and ``root=`` kernel parameter points to the correct + partition), required drivers such as storage hardware (such as SCSI or + USB!) and filesystem (ext3, jffs2, etc.) are builtin (alternatively as + modules, to be pre-loaded by an initrd). -A) Set "debug" kernel parameter (in bootloader config file or CONFIG_CMDLINE) - to get more detailed kernel messages. -B) make sure you have the correct root FS type - (and ``root=`` kernel parameter points to the correct partition), - required drivers such as storage hardware (such as SCSI or USB!) - and filesystem (ext3, jffs2 etc.) are builtin (alternatively as modules, - to be pre-loaded by an initrd) -C) Possibly a conflict in ``console= setup`` --> initial console unavailable. - E.g. some serial consoles are unreliable due to serial IRQ issues (e.g. - missing interrupt-based configuration). +3) **Broken console device**: Possibly a conflict in ``console= setup`` + --> initial console unavailable. E.g. some serial consoles are unreliable + due to serial IRQ issues (e.g. missing interrupt-based configuration). Try using a different ``console= device`` or e.g. ``netconsole=``. -D) e.g. required library dependencies of the init binary such as - ``/lib/ld-linux.so.2`` missing or broken. Use - ``readelf -d <INIT>|grep NEEDED`` to find out which libraries are required. -E) make sure the binary's architecture matches your hardware. - E.g. i386 vs. x86_64 mismatch, or trying to load x86 on ARM hardware. - In case you tried loading a non-binary file here (shell script?), - you should make sure that the script specifies an interpreter in its shebang - header line (``#!/...``) that is fully working (including its library - dependencies). And before tackling scripts, better first test a simple - non-script binary such as ``/bin/sh`` and confirm its successful execution. - To find out more, add code ``to init/main.c`` to display kernel_execve()s - return values. + +4) **Binary exists but dependencies not available**: E.g. required library + dependencies of the init binary such as ``/lib/ld-linux.so.2`` missing or + broken. Use ``readelf -d <INIT>|grep NEEDED`` to find out which libraries + are required. + +5) **Binary cannot be loaded**: Make sure the binary's architecture matches + your hardware. E.g. i386 vs. x86_64 mismatch, or trying to load x86 on ARM + hardware. In case you tried loading a non-binary file here (shell script?), + you should make sure that the script specifies an interpreter in its + shebang header line (``#!/...``) that is fully working (including its + library dependencies). And before tackling scripts, better first test a + simple non-script binary such as ``/bin/sh`` and confirm its successful + execution. To find out more, add code ``to init/main.c`` to display + kernel_execve()s return values. Please extend this explanation whenever you find new failure causes (after all loading the init binary is a CRITICAL and hard transition step -which needs to be made as painless as possible), then submit patch to LKML. +which needs to be made as painless as possible), then submit a patch to LKML. Further TODOs: - Implement the various ``run_init_process()`` invocations via a struct array which can then store the ``kernel_execve()`` result value and on failure log it all by iterating over **all** results (very important usability fix). -- try to make the implementation itself more helpful in general, - e.g. by providing additional error messages at affected places. +- Try to make the implementation itself more helpful in general, e.g. by + providing additional error messages at affected places. -Andreas Mohr <andi at lisas period de>
diff --git a/Documentation/admin-guide/initrd.rst b/Documentation/admin-guide/initrd.rst index a03daba..67bbad8 100644 --- a/Documentation/admin-guide/initrd.rst +++ b/Documentation/admin-guide/initrd.rst
@@ -376,7 +376,7 @@ --------- .. [#f1] Almesberger, Werner; "Booting Linux: The History and the Future" - http://www.almesberger.net/cv/papers/ols2k-9.ps.gz + https://www.almesberger.net/cv/papers/ols2k-9.ps.gz .. [#f2] newlib package (experimental), with initrd example https://www.sourceware.org/newlib/ .. [#f3] util-linux: Miscellaneous utilities for Linux
diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst index ac7e131..2da65fe 100644 --- a/Documentation/admin-guide/kdump/kdump.rst +++ b/Documentation/admin-guide/kdump/kdump.rst
@@ -521,6 +521,14 @@ to specify this during runtime, /proc/sys/kernel/panic_on_warn can be set to 1 to achieve the same behaviour. +Trigger Kdump on add_taint() +============================ + +The kernel parameter panic_on_taint facilitates a conditional call to panic() +from within add_taint() whenever the value set in this bitmask matches with the +bit flag being set by add_taint(). +This will cause a kdump to occur at the add_taint()->panic() call. + Contact =======
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index 007a6b8..e4ee8b2 100644 --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -393,6 +393,12 @@ The kernel randomization offset. Used to compute the page offset. If KASLR is disabled, this value is zero. +KERNELPACMASK +------------- + +The mask to extract the Pointer Authentication Code from a kernel virtual +address. + arm ===
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 3ed0b42..fb95fad 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -356,7 +356,7 @@ shot down by NMI autoconf= [IPV6] - See Documentation/networking/ipv6.txt. + See Documentation/networking/ipv6.rst. show_lapic= [APIC,X86] Advanced Programmable Interrupt Controller Limit apic dumping. The parameter defines the maximal @@ -638,7 +638,7 @@ See Documentation/admin-guide/serial-console.rst for more information. See - Documentation/networking/netconsole.txt for an + Documentation/networking/netconsole.rst for an alternative. uart[8250],io,<addr>[,options] @@ -831,15 +831,18 @@ decnet.addr= [HW,NET] Format: <area>[,<node>] - See also Documentation/networking/decnet.txt. + See also Documentation/networking/decnet.rst. default_hugepagesz= - [same as hugepagesz=] The size of the default - HugeTLB page size. This is the size represented by - the legacy /proc/ hugepages APIs, used for SHM, and - default size when mounting hugetlbfs filesystems. - Defaults to the default architecture's huge page size - if not specified. + [HW] The size of the default HugeTLB page. This is + the size represented by the legacy /proc/ hugepages + APIs. In addition, this is the default hugetlb size + used for shmget(), mmap() and mounting hugetlbfs + filesystems. If not specified, defaults to the + architecture's default huge page size. Huge page + sizes are architecture dependent. See also + Documentation/admin-guide/mm/hugetlbpage.rst. + Format: size[KMG] deferred_probe_timeout= [KNL] Debugging option to set a timeout in seconds for @@ -871,8 +874,13 @@ can be useful when debugging issues that require an SLB miss to occur. + stress_slb [PPC] + Limits the number of kernel SLB entries, and flushes + them frequently to increase the rate of SLB faults + on kernel addresses. + disable= [IPV6] - See Documentation/networking/ipv6.txt. + See Documentation/networking/ipv6.rst. hardened_usercopy= [KNL] Under CONFIG_HARDENED_USERCOPY, whether @@ -912,7 +920,7 @@ to workaround buggy firmware. disable_ipv6= [IPV6] - See Documentation/networking/ipv6.txt. + See Documentation/networking/ipv6.rst. disable_mtrr_cleanup [X86] The kernel tries to adjust MTRR layout from continuous @@ -1190,6 +1198,11 @@ This is designed to be used in conjunction with the boot argument: earlyprintk=vga + This parameter works in place of the kgdboc parameter + but can only be used if the backing tty is available + very early in the boot process. For early debugging + via a serial port see kgdboc_earlycon instead. + edd= [EDD] Format: {"off" | "on" | "skip[mbr]"} @@ -1432,7 +1445,7 @@ hardlockup_all_cpu_backtrace= [KNL] Should the hard-lockup detector generate backtraces on all cpus. - Format: <integer> + Format: 0 | 1 hashdist= [KNL,NUMA] Large hashes allocated during boot are distributed across NUMA nodes. Defaults on @@ -1479,19 +1492,30 @@ hugepages using the cma allocator. If enabled, the boot-time allocation of gigantic hugepages is skipped. - hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot. - hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages. - On x86-64 and powerpc, this option can be specified - multiple times interleaved with hugepages= to reserve - huge pages of different sizes. Valid pages sizes on - x86-64 are 2M (when the CPU supports "pse") and 1G - (when the CPU supports the "pdpe1gb" cpuinfo flag). + hugepages= [HW] Number of HugeTLB pages to allocate at boot. + If this follows hugepagesz (below), it specifies + 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> + + hugepagesz= + [HW] The size of the HugeTLB pages. This is used in + conjunction with hugepages (above) to allocate huge + pages of a specific size at boot. The pair + hugepagesz=X hugepages=Y can be specified once for + each supported huge page size. Huge page sizes are + architecture dependent. See also + Documentation/admin-guide/mm/hugetlbpage.rst. + Format: size[KMG] hung_task_panic= [KNL] Should the hung task detector generate panics. - Format: <integer> + Format: 0 | 1 - A nonzero value instructs the kernel to panic when a + A value of 1 instructs the kernel to panic when a hung task is detected. The default value is controlled by the CONFIG_BOOTPARAM_HUNG_TASK_PANIC build-time option. The value selected by this boot parameter can @@ -1748,6 +1772,13 @@ initrd= [BOOT] Specify the location of the initial ramdisk + initrdmem= [KNL] Specify a physical address and size from which to + load the initrd. If an initrd is compiled in or + specified in the bootparams, it takes priority over this + setting. + Format: ss[KMG],nn[KMG] + Default is 0, 0 + init_on_alloc= [MM] Fill newly allocated pages and heap objects with zeroes. Format: 0 | 1 @@ -2105,6 +2136,21 @@ kms, kbd format: kms,kbd kms, kbd and serial format: kms,kbd,<ser_dev>[,baud] + kgdboc_earlycon= [KGDB,HW] + If the boot console provides the ability to read + characters and can work in polling mode, you can use + this parameter to tell kgdb to use it as a backend + until the normal console is registered. Intended to + be used together with the kgdboc parameter which + specifies the normal console to transition to. + + The name of the early console should be specified + as the value of this parameter. Note that the name of + the early console might be different than the tty + name passed to kgdboc. It's OK to leave the value + blank and the first boot console that implements + read() will be picked. + kgdbwait [KGDB] Stop kernel execution and enter the kernel debugger at the earliest opportunity. @@ -3329,7 +3375,7 @@ See Documentation/admin-guide/sysctl/vm.rst for details. ohci1394_dma=early [HW] enable debugging via the ohci1394 driver. - See Documentation/debugging-via-ohci1394.txt for more + See Documentation/core-api/debugging-via-ohci1394.rst for more info. olpc_ec_timeout= [OLPC] ms delay when issuing EC commands @@ -3401,6 +3447,19 @@ bit 4: print ftrace buffer bit 5: print all printk messages in buffer + panic_on_taint= Bitmask for conditionally calling panic() in add_taint() + Format: <hex>[,nousertaint] + Hexadecimal bitmask representing the set of TAINT flags + that will cause the kernel to panic when add_taint() is + called with any of the flags in this set. + The optional switch "nousertaint" can be utilized to + prevent userspace forced crashes by writing to sysctl + /proc/sys/kernel/tainted any flagset matching with the + bitmask set on panic_on_taint. + See Documentation/admin-guide/tainted-kernels.rst for + extra details on the taint flags that users can pick + to compose the bitmask to assign to panic_on_taint. + panic_on_warn panic() instead of WARN(). Useful to cause kdump on a WARN(). @@ -3669,6 +3728,8 @@ may put more devices in an IOMMU group. force_floating [S390] Force usage of floating interrupts. nomio [S390] Do not use MIO instructions. + norid [S390] ignore the RID field and force use of + one PCI domain per PCI function pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power Management. @@ -4210,12 +4271,24 @@ Duration of CPU stall (s) to test RCU CPU stall warnings, zero to disable. + rcutorture.stall_cpu_block= [KNL] + Sleep while stalling if set. This will result + in warnings from preemptible RCU in addition + to any other stall-related activity. + rcutorture.stall_cpu_holdoff= [KNL] Time to wait (s) after boot before inducing stall. rcutorture.stall_cpu_irqsoff= [KNL] Disable interrupts while stalling if set. + rcutorture.stall_gp_kthread= [KNL] + Duration (s) of forced sleep within RCU + grace-period kthread to test RCU CPU stall + warnings, zero to disable. If both stall_cpu + and stall_gp_kthread are specified, the + kthread is starved first, then the CPU. + rcutorture.stat_interval= [KNL] Time (s) between statistics printk()s. @@ -4286,6 +4359,13 @@ only normal grace-period primitives. No effect on CONFIG_TINY_RCU kernels. + rcupdate.rcu_task_ipi_delay= [KNL] + Set time in jiffies during which RCU tasks will + avoid sending IPIs, starting with the beginning + of a given grace period. Setting a large + number avoids disturbing real-time workloads, + but lengthens grace periods. + rcupdate.rcu_task_stall_timeout= [KNL] Set timeout in jiffies for RCU task stall warning messages. Disable with a value less than or equal @@ -4587,9 +4667,9 @@ softlockup_panic= [KNL] Should the soft-lockup detector generate panics. - Format: <integer> + Format: 0 | 1 - A nonzero value instructs the soft-lockup detector + A value of 1 instructs the soft-lockup detector to panic the machine when a soft-lockup occurs. It is also controlled by the kernel.softlockup_panic sysctl and CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC, which is the @@ -4598,7 +4678,7 @@ softlockup_all_cpu_backtrace= [KNL] Should the soft-lockup detector generate backtraces on all cpus. - Format: <integer> + Format: 0 | 1 sonypi.*= [HW] Sony Programmable I/O Control Device driver See Documentation/admin-guide/laptops/sonypi.rst @@ -4757,6 +4837,26 @@ the kernel will oops in either "warn" or "fatal" mode. + srbds= [X86,INTEL] + Control the Special Register Buffer Data Sampling + (SRBDS) mitigation. + + Certain CPUs are vulnerable to an MDS-like + exploit which can leak bits from the random + number generator. + + By default, this issue is mitigated by + microcode. However, the microcode fix can cause + the RDRAND and RDSEED instructions to become + much slower. Among other effects, this will + result in reduced throughput from /dev/urandom. + + The microcode mitigation can be disabled with + the following option: + + off: Disable mitigation and remove + performance impact to RDRAND and RDSEED + srcutree.counter_wrap_check [KNL] Specifies how frequently to check for grace-period sequence counter wrap for the @@ -4891,6 +4991,15 @@ switches= [HW,M68k] + sysctl.*= [KNL] + Set a sysctl parameter, right before loading the init + process, as if the value was written to the respective + /proc/sys/... file. Both '.' and '/' are recognized as + separators. Unrecognized parameters and invalid values + are reported in the kernel log. Sysctls registered + later by a loaded module cannot be set this way. + Example: sysctl.vm.swappiness=40 + sysfs.deprecated=0|1 [KNL] Enable/disable old style sysfs layout for old udev on older distributions. When this option is enabled @@ -4910,7 +5019,7 @@ Set the number of tcp_metrics_hash slots. Default value is 8192 or 16384 depending on total ram pages. This is used to specify the TCP metrics - cache size. See Documentation/networking/ip-sysctl.txt + cache size. See Documentation/networking/ip-sysctl.rst "tcp_no_metrics_save" section for more details. tdfx= [HW,DRM] @@ -5067,6 +5176,12 @@ interruptions from clocksource watchdog are not acceptable). + tsc_early_khz= [X86] Skip early TSC calibration and use the given + value instead. Useful when the early TSC frequency discovery + procedure is not reliable, such as on overclocked systems + with CPUID.16h support and partial CPUID.15h support. + Format: <unsigned int> + tsx= [X86] Control Transactional Synchronization Extensions (TSX) feature in Intel processors that support TSX control. @@ -5187,8 +5302,7 @@ usbcore.old_scheme_first= [USB] Start with the old device initialization - scheme, applies only to low and full-speed devices - (default 0 = off). + scheme (default 0 = off). usbcore.usbfs_memory_mb= [USB] Memory limit (in MB) for buffers allocated by
diff --git a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst index 21818ac..dc36aeb 100644 --- a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst +++ b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst
@@ -10,7 +10,7 @@ References ========== -- Documentation/IRQ-affinity.txt: Binding interrupts to sets of CPUs. +- Documentation/core-api/irq/irq-affinity.rst: Binding interrupts to sets of CPUs. - Documentation/admin-guide/cgroup-v1: Using cgroups to bind tasks to sets of CPUs.
diff --git a/Documentation/admin-guide/md.rst b/Documentation/admin-guide/md.rst index 3c51084..d973d46 100644 --- a/Documentation/admin-guide/md.rst +++ b/Documentation/admin-guide/md.rst
@@ -5,7 +5,7 @@ --------------------------------- Tools that manage md devices can be found at - http://www.kernel.org/pub/linux/utils/raid/ + https://www.kernel.org/pub/linux/utils/raid/ You can boot with your md device with the following kernel command
diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst index 1cc0bc7..5026e58 100644 --- a/Documentation/admin-guide/mm/hugetlbpage.rst +++ b/Documentation/admin-guide/mm/hugetlbpage.rst
@@ -100,6 +100,41 @@ be specified in bytes with optional scale suffix [kKmMgG]. The default huge page size may be selected with the "default_hugepagesz=<size>" boot parameter. +Hugetlb boot command line parameter semantics +hugepagesz - Specify a huge page size. Used in conjunction with hugepages + parameter to preallocate a number of huge pages of the specified + size. Hence, hugepagesz and hugepages are typically specified in + pairs such as: + hugepagesz=2M hugepages=512 + hugepagesz can only be specified once on the command line for a + specific huge page size. Valid huge page sizes are architecture + dependent. +hugepages - Specify the number of huge pages to preallocate. This typically + follows a valid hugepagesz or default_hugepagesz parameter. However, + if hugepages is the first or only hugetlb command line parameter it + 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. + For example, on an architecture with 2M default huge page size: + hugepages=256 hugepagesz=2M hugepages=512 + will result in 256 2M huge pages being allocated and a warning message + indicating that the hugepages=512 parameter is ignored. If a hugepages + parameter is preceded by an invalid hugepagesz parameter, it 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 + optionally be followed by the hugepages parameter to preallocate a + specific number of huge pages of default size. The number of default + sized huge pages to preallocate can also be implicitly specified as + mentioned in the hugepages section above. Therefore, on an + architecture with 2M default huge page size: + hugepages=256 + default_hugepagesz=2M hugepages=256 + hugepages=256 default_hugepagesz=2M + will all result in 256 2M huge pages being allocated. Valid default + huge page size is architecture dependent. + When multiple huge page sizes are supported, ``/proc/sys/vm/nr_hugepages`` indicates the current number of pre-allocated huge pages of the default size. Thus, one can use the following command to dynamically allocate/deallocate
diff --git a/Documentation/admin-guide/mm/numa_memory_policy.rst b/Documentation/admin-guide/mm/numa_memory_policy.rst index 8463f55..067a90a 100644 --- a/Documentation/admin-guide/mm/numa_memory_policy.rst +++ b/Documentation/admin-guide/mm/numa_memory_policy.rst
@@ -364,19 +364,19 @@ 2) for querying the policy, we do not need to take an extra reference on the target task's task policy nor vma policies because we always acquire the - task's mm's mmap_sem for read during the query. The set_mempolicy() and - mbind() APIs [see below] always acquire the mmap_sem for write when + task's mm's mmap_lock for read during the query. The set_mempolicy() and + mbind() APIs [see below] always acquire the mmap_lock for write when installing or replacing task or vma policies. Thus, there is no possibility of a task or thread freeing a policy while another task or thread is querying it. 3) Page allocation usage of task or vma policy occurs in the fault path where - we hold them mmap_sem for read. Again, because replacing the task or vma - policy requires that the mmap_sem be held for write, the policy can't be + we hold them mmap_lock for read. Again, because replacing the task or vma + policy requires that the mmap_lock be held for write, the policy can't be freed out from under us while we're using it for page allocation. 4) Shared policies require special consideration. One task can replace a - shared memory policy while another task, with a distinct mmap_sem, is + shared memory policy while another task, with a distinct mmap_lock, is querying or allocating a page based on the policy. To resolve this potential race, the shared policy infrastructure adds an extra reference to the shared policy during lookup while holding a spin lock on the shared
diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst index 2f31de8..6a233e4 100644 --- a/Documentation/admin-guide/mm/transhuge.rst +++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -220,6 +220,13 @@ collapsed, resulting fewer pages being collapsed into THPs, and lower memory access performance. +``max_ptes_shared`` specifies how many pages can be shared across multiple +processes. Exceeding the number would block the collapse:: + + /sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared + +A higher value may increase memory footprint for some workloads. + Boot parameter ==============
diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst index c30176e..1dc2d5f 100644 --- a/Documentation/admin-guide/mm/userfaultfd.rst +++ b/Documentation/admin-guide/mm/userfaultfd.rst
@@ -12,107 +12,107 @@ memory page faults, something otherwise only the kernel code could do. For example userfaults allows a proper and more optimal implementation -of the PROT_NONE+SIGSEGV trick. +of the ``PROT_NONE+SIGSEGV`` trick. Design ====== -Userfaults are delivered and resolved through the userfaultfd syscall. +Userfaults are delivered and resolved through the ``userfaultfd`` syscall. -The userfaultfd (aside from registering and unregistering virtual +The ``userfaultfd`` (aside from registering and unregistering virtual memory ranges) provides two primary functionalities: -1) read/POLLIN protocol to notify a userland thread of the faults +1) ``read/POLLIN`` protocol to notify a userland thread of the faults happening -2) various UFFDIO_* ioctls that can manage the virtual memory regions - registered in the userfaultfd that allows userland to efficiently +2) various ``UFFDIO_*`` ioctls that can manage the virtual memory regions + registered in the ``userfaultfd`` that allows userland to efficiently resolve the userfaults it receives via 1) or to manage the virtual memory in the background The real advantage of userfaults if compared to regular virtual memory management of mremap/mprotect is that the userfaults in all their operations never involve heavyweight structures like vmas (in fact the -userfaultfd runtime load never takes the mmap_sem for writing). +``userfaultfd`` runtime load never takes the mmap_lock for writing). Vmas are not suitable for page- (or hugepage) granular fault tracking when dealing with virtual address spaces that could span Terabytes. Too many vmas would be needed for that. -The userfaultfd once opened by invoking the syscall, can also be +The ``userfaultfd`` once opened by invoking the syscall, can also be passed using unix domain sockets to a manager process, so the same manager process could handle the userfaults of a multitude of different processes without them being aware about what is going on -(well of course unless they later try to use the userfaultfd +(well of course unless they later try to use the ``userfaultfd`` themselves on the same region the manager is already tracking, which -is a corner case that would currently return -EBUSY). +is a corner case that would currently return ``-EBUSY``). API === -When first opened the userfaultfd must be enabled invoking the -UFFDIO_API ioctl specifying a uffdio_api.api value set to UFFD_API (or -a later API version) which will specify the read/POLLIN protocol -userland intends to speak on the UFFD and the uffdio_api.features -userland requires. The UFFDIO_API ioctl if successful (i.e. if the -requested uffdio_api.api is spoken also by the running kernel and the +When first opened the ``userfaultfd`` must be enabled invoking the +``UFFDIO_API`` ioctl specifying a ``uffdio_api.api`` value set to ``UFFD_API`` (or +a later API version) which will specify the ``read/POLLIN`` protocol +userland intends to speak on the ``UFFD`` and the ``uffdio_api.features`` +userland requires. The ``UFFDIO_API`` ioctl if successful (i.e. if the +requested ``uffdio_api.api`` is spoken also by the running kernel and the requested features are going to be enabled) will return into -uffdio_api.features and uffdio_api.ioctls two 64bit bitmasks of +``uffdio_api.features`` and ``uffdio_api.ioctls`` two 64bit bitmasks of respectively all the available features of the read(2) protocol and the generic ioctl available. -The uffdio_api.features bitmask returned by the UFFDIO_API ioctl -defines what memory types are supported by the userfaultfd and what +The ``uffdio_api.features`` bitmask returned by the ``UFFDIO_API`` ioctl +defines what memory types are supported by the ``userfaultfd`` and what events, except page fault notifications, may be generated. -If the kernel supports registering userfaultfd ranges on hugetlbfs -virtual memory areas, UFFD_FEATURE_MISSING_HUGETLBFS will be set in -uffdio_api.features. Similarly, UFFD_FEATURE_MISSING_SHMEM will be -set if the kernel supports registering userfaultfd ranges on shared -memory (covering all shmem APIs, i.e. tmpfs, IPCSHM, /dev/zero -MAP_SHARED, memfd_create, etc). +If the kernel supports registering ``userfaultfd`` ranges on hugetlbfs +virtual memory areas, ``UFFD_FEATURE_MISSING_HUGETLBFS`` will be set in +``uffdio_api.features``. Similarly, ``UFFD_FEATURE_MISSING_SHMEM`` will be +set if the kernel supports registering ``userfaultfd`` ranges on shared +memory (covering all shmem APIs, i.e. tmpfs, ``IPCSHM``, ``/dev/zero``, +``MAP_SHARED``, ``memfd_create``, etc). -The userland application that wants to use userfaultfd with hugetlbfs +The userland application that wants to use ``userfaultfd`` with hugetlbfs or shared memory need to set the corresponding flag in -uffdio_api.features to enable those features. +``uffdio_api.features`` to enable those features. If the userland desires to receive notifications for events other than -page faults, it has to verify that uffdio_api.features has appropriate -UFFD_FEATURE_EVENT_* bits set. These events are described in more -detail below in "Non-cooperative userfaultfd" section. +page faults, it has to verify that ``uffdio_api.features`` has appropriate +``UFFD_FEATURE_EVENT_*`` bits set. These events are described in more +detail below in `Non-cooperative userfaultfd`_ section. -Once the userfaultfd has been enabled the UFFDIO_REGISTER ioctl should -be invoked (if present in the returned uffdio_api.ioctls bitmask) to -register a memory range in the userfaultfd by setting the -uffdio_register structure accordingly. The uffdio_register.mode +Once the ``userfaultfd`` has been enabled the ``UFFDIO_REGISTER`` ioctl should +be invoked (if present in the returned ``uffdio_api.ioctls`` bitmask) to +register a memory range in the ``userfaultfd`` by setting the +uffdio_register structure accordingly. The ``uffdio_register.mode`` bitmask will specify to the kernel which kind of faults to track for -the range (UFFDIO_REGISTER_MODE_MISSING would track missing -pages). The UFFDIO_REGISTER ioctl will return the -uffdio_register.ioctls bitmask of ioctls that are suitable to resolve +the range (``UFFDIO_REGISTER_MODE_MISSING`` would track missing +pages). The ``UFFDIO_REGISTER`` ioctl will return the +``uffdio_register.ioctls`` bitmask of ioctls that are suitable to resolve userfaults on the range registered. Not all ioctls will necessarily be supported for all memory types depending on the underlying virtual memory backend (anonymous memory vs tmpfs vs real filebacked mappings). -Userland can use the uffdio_register.ioctls to manage the virtual +Userland can use the ``uffdio_register.ioctls`` to manage the virtual address space in the background (to add or potentially also remove -memory from the userfaultfd registered range). This means a userfault +memory from the ``userfaultfd`` registered range). This means a userfault could be triggering just before userland maps in the background the user-faulted page. -The primary ioctl to resolve userfaults is UFFDIO_COPY. That +The primary ioctl to resolve userfaults is ``UFFDIO_COPY``. That atomically copies a page into the userfault registered range and wakes -up the blocked userfaults (unless uffdio_copy.mode & -UFFDIO_COPY_MODE_DONTWAKE is set). Other ioctl works similarly to -UFFDIO_COPY. They're atomic as in guaranteeing that nothing can see an -half copied page since it'll keep userfaulting until the copy has -finished. +up the blocked userfaults +(unless ``uffdio_copy.mode & UFFDIO_COPY_MODE_DONTWAKE`` is set). +Other ioctl works similarly to ``UFFDIO_COPY``. They're atomic as in +guaranteeing that nothing can see an half copied page since it'll +keep userfaulting until the copy has finished. Notes: -- If you requested UFFDIO_REGISTER_MODE_MISSING when registering then +- If you requested ``UFFDIO_REGISTER_MODE_MISSING`` when registering then you must provide some kind of page in your thread after reading from - the uffd. You must provide either UFFDIO_COPY or UFFDIO_ZEROPAGE. + the uffd. You must provide either ``UFFDIO_COPY`` or ``UFFDIO_ZEROPAGE``. The normal behavior of the OS automatically providing a zero page on an annonymous mmaping is not in place. @@ -122,13 +122,13 @@ - You get the address of the access that triggered the missing page event out of a struct uffd_msg that you read in the thread from the - uffd. You can supply as many pages as you want with UFFDIO_COPY or - UFFDIO_ZEROPAGE. Keep in mind that unless you used DONTWAKE then + uffd. You can supply as many pages as you want with ``UFFDIO_COPY`` or + ``UFFDIO_ZEROPAGE``. Keep in mind that unless you used DONTWAKE then the first of any of those IOCTLs wakes up the faulting thread. -- Be sure to test for all errors including (pollfd[0].revents & - POLLERR). This can happen, e.g. when ranges supplied were - incorrect. +- Be sure to test for all errors including + (``pollfd[0].revents & POLLERR``). This can happen, e.g. when ranges + supplied were incorrect. Write Protect Notifications --------------------------- @@ -136,41 +136,42 @@ This is equivalent to (but faster than) using mprotect and a SIGSEGV signal handler. -Firstly you need to register a range with UFFDIO_REGISTER_MODE_WP. -Instead of using mprotect(2) you use ioctl(uffd, UFFDIO_WRITEPROTECT, -struct *uffdio_writeprotect) while mode = UFFDIO_WRITEPROTECT_MODE_WP +Firstly you need to register a range with ``UFFDIO_REGISTER_MODE_WP``. +Instead of using mprotect(2) you use +``ioctl(uffd, UFFDIO_WRITEPROTECT, struct *uffdio_writeprotect)`` +while ``mode = UFFDIO_WRITEPROTECT_MODE_WP`` in the struct passed in. The range does not default to and does not have to be identical to the range you registered with. You can write protect as many ranges as you like (inside the registered range). Then, in the thread reading from uffd the struct will have -msg.arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WP set. Now you send -ioctl(uffd, UFFDIO_WRITEPROTECT, struct *uffdio_writeprotect) again -while pagefault.mode does not have UFFDIO_WRITEPROTECT_MODE_WP set. -This wakes up the thread which will continue to run with writes. This +``msg.arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WP`` set. Now you send +``ioctl(uffd, UFFDIO_WRITEPROTECT, struct *uffdio_writeprotect)`` +again while ``pagefault.mode`` does not have ``UFFDIO_WRITEPROTECT_MODE_WP`` +set. This wakes up the thread which will continue to run with writes. This allows you to do the bookkeeping about the write in the uffd reading thread before the ioctl. -If you registered with both UFFDIO_REGISTER_MODE_MISSING and -UFFDIO_REGISTER_MODE_WP then you need to think about the sequence in +If you registered with both ``UFFDIO_REGISTER_MODE_MISSING`` and +``UFFDIO_REGISTER_MODE_WP`` then you need to think about the sequence in which you supply a page and undo write protect. Note that there is a difference between writes into a WP area and into a !WP area. The -former will have UFFD_PAGEFAULT_FLAG_WP set, the latter -UFFD_PAGEFAULT_FLAG_WRITE. The latter did not fail on protection but -you still need to supply a page when UFFDIO_REGISTER_MODE_MISSING was +former will have ``UFFD_PAGEFAULT_FLAG_WP`` set, the latter +``UFFD_PAGEFAULT_FLAG_WRITE``. The latter did not fail on protection but +you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was used. QEMU/KVM ======== -QEMU/KVM is using the userfaultfd syscall to implement postcopy live +QEMU/KVM is using the ``userfaultfd`` syscall to implement postcopy live migration. Postcopy live migration is one form of memory externalization consisting of a virtual machine running with part or all of its memory residing on a different node in the cloud. The -userfaultfd abstraction is generic enough that not a single line of +``userfaultfd`` abstraction is generic enough that not a single line of KVM kernel code had to be modified in order to add postcopy live migration to QEMU. -Guest async page faults, FOLL_NOWAIT and all other GUP features work +Guest async page faults, ``FOLL_NOWAIT`` and all other ``GUP*`` features work just fine in combination with userfaults. Userfaults trigger async page faults in the guest scheduler so those guest processes that aren't waiting for userfaults (i.e. network bound) can keep running in @@ -183,19 +184,19 @@ The implementation of postcopy live migration currently uses one single bidirectional socket but in the future two different sockets will be used (to reduce the latency of the userfaults to the minimum -possible without having to decrease /proc/sys/net/ipv4/tcp_wmem). +possible without having to decrease ``/proc/sys/net/ipv4/tcp_wmem``). The QEMU in the source node writes all pages that it knows are missing in the destination node, into the socket, and the migration thread of -the QEMU running in the destination node runs UFFDIO_COPY|ZEROPAGE -ioctls on the userfaultfd in order to map the received pages into the -guest (UFFDIO_ZEROCOPY is used if the source page was a zero page). +the QEMU running in the destination node runs ``UFFDIO_COPY|ZEROPAGE`` +ioctls on the ``userfaultfd`` in order to map the received pages into the +guest (``UFFDIO_ZEROCOPY`` is used if the source page was a zero page). A different postcopy thread in the destination node listens with -poll() to the userfaultfd in parallel. When a POLLIN event is +poll() to the ``userfaultfd`` in parallel. When a ``POLLIN`` event is generated after a userfault triggers, the postcopy thread read() from -the userfaultfd and receives the fault address (or -EAGAIN in case the -userfault was already resolved and waken by a UFFDIO_COPY|ZEROPAGE run +the ``userfaultfd`` and receives the fault address (or ``-EAGAIN`` in case the +userfault was already resolved and waken by a ``UFFDIO_COPY|ZEROPAGE`` run by the parallel QEMU migration thread). After the QEMU postcopy thread (running in the destination node) gets @@ -206,7 +207,7 @@ (just the time to flush the tcp_wmem queue through the network) the migration thread in the QEMU running in the destination node will receive the page that triggered the userfault and it'll map it as -usual with the UFFDIO_COPY|ZEROPAGE (without actually knowing if it +usual with the ``UFFDIO_COPY|ZEROPAGE`` (without actually knowing if it was spontaneously sent by the source or if it was an urgent page requested through a userfault). @@ -219,74 +220,74 @@ over it when receiving incoming userfaults. After sending each page of course the bitmap is updated accordingly. It's also useful to avoid sending the same page twice (in case the userfault is read by the -postcopy thread just before UFFDIO_COPY|ZEROPAGE runs in the migration +postcopy thread just before ``UFFDIO_COPY|ZEROPAGE`` runs in the migration thread). Non-cooperative userfaultfd =========================== -When the userfaultfd is monitored by an external manager, the manager +When the ``userfaultfd`` is monitored by an external manager, the manager must be able to track changes in the process virtual memory layout. Userfaultfd can notify the manager about such changes using the same read(2) protocol as for the page fault notifications. The manager has to explicitly enable these events by setting appropriate -bits in uffdio_api.features passed to UFFDIO_API ioctl: +bits in ``uffdio_api.features`` passed to ``UFFDIO_API`` ioctl: -UFFD_FEATURE_EVENT_FORK - enable userfaultfd hooks for fork(). When this feature is - enabled, the userfaultfd context of the parent process is +``UFFD_FEATURE_EVENT_FORK`` + enable ``userfaultfd`` hooks for fork(). When this feature is + enabled, the ``userfaultfd`` context of the parent process is duplicated into the newly created process. The manager - receives UFFD_EVENT_FORK with file descriptor of the new - userfaultfd context in the uffd_msg.fork. + receives ``UFFD_EVENT_FORK`` with file descriptor of the new + ``userfaultfd`` context in the ``uffd_msg.fork``. -UFFD_FEATURE_EVENT_REMAP +``UFFD_FEATURE_EVENT_REMAP`` enable notifications about mremap() calls. When the non-cooperative process moves a virtual memory area to a different location, the manager will receive - UFFD_EVENT_REMAP. The uffd_msg.remap will contain the old and + ``UFFD_EVENT_REMAP``. The ``uffd_msg.remap`` will contain the old and new addresses of the area and its original length. -UFFD_FEATURE_EVENT_REMOVE +``UFFD_FEATURE_EVENT_REMOVE`` enable notifications about madvise(MADV_REMOVE) and - madvise(MADV_DONTNEED) calls. The event UFFD_EVENT_REMOVE will - be generated upon these calls to madvise. The uffd_msg.remove + madvise(MADV_DONTNEED) calls. The event ``UFFD_EVENT_REMOVE`` will + be generated upon these calls to madvise(). The ``uffd_msg.remove`` will contain start and end addresses of the removed area. -UFFD_FEATURE_EVENT_UNMAP +``UFFD_FEATURE_EVENT_UNMAP`` enable notifications about memory unmapping. The manager will - get UFFD_EVENT_UNMAP with uffd_msg.remove containing start and + get ``UFFD_EVENT_UNMAP`` with ``uffd_msg.remove`` containing start and end addresses of the unmapped area. -Although the UFFD_FEATURE_EVENT_REMOVE and UFFD_FEATURE_EVENT_UNMAP +Although the ``UFFD_FEATURE_EVENT_REMOVE`` and ``UFFD_FEATURE_EVENT_UNMAP`` are pretty similar, they quite differ in the action expected from the -userfaultfd manager. In the former case, the virtual memory is +``userfaultfd`` manager. In the former case, the virtual memory is removed, but the area is not, the area remains monitored by the -userfaultfd, and if a page fault occurs in that area it will be +``userfaultfd``, and if a page fault occurs in that area it will be delivered to the manager. The proper resolution for such page fault is to zeromap the faulting address. However, in the latter case, when an area is unmapped, either explicitly (with munmap() system call), or implicitly (e.g. during mremap()), the area is removed and in turn the -userfaultfd context for such area disappears too and the manager will +``userfaultfd`` context for such area disappears too and the manager will not get further userland page faults from the removed area. Still, the notification is required in order to prevent manager from using -UFFDIO_COPY on the unmapped area. +``UFFDIO_COPY`` on the unmapped area. Unlike userland page faults which have to be synchronous and require explicit or implicit wakeup, all the events are delivered asynchronously and the non-cooperative process resumes execution as -soon as manager executes read(). The userfaultfd manager should -carefully synchronize calls to UFFDIO_COPY with the events -processing. To aid the synchronization, the UFFDIO_COPY ioctl will -return -ENOSPC when the monitored process exits at the time of -UFFDIO_COPY, and -ENOENT, when the non-cooperative process has changed -its virtual memory layout simultaneously with outstanding UFFDIO_COPY +soon as manager executes read(). The ``userfaultfd`` manager should +carefully synchronize calls to ``UFFDIO_COPY`` with the events +processing. To aid the synchronization, the ``UFFDIO_COPY`` ioctl will +return ``-ENOSPC`` when the monitored process exits at the time of +``UFFDIO_COPY``, and ``-ENOENT``, when the non-cooperative process has changed +its virtual memory layout simultaneously with outstanding ``UFFDIO_COPY`` operation. The current asynchronous model of the event delivery is optimal for -single threaded non-cooperative userfaultfd manager implementations. A +single threaded non-cooperative ``userfaultfd`` manager implementations. A synchronous event delivery model can be added later as a new -userfaultfd feature to facilitate multithreading enhancements of the -non cooperative manager, for example to allow UFFDIO_COPY ioctls to +``userfaultfd`` feature to facilitate multithreading enhancements of the +non cooperative manager, for example to allow ``UFFDIO_COPY`` ioctls to run in parallel to the event reception. Single threaded implementations should continue to use the current async event delivery model instead.
diff --git a/Documentation/admin-guide/mono.rst b/Documentation/admin-guide/mono.rst index 59e6d59..c6dab56 100644 --- a/Documentation/admin-guide/mono.rst +++ b/Documentation/admin-guide/mono.rst
@@ -12,11 +12,11 @@ a binary package, a source tarball or by installing from Git. Binary packages for several distributions can be found at: - http://www.mono-project.com/download/ + https://www.mono-project.com/download/ Instructions for compiling Mono can be found at: - http://www.mono-project.com/docs/compiling-mono/linux/ + https://www.mono-project.com/docs/compiling-mono/linux/ Once the Mono CLR support has been installed, just check that ``/usr/bin/mono`` (which could be located elsewhere, for example
diff --git a/Documentation/admin-guide/nfs/nfsroot.rst b/Documentation/admin-guide/nfs/nfsroot.rst index 82a4fda..c677207 100644 --- a/Documentation/admin-guide/nfs/nfsroot.rst +++ b/Documentation/admin-guide/nfs/nfsroot.rst
@@ -18,7 +18,7 @@ In order to use a diskless system, such as an X-terminal or printer server for example, it is necessary for the root filesystem to be present on a non-disk device. This may be an initramfs (see -Documentation/filesystems/ramfs-rootfs-initramfs.txt), a ramdisk (see +Documentation/filesystems/ramfs-rootfs-initramfs.rst), a ramdisk (see Documentation/admin-guide/initrd.rst) or a filesystem mounted via NFS. The following text describes on how to use NFS for the root filesystem. For the rest of this text 'client' means the diskless system, and 'server' means the NFS
diff --git a/Documentation/admin-guide/numastat.rst b/Documentation/admin-guide/numastat.rst index aaf1667..08ec2c2 100644 --- a/Documentation/admin-guide/numastat.rst +++ b/Documentation/admin-guide/numastat.rst
@@ -6,6 +6,21 @@ All units are pages. Hugepages have separate counters. +The numa_hit, numa_miss and numa_foreign counters reflect how well processes +are able to allocate memory from nodes they prefer. If they succeed, numa_hit +is incremented on the preferred node, otherwise numa_foreign is incremented on +the preferred node and numa_miss on the node where allocation succeeded. + +Usually preferred node is the one local to the CPU where the process executes, +but restrictions such as mempolicies can change that, so there are also two +counters based on CPU local node. local_node is similar to numa_hit and is +incremented on allocation from a node by CPU on the same node. other_node is +similar to numa_miss and is incremented on the node where allocation succeeds +from a CPU from a different node. Note there is no counter analogical to +numa_foreign. + +In more detail: + =============== ============================================================ numa_hit A process wanted to allocate memory from this node, and succeeded. @@ -14,11 +29,13 @@ but ended up with memory from this node. numa_foreign A process wanted to allocate on this node, - but ended up with memory from another one. + but ended up with memory from another node. -local_node A process ran on this node and got memory from it. +local_node A process ran on this node's CPU, + and got memory from this node. -other_node A process ran on this node and got memory from another node. +other_node A process ran on a different node's CPU + and got memory from this node. interleave_hit Interleaving wanted to allocate from this node and succeeded. @@ -28,3 +45,11 @@ (http://oss.sgi.com/projects/libnuma/). Note that it only works well right now on machines with a small number of CPUs. +Note that on systems with memoryless nodes (where a node has CPUs but no +memory) the numa_hit, numa_miss and numa_foreign statistics can be skewed +heavily. In the current kernel implementation, if a process prefers a +memoryless node (i.e. because it is running on one of its local CPU), the +implementation actually treats one of the nearest nodes with memory as the +preferred node. As a result, such allocation will not increase the numa_foreign +counter on the memoryless node, and will skew the numa_hit, numa_miss and +numa_foreign statistics of the nearest node.
diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst index 72effa7..1307b52 100644 --- a/Documentation/admin-guide/perf-security.rst +++ b/Documentation/admin-guide/perf-security.rst
@@ -1,6 +1,6 @@ .. _perf_security: -Perf Events and tool security +Perf events and tool security ============================= Overview @@ -42,11 +42,11 @@ Data that belong to the fourth category can potentially contain sensitive process data. If PMUs in some monitoring modes capture values of execution context registers or data from process memory then access -to such monitoring capabilities requires to be ordered and secured -properly. So, perf_events/Perf performance monitoring is the subject for -security access control management [5]_ . +to such monitoring modes requires to be ordered and secured properly. +So, perf_events performance monitoring and observability operations are +the subject for security access control management [5]_ . -perf_events/Perf access control +perf_events access control ------------------------------- To perform security checks, the Linux implementation splits processes @@ -66,11 +66,25 @@ independently enabled and disabled on per-thread basis for processes and files of unprivileged users. -Unprivileged processes with enabled CAP_SYS_ADMIN capability are treated +Unprivileged processes with enabled CAP_PERFMON capability are treated as privileged processes with respect to perf_events performance -monitoring and bypass *scope* permissions checks in the kernel. +monitoring and observability operations, thus, bypass *scope* permissions +checks in the kernel. CAP_PERFMON implements the principle of least +privilege [13]_ (POSIX 1003.1e: 2.2.2.39) for performance monitoring and +observability operations in the kernel and provides a secure approach to +perfomance monitoring and observability in the system. -Unprivileged processes using perf_events system call API is also subject +For backward compatibility reasons the access to perf_events monitoring and +observability operations is also open for CAP_SYS_ADMIN privileged +processes but CAP_SYS_ADMIN usage for secure monitoring and observability +use cases is discouraged with respect to the CAP_PERFMON capability. +If system audit records [14]_ for a process using perf_events system call +API contain denial records of acquiring both CAP_PERFMON and CAP_SYS_ADMIN +capabilities then providing the process with CAP_PERFMON capability singly +is recommended as the preferred secure approach to resolve double access +denial logging related to usage of performance monitoring and observability. + +Unprivileged processes using perf_events system call are also subject for PTRACE_MODE_READ_REALCREDS ptrace access mode check [7]_ , whose outcome determines whether monitoring is permitted. So unprivileged processes provided with CAP_SYS_PTRACE capability are effectively @@ -82,14 +96,14 @@ CAP_SYSLOG capability permits reading kernel space memory addresses from /proc/kallsyms file. -perf_events/Perf privileged users +Privileged Perf users groups --------------------------------- Mechanisms of capabilities, privileged capability-dumb files [6]_ and -file system ACLs [10]_ can be used to create a dedicated group of -perf_events/Perf privileged users who are permitted to execute -performance monitoring without scope limits. The following steps can be -taken to create such a group of privileged Perf users. +file system ACLs [10]_ can be used to create dedicated groups of +privileged Perf users who are permitted to execute performance monitoring +and observability without scope limits. The following steps can be +taken to create such groups of privileged Perf users. 1. Create perf_users group of privileged Perf users, assign perf_users group to Perf tool executable and limit access to the executable for @@ -108,30 +122,51 @@ -rwxr-x--- 2 root perf_users 11M Oct 19 15:12 perf 2. Assign the required capabilities to the Perf tool executable file and - enable members of perf_users group with performance monitoring + enable members of perf_users group with monitoring and observability privileges [6]_ : :: - # setcap "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf - # setcap -v "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf + # setcap "cap_perfmon,cap_sys_ptrace,cap_syslog=ep" perf + # setcap -v "cap_perfmon,cap_sys_ptrace,cap_syslog=ep" perf perf: OK # getcap perf - perf = cap_sys_ptrace,cap_sys_admin,cap_syslog+ep + perf = cap_sys_ptrace,cap_syslog,cap_perfmon+ep + +If the libcap installed doesn't yet support "cap_perfmon", use "38" instead, +i.e.: + +:: + + # setcap "38,cap_ipc_lock,cap_sys_ptrace,cap_syslog=ep" perf + +Note that you may need to have 'cap_ipc_lock' in the mix for tools such as +'perf top', alternatively use 'perf top -m N', to reduce the memory that +it uses for the perf ring buffer, see the memory allocation section below. + +Using a libcap without support for CAP_PERFMON will make cap_get_flag(caps, 38, +CAP_EFFECTIVE, &val) fail, which will lead the default event to be 'cycles:u', +so as a workaround explicitly ask for the 'cycles' event, i.e.: + +:: + + # perf top -e cycles + +To get kernel and user samples with a perf binary with just CAP_PERFMON. As a result, members of perf_users group are capable of conducting -performance monitoring by using functionality of the configured Perf -tool executable that, when executes, passes perf_events subsystem scope -checks. +performance monitoring and observability by using functionality of the +configured Perf tool executable that, when executes, passes perf_events +subsystem scope checks. This specific access control management is only available to superuser or root running processes with CAP_SETPCAP, CAP_SETFCAP [6]_ capabilities. -perf_events/Perf unprivileged users +Unprivileged users ----------------------------------- -perf_events/Perf *scope* and *access* control for unprivileged processes +perf_events *scope* and *access* control for unprivileged processes is governed by perf_event_paranoid [2]_ setting: -1: @@ -166,7 +201,7 @@ perf_event_mlock_kb locking limit is imposed but ignored for unprivileged processes with CAP_IPC_LOCK capability. -perf_events/Perf resource control +Resource control --------------------------------- Open file descriptors @@ -227,4 +262,5 @@ .. [10] `<http://man7.org/linux/man-pages/man5/acl.5.html>`_ .. [11] `<http://man7.org/linux/man-pages/man2/getrlimit.2.html>`_ .. [12] `<http://man7.org/linux/man-pages/man5/limits.conf.5.html>`_ - +.. [13] `<https://sites.google.com/site/fullycapable>`_ +.. [14] `<http://man7.org/linux/man-pages/man8/auditd.8.html>`_
diff --git a/Documentation/admin-guide/pm/cpuidle.rst b/Documentation/admin-guide/pm/cpuidle.rst index 5605cc6..a96a423 100644 --- a/Documentation/admin-guide/pm/cpuidle.rst +++ b/Documentation/admin-guide/pm/cpuidle.rst
@@ -159,17 +159,15 @@ and that is the primary reason for having more than one governor in the ``CPUIdle`` subsystem. -There are three ``CPUIdle`` governors available, ``menu``, `TEO <teo-gov_>`_ -and ``ladder``. Which of them is used by default depends on the configuration -of the kernel and in particular on whether or not the scheduler tick can be -`stopped by the idle loop <idle-cpus-and-tick_>`_. It is possible to change the -governor at run time if the ``cpuidle_sysfs_switch`` command line parameter has -been passed to the kernel, but that is not safe in general, so it should not be -done on production systems (that may change in the future, though). The name of -the ``CPUIdle`` governor currently used by the kernel can be read from the -:file:`current_governor_ro` (or :file:`current_governor` if -``cpuidle_sysfs_switch`` is present in the kernel command line) file under -:file:`/sys/devices/system/cpu/cpuidle/` in ``sysfs``. +There are four ``CPUIdle`` governors available, ``menu``, `TEO <teo-gov_>`_, +``ladder`` and ``haltpoll``. Which of them is used by default depends on the +configuration of the kernel and in particular on whether or not the scheduler +tick can be `stopped by the idle loop <idle-cpus-and-tick_>`_. Available +governors can be read from the :file:`available_governors`, and the governor +can be changed at runtime. The name of the ``CPUIdle`` governor currently +used by the kernel can be read from the :file:`current_governor_ro` or +:file:`current_governor` file under :file:`/sys/devices/system/cpu/cpuidle/` +in ``sysfs``. Which ``CPUIdle`` driver is used, on the other hand, usually depends on the platform the kernel is running on, but there are platforms with more than one
diff --git a/Documentation/admin-guide/pm/intel-speed-select.rst b/Documentation/admin-guide/pm/intel-speed-select.rst new file mode 100644 index 0000000..b2ca601 --- /dev/null +++ b/Documentation/admin-guide/pm/intel-speed-select.rst
@@ -0,0 +1,917 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================================ +Intel(R) Speed Select Technology User Guide +============================================================ + +The Intel(R) Speed Select Technology (Intel(R) SST) provides a powerful new +collection of features that give more granular control over CPU performance. +With Intel(R) SST, one server can be configured for power and performance for a +variety of diverse workload requirements. + +Refer to the links below for an overview of the technology: + +- https://www.intel.com/content/www/us/en/architecture-and-technology/speed-select-technology-article.html +- https://builders.intel.com/docs/networkbuilders/intel-speed-select-technology-base-frequency-enhancing-performance.pdf + +These capabilities are further enhanced in some of the newer generations of +server platforms where these features can be enumerated and controlled +dynamically without pre-configuring via BIOS setup options. This dynamic +configuration is done via mailbox commands to the hardware. One way to enumerate +and configure these features is by using the Intel Speed Select utility. + +This document explains how to use the Intel Speed Select tool to enumerate and +control Intel(R) SST features. This document gives example commands and explains +how these commands change the power and performance profile of the system under +test. Using this tool as an example, customers can replicate the messaging +implemented in the tool in their production software. + +intel-speed-select configuration tool +====================================== + +Most Linux distribution packages may include the "intel-speed-select" tool. If not, +it can be built by downloading the Linux kernel tree from kernel.org. Once +downloaded, the tool can be built without building the full kernel. + +From the kernel tree, run the following commands:: + +# cd tools/power/x86/intel-speed-select/ +# make +# make install + +Getting Help +------------ + +To get help with the tool, execute the command below:: + +# intel-speed-select --help + +The top-level help describes arguments and features. Notice that there is a +multi-level help structure in the tool. For example, to get help for the feature "perf-profile":: + +# intel-speed-select perf-profile --help + +To get help on a command, another level of help is provided. For example for the command info "info":: + +# intel-speed-select perf-profile info --help + +Summary of platform capability +------------------------------ +To check the current platform and driver capaibilities, execute:: + +#intel-speed-select --info + +For example on a test system:: + + # intel-speed-select --info + Intel(R) Speed Select Technology + Executing on CPU model: X + Platform: API version : 1 + Platform: Driver version : 1 + Platform: mbox supported : 1 + Platform: mmio supported : 1 + Intel(R) SST-PP (feature perf-profile) is supported + TDP level change control is unlocked, max level: 4 + Intel(R) SST-TF (feature turbo-freq) is supported + Intel(R) SST-BF (feature base-freq) is not supported + Intel(R) SST-CP (feature core-power) is supported + +Intel(R) Speed Select Technology - Performance Profile (Intel(R) SST-PP) +------------------------------------------------------------------------ + +This feature allows configuration of a server dynamically based on workload +performance requirements. This helps users during deployment as they do not have +to choose a specific server configuration statically. This Intel(R) Speed Select +Technology - Performance Profile (Intel(R) SST-PP) feature introduces a mechanism +that allows multiple optimized performance profiles per system. Each profile +defines a set of CPUs that need to be online and rest offline to sustain a +guaranteed base frequency. Once the user issues a command to use a specific +performance profile and meet CPU online/offline requirement, the user can expect +a change in the base frequency dynamically. This feature is called +"perf-profile" when using the Intel Speed Select tool. + +Number or performance levels +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +There can be multiple performance profiles on a system. To get the number of +profiles, execute the command below:: + + # intel-speed-select perf-profile get-config-levels + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + get-config-levels:4 + package-1 + die-0 + cpu-14 + get-config-levels:4 + +On this system under test, there are 4 performance profiles in addition to the +base performance profile (which is performance level 0). + +Lock/Unlock status +~~~~~~~~~~~~~~~~~~ + +Even if there are multiple performance profiles, it is possible that that they +are locked. If they are locked, users cannot issue a command to change the +performance state. It is possible that there is a BIOS setup to unlock or check +with your system vendor. + +To check if the system is locked, execute the following command:: + + # intel-speed-select perf-profile get-lock-status + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + get-lock-status:0 + package-1 + die-0 + cpu-14 + get-lock-status:0 + +In this case, lock status is 0, which means that the system is unlocked. + +Properties of a performance level +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To get properties of a specific performance level (For example for the level 0, below), execute the command below:: + + # intel-speed-select perf-profile info -l 0 + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + perf-profile-level-0 + cpu-count:28 + enable-cpu-mask:000003ff,f0003fff + enable-cpu-list:0,1,2,3,4,5,6,7,8,9,10,11,12,13,28,29,30,31,32,33,34,35,36,37,38,39,40,41 + thermal-design-power-ratio:26 + base-frequency(MHz):2600 + speed-select-turbo-freq:disabled + speed-select-base-freq:disabled + ... + ... + +Here -l option is used to specify a performance level. + +If the option -l is omitted, then this command will print information about all +the performance levels. The above command is printing properties of the +performance level 0. + +For this performance profile, the list of CPUs displayed by the +"enable-cpu-mask/enable-cpu-list" at the max can be "online." When that +condition is met, then base frequency of 2600 MHz can be maintained. To +understand more, execute "intel-speed-select perf-profile info" for performance +level 4:: + + # intel-speed-select perf-profile info -l 4 + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + perf-profile-level-4 + cpu-count:28 + enable-cpu-mask:000000fa,f0000faf + enable-cpu-list:0,1,2,3,5,7,8,9,10,11,28,29,30,31,33,35,36,37,38,39 + thermal-design-power-ratio:28 + base-frequency(MHz):2800 + speed-select-turbo-freq:disabled + speed-select-base-freq:unsupported + ... + ... + +There are fewer CPUs in the "enable-cpu-mask/enable-cpu-list". Consequently, if +the user only keeps these CPUs online and the rest "offline," then the base +frequency is increased to 2.8 GHz compared to 2.6 GHz at performance level 0. + +Get current performance level +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To get the current performance level, execute:: + + # intel-speed-select perf-profile get-config-current-level + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + get-config-current_level:0 + +First verify that the base_frequency displayed by the cpufreq sysfs is correct:: + + # cat /sys/devices/system/cpu/cpu0/cpufreq/base_frequency + 2600000 + +This matches the base-frequency (MHz) field value displayed from the +"perf-profile info" command for performance level 0(cpufreq frequency is in +KHz). + +To check if the average frequency is equal to the base frequency for a 100% busy +workload, disable turbo:: + +# echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo + +Then runs a busy workload on all CPUs, for example:: + +#stress -c 64 + +To verify the base frequency, run turbostat:: + + #turbostat -c 0-13 --show Package,Core,CPU,Bzy_MHz -i 1 + + Package Core CPU Bzy_MHz + - - 2600 + 0 0 0 2600 + 0 1 1 2600 + 0 2 2 2600 + 0 3 3 2600 + 0 4 4 2600 + . . . . + + +Changing performance level +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To the change the performance level to 4, execute:: + + # intel-speed-select -d perf-profile set-config-level -l 4 -o + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + perf-profile + set_tdp_level:success + +In the command above, "-o" is optional. If it is specified, then it will also +offline CPUs which are not present in the enable_cpu_mask for this performance +level. + +Now if the base_frequency is checked:: + + #cat /sys/devices/system/cpu/cpu0/cpufreq/base_frequency + 2800000 + +Which shows that the base frequency now increased from 2600 MHz at performance +level 0 to 2800 MHz at performance level 4. As a result, any workload, which can +use fewer CPUs, can see a boost of 200 MHz compared to performance level 0. + +Check presence of other Intel(R) SST features +--------------------------------------------- + +Each of the performance profiles also specifies weather there is support of +other two Intel(R) SST features (Intel(R) Speed Select Technology - Base Frequency +(Intel(R) SST-BF) and Intel(R) Speed Select Technology - Turbo Frequency (Intel +SST-TF)). + +For example, from the output of "perf-profile info" above, for level 0 and level +4: + +For level 0:: + speed-select-turbo-freq:disabled + speed-select-base-freq:disabled + +For level 4:: + speed-select-turbo-freq:disabled + speed-select-base-freq:unsupported + +Given these results, the "speed-select-base-freq" (Intel(R) SST-BF) in level 4 +changed from "disabled" to "unsupported" compared to performance level 0. + +This means that at performance level 4, the "speed-select-base-freq" feature is +not supported. However, at performance level 0, this feature is "supported", but +currently "disabled", meaning the user has not activated this feature. Whereas +"speed-select-turbo-freq" (Intel(R) SST-TF) is supported at both performance +levels, but currently not activated by the user. + +The Intel(R) SST-BF and the Intel(R) SST-TF features are built on a foundation +technology called Intel(R) Speed Select Technology - Core Power (Intel(R) SST-CP). +The platform firmware enables this feature when Intel(R) SST-BF or Intel(R) SST-TF +is supported on a platform. + +Intel(R) Speed Select Technology Core Power (Intel(R) SST-CP) +--------------------------------------------------------------- + +Intel(R) Speed Select Technology Core Power (Intel(R) SST-CP) is an interface that +allows users to define per core priority. This defines a mechanism to distribute +power among cores when there is a power constrained scenario. This defines a +class of service (CLOS) configuration. + +The user can configure up to 4 class of service configurations. Each CLOS group +configuration allows definitions of parameters, which affects how the frequency +can be limited and power is distributed. Each CPU core can be tied to a class of +service and hence an associated priority. The granularity is at core level not +at per CPU level. + +Enable CLOS based prioritization +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To use CLOS based prioritization feature, firmware must be informed to enable +and use a priority type. There is a default per platform priority type, which +can be changed with optional command line parameter. + +To enable and check the options, execute:: + + # intel-speed-select core-power enable --help + Intel(R) Speed Select Technology + Executing on CPU model: X + Enable core-power for a package/die + Clos Enable: Specify priority type with [--priority|-p] + 0: Proportional, 1: Ordered + +There are two types of priority types: + +- Ordered + +Priority for ordered throttling is defined based on the index of the assigned +CLOS group. Where CLOS0 gets highest priority (throttled last). + +Priority order is: +CLOS0 > CLOS1 > CLOS2 > CLOS3. + +- Proportional + +When proportional priority is used, there is an additional parameter called +frequency_weight, which can be specified per CLOS group. The goal of +proportional priority is to provide each core with the requested min., then +distribute all remaining (excess/deficit) budgets in proportion to a defined +weight. This proportional priority can be configured using "core-power config" +command. + +To enable with the platform default priority type, execute:: + + # intel-speed-select core-power enable + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + core-power + enable:success + package-1 + die-0 + cpu-6 + core-power + enable:success + +The scope of this enable is per package or die scoped when a package contains +multiple dies. To check if CLOS is enabled and get priority type, "core-power +info" command can be used. For example to check the status of core-power feature +on CPU 0, execute:: + + # intel-speed-select -c 0 core-power info + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + core-power + support-status:supported + enable-status:enabled + clos-enable-status:enabled + priority-type:proportional + package-1 + die-0 + cpu-24 + core-power + support-status:supported + enable-status:enabled + clos-enable-status:enabled + priority-type:proportional + +Configuring CLOS groups +~~~~~~~~~~~~~~~~~~~~~~~ + +Each CLOS group has its own attributes including min, max, freq_weight and +desired. These parameters can be configured with "core-power config" command. +Defaults will be used if user skips setting a parameter except clos id, which is +mandatory. To check core-power config options, execute:: + + # intel-speed-select core-power config --help + Intel(R) Speed Select Technology + Executing on CPU model: X + Set core-power configuration for one of the four clos ids + Specify targeted clos id with [--clos|-c] + Specify clos Proportional Priority [--weight|-w] + Specify clos min in MHz with [--min|-n] + Specify clos max in MHz with [--max|-m] + +For example:: + + # intel-speed-select core-power config -c 0 + Intel(R) Speed Select Technology + Executing on CPU model: X + clos epp is not specified, default: 0 + clos frequency weight is not specified, default: 0 + clos min is not specified, default: 0 MHz + clos max is not specified, default: 25500 MHz + clos desired is not specified, default: 0 + package-0 + die-0 + cpu-0 + core-power + config:success + package-1 + die-0 + cpu-6 + core-power + config:success + +The user has the option to change defaults. For example, the user can change the +"min" and set the base frequency to always get guaranteed base frequency. + +Get the current CLOS configuration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To check the current configuration, "core-power get-config" can be used. For +example, to get the configuration of CLOS 0:: + + # intel-speed-select core-power get-config -c 0 + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + core-power + clos:0 + epp:0 + clos-proportional-priority:0 + clos-min:0 MHz + clos-max:Max Turbo frequency + clos-desired:0 MHz + package-1 + die-0 + cpu-24 + core-power + clos:0 + epp:0 + clos-proportional-priority:0 + clos-min:0 MHz + clos-max:Max Turbo frequency + clos-desired:0 MHz + +Associating a CPU with a CLOS group +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To associate a CPU to a CLOS group "core-power assoc" command can be used:: + + # intel-speed-select core-power assoc --help + Intel(R) Speed Select Technology + Executing on CPU model: X + Associate a clos id to a CPU + Specify targeted clos id with [--clos|-c] + + +For example to associate CPU 10 to CLOS group 3, execute:: + + # intel-speed-select -c 10 core-power assoc -c 3 + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-10 + core-power + assoc:success + +Once a CPU is associated, its sibling CPUs are also associated to a CLOS group. +Once associated, avoid changing Linux "cpufreq" subsystem scaling frequency +limits. + +To check the existing association for a CPU, "core-power get-assoc" command can +be used. For example, to get association of CPU 10, execute:: + + # intel-speed-select -c 10 core-power get-assoc + Intel(R) Speed Select Technology + Executing on CPU model: X + package-1 + die-0 + cpu-10 + get-assoc + clos:3 + +This shows that CPU 10 is part of a CLOS group 3. + + +Disable CLOS based prioritization +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To disable, execute:: + +# intel-speed-select core-power disable + +Some features like Intel(R) SST-TF can only be enabled when CLOS based prioritization +is enabled. For this reason, disabling while Intel(R) SST-TF is enabled can cause +Intel(R) SST-TF to fail. This will cause the "disable" command to display an error +if Intel(R) SST-TF is already enabled. In turn, to disable, the Intel(R) SST-TF +feature must be disabled first. + +Intel(R) Speed Select Technology - Base Frequency (Intel(R) SST-BF) +------------------------------------------------------------------- + +The Intel(R) Speed Select Technology - Base Frequency (Intel(R) SST-BF) feature lets +the user control base frequency. If some critical workload threads demand +constant high guaranteed performance, then this feature can be used to execute +the thread at higher base frequency on specific sets of CPUs (high priority +CPUs) at the cost of lower base frequency (low priority CPUs) on other CPUs. +This feature does not require offline of the low priority CPUs. + +The support of Intel(R) SST-BF depends on the Intel(R) Speed Select Technology - +Performance Profile (Intel(R) SST-PP) performance level configuration. It is +possible that only certain performance levels support Intel(R) SST-BF. It is also +possible that only base performance level (level = 0) has support of Intel +SST-BF. Consequently, first select the desired performance level to enable this +feature. + +In the system under test here, Intel(R) SST-BF is supported at the base +performance level 0, but currently disabled. For example for the level 0:: + + # intel-speed-select -c 0 perf-profile info -l 0 + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + perf-profile-level-0 + ... + + speed-select-base-freq:disabled + ... + +Before enabling Intel(R) SST-BF and measuring its impact on a workload +performance, execute some workload and measure performance and get a baseline +performance to compare against. + +Here the user wants more guaranteed performance. For this reason, it is likely +that turbo is disabled. To disable turbo, execute:: + +#echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo + +Based on the output of the "intel-speed-select perf-profile info -l 0" base +frequency of guaranteed frequency 2600 MHz. + + +Measure baseline performance for comparison +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To compare, pick a multi-threaded workload where each thread can be scheduled on +separate CPUs. "Hackbench pipe" test is a good example on how to improve +performance using Intel(R) SST-BF. + +Below, the workload is measuring average scheduler wakeup latency, so a lower +number means better performance:: + + # taskset -c 3,4 perf bench -r 100 sched pipe + # Running 'sched/pipe' benchmark: + # Executed 1000000 pipe operations between two processes + Total time: 6.102 [sec] + 6.102445 usecs/op + 163868 ops/sec + +While running the above test, if we take turbostat output, it will show us that +2 of the CPUs are busy and reaching max. frequency (which would be the base +frequency as the turbo is disabled). The turbostat output:: + + #turbostat -c 0-13 --show Package,Core,CPU,Bzy_MHz -i 1 + Package Core CPU Bzy_MHz + 0 0 0 1000 + 0 1 1 1005 + 0 2 2 1000 + 0 3 3 2600 + 0 4 4 2600 + 0 5 5 1000 + 0 6 6 1000 + 0 7 7 1005 + 0 8 8 1005 + 0 9 9 1000 + 0 10 10 1000 + 0 11 11 995 + 0 12 12 1000 + 0 13 13 1000 + +From the above turbostat output, both CPU 3 and 4 are very busy and reaching +full guaranteed frequency of 2600 MHz. + +Intel(R) SST-BF Capabilities +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To get capabilities of Intel(R) SST-BF for the current performance level 0, +execute:: + + # intel-speed-select base-freq info -l 0 + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + speed-select-base-freq + high-priority-base-frequency(MHz):3000 + high-priority-cpu-mask:00000216,00002160 + high-priority-cpu-list:5,6,8,13,33,34,36,41 + low-priority-base-frequency(MHz):2400 + tjunction-temperature(C):125 + thermal-design-power(W):205 + +The above capabilities show that there are some CPUs on this system that can +offer base frequency of 3000 MHz compared to the standard base frequency at this +performance levels. Nevertheless, these CPUs are fixed, and they are presented +via high-priority-cpu-list/high-priority-cpu-mask. But if this Intel(R) SST-BF +feature is selected, the low priorities CPUs (which are not in +high-priority-cpu-list) can only offer up to 2400 MHz. As a result, if this +clipping of low priority CPUs is acceptable, then the user can enable Intel +SST-BF feature particularly for the above "sched pipe" workload since only two +CPUs are used, they can be scheduled on high priority CPUs and can get boost of +400 MHz. + +Enable Intel(R) SST-BF +~~~~~~~~~~~~~~~~~~~~~~ + +To enable Intel(R) SST-BF feature, execute:: + + # intel-speed-select base-freq enable -a + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + base-freq + enable:success + package-1 + die-0 + cpu-14 + base-freq + enable:success + +In this case, -a option is optional. This not only enables Intel(R) SST-BF, but it +also adjusts the priority of cores using Intel(R) Speed Select Technology Core +Power (Intel(R) SST-CP) features. This option sets the minimum performance of each +Intel(R) Speed Select Technology - Performance Profile (Intel(R) SST-PP) class to +maximum performance so that the hardware will give maximum performance possible +for each CPU. + +If -a option is not used, then the following steps are required before enabling +Intel(R) SST-BF: + +- Discover Intel(R) SST-BF and note low and high priority base frequency +- Note the high prioity CPU list +- Enable CLOS using core-power feature set +- Configure CLOS parameters. Use CLOS.min to set to minimum performance +- Subscribe desired CPUs to CLOS groups + +With this configuration, if the same workload is executed by pinning the +workload to high priority CPUs (CPU 5 and 6 in this case):: + + #taskset -c 5,6 perf bench -r 100 sched pipe + # Running 'sched/pipe' benchmark: + # Executed 1000000 pipe operations between two processes + Total time: 5.627 [sec] + 5.627922 usecs/op + 177685 ops/sec + +This way, by enabling Intel(R) SST-BF, the performance of this benchmark is +improved (latency reduced) by 7.79%. From the turbostat output, it can be +observed that the high priority CPUs reached 3000 MHz compared to 2600 MHz. +The turbostat output:: + + #turbostat -c 0-13 --show Package,Core,CPU,Bzy_MHz -i 1 + Package Core CPU Bzy_MHz + 0 0 0 2151 + 0 1 1 2166 + 0 2 2 2175 + 0 3 3 2175 + 0 4 4 2175 + 0 5 5 3000 + 0 6 6 3000 + 0 7 7 2180 + 0 8 8 2662 + 0 9 9 2176 + 0 10 10 2175 + 0 11 11 2176 + 0 12 12 2176 + 0 13 13 2661 + +Disable Intel(R) SST-BF +~~~~~~~~~~~~~~~~~~~~~~~ + +To disable the Intel(R) SST-BF feature, execute:: + +# intel-speed-select base-freq disable -a + + +Intel(R) Speed Select Technology - Turbo Frequency (Intel(R) SST-TF) +-------------------------------------------------------------------- + +This feature enables the ability to set different "All core turbo ratio limits" +to cores based on the priority. By using this feature, some cores can be +configured to get higher turbo frequency by designating them as high priority at +the cost of lower or no turbo frequency on the low priority cores. + +For this reason, this feature is only useful when system is busy utilizing all +CPUs, but the user wants some configurable option to get high performance on +some CPUs. + +The support of Intel(R) Speed Select Technology - Turbo Frequency (Intel(R) SST-TF) +depends on the Intel(R) Speed Select Technology - Performance Profile (Intel +SST-PP) performance level configuration. It is possible that only a certain +performance level supports Intel(R) SST-TF. It is also possible that only the base +performance level (level = 0) has the support of Intel(R) SST-TF. Hence, first +select the desired performance level to enable this feature. + +In the system under test here, Intel(R) SST-TF is supported at the base +performance level 0, but currently disabled:: + + # intel-speed-select -c 0 perf-profile info -l 0 + Intel(R) Speed Select Technology + package-0 + die-0 + cpu-0 + perf-profile-level-0 + ... + ... + speed-select-turbo-freq:disabled + ... + ... + + +To check if performance can be improved using Intel(R) SST-TF feature, get the turbo +frequency properties with Intel(R) SST-TF enabled and compare to the base turbo +capability of this system. + +Get Base turbo capability +~~~~~~~~~~~~~~~~~~~~~~~~~ + +To get the base turbo capability of performance level 0, execute:: + + # intel-speed-select perf-profile info -l 0 + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + perf-profile-level-0 + ... + ... + turbo-ratio-limits-sse + bucket-0 + core-count:2 + max-turbo-frequency(MHz):3200 + bucket-1 + core-count:4 + max-turbo-frequency(MHz):3100 + bucket-2 + core-count:6 + max-turbo-frequency(MHz):3100 + bucket-3 + core-count:8 + max-turbo-frequency(MHz):3100 + bucket-4 + core-count:10 + max-turbo-frequency(MHz):3100 + bucket-5 + core-count:12 + max-turbo-frequency(MHz):3100 + bucket-6 + core-count:14 + max-turbo-frequency(MHz):3100 + bucket-7 + core-count:16 + max-turbo-frequency(MHz):3100 + +Based on the data above, when all the CPUS are busy, the max. frequency of 3100 +MHz can be achieved. If there is some busy workload on cpu 0 - 11 (e.g. stress) +and on CPU 12 and 13, execute "hackbench pipe" workload:: + + # taskset -c 12,13 perf bench -r 100 sched pipe + # Running 'sched/pipe' benchmark: + # Executed 1000000 pipe operations between two processes + Total time: 5.705 [sec] + 5.705488 usecs/op + 175269 ops/sec + +The turbostat output:: + + #turbostat -c 0-13 --show Package,Core,CPU,Bzy_MHz -i 1 + Package Core CPU Bzy_MHz + 0 0 0 3000 + 0 1 1 3000 + 0 2 2 3000 + 0 3 3 3000 + 0 4 4 3000 + 0 5 5 3100 + 0 6 6 3100 + 0 7 7 3000 + 0 8 8 3100 + 0 9 9 3000 + 0 10 10 3000 + 0 11 11 3000 + 0 12 12 3100 + 0 13 13 3100 + +Based on turbostat output, the performance is limited by frequency cap of 3100 +MHz. To check if the hackbench performance can be improved for CPU 12 and CPU +13, first check the capability of the Intel(R) SST-TF feature for this performance +level. + +Get Intel(R) SST-TF Capability +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To get the capability, the "turbo-freq info" command can be used:: + + # intel-speed-select turbo-freq info -l 0 + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-0 + speed-select-turbo-freq + bucket-0 + high-priority-cores-count:2 + high-priority-max-frequency(MHz):3200 + high-priority-max-avx2-frequency(MHz):3200 + high-priority-max-avx512-frequency(MHz):3100 + bucket-1 + high-priority-cores-count:4 + high-priority-max-frequency(MHz):3100 + high-priority-max-avx2-frequency(MHz):3000 + high-priority-max-avx512-frequency(MHz):2900 + bucket-2 + high-priority-cores-count:6 + high-priority-max-frequency(MHz):3100 + high-priority-max-avx2-frequency(MHz):3000 + high-priority-max-avx512-frequency(MHz):2900 + speed-select-turbo-freq-clip-frequencies + low-priority-max-frequency(MHz):2600 + low-priority-max-avx2-frequency(MHz):2400 + low-priority-max-avx512-frequency(MHz):2100 + +Based on the output above, there is an Intel(R) SST-TF bucket for which there are +two high priority cores. If only two high priority cores are set, then max. +turbo frequency on those cores can be increased to 3200 MHz. This is 100 MHz +more than the base turbo capability for all cores. + +In turn, for the hackbench workload, two CPUs can be set as high priority and +rest as low priority. One side effect is that once enabled, the low priority +cores will be clipped to a lower frequency of 2600 MHz. + +Enable Intel(R) SST-TF +~~~~~~~~~~~~~~~~~~~~~~ + +To enable Intel(R) SST-TF, execute:: + + # intel-speed-select -c 12,13 turbo-freq enable -a + Intel(R) Speed Select Technology + Executing on CPU model: X + package-0 + die-0 + cpu-12 + turbo-freq + enable:success + package-0 + die-0 + cpu-13 + turbo-freq + enable:success + package--1 + die-0 + cpu-63 + turbo-freq --auto + enable:success + +In this case, the option "-a" is optional. If set, it enables Intel(R) SST-TF +feature and also sets the CPUs to high and and low priority using Intel Speed +Select Technology Core Power (Intel(R) SST-CP) features. The CPU numbers passed +with "-c" arguments are marked as high priority, including its siblings. + +If -a option is not used, then the following steps are required before enabling +Intel(R) SST-TF: + +- Discover Intel(R) SST-TF and note buckets of high priority cores and maximum frequency + +- Enable CLOS using core-power feature set - Configure CLOS parameters + +- Subscribe desired CPUs to CLOS groups making sure that high priority cores are set to the maximum frequency + +If the same hackbench workload is executed, schedule hackbench threads on high +priority CPUs:: + + #taskset -c 12,13 perf bench -r 100 sched pipe + # Running 'sched/pipe' benchmark: + # Executed 1000000 pipe operations between two processes + Total time: 5.510 [sec] + 5.510165 usecs/op + 180826 ops/sec + +This improved performance by around 3.3% improvement on a busy system. Here the +turbostat output will show that the CPU 12 and CPU 13 are getting 100 MHz boost. +The turbostat output:: + + #turbostat -c 0-13 --show Package,Core,CPU,Bzy_MHz -i 1 + Package Core CPU Bzy_MHz + ... + 0 12 12 3200 + 0 13 13 3200
diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst index ad392f3..39d80bc 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst
@@ -62,9 +62,10 @@ Active Mode ----------- -This is the default operation mode of ``intel_pstate``. If it works in this -mode, the ``scaling_driver`` policy attribute in ``sysfs`` for all ``CPUFreq`` -policies contains the string "intel_pstate". +This is the default operation mode of ``intel_pstate`` for processors with +hardware-managed P-states (HWP) support. If it works in this mode, the +``scaling_driver`` policy attribute in ``sysfs`` for all ``CPUFreq`` policies +contains the string "intel_pstate". In this mode the driver bypasses the scaling governors layer of ``CPUFreq`` and provides its own scaling algorithms for P-state selection. Those algorithms @@ -138,12 +139,13 @@ Active Mode Without HWP ~~~~~~~~~~~~~~~~~~~~~~~ -This is the default operation mode for processors that do not support the HWP -feature. It also is used by default with the ``intel_pstate=no_hwp`` argument -in the kernel command line. However, in this mode ``intel_pstate`` may refuse -to work with the given processor if it does not recognize it. [Note that -``intel_pstate`` will never refuse to work with any processor with the HWP -feature enabled.] +This operation mode is optional for processors that do not support the HWP +feature or when the ``intel_pstate=no_hwp`` argument is passed to the kernel in +the command line. The active mode is used in those cases if the +``intel_pstate=active`` argument is passed to the kernel in the command line. +In this mode ``intel_pstate`` may refuse to work with processors that are not +recognized by it. [Note that ``intel_pstate`` will never refuse to work with +any processor with the HWP feature enabled.] In this mode ``intel_pstate`` registers utilization update callbacks with the CPU scheduler in order to run a P-state selection algorithm, either @@ -188,10 +190,14 @@ Passive Mode ------------ -This mode is used if the ``intel_pstate=passive`` argument is passed to the -kernel in the command line (it implies the ``intel_pstate=no_hwp`` setting too). -Like in the active mode without HWP support, in this mode ``intel_pstate`` may -refuse to work with the given processor if it does not recognize it. +This is the default operation mode of ``intel_pstate`` for processors without +hardware-managed P-states (HWP) support. It is always used if the +``intel_pstate=passive`` argument is passed to the kernel in the command line +regardless of whether or not the given processor supports HWP. [Note that the +``intel_pstate=no_hwp`` setting implies ``intel_pstate=passive`` if it is used +without ``intel_pstate=active``.] Like in the active mode without HWP support, +in this mode ``intel_pstate`` may refuse to work with processors that are not +recognized by it. If the driver works in this mode, the ``scaling_driver`` policy attribute in ``sysfs`` for all ``CPUFreq`` policies contains the string "intel_cpufreq".
diff --git a/Documentation/admin-guide/pm/working-state.rst b/Documentation/admin-guide/pm/working-state.rst index 0a38cdf..f40994c 100644 --- a/Documentation/admin-guide/pm/working-state.rst +++ b/Documentation/admin-guide/pm/working-state.rst
@@ -13,3 +13,4 @@ intel_pstate cpufreq_drivers intel_epb + intel-speed-select
diff --git a/Documentation/admin-guide/pstore-blk.rst b/Documentation/admin-guide/pstore-blk.rst new file mode 100644 index 0000000..296d502 --- /dev/null +++ b/Documentation/admin-guide/pstore-blk.rst
@@ -0,0 +1,243 @@ +.. SPDX-License-Identifier: GPL-2.0 + +pstore block oops/panic logger +============================== + +Introduction +------------ + +pstore block (pstore/blk) is an oops/panic logger that writes its logs to a +block device and non-block device before the system crashes. You can get +these log files by mounting pstore filesystem like:: + + mount -t pstore pstore /sys/fs/pstore + + +pstore block concepts +--------------------- + +pstore/blk provides efficient configuration method for pstore/blk, which +divides all configurations into two parts, configurations for user and +configurations for driver. + +Configurations for user determine how pstore/blk works, such as pmsg_size, +kmsg_size and so on. All of them support both Kconfig and module parameters, +but module parameters have priority over Kconfig. + +Configurations for driver are all about block device and non-block device, +such as total_size of block device and read/write operations. + +Configurations for user +----------------------- + +All of these configurations support both Kconfig and module parameters, but +module parameters have priority over Kconfig. + +Here is an example for module parameters:: + + pstore_blk.blkdev=179:7 pstore_blk.kmsg_size=64 + +The detail of each configurations may be of interest to you. + +blkdev +~~~~~~ + +The block device to use. Most of the time, it is a partition of block device. +It's required for pstore/blk. It is also used for MTD device. + +It accepts the following variants for block device: + +1. <hex_major><hex_minor> device number in hexadecimal represents itself; no + leading 0x, for example b302. +#. /dev/<disk_name> represents the device number of disk +#. /dev/<disk_name><decimal> represents the device number of partition - device + number of disk plus the partition number +#. /dev/<disk_name>p<decimal> - same as the above; this form is used when disk + name of partitioned disk ends with a digit. +#. PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF represents the unique id of + a partition if the partition table provides it. The UUID may be either an + EFI/GPT UUID, or refer to an MSDOS partition using the format SSSSSSSS-PP, + where SSSSSSSS is a zero-filled hex representation of the 32-bit + "NT disk signature", and PP is a zero-filled hex representation of the + 1-based partition number. +#. PARTUUID=<UUID>/PARTNROFF=<int> to select a partition in relation to a + partition with a known unique id. +#. <major>:<minor> major and minor number of the device separated by a colon. + +It accepts the following variants for MTD device: + +1. <device name> MTD device name. "pstore" is recommended. +#. <device number> MTD device number. + +kmsg_size +~~~~~~~~~ + +The chunk size in KB for oops/panic front-end. It **MUST** be a multiple of 4. +It's optional if you do not care oops/panic log. + +There are multiple chunks for oops/panic front-end depending on the remaining +space except other pstore front-ends. + +pstore/blk will log to oops/panic chunks one by one, and always overwrite the +oldest chunk if there is no more free chunk. + +pmsg_size +~~~~~~~~~ + +The chunk size in KB for pmsg front-end. It **MUST** be a multiple of 4. +It's optional if you do not care pmsg log. + +Unlike oops/panic front-end, there is only one chunk for pmsg front-end. + +Pmsg is a user space accessible pstore object. Writes to */dev/pmsg0* are +appended to the chunk. On reboot the contents are available in +*/sys/fs/pstore/pmsg-pstore-blk-0*. + +console_size +~~~~~~~~~~~~ + +The chunk size in KB for console front-end. It **MUST** be a multiple of 4. +It's optional if you do not care console log. + +Similar to pmsg front-end, there is only one chunk for console front-end. + +All log of console will be appended to the chunk. On reboot the contents are +available in */sys/fs/pstore/console-pstore-blk-0*. + +ftrace_size +~~~~~~~~~~~ + +The chunk size in KB for ftrace front-end. It **MUST** be a multiple of 4. +It's optional if you do not care console log. + +Similar to oops front-end, there are multiple chunks for ftrace front-end +depending on the count of cpu processors. Each chunk size is equal to +ftrace_size / processors_count. + +All log of ftrace will be appended to the chunk. On reboot the contents are +combined and available in */sys/fs/pstore/ftrace-pstore-blk-0*. + +Persistent function tracing might be useful for debugging software or hardware +related hangs. Here is an example of usage:: + + # mount -t pstore pstore /sys/fs/pstore + # mount -t debugfs debugfs /sys/kernel/debug/ + # echo 1 > /sys/kernel/debug/pstore/record_ftrace + # reboot -f + [...] + # mount -t pstore pstore /sys/fs/pstore + # tail /sys/fs/pstore/ftrace-pstore-blk-0 + CPU:0 ts:5914676 c0063828 c0063b94 call_cpuidle <- cpu_startup_entry+0x1b8/0x1e0 + CPU:0 ts:5914678 c039ecdc c006385c cpuidle_enter_state <- call_cpuidle+0x44/0x48 + CPU:0 ts:5914680 c039e9a0 c039ecf0 cpuidle_enter_freeze <- cpuidle_enter_state+0x304/0x314 + CPU:0 ts:5914681 c0063870 c039ea30 sched_idle_set_state <- cpuidle_enter_state+0x44/0x314 + CPU:1 ts:5916720 c0160f59 c015ee04 kernfs_unmap_bin_file <- __kernfs_remove+0x140/0x204 + CPU:1 ts:5916721 c05ca625 c015ee0c __mutex_lock_slowpath <- __kernfs_remove+0x148/0x204 + CPU:1 ts:5916723 c05c813d c05ca630 yield_to <- __mutex_lock_slowpath+0x314/0x358 + CPU:1 ts:5916724 c05ca2d1 c05ca638 __ww_mutex_lock <- __mutex_lock_slowpath+0x31c/0x358 + +max_reason +~~~~~~~~~~ + +Limiting which kinds of kmsg dumps are stored can be controlled via +the ``max_reason`` value, as defined in include/linux/kmsg_dump.h's +``enum kmsg_dump_reason``. For example, to store both Oopses and Panics, +``max_reason`` should be set to 2 (KMSG_DUMP_OOPS), to store only Panics +``max_reason`` should be set to 1 (KMSG_DUMP_PANIC). 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'll be KMSG_DUMP_OOPS, +otherwise KMSG_DUMP_MAX. + +Configurations for driver +------------------------- + +Only a block device driver cares about these configurations. A block device +driver uses ``register_pstore_blk`` to register to pstore/blk. + +.. kernel-doc:: fs/pstore/blk.c + :identifiers: register_pstore_blk + +A non-block device driver uses ``register_pstore_device`` with +``struct pstore_device_info`` to register to pstore/blk. + +.. kernel-doc:: fs/pstore/blk.c + :identifiers: register_pstore_device + +.. kernel-doc:: include/linux/pstore_blk.h + :identifiers: pstore_device_info + +Compression and header +---------------------- + +Block device is large enough for uncompressed oops data. Actually we do not +recommend data compression because pstore/blk will insert some information into +the first line of oops/panic data. For example:: + + Panic: Total 16 times + +It means that it's OOPS|Panic for the 16th time since the first booting. +Sometimes the number of occurrences of oops|panic since the first booting is +important to judge whether the system is stable. + +The following line is inserted by pstore filesystem. For example:: + + Oops#2 Part1 + +It means that it's OOPS for the 2nd time on the last boot. + +Reading the data +---------------- + +The dump data can be read from the pstore filesystem. The format for these +files is ``dmesg-pstore-blk-[N]`` for oops/panic front-end, +``pmsg-pstore-blk-0`` for pmsg front-end and so on. The timestamp of the +dump file records the trigger time. To delete a stored record from block +device, simply unlink the respective pstore file. + +Attentions in panic read/write APIs +----------------------------------- + +If on panic, the kernel is not going to run for much longer, the tasks will not +be scheduled and most kernel resources will be out of service. It +looks like a single-threaded program running on a single-core computer. + +The following points require special attention for panic read/write APIs: + +1. Can **NOT** allocate any memory. + If you need memory, just allocate while the block driver is initializing + rather than waiting until the panic. +#. Must be polled, **NOT** interrupt driven. + No task schedule any more. The block driver should delay to ensure the write + succeeds, but NOT sleep. +#. Can **NOT** take any lock. + There is no other task, nor any shared resource; you are safe to break all + locks. +#. Just use CPU to transfer. + Do not use DMA to transfer unless you are sure that DMA will not keep lock. +#. Control registers directly. + Please control registers directly rather than use Linux kernel resources. + Do I/O map while initializing rather than wait until a panic occurs. +#. Reset your block device and controller if necessary. + If you are not sure of the state of your block device and controller when + a panic occurs, you are safe to stop and reset them. + +pstore/blk supports psblk_blkdev_info(), which is defined in +*linux/pstore_blk.h*, to get information of using block device, such as the +device number, sector count and start sector of the whole disk. + +pstore block internals +---------------------- + +For developer reference, here are all the important structures and APIs: + +.. kernel-doc:: fs/pstore/zone.c + :internal: + +.. kernel-doc:: include/linux/pstore_zone.h + :internal: + +.. kernel-doc:: fs/pstore/blk.c + :export: + +.. kernel-doc:: include/linux/pstore_blk.h + :internal:
diff --git a/Documentation/admin-guide/ramoops.rst b/Documentation/admin-guide/ramoops.rst index 6dbcc54..a60a962 100644 --- a/Documentation/admin-guide/ramoops.rst +++ b/Documentation/admin-guide/ramoops.rst
@@ -32,11 +32,17 @@ memory are implementation defined, and won't work on many ARMs such as omaps. The memory area is divided into ``record_size`` chunks (also rounded down to -power of two) and each oops/panic writes a ``record_size`` chunk of +power of two) and each kmesg dump writes a ``record_size`` chunk of information. -Dumping both oopses and panics can be done by setting 1 in the ``dump_oops`` -variable while setting 0 in that variable dumps only the panics. +Limiting which kinds of kmsg dumps are stored can be controlled via +the ``max_reason`` value, as defined in include/linux/kmsg_dump.h's +``enum kmsg_dump_reason``. For example, to store both Oopses and Panics, +``max_reason`` should be set to 2 (KMSG_DUMP_OOPS), to store only Panics +``max_reason`` should be set to 1 (KMSG_DUMP_PANIC). 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'll be KMSG_DUMP_OOPS, +otherwise KMSG_DUMP_MAX. The module uses a counter to record multiple dumps but the counter gets reset on restart (i.e. new dumps after the restart will overwrite old ones). @@ -90,7 +96,7 @@ .mem_address = <...>, .mem_type = <...>, .record_size = <...>, - .dump_oops = <...>, + .max_reason = <...>, .ecc = <...>, };
diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst index 0310db6..7b481b2 100644 --- a/Documentation/admin-guide/ras.rst +++ b/Documentation/admin-guide/ras.rst
@@ -156,11 +156,11 @@ ECC memory ---------- -As mentioned on the previous section, ECC memory has extra bits to be -used for error correction. So, on 64 bit systems, a memory module -has 64 bits of *data width*, and 74 bits of *total width*. So, there are -8 bits extra bits to be used for the error detection and correction -mechanisms. Those extra bits are called *syndrome*\ [#f1]_\ [#f2]_. +As mentioned in the previous section, ECC memory has extra bits to be +used for error correction. In the above example, a memory module has +64 bits of *data width*, and 72 bits of *total width*. The extra 8 +bits which are used for the error detection and correction mechanisms +are referred to as the *syndrome*\ [#f1]_\ [#f2]_. So, when the cpu requests the memory controller to write a word with *data width*, the memory controller calculates the *syndrome* in real time, @@ -212,7 +212,7 @@ purposes. When the subsystem was pushed upstream for the first time, on - Kernel 2.6.16, for the first time, it was renamed to ``EDAC``. + Kernel 2.6.16, it was renamed to ``EDAC``. Purpose ------- @@ -351,15 +351,17 @@ +------------+-----------+-----------+ | | ``ch0`` | ``ch1`` | +============+===========+===========+ - | ``csrow0`` | DIMM_A0 | DIMM_B0 | - | | rank0 | rank0 | - +------------+ - | - | + | |**DIMM_A0**|**DIMM_B0**| + +------------+-----------+-----------+ + | ``csrow0`` | rank0 | rank0 | + +------------+-----------+-----------+ | ``csrow1`` | rank1 | rank1 | +------------+-----------+-----------+ - | ``csrow2`` | DIMM_A1 | DIMM_B1 | - | | rank0 | rank0 | - +------------+ - | - | - | ``csrow3`` | rank1 | rank1 | + | |**DIMM_A1**|**DIMM_B1**| + +------------+-----------+-----------+ + | ``csrow2`` | rank0 | rank0 | + +------------+-----------+-----------+ + | ``csrow3`` | rank1 | rank1 | +------------+-----------+-----------+ In the above example, there are 4 physical slots on the motherboard
diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst index 49ac8dc..42481ea 100644 --- a/Documentation/admin-guide/reporting-bugs.rst +++ b/Documentation/admin-guide/reporting-bugs.rst
@@ -75,7 +75,7 @@ If you haven't reported a bug before, please read: - http://www.chiark.greenend.org.uk/~sgtatham/bugs.html + https://www.chiark.greenend.org.uk/~sgtatham/bugs.html http://www.catb.org/esr/faqs/smart-questions.html
diff --git a/Documentation/admin-guide/serial-console.rst b/Documentation/admin-guide/serial-console.rst index a8d1e36..58b3283 100644 --- a/Documentation/admin-guide/serial-console.rst +++ b/Documentation/admin-guide/serial-console.rst
@@ -54,7 +54,7 @@ ``/dev/console`` is now character device 5,1. (You can also use a network device as a console. See -``Documentation/networking/netconsole.txt`` for information on that.) +``Documentation/networking/netconsole.rst`` for information on that.) Here's an example that will use ``/dev/ttyS1`` (COM2) as the console. Replace the sample values as needed.
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 0d427fd..83acf50 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -102,6 +102,30 @@ :doc:`/x86/boot` for additional information. +bpf_stats_enabled +================= + +Controls whether the kernel should collect statistics on BPF programs +(total time spent running, number of times run...). Enabling +statistics causes a slight reduction in performance on each program +run. The statistics can be seen using ``bpftool``. + += =================================== +0 Don't collect statistics (default). +1 Collect statistics. += =================================== + + +cad_pid +======= + +This is the pid which will be signalled on reboot (notably, by +Ctrl-Alt-Delete). Writing a value to this file which doesn't +correspond to a running process will result in ``-ESRCH``. + +See also `ctrl-alt-del`_. + + cap_last_cap ============ @@ -241,6 +265,40 @@ see the ``hostname(1)`` man page. +firmware_config +=============== + +See :doc:`/driver-api/firmware/fallback-mechanisms`. + +The entries in this directory allow the firmware loader helper +fallback to be controlled: + +* ``force_sysfs_fallback``, when set to 1, forces the use of the + fallback; +* ``ignore_sysfs_fallback``, when set to 1, ignores any fallback. + + +ftrace_dump_on_oops +=================== + +Determines whether ``ftrace_dump()`` should be called on an oops (or +kernel panic). This will output the contents of the ftrace buffers to +the console. This is very useful for capturing traces that lead to +crashes and outputting them to a serial console. + += =================================================== +0 Disabled (default). +1 Dump buffers of all CPUs. +2 Dump the buffer of the CPU that triggered the oops. += =================================================== + + +ftrace_enabled, stack_tracer_enabled +==================================== + +See :doc:`/trace/ftrace`. + + hardlockup_all_cpu_backtrace ============================ @@ -277,6 +335,20 @@ Default value is "``/sbin/hotplug``". +hung_task_all_cpu_backtrace: +================ + +If this option is set, the kernel will send an NMI to all CPUs to dump +their backtraces when a hung task is detected. This file shows up if +CONFIG_DETECT_HUNG_TASK and CONFIG_SMP are enabled. + +0: Won't show all CPUs backtraces when a hung task is detected. +This is the default behavior. + +1: Will non-maskably interrupt all CPUs and dump their backtraces when +a hung task is detected. + + hung_task_panic =============== @@ -344,6 +416,25 @@ = ========================================================= +ignore-unaligned-usertrap +========================= + +On architectures where unaligned accesses cause traps, and where this +feature is supported (``CONFIG_SYSCTL_ARCH_UNALIGN_NO_WARN``; +currently, ``arc`` and ``ia64``), controls whether all unaligned traps +are logged. + += ============================================================= +0 Log all unaligned accesses. +1 Only warn the first time a process traps. This is the default + setting. += ============================================================= + +See also `unaligned-trap`_ and `unaligned-dump-stack`_. On ``ia64``, +this allows system administrators to override the +``IA64_THREAD_UAC_NOPRINT`` ``prctl`` and avoid logs being flooded. + + kexec_load_disabled =================== @@ -459,6 +550,15 @@ successful IPC object allocation. If an IPC object allocation syscall fails, it is undefined if the value remains unmodified or is reset to -1. + +ngroups_max +=========== + +Maximum number of supplementary groups, _i.e._ the maximum size which +``setgroups`` will accept. Exports ``NGROUPS_MAX`` from the kernel. + + + nmi_watchdog ============ @@ -546,6 +646,22 @@ scanned for a given scan. +oops_all_cpu_backtrace: +================ + +If this option is set, the kernel will send an NMI to all CPUs to dump +their backtraces when an oops event occurs. It should be used as a last +resort in case a panic cannot be triggered (to protect VMs running, for +example) or kdump can't be collected. This file shows up if CONFIG_SMP +is enabled. + +0: Won't show all CPUs backtraces when an oops is detected. +This is the default behavior. + +1: Will non-maskably interrupt all CPUs and dump their backtraces when +an oops event is detected. + + osrelease, ostype & version =========================== @@ -721,7 +837,13 @@ =================== Controls use of the performance events system by unprivileged -users (without CAP_SYS_ADMIN). The default value is 2. +users (without CAP_PERFMON). The default value is 2. + +For backward compatibility reasons access to system performance +monitoring and observability remains open for CAP_SYS_ADMIN +privileged processes but CAP_SYS_ADMIN usage for secure system +performance monitoring and observability operations is discouraged +with respect to CAP_PERFMON use cases. === ================================================================== -1 Allow use of (almost) all events by all users. @@ -730,13 +852,13 @@ ``CAP_IPC_LOCK``. >=0 Disallow ftrace function tracepoint by users without - ``CAP_SYS_ADMIN``. + ``CAP_PERFMON``. - Disallow raw tracepoint access by users without ``CAP_SYS_ADMIN``. + Disallow raw tracepoint access by users without ``CAP_PERFMON``. ->=1 Disallow CPU event access by users without ``CAP_SYS_ADMIN``. +>=1 Disallow CPU event access by users without ``CAP_PERFMON``. ->=2 Disallow kernel profiling by users without ``CAP_SYS_ADMIN``. +>=2 Disallow kernel profiling by users without ``CAP_PERFMON``. === ================================================================== @@ -871,7 +993,7 @@ pty === -See Documentation/filesystems/devpts.txt. +See Documentation/filesystems/devpts.rst. randomize_va_space @@ -1147,6 +1269,13 @@ See :doc:`/admin-guide/tainted-kernels` for more information. +Note: + writes to this sysctl interface will fail with ``EINVAL`` if the kernel is + booted with the command line option ``panic_on_taint=<bitmask>,nousertaint`` + and any of the ORed together values being written to ``tainted`` match with + the bitmask declared on panic_on_taint. + See :doc:`/admin-guide/kernel-parameters` for more details on that particular + kernel command line option and its optional ``nousertaint`` switch. threads-max =========== @@ -1167,6 +1296,65 @@ ``EINVAL`` error occurs. +traceoff_on_warning +=================== + +When set, disables tracing (see :doc:`/trace/ftrace`) when a +``WARN()`` is hit. + + +tracepoint_printk +================= + +When tracepoints are sent to printk() (enabled by the ``tp_printk`` +boot parameter), this entry provides runtime control:: + + echo 0 > /proc/sys/kernel/tracepoint_printk + +will stop tracepoints from being sent to printk(), and:: + + echo 1 > /proc/sys/kernel/tracepoint_printk + +will send them to printk() again. + +This only works if the kernel was booted with ``tp_printk`` enabled. + +See :doc:`/admin-guide/kernel-parameters` and +:doc:`/trace/boottime-trace`. + + +.. _unaligned-dump-stack: + +unaligned-dump-stack (ia64) +=========================== + +When logging unaligned accesses, controls whether the stack is +dumped. + += =================================================== +0 Do not dump the stack. This is the default setting. +1 Dump the stack. += =================================================== + +See also `ignore-unaligned-usertrap`_. + + +unaligned-trap +============== + +On architectures where unaligned accesses cause traps, and where this +feature is supported (``CONFIG_SYSCTL_ARCH_UNALIGN_ALLOW``; currently, +``arc`` and ``parisc``), controls whether unaligned traps are caught +and emulated (instead of failing). + += ======================================================== +0 Do not emulate unaligned accesses. +1 Emulate unaligned accesses. This is the default setting. += ======================================================== + +See also `ignore-unaligned-usertrap`_. + + unknown_nmi_panic ================= @@ -1178,6 +1366,16 @@ example. If a system hangs up, try pressing the NMI switch. +unprivileged_bpf_disabled +========================= + +Writing 1 to this entry will disable unprivileged calls to ``bpf()``; +once disabled, calling ``bpf()`` without ``CAP_SYS_ADMIN`` will return +``-EPERM``. + +Once set, this can't be cleared. + + watchdog ========
diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst index e043c92..42cd04b 100644 --- a/Documentation/admin-guide/sysctl/net.rst +++ b/Documentation/admin-guide/sysctl/net.rst
@@ -339,7 +339,9 @@ If set to 1, both IPv4 and IPv6 settings are forced to inherit from current ones in init_net. If set to 2, both IPv4 and IPv6 settings are -forced to reset to their default values. +forced to reset to their default values. If set to 3, both IPv4 and IPv6 +settings are forced to inherit from current ones in the netns where this +new netns has been created. Default : 0 (for compatibility reasons) @@ -353,8 +355,8 @@ 3. /proc/sys/net/ipv4 - IPV4 settings ------------------------------------- -Please see: Documentation/networking/ip-sysctl.txt and ipvs-sysctl.txt for -descriptions of these entries. +Please see: Documentation/networking/ip-sysctl.rst and +Documentation/admin-guide/sysctl/net.rst for descriptions of these entries. 4. Appletalk
diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index 0329a4d..d46d5b7 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -831,14 +831,27 @@ swappiness ========== -This control is used to define how aggressive the kernel will swap -memory pages. Higher values will increase aggressiveness, lower values -decrease the amount of swap. A value of 0 instructs the kernel not to -initiate swap until the amount of free and file-backed pages is less -than the high water mark in a zone. +This control is used to define the rough relative IO cost of swapping +and filesystem paging, as a value between 0 and 200. At 100, the VM +assumes equal IO cost and will thus apply memory pressure to the page +cache and swap-backed pages equally; lower values signify more +expensive swap IO, higher values indicates cheaper. + +Keep in mind that filesystem IO patterns under memory pressure tend to +be more efficient than swap's random IO. An optimal value will require +experimentation and will also be workload-dependent. The default value is 60. +For in-memory swap, like zram or zswap, as well as hybrid setups that +have swap on faster devices than the filesystem, values beyond 100 can +be considered. For example, if the random IO against the swap device +is on average 2x faster than IO from the filesystem, swappiness should +be 133 (x + 2x = 200, 2x = 133.33). + +At 0, the kernel will not initiate swap until the amount of free and +file-backed pages is less than the high watermark in a zone. + unprivileged_userfaultfd ========================
diff --git a/Documentation/admin-guide/sysrq.rst b/Documentation/admin-guide/sysrq.rst index a46209f..e6424d8 100644 --- a/Documentation/admin-guide/sysrq.rst +++ b/Documentation/admin-guide/sysrq.rst
@@ -231,13 +231,13 @@ handler is called. Your handler must conform to the prototype in 'sysrq.h'. After the ``sysrq_key_op`` is created, you can call the kernel function -``register_sysrq_key(int key, struct sysrq_key_op *op_p);`` this will +``register_sysrq_key(int key, const struct sysrq_key_op *op_p);`` this will register the operation pointed to by ``op_p`` at table key 'key', if that slot in the table is blank. At module unload time, you must call -the function ``unregister_sysrq_key(int key, struct sysrq_key_op *op_p)``, which -will remove the key op pointed to by 'op_p' from the key 'key', if and only if -it is currently registered in that slot. This is in case the slot has been -overwritten since you registered it. +the function ``unregister_sysrq_key(int key, const struct sysrq_key_op *op_p)``, +which will remove the key op pointed to by 'op_p' from the key 'key', if and +only if it is currently registered in that slot. This is in case the slot has +been overwritten since you registered it. The Magic SysRQ system works by registering key operations against a key op lookup table, which is defined in 'drivers/tty/sysrq.c'. This key table has
diff --git a/Documentation/admin-guide/unicode.rst b/Documentation/admin-guide/unicode.rst index 7425a33..290fe83 100644 --- a/Documentation/admin-guide/unicode.rst +++ b/Documentation/admin-guide/unicode.rst
@@ -114,7 +114,7 @@ This range is now officially managed by the ConScript Unicode Registry. The normative reference is at: - http://www.evertype.com/standards/csur/klingon.html + https://www.evertype.com/standards/csur/klingon.html Klingon has an alphabet of 26 characters, a positional numeric writing system with 10 digits, and is written left-to-right, top-to-bottom. @@ -178,7 +178,7 @@ <jcowan@reutershealth.com> and Michael Everson <everson@evertype.com>. The ConScript Unicode Registry is accessible at: - http://www.evertype.com/standards/csur/ + https://www.evertype.com/standards/csur/ The ranges used fall at the low end of the End User Zone and can hence not be normatively assigned, but it is recommended that people who
diff --git a/Documentation/arm/microchip.rst b/Documentation/arm/microchip.rst index 05e5f2d..9c01329 100644 --- a/Documentation/arm/microchip.rst +++ b/Documentation/arm/microchip.rst
@@ -192,7 +192,7 @@ considered as "Unstable". To be completely clear, any at91 binding can change at any time. So, be sure to use a Device Tree Binary and a Kernel Image generated from the same source tree. -Please refer to the Documentation/devicetree/bindings/ABI.txt file for a +Please refer to the Documentation/devicetree/bindings/ABI.rst file for a definition of a "Stable" binding/ABI. This statement will be removed by AT91 MAINTAINERS when appropriate.
diff --git a/Documentation/arm64/amu.rst b/Documentation/arm64/amu.rst index 5057b11..452ec8b 100644 --- a/Documentation/arm64/amu.rst +++ b/Documentation/arm64/amu.rst
@@ -23,6 +23,7 @@ Version 1 of the Activity Monitors architecture implements a counter group of four fixed and architecturally defined 64-bit event counters. + - CPU cycle counter: increments at the frequency of the CPU. - Constant counter: increments at the fixed frequency of the system clock. @@ -57,6 +58,7 @@ Firmware (code running at higher exception levels, e.g. arm-tf) support is needed to: + - Enable access for lower exception levels (EL2 and EL1) to the AMU registers. - Enable the counters. If not enabled these will read as 0. @@ -78,6 +80,7 @@ The fixed counters of AMUv1 are accessible though the following system register definitions: + - SYS_AMEVCNTR0_CORE_EL0 - SYS_AMEVCNTR0_CONST_EL0 - SYS_AMEVCNTR0_INST_RET_EL0 @@ -93,6 +96,7 @@ ---------------- Currently, access from userspace to the AMU registers is disabled due to: + - Security reasons: they might expose information about code executed in secure mode. - Purpose: AMU counters are intended for system management use. @@ -105,6 +109,7 @@ Currently, access from userspace (EL0) and kernelspace (EL1) on the KVM guest side is disabled due to: + - Security reasons: they might expose information about code executed by other guests or the host.
diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index a3f1a47..7552dbc 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst
@@ -173,7 +173,10 @@ - Caches, MMUs The MMU must be off. - Instruction cache may be on or off. + + The instruction cache may be on or off, and must not hold any stale + entries corresponding to the loaded kernel image. + The address range corresponding to the loaded kernel image must be cleaned to the PoC. In the presence of a system cache or other coherent masters with caches enabled, this will typically require @@ -238,6 +241,7 @@ - The DT or ACPI tables must describe a GICv2 interrupt controller. For CPUs with pointer authentication functionality: + - If EL3 is present: - SCR_EL3.APK (bit 16) must be initialised to 0b1 @@ -249,18 +253,22 @@ - HCR_EL2.API (bit 41) must be initialised to 0b1 For CPUs with Activity Monitors Unit v1 (AMUv1) extension present: + - If EL3 is present: - CPTR_EL3.TAM (bit 30) must be initialised to 0b0 - CPTR_EL2.TAM (bit 30) must be initialised to 0b0 - AMCNTENSET0_EL0 must be initialised to 0b1111 - AMCNTENSET1_EL0 must be initialised to a platform specific value - having 0b1 set for the corresponding bit for each of the auxiliary - counters present. + + - CPTR_EL3.TAM (bit 30) must be initialised to 0b0 + - CPTR_EL2.TAM (bit 30) must be initialised to 0b0 + - AMCNTENSET0_EL0 must be initialised to 0b1111 + - AMCNTENSET1_EL0 must be initialised to a platform specific value + having 0b1 set for the corresponding bit for each of the auxiliary + counters present. + - If the kernel is entered at EL1: - AMCNTENSET0_EL0 must be initialised to 0b1111 - AMCNTENSET1_EL0 must be initialised to a platform specific value - having 0b1 set for the corresponding bit for each of the auxiliary - counters present. + + - AMCNTENSET0_EL0 must be initialised to 0b1111 + - AMCNTENSET1_EL0 must be initialised to a platform specific value + having 0b1 set for the corresponding bit for each of the auxiliary + counters present. The requirements described above for CPU mode, caches, MMUs, architected timers, coherency and system registers apply to all CPUs. All CPUs must @@ -304,7 +312,8 @@ Documentation/devicetree/bindings/arm/psci.yaml. - Secondary CPU general-purpose register settings - x0 = 0 (reserved for future use) - x1 = 0 (reserved for future use) - x2 = 0 (reserved for future use) - x3 = 0 (reserved for future use) + + - x0 = 0 (reserved for future use) + - x1 = 0 (reserved for future use) + - x2 = 0 (reserved for future use) + - x3 = 0 (reserved for future use)
diff --git a/Documentation/arm64/cpu-feature-registers.rst b/Documentation/arm64/cpu-feature-registers.rst index 41937a8..314fa5b 100644 --- a/Documentation/arm64/cpu-feature-registers.rst +++ b/Documentation/arm64/cpu-feature-registers.rst
@@ -176,6 +176,8 @@ +------------------------------+---------+---------+ | SSBS | [7-4] | y | +------------------------------+---------+---------+ + | BT | [3-0] | y | + +------------------------------+---------+---------+ 4) MIDR_EL1 - Main ID Register
diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst index 7dfb97d..84a9fd2 100644 --- a/Documentation/arm64/elf_hwcaps.rst +++ b/Documentation/arm64/elf_hwcaps.rst
@@ -236,6 +236,11 @@ Functionality implied by ID_AA64ISAR0_EL1.RNDR == 0b0001. +HWCAP2_BTI + + Functionality implied by ID_AA64PFR0_EL1.BT == 0b0001. + + 4. Unused AT_HWCAP bits -----------------------
diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index 2c08c62..936cf2a 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst
@@ -64,6 +64,10 @@ +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A55 | #1530923 | ARM64_ERRATUM_1530923 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A57 | #852523 | N/A | @@ -78,8 +82,6 @@ +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 | +----------------+-----------------+-----------------+-----------------------------+ -| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 | -+----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A76 | #1165522 | ARM64_ERRATUM_1165522 | @@ -88,8 +90,6 @@ +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A76 | #1463225 | ARM64_ERRATUM_1463225 | +----------------+-----------------+-----------------+-----------------------------+ -| ARM | Cortex-A55 | #1530923 | ARM64_ERRATUM_1530923 | -+----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1349291 | N/A |
diff --git a/Documentation/block/biovecs.rst b/Documentation/block/biovecs.rst index ad303a2..36771a1 100644 --- a/Documentation/block/biovecs.rst +++ b/Documentation/block/biovecs.rst
@@ -129,6 +129,7 @@ :: bio_for_each_segment_all() + bio_for_each_bvec_all() bio_first_bvec_all() bio_first_page_all() bio_last_bvec_all() @@ -143,4 +144,5 @@ bio_vec' will contain a multi-page IO vector during the iteration:: bio_for_each_bvec() + bio_for_each_bvec_all() rq_for_each_bvec()
diff --git a/Documentation/block/index.rst b/Documentation/block/index.rst index 3fa7a52..026addf 100644 --- a/Documentation/block/index.rst +++ b/Documentation/block/index.rst
@@ -14,6 +14,7 @@ cmdline-partition data-integrity deadline-iosched + inline-encryption ioprio kyber-iosched null_blk
diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst new file mode 100644 index 0000000..354817b --- /dev/null +++ b/Documentation/block/inline-encryption.rst
@@ -0,0 +1,263 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================= +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. + + +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). + + +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 :c:type:`struct bio_crypt_ctx` to :c:type:`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 +:c:type:`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 +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 +:c:type:`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``. + + +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). + +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`` on the ``blk_keyslot_manager``, which 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 +:c:type:`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. + +``blk_ksm_destroy`` should be called to free up all resources used by a keyslot +manager upon ``blk_ksm_init``, once the ``blk_keyslot_manager`` 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. + + +Interaction between inline encryption and blk integrity +======================================================= + +At the time of this patch, there is no real hardware that supports both these +features. However, these features do interact with each other, and it's not +completely trivial to make them both work together properly. In particular, +when a WRITE bio wants to use inline encryption on a device that supports both +features, the bio will have an encryption context specified, after which +its integrity information is calculated (using the plaintext data, since +the encryption will happen while data is being written), and the data and +integrity info is sent to the device. Obviously, the integrity info must be +verified before the data is encrypted. After the data is encrypted, the device +must not store the integrity info that it received with the plaintext data +since that might reveal information about the plaintext data. As such, it must +re-generate the integrity info from the ciphertext data and store that on disk +instead. Another issue with storing the integrity info of the plaintext data is +that it changes the on disk format depending on whether hardware inline +encryption support is present or the kernel crypto API fallback is used (since +if the fallback is used, the device will receive the integrity info of the +ciphertext, not that of the plaintext). + +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.
diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst index 38c15c6..0b3db91 100644 --- a/Documentation/bpf/bpf_devel_QA.rst +++ b/Documentation/bpf/bpf_devel_QA.rst
@@ -437,6 +437,21 @@ See the kernels selftest `Documentation/dev-tools/kselftest.rst`_ document for further documentation. +To maximize the number of tests passing, the .config of the kernel +under test should match the config file fragment in +tools/testing/selftests/bpf as closely as possible. + +Finally to ensure support for latest BPF Type Format features - +discussed in `Documentation/bpf/btf.rst`_ - pahole version 1.16 +is required for kernels built with CONFIG_DEBUG_INFO_BTF=y. +pahole is delivered in the dwarves package or can be built +from source at + +https://github.com/acmel/dwarves + +Some distros have pahole version 1.16 packaged already, e.g. +Fedora, Gentoo. + Q: Which BPF kernel selftests version should I run my kernel against? --------------------------------------------------------------------- A: If you run a kernel ``xyz``, then always run the BPF kernel selftests
diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index f99677f..38b4db8 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst
@@ -7,7 +7,7 @@ This kernel side documentation is still work in progress. The main textual documentation is (for historical reasons) described in -`Documentation/networking/filter.txt`_, which describe both classical +`Documentation/networking/filter.rst`_, which describe both classical and extended BPF instruction-set. The Cilium project also maintains a `BPF and XDP Reference Guide`_ that goes into great technical depth about the BPF Architecture. @@ -59,7 +59,7 @@ .. Links: -.. _Documentation/networking/filter.txt: ../networking/filter.txt +.. _Documentation/networking/filter.rst: ../networking/filter.txt .. _man-pages: https://www.kernel.org/doc/man-pages/ .. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html .. _BPF and XDP Reference Guide: http://cilium.readthedocs.io/en/latest/bpf/
diff --git a/Documentation/bpf/ringbuf.rst b/Documentation/bpf/ringbuf.rst new file mode 100644 index 0000000..75f943f --- /dev/null +++ b/Documentation/bpf/ringbuf.rst
@@ -0,0 +1,209 @@ +=============== +BPF ring buffer +=============== + +This document describes BPF ring buffer design, API, and implementation details. + +.. contents:: + :local: + :depth: 2 + +Motivation +---------- + +There are two distinctive motivators for this work, which are not satisfied by +existing perf buffer, which prompted creation of a new ring buffer +implementation. + +- more efficient memory utilization by sharing ring buffer across CPUs; +- preserving ordering of events that happen sequentially in time, even across + multiple CPUs (e.g., fork/exec/exit events for a task). + +These two problems are independent, but perf buffer fails to satisfy both. +Both are a result of a choice to have per-CPU perf ring buffer. Both can be +also solved by having an MPSC implementation of ring buffer. The ordering +problem could technically be solved for perf buffer with some in-kernel +counting, but given the first one requires an MPSC buffer, the same solution +would solve the second problem automatically. + +Semantics and APIs +------------------ + +Single ring buffer is presented to BPF programs as an instance of BPF map of +type ``BPF_MAP_TYPE_RINGBUF``. Two other alternatives considered, but +ultimately rejected. + +One way would be to, similar to ``BPF_MAP_TYPE_PERF_EVENT_ARRAY``, make +``BPF_MAP_TYPE_RINGBUF`` could represent an array of ring buffers, but not +enforce "same CPU only" rule. This would be more familiar interface compatible +with existing perf buffer use in BPF, but would fail if application needed more +advanced logic to lookup ring buffer by arbitrary key. +``BPF_MAP_TYPE_HASH_OF_MAPS`` addresses this with current approach. +Additionally, given the performance of BPF ringbuf, many use cases would just +opt into a simple single ring buffer shared among all CPUs, for which current +approach would be an overkill. + +Another approach could introduce a new concept, alongside BPF map, to represent +generic "container" object, which doesn't necessarily have key/value interface +with lookup/update/delete operations. This approach would add a lot of extra +infrastructure that has to be built for observability and verifier support. It +would also add another concept that BPF developers would have to familiarize +themselves with, new syntax in libbpf, etc. But then would really provide no +additional benefits over the approach of using a map. ``BPF_MAP_TYPE_RINGBUF`` +doesn't support lookup/update/delete operations, but so doesn't few other map +types (e.g., queue and stack; array doesn't support delete, etc). + +The approach chosen has an advantage of re-using existing BPF map +infrastructure (introspection APIs in kernel, libbpf support, etc), being +familiar concept (no need to teach users a new type of object in BPF program), +and utilizing existing tooling (bpftool). For common scenario of using a single +ring buffer for all CPUs, it's as simple and straightforward, as would be with +a dedicated "container" object. On the other hand, by being a map, it can be +combined with ``ARRAY_OF_MAPS`` and ``HASH_OF_MAPS`` map-in-maps to implement +a wide variety of topologies, from one ring buffer for each CPU (e.g., as +a replacement for perf buffer use cases), to a complicated application +hashing/sharding of ring buffers (e.g., having a small pool of ring buffers +with hashed task's tgid being a look up key to preserve order, but reduce +contention). + +Key and value sizes are enforced to be zero. ``max_entries`` is used to specify +the size of ring buffer and has to be a power of 2 value. + +There are a bunch of similarities between perf buffer +(``BPF_MAP_TYPE_PERF_EVENT_ARRAY``) and new BPF ring buffer semantics: + +- variable-length records; +- if there is no more space left in ring buffer, reservation fails, no + blocking; +- memory-mappable data area for user-space applications for ease of + consumption and high performance; +- epoll notifications for new incoming data; +- but still the ability to do busy polling for new data to achieve the + lowest latency, if necessary. + +BPF ringbuf provides two sets of APIs to BPF programs: + +- ``bpf_ringbuf_output()`` allows to *copy* data from one place to a ring + buffer, similarly to ``bpf_perf_event_output()``; +- ``bpf_ringbuf_reserve()``/``bpf_ringbuf_commit()``/``bpf_ringbuf_discard()`` + APIs split the whole process into two steps. First, a fixed amount of space + is reserved. If successful, a pointer to a data inside ring buffer data + area is returned, which BPF programs can use similarly to a data inside + array/hash maps. Once ready, this piece of memory is either committed or + discarded. Discard is similar to commit, but makes consumer ignore the + record. + +``bpf_ringbuf_output()`` has disadvantage of incurring extra memory copy, +because record has to be prepared in some other place first. But it allows to +submit records of the length that's not known to verifier beforehand. It also +closely matches ``bpf_perf_event_output()``, so will simplify migration +significantly. + +``bpf_ringbuf_reserve()`` avoids the extra copy of memory by providing a memory +pointer directly to ring buffer memory. In a lot of cases records are larger +than BPF stack space allows, so many programs have use extra per-CPU array as +a temporary heap for preparing sample. bpf_ringbuf_reserve() avoid this needs +completely. But in exchange, it only allows a known constant size of memory to +be reserved, such that verifier can verify that BPF program can't access memory +outside its reserved record space. bpf_ringbuf_output(), while slightly slower +due to extra memory copy, covers some use cases that are not suitable for +``bpf_ringbuf_reserve()``. + +The difference between commit and discard is very small. Discard just marks +a record as discarded, and such records are supposed to be ignored by consumer +code. Discard is useful for some advanced use-cases, such as ensuring +all-or-nothing multi-record submission, or emulating temporary +``malloc()``/``free()`` within single BPF program invocation. + +Each reserved record is tracked by verifier through existing +reference-tracking logic, similar to socket ref-tracking. It is thus +impossible to reserve a record, but forget to submit (or discard) it. + +``bpf_ringbuf_query()`` helper allows to query various properties of ring +buffer. Currently 4 are supported: + +- ``BPF_RB_AVAIL_DATA`` returns amount of unconsumed data in ring buffer; +- ``BPF_RB_RING_SIZE`` returns the size of ring buffer; +- ``BPF_RB_CONS_POS``/``BPF_RB_PROD_POS`` returns current logical possition + of consumer/producer, respectively. + +Returned values are momentarily snapshots of ring buffer state and could be +off by the time helper returns, so this should be used only for +debugging/reporting reasons or for implementing various heuristics, that take +into account highly-changeable nature of some of those characteristics. + +One such heuristic might involve more fine-grained control over poll/epoll +notifications about new data availability in ring buffer. Together with +``BPF_RB_NO_WAKEUP``/``BPF_RB_FORCE_WAKEUP`` flags for output/commit/discard +helpers, it allows BPF program a high degree of control and, e.g., more +efficient batched notifications. Default self-balancing strategy, though, +should be adequate for most applications and will work reliable and efficiently +already. + +Design and Implementation +------------------------- + +This reserve/commit schema allows a natural way for multiple producers, either +on different CPUs or even on the same CPU/in the same BPF program, to reserve +independent records and work with them without blocking other producers. This +means that if BPF program was interruped by another BPF program sharing the +same ring buffer, they will both get a record reserved (provided there is +enough space left) and can work with it and submit it independently. This +applies to NMI context as well, except that due to using a spinlock during +reservation, in NMI context, ``bpf_ringbuf_reserve()`` might fail to get +a lock, in which case reservation will fail even if ring buffer is not full. + +The ring buffer itself internally is implemented as a power-of-2 sized +circular buffer, with two logical and ever-increasing counters (which might +wrap around on 32-bit architectures, that's not a problem): + +- consumer counter shows up to which logical position consumer consumed the + data; +- producer counter denotes amount of data reserved by all producers. + +Each time a record is reserved, producer that "owns" the record will +successfully advance producer counter. At that point, data is still not yet +ready to be consumed, though. Each record has 8 byte header, which contains the +length of reserved record, as well as two extra bits: busy bit to denote that +record is still being worked on, and discard bit, which might be set at commit +time if record is discarded. In the latter case, consumer is supposed to skip +the record and move on to the next one. Record header also encodes record's +relative offset from the beginning of ring buffer data area (in pages). This +allows ``bpf_ringbuf_commit()``/``bpf_ringbuf_discard()`` to accept only the +pointer to the record itself, without requiring also the pointer to ring buffer +itself. Ring buffer memory location will be restored from record metadata +header. This significantly simplifies verifier, as well as improving API +usability. + +Producer counter increments are serialized under spinlock, so there is +a strict ordering between reservations. Commits, on the other hand, are +completely lockless and independent. All records become available to consumer +in the order of reservations, but only after all previous records where +already committed. It is thus possible for slow producers to temporarily hold +off submitted records, that were reserved later. + +Reservation/commit/consumer protocol is verified by litmus tests in +Documentation/litmus_tests/bpf-rb/_. + +One interesting implementation bit, that significantly simplifies (and thus +speeds up as well) implementation of both producers and consumers is how data +area is mapped twice contiguously back-to-back in the virtual memory. This +allows to not take any special measures for samples that have to wrap around +at the end of the circular buffer data area, because the next page after the +last data page would be first data page again, and thus the sample will still +appear completely contiguous in virtual memory. See comment and a simple ASCII +diagram showing this visually in ``bpf_ringbuf_area_alloc()``. + +Another feature that distinguishes BPF ringbuf from perf ring buffer is +a self-pacing notifications of new data being availability. +``bpf_ringbuf_commit()`` implementation will send a notification of new record +being available after commit only if consumer has already caught up right up to +the record being committed. If not, consumer still has to catch up and thus +will see new data anyways without needing an extra poll notification. +Benchmarks (see tools/testing/selftests/bpf/benchs/bench_ringbuf.c_) show that +this allows to achieve a very high throughput without having to resort to +tricks like "notify only every Nth sample", which are necessary with perf +buffer. For extreme cases, when BPF program wants more manual control of +notifications, commit/discard/output helpers accept ``BPF_RB_NO_WAKEUP`` and +``BPF_RB_FORCE_WAKEUP`` flags, which give full control over notifications of +data availability, but require extra caution and diligence in using this API.
diff --git a/Documentation/conf.py b/Documentation/conf.py index 9ae8e9a..c503188 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py
@@ -388,44 +388,6 @@ # author, documentclass [howto, manual, or own class]). # Sorted in alphabetical order latex_documents = [ - ('admin-guide/index', 'linux-user.tex', 'Linux Kernel User Documentation', - 'The kernel development community', 'manual'), - ('core-api/index', 'core-api.tex', 'The kernel core API manual', - 'The kernel development community', 'manual'), - ('crypto/index', 'crypto-api.tex', 'Linux Kernel Crypto API manual', - 'The kernel development community', 'manual'), - ('dev-tools/index', 'dev-tools.tex', 'Development tools for the Kernel', - 'The kernel development community', 'manual'), - ('doc-guide/index', 'kernel-doc-guide.tex', 'Linux Kernel Documentation Guide', - 'The kernel development community', 'manual'), - ('driver-api/index', 'driver-api.tex', 'The kernel driver API manual', - 'The kernel development community', 'manual'), - ('filesystems/index', 'filesystems.tex', 'Linux Filesystems API', - 'The kernel development community', 'manual'), - ('admin-guide/ext4', 'ext4-admin-guide.tex', 'ext4 Administration Guide', - 'ext4 Community', 'manual'), - ('filesystems/ext4/index', 'ext4-data-structures.tex', - 'ext4 Data Structures and Algorithms', 'ext4 Community', 'manual'), - ('gpu/index', 'gpu.tex', 'Linux GPU Driver Developer\'s Guide', - 'The kernel development community', 'manual'), - ('input/index', 'linux-input.tex', 'The Linux input driver subsystem', - 'The kernel development community', 'manual'), - ('kernel-hacking/index', 'kernel-hacking.tex', 'Unreliable Guide To Hacking The Linux Kernel', - 'The kernel development community', 'manual'), - ('media/index', 'media.tex', 'Linux Media Subsystem Documentation', - 'The kernel development community', 'manual'), - ('networking/index', 'networking.tex', 'Linux Networking Documentation', - 'The kernel development community', 'manual'), - ('process/index', 'development-process.tex', 'Linux Kernel Development Documentation', - 'The kernel development community', 'manual'), - ('security/index', 'security.tex', 'The kernel security subsystem manual', - 'The kernel development community', 'manual'), - ('sh/index', 'sh.tex', 'SuperH architecture implementation manual', - 'The kernel development community', 'manual'), - ('sound/index', 'sound.tex', 'Linux Sound Subsystem Documentation', - 'The kernel development community', 'manual'), - ('userspace-api/index', 'userspace-api.tex', 'The Linux kernel user-space API guide', - 'The kernel development community', 'manual'), ] # Add all other index files from Documentation/ subdirectories @@ -576,7 +538,7 @@ # Grouping the document tree into PDF files. List of tuples # (source start file, target name, title, author, options). # -# See the Sphinx chapter of http://ralsina.me/static/manual.pdf +# See the Sphinx chapter of https://ralsina.me/static/manual.pdf # # FIXME: Do not add the index file here; the result will be too big. Adding # multiple PDF files here actually tries to get the cross-referencing right
diff --git a/Documentation/core-api/cachetlb.rst b/Documentation/core-api/cachetlb.rst index 93cb65d..a1582cc 100644 --- a/Documentation/core-api/cachetlb.rst +++ b/Documentation/core-api/cachetlb.rst
@@ -213,7 +213,7 @@ there will be no entries in the cache for the kernel address space for virtual addresses in the range 'start' to 'end-1'. - The first of these two routines is invoked after map_vm_area() + The first of these two routines is invoked after map_kernel_range() has installed the page table entries. The second is invoked before unmap_kernel_range() deletes the page table entries.
diff --git a/Documentation/debugging-via-ohci1394.txt b/Documentation/core-api/debugging-via-ohci1394.rst similarity index 100% rename from Documentation/debugging-via-ohci1394.txt rename to Documentation/core-api/debugging-via-ohci1394.rst
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/core-api/dma-api-howto.rst similarity index 100% rename from Documentation/DMA-API-HOWTO.txt rename to Documentation/core-api/dma-api-howto.rst
diff --git a/Documentation/DMA-API.txt b/Documentation/core-api/dma-api.rst similarity index 100% rename from Documentation/DMA-API.txt rename to Documentation/core-api/dma-api.rst
diff --git a/Documentation/DMA-attributes.txt b/Documentation/core-api/dma-attributes.rst similarity index 100% rename from Documentation/DMA-attributes.txt rename to Documentation/core-api/dma-attributes.rst
diff --git a/Documentation/DMA-ISA-LPC.txt b/Documentation/core-api/dma-isa-lpc.rst similarity index 100% rename from Documentation/DMA-ISA-LPC.txt rename to Documentation/core-api/dma-isa-lpc.rst
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index 0897ad1..15ab861 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst
@@ -18,6 +18,7 @@ kernel-api workqueue + printk-basics printk-formats symbol-namespaces @@ -30,10 +31,12 @@ :maxdepth: 1 kobject + kref assoc_array xarray idr circular-buffers + rbtree generic-radix-tree packing timekeeping @@ -50,6 +53,7 @@ atomic_ops refcount-vs-atomic + irq/index local_ops padata ../RCU/index @@ -78,6 +82,10 @@ :maxdepth: 1 memory-allocation + dma-api + dma-api-howto + dma-attributes + dma-isa-lpc mm-api genalloc pin_user_pages @@ -92,6 +100,7 @@ debug-objects tracepoint + debugging-via-ohci1394 Everything else ===============
diff --git a/Documentation/IRQ.txt b/Documentation/core-api/irq/concepts.rst similarity index 100% rename from Documentation/IRQ.txt rename to Documentation/core-api/irq/concepts.rst
diff --git a/Documentation/core-api/irq/index.rst b/Documentation/core-api/irq/index.rst new file mode 100644 index 0000000..0d65d11 --- /dev/null +++ b/Documentation/core-api/irq/index.rst
@@ -0,0 +1,11 @@ +==== +IRQs +==== + +.. toctree:: + :maxdepth: 1 + + concepts + irq-affinity + irq-domain + irqflags-tracing
diff --git a/Documentation/IRQ-affinity.txt b/Documentation/core-api/irq/irq-affinity.rst similarity index 100% rename from Documentation/IRQ-affinity.txt rename to Documentation/core-api/irq/irq-affinity.rst
diff --git a/Documentation/core-api/irq/irq-domain.rst b/Documentation/core-api/irq/irq-domain.rst new file mode 100644 index 0000000..096db12 --- /dev/null +++ b/Documentation/core-api/irq/irq-domain.rst
@@ -0,0 +1,270 @@ +=============================================== +The irq_domain interrupt number mapping library +=============================================== + +The current design of the Linux kernel uses a single large number +space where each separate IRQ source is assigned a different number. +This is simple when there is only one interrupt controller, but in +systems with multiple interrupt controllers the kernel must ensure +that each one gets assigned non-overlapping allocations of Linux +IRQ numbers. + +The number of interrupt controllers registered as unique irqchips +show a rising tendency: for example subdrivers of different kinds +such as GPIO controllers avoid reimplementing identical callback +mechanisms as the IRQ core system by modelling their interrupt +handlers as irqchips, i.e. in effect cascading interrupt controllers. + +Here the interrupt number loose all kind of correspondence to +hardware interrupt numbers: whereas in the past, IRQ numbers could +be chosen so they matched the hardware IRQ line into the root +interrupt controller (i.e. the component actually fireing the +interrupt line to the CPU) nowadays this number is just a number. + +For this reason we need a mechanism to separate controller-local +interrupt numbers, called hardware irq's, from Linux IRQ numbers. + +The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of +irq numbers, but they don't provide any support for reverse mapping of +the controller-local IRQ (hwirq) number into the Linux IRQ number +space. + +The irq_domain library adds mapping between hwirq and IRQ numbers on +top of the irq_alloc_desc*() API. An irq_domain to manage mapping is +preferred over interrupt controller drivers open coding their own +reverse mapping scheme. + +irq_domain also implements translation from an abstract irq_fwspec +structure to hwirq numbers (Device Tree and ACPI GSI so far), and can +be easily extended to support other IRQ topology data sources. + +irq_domain usage +================ + +An interrupt controller driver creates and registers an irq_domain by +calling one of the irq_domain_add_*() functions (each mapping method +has a different allocator function, more on that later). The function +will return a pointer to the irq_domain on success. The caller must +provide the allocator function with an irq_domain_ops structure. + +In most cases, the irq_domain will begin empty without any mappings +between hwirq and IRQ numbers. Mappings are added to the irq_domain +by calling irq_create_mapping() which accepts the irq_domain and a +hwirq number as arguments. If a mapping for the hwirq doesn't already +exist then it will allocate a new Linux irq_desc, associate it with +the hwirq, and call the .map() callback so the driver can perform any +required hardware setup. + +When an interrupt is received, irq_find_mapping() function should +be used to find the Linux IRQ number from the hwirq number. + +The irq_create_mapping() function must be called *atleast once* +before any call to irq_find_mapping(), lest the descriptor will not +be allocated. + +If the driver has the Linux IRQ number or the irq_data pointer, and +needs to know the associated hwirq number (such as in the irq_chip +callbacks) then it can be directly obtained from irq_data->hwirq. + +Types of irq_domain mappings +============================ + +There are several mechanisms available for reverse mapping from hwirq +to Linux irq, and each mechanism uses a different allocation function. +Which reverse map type should be used depends on the use case. Each +of the reverse map types are described below: + +Linear +------ + +:: + + irq_domain_add_linear() + irq_domain_create_linear() + +The linear reverse map maintains a fixed size table indexed by the +hwirq number. When a hwirq is mapped, an irq_desc is allocated for +the hwirq, and the IRQ number is stored in the table. + +The Linear map is a good choice when the maximum number of hwirqs is +fixed and a relatively small number (~ < 256). The advantages of this +map are fixed time lookup for IRQ numbers, and irq_descs are only +allocated for in-use IRQs. The disadvantage is that the table must be +as large as the largest possible hwirq number. + +irq_domain_add_linear() and irq_domain_create_linear() are functionally +equivalent, except for the first argument is different - the former +accepts an Open Firmware specific 'struct device_node', while the latter +accepts a more general abstraction 'struct fwnode_handle'. + +The majority of drivers should use the linear map. + +Tree +---- + +:: + + irq_domain_add_tree() + irq_domain_create_tree() + +The irq_domain maintains a radix tree map from hwirq numbers to Linux +IRQs. When an hwirq is mapped, an irq_desc is allocated and the +hwirq is used as the lookup key for the radix tree. + +The tree map is a good choice if the hwirq number can be very large +since it doesn't need to allocate a table as large as the largest +hwirq number. The disadvantage is that hwirq to IRQ number lookup is +dependent on how many entries are in the table. + +irq_domain_add_tree() and irq_domain_create_tree() are functionally +equivalent, except for the first argument is different - the former +accepts an Open Firmware specific 'struct device_node', while the latter +accepts a more general abstraction 'struct fwnode_handle'. + +Very few drivers should need this mapping. + +No Map +------ + +:: + + irq_domain_add_nomap() + +The No Map mapping is to be used when the hwirq number is +programmable in the hardware. In this case it is best to program the +Linux IRQ number into the hardware itself so that no mapping is +required. Calling irq_create_direct_mapping() will allocate a Linux +IRQ number and call the .map() callback so that driver can program the +Linux IRQ number into the hardware. + +Most drivers cannot use this mapping. + +Legacy +------ + +:: + + irq_domain_add_simple() + irq_domain_add_legacy() + irq_domain_add_legacy_isa() + +The Legacy mapping is a special case for drivers that already have a +range of irq_descs allocated for the hwirqs. It is used when the +driver cannot be immediately converted to use the linear mapping. For +example, many embedded system board support files use a set of #defines +for IRQ numbers that are passed to struct device registrations. In that +case the Linux IRQ numbers cannot be dynamically assigned and the legacy +mapping should be used. + +The legacy map assumes a contiguous range of IRQ numbers has already +been allocated for the controller and that the IRQ number can be +calculated by adding a fixed offset to the hwirq number, and +visa-versa. The disadvantage is that it requires the interrupt +controller to manage IRQ allocations and it requires an irq_desc to be +allocated for every hwirq, even if it is unused. + +The legacy map should only be used if fixed IRQ mappings must be +supported. For example, ISA controllers would use the legacy map for +mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ +numbers. + +Most users of legacy mappings should use irq_domain_add_simple() which +will use a legacy domain only if an IRQ range is supplied by the +system and will otherwise use a linear domain mapping. The semantics +of this call are such that if an IRQ range is specified then +descriptors will be allocated on-the-fly for it, and if no range is +specified it will fall through to irq_domain_add_linear() which means +*no* irq descriptors will be allocated. + +A typical use case for simple domains is where an irqchip provider +is supporting both dynamic and static IRQ assignments. + +In order to avoid ending up in a situation where a linear domain is +used and no descriptor gets allocated it is very important to make sure +that the driver using the simple domain call irq_create_mapping() +before any irq_find_mapping() since the latter will actually work +for the static IRQ assignment case. + +Hierarchy IRQ domain +-------------------- + +On some architectures, there may be multiple interrupt controllers +involved in delivering an interrupt from the device to the target CPU. +Let's look at a typical interrupt delivering path on x86 platforms:: + + Device --> IOAPIC -> Interrupt remapping Controller -> Local APIC -> CPU + +There are three interrupt controllers involved: + +1) IOAPIC controller +2) Interrupt remapping controller +3) Local APIC controller + +To support such a hardware topology and make software architecture match +hardware architecture, an irq_domain data structure is built for each +interrupt controller and those irq_domains are organized into hierarchy. +When building irq_domain hierarchy, the irq_domain near to the device is +child and the irq_domain near to CPU is parent. So a hierarchy structure +as below will be built for the example above:: + + CPU Vector irq_domain (root irq_domain to manage CPU vectors) + ^ + | + Interrupt Remapping irq_domain (manage irq_remapping entries) + ^ + | + IOAPIC irq_domain (manage IOAPIC delivery entries/pins) + +There are four major interfaces to use hierarchy irq_domain: + +1) irq_domain_alloc_irqs(): allocate IRQ descriptors and interrupt + controller related resources to deliver these interrupts. +2) irq_domain_free_irqs(): free IRQ descriptors and interrupt controller + related resources associated with these interrupts. +3) irq_domain_activate_irq(): activate interrupt controller hardware to + deliver the interrupt. +4) irq_domain_deactivate_irq(): deactivate interrupt controller hardware + to stop delivering the interrupt. + +Following changes are needed to support hierarchy irq_domain: + +1) a new field 'parent' is added to struct irq_domain; it's used to + maintain irq_domain hierarchy information. +2) a new field 'parent_data' is added to struct irq_data; it's used to + build hierarchy irq_data to match hierarchy irq_domains. The irq_data + is used to store irq_domain pointer and hardware irq number. +3) new callbacks are added to struct irq_domain_ops to support hierarchy + irq_domain operations. + +With support of hierarchy irq_domain and hierarchy irq_data ready, an +irq_domain structure is built for each interrupt controller, and an +irq_data structure is allocated for each irq_domain associated with an +IRQ. Now we could go one step further to support stacked(hierarchy) +irq_chip. That is, an irq_chip is associated with each irq_data along +the hierarchy. A child irq_chip may implement a required action by +itself or by cooperating with its parent irq_chip. + +With stacked irq_chip, interrupt controller driver only needs to deal +with the hardware managed by itself and may ask for services from its +parent irq_chip when needed. So we could achieve a much cleaner +software architecture. + +For an interrupt controller driver to support hierarchy irq_domain, it +needs to: + +1) Implement irq_domain_ops.alloc and irq_domain_ops.free +2) Optionally implement irq_domain_ops.activate and + irq_domain_ops.deactivate. +3) Optionally implement an irq_chip to manage the interrupt controller + hardware. +4) No need to implement irq_domain_ops.map and irq_domain_ops.unmap, + they are unused with hierarchy irq_domain. + +Hierarchy irq_domain is in no way x86 specific, and is heavily used to +support other architectures, such as ARM, ARM64 etc. + +Debugging +========= + +Most of the internals of the IRQ subsystem are exposed in debugfs by +turning CONFIG_GENERIC_IRQ_DEBUGFS on.
diff --git a/Documentation/irqflags-tracing.txt b/Documentation/core-api/irq/irqflags-tracing.rst similarity index 100% rename from Documentation/irqflags-tracing.txt rename to Documentation/core-api/irq/irqflags-tracing.rst
diff --git a/Documentation/core-api/kobject.rst b/Documentation/core-api/kobject.rst index 1f62d4d..e93dc8c 100644 --- a/Documentation/core-api/kobject.rst +++ b/Documentation/core-api/kobject.rst
@@ -80,11 +80,11 @@ (such as assuming that the kobject is at the beginning of the structure) and, instead, use the container_of() macro, found in ``<linux/kernel.h>``:: - container_of(pointer, type, member) + container_of(ptr, type, member) where: - * ``pointer`` is the pointer to the embedded kobject, + * ``ptr`` is the pointer to the embedded kobject, * ``type`` is the type of the containing structure, and * ``member`` is the name of the structure field to which ``pointer`` points. @@ -140,7 +140,7 @@ int kobject_rename(struct kobject *kobj, const char *new_name); -kobject_rename does not perform any locking or have a solid notion of +kobject_rename() does not perform any locking or have a solid notion of what names are valid so the caller must provide their own sanity checking and serialization. @@ -210,7 +210,7 @@ If all that you want to use a kobject for is to provide a reference counter for your structure, please use the struct kref instead; a kobject would be overkill. For more information on how to use struct kref, please see the -file Documentation/kref.txt in the Linux kernel source tree. +file Documentation/core-api/kref.rst in the Linux kernel source tree. Creating "simple" kobjects @@ -222,17 +222,17 @@ exception where a single kobject should be created. To create such an entry, use the function:: - struct kobject *kobject_create_and_add(char *name, struct kobject *parent); + struct kobject *kobject_create_and_add(const char *name, struct kobject *parent); This function will create a kobject and place it in sysfs in the location underneath the specified parent kobject. To create simple attributes associated with this kobject, use:: - int sysfs_create_file(struct kobject *kobj, struct attribute *attr); + int sysfs_create_file(struct kobject *kobj, const struct attribute *attr); or:: - int sysfs_create_group(struct kobject *kobj, struct attribute_group *grp); + int sysfs_create_group(struct kobject *kobj, const struct attribute_group *grp); Both types of attributes used here, with a kobject that has been created with the kobject_create_and_add(), can be of type kobj_attribute, so no @@ -300,8 +300,10 @@ void (*release)(struct kobject *kobj); const struct sysfs_ops *sysfs_ops; struct attribute **default_attrs; + const struct attribute_group **default_groups; const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj); const void *(*namespace)(struct kobject *kobj); + void (*get_ownership)(struct kobject *kobj, kuid_t *uid, kgid_t *gid); }; This structure is used to describe a particular type of kobject (or, more @@ -352,12 +354,12 @@ kset use:: struct kset *kset_create_and_add(const char *name, - struct kset_uevent_ops *u, - struct kobject *parent); + const struct kset_uevent_ops *uevent_ops, + struct kobject *parent_kobj); When you are finished with the kset, call:: - void kset_unregister(struct kset *kset); + void kset_unregister(struct kset *k); to destroy it. This removes the kset from sysfs and decrements its reference count. When the reference count goes to zero, the kset will be released. @@ -371,9 +373,9 @@ associated with it, it can use the struct kset_uevent_ops to handle it:: struct kset_uevent_ops { - int (*filter)(struct kset *kset, struct kobject *kobj); - const char *(*name)(struct kset *kset, struct kobject *kobj); - int (*uevent)(struct kset *kset, struct kobject *kobj, + int (* const filter)(struct kset *kset, struct kobject *kobj); + const char *(* const name)(struct kset *kset, struct kobject *kobj); + int (* const uevent)(struct kset *kset, struct kobject *kobj, struct kobj_uevent_env *env); };
diff --git a/Documentation/kref.txt b/Documentation/core-api/kref.rst similarity index 100% rename from Documentation/kref.txt rename to Documentation/core-api/kref.rst
diff --git a/Documentation/core-api/padata.rst b/Documentation/core-api/padata.rst index 9a24c11..0830e5b 100644 --- a/Documentation/core-api/padata.rst +++ b/Documentation/core-api/padata.rst
@@ -4,23 +4,26 @@ The padata parallel execution mechanism ======================================= -:Date: December 2019 +:Date: May 2020 Padata is a mechanism by which the kernel can farm jobs out to be done in -parallel on multiple CPUs while retaining their ordering. It was developed for -use with the IPsec code, which needs to be able to perform encryption and -decryption on large numbers of packets without reordering those packets. The -crypto developers made a point of writing padata in a sufficiently general -fashion that it could be put to other uses as well. +parallel on multiple CPUs while optionally retaining their ordering. -Usage -===== +It was originally developed for IPsec, which needs to perform encryption and +decryption on large numbers of packets without reordering those packets. This +is currently the sole consumer of padata's serialized job support. + +Padata also supports multithreaded jobs, splitting up the job evenly while load +balancing and coordinating between threads. + +Running Serialized Jobs +======================= Initializing ------------ -The first step in using padata is to set up a padata_instance structure for -overall control of how jobs are to be run:: +The first step in using padata to run serialized jobs is to set up a +padata_instance structure for overall control of how jobs are to be run:: #include <linux/padata.h> @@ -162,6 +165,24 @@ It is the user's responsibility to ensure all outstanding jobs are complete before any of the above are called. +Running Multithreaded Jobs +========================== + +A multithreaded job has a main thread and zero or more helper threads, with the +main thread participating in the job and then waiting until all helpers have +finished. padata splits the job into units called chunks, where a chunk is a +piece of the job that one thread completes in one call to the thread function. + +A user has to do three things to run a multithreaded job. First, describe the +job by defining a padata_mt_job structure, which is explained in the Interface +section. This includes a pointer to the thread function, which padata will +call each time it assigns a job chunk to a thread. Then, define the thread +function, which accepts three arguments, ``start``, ``end``, and ``arg``, where +the first two delimit the range that the thread operates on and the last is a +pointer to the job's shared state, if any. Prepare the shared state, which is +typically allocated on the main thread's stack. Last, call +padata_do_multithreaded(), which will return once the job is finished. + Interface =========
diff --git a/Documentation/core-api/pin_user_pages.rst b/Documentation/core-api/pin_user_pages.rst index 2e939ff..6068266 100644 --- a/Documentation/core-api/pin_user_pages.rst +++ b/Documentation/core-api/pin_user_pages.rst
@@ -148,23 +148,46 @@ because DAX pages do not have a separate page cache, and so "pinning" implies locking down file system blocks, which is not (yet) supported in that way. -CASE 3: Hardware with page faulting support -------------------------------------------- -Here, a well-written driver doesn't normally need to pin pages at all. However, -if the driver does choose to do so, it can register MMU notifiers for the range, -and will be called back upon invalidation. Either way (avoiding page pinning, or -using MMU notifiers to unpin upon request), there is proper synchronization with -both filesystem and mm (page_mkclean(), munmap(), etc). +CASE 3: MMU notifier registration, with or without page faulting hardware +------------------------------------------------------------------------- +Device drivers can pin pages via get_user_pages*(), and register for mmu +notifier callbacks for the memory range. Then, upon receiving a notifier +"invalidate range" callback , stop the device from using the range, and unpin +the pages. There may be other possible schemes, such as for example explicitly +synchronizing against pending IO, that accomplish approximately the same thing. -Therefore, neither flag needs to be set. +Or, if the hardware supports replayable page faults, then the device driver can +avoid pinning entirely (this is ideal), as follows: register for mmu notifier +callbacks as above, but instead of stopping the device and unpinning in the +callback, simply remove the range from the device's page tables. -In this case, ideally, neither get_user_pages() nor pin_user_pages() should be -called. Instead, the software should be written so that it does not pin pages. -This allows mm and filesystems to operate more efficiently and reliably. +Either way, as long as the driver unpins the pages upon mmu notifier callback, +then there is proper synchronization with both filesystem and mm +(page_mkclean(), munmap(), etc). Therefore, neither flag needs to be set. CASE 4: Pinning for struct page manipulation only ------------------------------------------------- -Here, normal GUP calls are sufficient, so neither flag needs to be set. +If only struct page data (as opposed to the actual memory contents that a page +is tracking) is affected, then normal GUP calls are sufficient, and neither flag +needs to be set. + +CASE 5: Pinning in order to write to the data within the page +------------------------------------------------------------- +Even though neither DMA nor Direct IO is involved, just a simple case of "pin, +write to a page's data, unpin" can cause a problem. Case 5 may be considered a +superset of Case 1, plus Case 2, plus anything that invokes that pattern. In +other words, if the code is neither Case 1 nor Case 2, it may still require +FOLL_PIN, for patterns like this: + +Correct (uses FOLL_PIN calls): + pin_user_pages() + write to the data within the pages + unpin_user_pages() + +INCORRECT (uses FOLL_GET calls): + get_user_pages() + write to the data within the pages + put_page() page_maybe_dma_pinned(): the whole point of pinning ===================================================
diff --git a/Documentation/core-api/printk-basics.rst b/Documentation/core-api/printk-basics.rst new file mode 100644 index 0000000..563a9ce --- /dev/null +++ b/Documentation/core-api/printk-basics.rst
@@ -0,0 +1,115 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================== +Message logging with printk +=========================== + +printk() is one of the most widely known functions in the Linux kernel. It's the +standard tool we have for printing messages and usually the most basic way of +tracing and debugging. If you're familiar with printf(3) you can tell printk() +is based on it, although it has some functional differences: + + - printk() messages can specify a log level. + + - the format string, while largely compatible with C99, doesn't follow the + exact same specification. It has some extensions and a few limitations + (no ``%n`` or floating point conversion specifiers). See :ref:`How to get + printk format specifiers right <printk-specifiers>`. + +All printk() messages are printed to the kernel log buffer, which is a ring +buffer exported to userspace through /dev/kmsg. The usual way to read it is +using ``dmesg``. + +printk() is typically used like this:: + + printk(KERN_INFO "Message: %s\n", arg); + +where ``KERN_INFO`` is the log level (note that it's concatenated to the format +string, the log level is not a separate argument). The available log levels are: + ++----------------+--------+-----------------------------------------------+ +| Name | String | Alias function | ++================+========+===============================================+ +| KERN_EMERG | "0" | pr_emerg() | ++----------------+--------+-----------------------------------------------+ +| KERN_ALERT | "1" | pr_alert() | ++----------------+--------+-----------------------------------------------+ +| KERN_CRIT | "2" | pr_crit() | ++----------------+--------+-----------------------------------------------+ +| KERN_ERR | "3" | pr_err() | ++----------------+--------+-----------------------------------------------+ +| KERN_WARNING | "4" | pr_warn() | ++----------------+--------+-----------------------------------------------+ +| KERN_NOTICE | "5" | pr_notice() | ++----------------+--------+-----------------------------------------------+ +| KERN_INFO | "6" | pr_info() | ++----------------+--------+-----------------------------------------------+ +| KERN_DEBUG | "7" | pr_debug() and pr_devel() if DEBUG is defined | ++----------------+--------+-----------------------------------------------+ +| KERN_DEFAULT | "" | | ++----------------+--------+-----------------------------------------------+ +| KERN_CONT | "c" | pr_cont() | ++----------------+--------+-----------------------------------------------+ + + +The log level specifies the importance of a message. The kernel decides whether +to show the message immediately (printing it to the current console) depending +on its log level and the current *console_loglevel* (a kernel variable). If the +message priority is higher (lower log level value) than the *console_loglevel* +the message will be printed to the console. + +If the log level is omitted, the message is printed with ``KERN_DEFAULT`` +level. + +You can check the current *console_loglevel* with:: + + $ cat /proc/sys/kernel/printk + 4 4 1 7 + +The result shows the *current*, *default*, *minimum* and *boot-time-default* log +levels. + +To change the current console_loglevel simply write the the desired level to +``/proc/sys/kernel/printk``. For example, to print all messages to the console:: + + # echo 8 > /proc/sys/kernel/printk + +Another way, using ``dmesg``:: + + # dmesg -n 5 + +sets the console_loglevel to print KERN_WARNING (4) or more severe messages to +console. See ``dmesg(1)`` for more information. + +As an alternative to printk() you can use the ``pr_*()`` aliases for +logging. This family of macros embed the log level in the macro names. For +example:: + + pr_info("Info message no. %d\n", msg_num); + +prints a ``KERN_INFO`` message. + +Besides being more concise than the equivalent printk() calls, they can use a +common definition for the format string through the pr_fmt() macro. For +instance, defining this at the top of a source file (before any ``#include`` +directive):: + + #define pr_fmt(fmt) "%s:%s: " fmt, KBUILD_MODNAME, __func__ + +would prefix every pr_*() message in that file with the module and function name +that originated the message. + +For debugging purposes there are also two conditionally-compiled macros: +pr_debug() and pr_devel(), which are compiled-out unless ``DEBUG`` (or +also ``CONFIG_DYNAMIC_DEBUG`` in the case of pr_debug()) is defined. + + +Function reference +================== + +.. kernel-doc:: kernel/printk/printk.c + :functions: printk + +.. kernel-doc:: include/linux/printk.h + :functions: pr_emerg pr_alert pr_crit pr_err pr_warn pr_notice pr_info + pr_fmt pr_debug pr_devel pr_cont
diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index 8ebe46b1..8c9aba2 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst
@@ -2,6 +2,8 @@ How to get printk format specifiers right ========================================= +.. _printk-specifiers: + :Author: Randy Dunlap <rdunlap@infradead.org> :Author: Andrew Murray <amurray@mpc-data.co.uk> @@ -112,6 +114,20 @@ consideration the effect of compiler optimisations which may occur when tail-calls are used and marked with the noreturn GCC attribute. +Probed Pointers from BPF / tracing +---------------------------------- + +:: + + %pks kernel string + %pus user string + +The ``k`` and ``u`` specifiers are used for printing prior probed memory from +either kernel memory (k) or user memory (u). The subsequent ``s`` specifier +results in printing a string. For direct use in regular vsnprintf() the (k) +and (u) annotation is ignored, however, when used out of BPF's bpf_trace_printk(), +for example, it reads the memory it is pointing to without faulting. + Kernel Pointers --------------- @@ -468,21 +484,23 @@ %pfwf /ocp@68000000/i2c@48072000/camera@10/port/endpoint - Full name %pfwP endpoint - Node name -Time and date (struct rtc_time) -------------------------------- +Time and date +------------- :: - %ptR YYYY-mm-ddTHH:MM:SS - %ptRd YYYY-mm-dd - %ptRt HH:MM:SS - %ptR[dt][r] + %pt[RT] YYYY-mm-ddTHH:MM:SS + %pt[RT]d YYYY-mm-dd + %pt[RT]t HH:MM:SS + %pt[RT][dt][r] -For printing date and time as represented by struct rtc_time structure in -human readable format. +For printing date and time as represented by + R struct rtc_time structure + T time64_t type +in human readable format. -By default year will be incremented by 1900 and month by 1. Use %ptRr (raw) -to suppress this behaviour. +By default year will be incremented by 1900 and month by 1. +Use %pt[RT]r (raw) to suppress this behaviour. Passed by reference.
diff --git a/Documentation/core-api/protection-keys.rst b/Documentation/core-api/protection-keys.rst index 49d9833..ec575e7 100644 --- a/Documentation/core-api/protection-keys.rst +++ b/Documentation/core-api/protection-keys.rst
@@ -5,8 +5,9 @@ ====================== Memory Protection Keys for Userspace (PKU aka PKEYs) is a feature -which is found on Intel's Skylake "Scalable Processor" Server CPUs. -It will be avalable in future non-server parts. +which is found on Intel's Skylake (and later) "Scalable Processor" +Server CPUs. It will be available in future non-server Intel parts +and future AMD processors. For anyone wishing to test or use this feature, it is available in Amazon's EC2 C5 instances and is known to work there using an Ubuntu
diff --git a/Documentation/core-api/rbtree.rst b/Documentation/core-api/rbtree.rst new file mode 100644 index 0000000..6b88837 --- /dev/null +++ b/Documentation/core-api/rbtree.rst
@@ -0,0 +1,429 @@ +================================= +Red-black Trees (rbtree) in Linux +================================= + + +:Date: January 18, 2007 +:Author: Rob Landley <rob@landley.net> + +What are red-black trees, and what are they for? +------------------------------------------------ + +Red-black trees are a type of self-balancing binary search tree, used for +storing sortable key/value data pairs. This differs from radix trees (which +are used to efficiently store sparse arrays and thus use long integer indexes +to insert/access/delete nodes) and hash tables (which are not kept sorted to +be easily traversed in order, and must be tuned for a specific size and +hash function where rbtrees scale gracefully storing arbitrary keys). + +Red-black trees are similar to AVL trees, but provide faster real-time bounded +worst case performance for insertion and deletion (at most two rotations and +three rotations, respectively, to balance the tree), with slightly slower +(but still O(log n)) lookup time. + +To quote Linux Weekly News: + + There are a number of red-black trees in use in the kernel. + The deadline and CFQ I/O schedulers employ rbtrees to + track requests; the packet CD/DVD driver does the same. + The high-resolution timer code uses an rbtree to organize outstanding + timer requests. The ext3 filesystem tracks directory entries in a + red-black tree. Virtual memory areas (VMAs) are tracked with red-black + trees, as are epoll file descriptors, cryptographic keys, and network + packets in the "hierarchical token bucket" scheduler. + +This document covers use of the Linux rbtree implementation. For more +information on the nature and implementation of Red Black Trees, see: + + Linux Weekly News article on red-black trees + https://lwn.net/Articles/184495/ + + Wikipedia entry on red-black trees + https://en.wikipedia.org/wiki/Red-black_tree + +Linux implementation of red-black trees +--------------------------------------- + +Linux's rbtree implementation lives in the file "lib/rbtree.c". To use it, +"#include <linux/rbtree.h>". + +The Linux rbtree implementation is optimized for speed, and thus has one +less layer of indirection (and better cache locality) than more traditional +tree implementations. Instead of using pointers to separate rb_node and data +structures, each instance of struct rb_node is embedded in the data structure +it organizes. And instead of using a comparison callback function pointer, +users are expected to write their own tree search and insert functions +which call the provided rbtree functions. Locking is also left up to the +user of the rbtree code. + +Creating a new rbtree +--------------------- + +Data nodes in an rbtree tree are structures containing a struct rb_node member:: + + struct mytype { + struct rb_node node; + char *keystring; + }; + +When dealing with a pointer to the embedded struct rb_node, the containing data +structure may be accessed with the standard container_of() macro. In addition, +individual members may be accessed directly via rb_entry(node, type, member). + +At the root of each rbtree is an rb_root structure, which is initialized to be +empty via: + + struct rb_root mytree = RB_ROOT; + +Searching for a value in an rbtree +---------------------------------- + +Writing a search function for your tree is fairly straightforward: start at the +root, compare each value, and follow the left or right branch as necessary. + +Example:: + + struct mytype *my_search(struct rb_root *root, char *string) + { + struct rb_node *node = root->rb_node; + + while (node) { + struct mytype *data = container_of(node, struct mytype, node); + int result; + + result = strcmp(string, data->keystring); + + if (result < 0) + node = node->rb_left; + else if (result > 0) + node = node->rb_right; + else + return data; + } + return NULL; + } + +Inserting data into an rbtree +----------------------------- + +Inserting data in the tree involves first searching for the place to insert the +new node, then inserting the node and rebalancing ("recoloring") the tree. + +The search for insertion differs from the previous search by finding the +location of the pointer on which to graft the new node. The new node also +needs a link to its parent node for rebalancing purposes. + +Example:: + + int my_insert(struct rb_root *root, struct mytype *data) + { + struct rb_node **new = &(root->rb_node), *parent = NULL; + + /* Figure out where to put new node */ + while (*new) { + struct mytype *this = container_of(*new, struct mytype, node); + int result = strcmp(data->keystring, this->keystring); + + parent = *new; + if (result < 0) + new = &((*new)->rb_left); + else if (result > 0) + new = &((*new)->rb_right); + else + return FALSE; + } + + /* Add new node and rebalance tree. */ + rb_link_node(&data->node, parent, new); + rb_insert_color(&data->node, root); + + return TRUE; + } + +Removing or replacing existing data in an rbtree +------------------------------------------------ + +To remove an existing node from a tree, call:: + + void rb_erase(struct rb_node *victim, struct rb_root *tree); + +Example:: + + struct mytype *data = mysearch(&mytree, "walrus"); + + if (data) { + rb_erase(&data->node, &mytree); + myfree(data); + } + +To replace an existing node in a tree with a new one with the same key, call:: + + void rb_replace_node(struct rb_node *old, struct rb_node *new, + struct rb_root *tree); + +Replacing a node this way does not re-sort the tree: If the new node doesn't +have the same key as the old node, the rbtree will probably become corrupted. + +Iterating through the elements stored in an rbtree (in sort order) +------------------------------------------------------------------ + +Four functions are provided for iterating through an rbtree's contents in +sorted order. These work on arbitrary trees, and should not need to be +modified or wrapped (except for locking purposes):: + + struct rb_node *rb_first(struct rb_root *tree); + struct rb_node *rb_last(struct rb_root *tree); + struct rb_node *rb_next(struct rb_node *node); + struct rb_node *rb_prev(struct rb_node *node); + +To start iterating, call rb_first() or rb_last() with a pointer to the root +of the tree, which will return a pointer to the node structure contained in +the first or last element in the tree. To continue, fetch the next or previous +node by calling rb_next() or rb_prev() on the current node. This will return +NULL when there are no more nodes left. + +The iterator functions return a pointer to the embedded struct rb_node, from +which the containing data structure may be accessed with the container_of() +macro, and individual members may be accessed directly via +rb_entry(node, type, member). + +Example:: + + struct rb_node *node; + for (node = rb_first(&mytree); node; node = rb_next(node)) + printk("key=%s\n", rb_entry(node, struct mytype, node)->keystring); + +Cached rbtrees +-------------- + +Computing the leftmost (smallest) node is quite a common task for binary +search trees, such as for traversals or users relying on a the particular +order for their own logic. To this end, users can use 'struct rb_root_cached' +to optimize O(logN) rb_first() calls to a simple pointer fetch avoiding +potentially expensive tree iterations. This is done at negligible runtime +overhead for maintanence; albeit larger memory footprint. + +Similar to the rb_root structure, cached rbtrees are initialized to be +empty via:: + + struct rb_root_cached mytree = RB_ROOT_CACHED; + +Cached rbtree is simply a regular rb_root with an extra pointer to cache the +leftmost node. This allows rb_root_cached to exist wherever rb_root does, +which permits augmented trees to be supported as well as only a few extra +interfaces:: + + struct rb_node *rb_first_cached(struct rb_root_cached *tree); + void rb_insert_color_cached(struct rb_node *, struct rb_root_cached *, bool); + void rb_erase_cached(struct rb_node *node, struct rb_root_cached *); + +Both insert and erase calls have their respective counterpart of augmented +trees:: + + void rb_insert_augmented_cached(struct rb_node *node, struct rb_root_cached *, + bool, struct rb_augment_callbacks *); + void rb_erase_augmented_cached(struct rb_node *, struct rb_root_cached *, + struct rb_augment_callbacks *); + + +Support for Augmented rbtrees +----------------------------- + +Augmented rbtree is an rbtree with "some" additional data stored in +each node, where the additional data for node N must be a function of +the contents of all nodes in the subtree rooted at N. This data can +be used to augment some new functionality to rbtree. Augmented rbtree +is an optional feature built on top of basic rbtree infrastructure. +An rbtree user who wants this feature will have to call the augmentation +functions with the user provided augmentation callback when inserting +and erasing nodes. + +C files implementing augmented rbtree manipulation must include +<linux/rbtree_augmented.h> instead of <linux/rbtree.h>. Note that +linux/rbtree_augmented.h exposes some rbtree implementations details +you are not expected to rely on; please stick to the documented APIs +there and do not include <linux/rbtree_augmented.h> from header files +either so as to minimize chances of your users accidentally relying on +such implementation details. + +On insertion, the user must update the augmented information on the path +leading to the inserted node, then call rb_link_node() as usual and +rb_augment_inserted() instead of the usual rb_insert_color() call. +If rb_augment_inserted() rebalances the rbtree, it will callback into +a user provided function to update the augmented information on the +affected subtrees. + +When erasing a node, the user must call rb_erase_augmented() instead of +rb_erase(). rb_erase_augmented() calls back into user provided functions +to updated the augmented information on affected subtrees. + +In both cases, the callbacks are provided through struct rb_augment_callbacks. +3 callbacks must be defined: + +- A propagation callback, which updates the augmented value for a given + node and its ancestors, up to a given stop point (or NULL to update + all the way to the root). + +- A copy callback, which copies the augmented value for a given subtree + to a newly assigned subtree root. + +- A tree rotation callback, which copies the augmented value for a given + subtree to a newly assigned subtree root AND recomputes the augmented + information for the former subtree root. + +The compiled code for rb_erase_augmented() may inline the propagation and +copy callbacks, which results in a large function, so each augmented rbtree +user should have a single rb_erase_augmented() call site in order to limit +compiled code size. + + +Sample usage +^^^^^^^^^^^^ + +Interval tree is an example of augmented rb tree. Reference - +"Introduction to Algorithms" by Cormen, Leiserson, Rivest and Stein. +More details about interval trees: + +Classical rbtree has a single key and it cannot be directly used to store +interval ranges like [lo:hi] and do a quick lookup for any overlap with a new +lo:hi or to find whether there is an exact match for a new lo:hi. + +However, rbtree can be augmented to store such interval ranges in a structured +way making it possible to do efficient lookup and exact match. + +This "extra information" stored in each node is the maximum hi +(max_hi) value among all the nodes that are its descendants. This +information can be maintained at each node just be looking at the node +and its immediate children. And this will be used in O(log n) lookup +for lowest match (lowest start address among all possible matches) +with something like:: + + struct interval_tree_node * + interval_tree_first_match(struct rb_root *root, + unsigned long start, unsigned long last) + { + struct interval_tree_node *node; + + if (!root->rb_node) + return NULL; + node = rb_entry(root->rb_node, struct interval_tree_node, rb); + + while (true) { + if (node->rb.rb_left) { + struct interval_tree_node *left = + rb_entry(node->rb.rb_left, + struct interval_tree_node, rb); + if (left->__subtree_last >= start) { + /* + * Some nodes in left subtree satisfy Cond2. + * Iterate to find the leftmost such node N. + * If it also satisfies Cond1, that's the match + * we are looking for. Otherwise, there is no + * matching interval as nodes to the right of N + * can't satisfy Cond1 either. + */ + node = left; + continue; + } + } + if (node->start <= last) { /* Cond1 */ + if (node->last >= start) /* Cond2 */ + return node; /* node is leftmost match */ + if (node->rb.rb_right) { + node = rb_entry(node->rb.rb_right, + struct interval_tree_node, rb); + if (node->__subtree_last >= start) + continue; + } + } + return NULL; /* No match */ + } + } + +Insertion/removal are defined using the following augmented callbacks:: + + static inline unsigned long + compute_subtree_last(struct interval_tree_node *node) + { + unsigned long max = node->last, subtree_last; + if (node->rb.rb_left) { + subtree_last = rb_entry(node->rb.rb_left, + struct interval_tree_node, rb)->__subtree_last; + if (max < subtree_last) + max = subtree_last; + } + if (node->rb.rb_right) { + subtree_last = rb_entry(node->rb.rb_right, + struct interval_tree_node, rb)->__subtree_last; + if (max < subtree_last) + max = subtree_last; + } + return max; + } + + static void augment_propagate(struct rb_node *rb, struct rb_node *stop) + { + while (rb != stop) { + struct interval_tree_node *node = + rb_entry(rb, struct interval_tree_node, rb); + unsigned long subtree_last = compute_subtree_last(node); + if (node->__subtree_last == subtree_last) + break; + node->__subtree_last = subtree_last; + rb = rb_parent(&node->rb); + } + } + + static void augment_copy(struct rb_node *rb_old, struct rb_node *rb_new) + { + struct interval_tree_node *old = + rb_entry(rb_old, struct interval_tree_node, rb); + struct interval_tree_node *new = + rb_entry(rb_new, struct interval_tree_node, rb); + + new->__subtree_last = old->__subtree_last; + } + + static void augment_rotate(struct rb_node *rb_old, struct rb_node *rb_new) + { + struct interval_tree_node *old = + rb_entry(rb_old, struct interval_tree_node, rb); + struct interval_tree_node *new = + rb_entry(rb_new, struct interval_tree_node, rb); + + new->__subtree_last = old->__subtree_last; + old->__subtree_last = compute_subtree_last(old); + } + + static const struct rb_augment_callbacks augment_callbacks = { + augment_propagate, augment_copy, augment_rotate + }; + + void interval_tree_insert(struct interval_tree_node *node, + struct rb_root *root) + { + struct rb_node **link = &root->rb_node, *rb_parent = NULL; + unsigned long start = node->start, last = node->last; + struct interval_tree_node *parent; + + while (*link) { + rb_parent = *link; + parent = rb_entry(rb_parent, struct interval_tree_node, rb); + if (parent->__subtree_last < last) + parent->__subtree_last = last; + if (start < parent->start) + link = &parent->rb.rb_left; + else + link = &parent->rb.rb_right; + } + + node->__subtree_last = last; + rb_link_node(&node->rb, rb_parent, link); + rb_insert_augmented(&node->rb, root, &augment_callbacks); + } + + void interval_tree_remove(struct interval_tree_node *node, + struct rb_root *root) + { + rb_erase_augmented(&node->rb, root, &augment_callbacks); + }
diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst index 00a3409..70274c3 100644 --- a/Documentation/dev-tools/coccinelle.rst +++ b/Documentation/dev-tools/coccinelle.rst
@@ -14,7 +14,7 @@ tree-wide patches and detection of problematic programming patterns. Getting Coccinelle -------------------- +------------------ The semantic patches included in the kernel use features and options which are provided by Coccinelle version 1.0.0-rc11 and above. @@ -56,7 +56,7 @@ https://github.com/coccinelle/coccinelle/blob/master/install.txt Supplemental documentation ---------------------------- +-------------------------- For supplemental documentation refer to the wiki: @@ -128,7 +128,7 @@ make coccicheck MODE=report V=1 Coccinelle parallelization ---------------------------- +-------------------------- By default, coccicheck tries to run as parallel as possible. To change the parallelism, set the J= variable. For example, to run across 4 CPUs:: @@ -333,7 +333,7 @@ // Requires: 1.0.5 Proposing new semantic patches -------------------------------- +------------------------------ New semantic patches can be proposed and submitted by kernel developers. For sake of clarity, they should be organized in the
diff --git a/Documentation/dev-tools/gdb-kernel-debugging.rst b/Documentation/dev-tools/gdb-kernel-debugging.rst index 19df792..4756f6b 100644 --- a/Documentation/dev-tools/gdb-kernel-debugging.rst +++ b/Documentation/dev-tools/gdb-kernel-debugging.rst
@@ -24,7 +24,7 @@ - Create a virtual Linux machine for QEMU/KVM (see www.linux-kvm.org and www.qemu.org for more details). For cross-development, - http://landley.net/aboriginal/bin keeps a pool of machine images and + https://landley.net/aboriginal/bin keeps a pool of machine images and toolchains that can be helpful to start from. - Build the kernel with CONFIG_GDB_SCRIPTS enabled, but leave
diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst index 09dee10..f7809c7 100644 --- a/Documentation/dev-tools/index.rst +++ b/Documentation/dev-tools/index.rst
@@ -21,6 +21,7 @@ kasan ubsan kmemleak + kcsan gdb-kernel-debugging kgdb kselftest
diff --git a/Documentation/dev-tools/kcov.rst b/Documentation/dev-tools/kcov.rst index 1c4e182..8548b0b 100644 --- a/Documentation/dev-tools/kcov.rst +++ b/Documentation/dev-tools/kcov.rst
@@ -217,14 +217,15 @@ threads: the global ones, that are spawned during kernel boot in a limited number of instances (e.g. one USB hub_event() worker thread is spawned per USB HCD); and the local ones, that are spawned when a user interacts with -some kernel interface (e.g. vhost workers). +some kernel interface (e.g. vhost workers); as well as from soft +interrupts. -To enable collecting coverage from a global background thread, a unique -global handle must be assigned and passed to the corresponding -kcov_remote_start() call. Then a userspace process can pass a list of such -handles to the KCOV_REMOTE_ENABLE ioctl in the handles array field of the -kcov_remote_arg struct. This will attach the used kcov device to the code -sections, that are referenced by those handles. +To enable collecting coverage from a global background thread or from a +softirq, a unique global handle must be assigned and passed to the +corresponding kcov_remote_start() call. Then a userspace process can pass +a list of such handles to the KCOV_REMOTE_ENABLE ioctl in the handles +array field of the kcov_remote_arg struct. This will attach the used kcov +device to the code sections, that are referenced by those handles. Since there might be many local background threads spawned from different userspace processes, we can't use a single global handle per annotation. @@ -242,7 +243,7 @@ currently reserved and must be zero. In the future the number of bytes used for the subsystem or handle ids might be increased. -When a particular userspace proccess collects coverage by via a common +When a particular userspace proccess collects coverage via a common handle, kcov will collect coverage for each code section that is annotated to use the common handle obtained as kcov_handle from the current task_struct. However non common handles allow to collect coverage
diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst new file mode 100644 index 0000000..ce4bbd9 --- /dev/null +++ b/Documentation/dev-tools/kcsan.rst
@@ -0,0 +1,321 @@ +The Kernel Concurrency Sanitizer (KCSAN) +======================================== + +The Kernel Concurrency Sanitizer (KCSAN) is a dynamic race detector, which +relies on compile-time instrumentation, and uses a watchpoint-based sampling +approach to detect races. KCSAN's primary purpose is to detect `data races`_. + +Usage +----- + +KCSAN requires Clang version 11 or later. + +To enable KCSAN configure the kernel with:: + + CONFIG_KCSAN = y + +KCSAN provides several other configuration options to customize behaviour (see +the respective help text in ``lib/Kconfig.kcsan`` for more info). + +Error reports +~~~~~~~~~~~~~ + +A typical data race report looks like this:: + + ================================================================== + BUG: KCSAN: data-race in generic_permission / kernfs_refresh_inode + + write to 0xffff8fee4c40700c of 4 bytes by task 175 on cpu 4: + kernfs_refresh_inode+0x70/0x170 + kernfs_iop_permission+0x4f/0x90 + inode_permission+0x190/0x200 + link_path_walk.part.0+0x503/0x8e0 + path_lookupat.isra.0+0x69/0x4d0 + filename_lookup+0x136/0x280 + user_path_at_empty+0x47/0x60 + vfs_statx+0x9b/0x130 + __do_sys_newlstat+0x50/0xb0 + __x64_sys_newlstat+0x37/0x50 + do_syscall_64+0x85/0x260 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + + read to 0xffff8fee4c40700c of 4 bytes by task 166 on cpu 6: + generic_permission+0x5b/0x2a0 + kernfs_iop_permission+0x66/0x90 + inode_permission+0x190/0x200 + link_path_walk.part.0+0x503/0x8e0 + path_lookupat.isra.0+0x69/0x4d0 + filename_lookup+0x136/0x280 + user_path_at_empty+0x47/0x60 + do_faccessat+0x11a/0x390 + __x64_sys_access+0x3c/0x50 + do_syscall_64+0x85/0x260 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + + Reported by Kernel Concurrency Sanitizer on: + CPU: 6 PID: 166 Comm: systemd-journal Not tainted 5.3.0-rc7+ #1 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 + ================================================================== + +The header of the report provides a short summary of the functions involved in +the race. It is followed by the access types and stack traces of the 2 threads +involved in the data race. + +The other less common type of data race report looks like this:: + + ================================================================== + BUG: KCSAN: data-race in e1000_clean_rx_irq+0x551/0xb10 + + race at unknown origin, with read to 0xffff933db8a2ae6c of 1 bytes by interrupt on cpu 0: + e1000_clean_rx_irq+0x551/0xb10 + e1000_clean+0x533/0xda0 + net_rx_action+0x329/0x900 + __do_softirq+0xdb/0x2db + irq_exit+0x9b/0xa0 + do_IRQ+0x9c/0xf0 + ret_from_intr+0x0/0x18 + default_idle+0x3f/0x220 + arch_cpu_idle+0x21/0x30 + do_idle+0x1df/0x230 + cpu_startup_entry+0x14/0x20 + rest_init+0xc5/0xcb + arch_call_rest_init+0x13/0x2b + start_kernel+0x6db/0x700 + + Reported by Kernel Concurrency Sanitizer on: + CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc7+ #2 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 + ================================================================== + +This report is generated where it was not possible to determine the other +racing thread, but a race was inferred due to the data value of the watched +memory location having changed. These can occur either due to missing +instrumentation or e.g. DMA accesses. These reports will only be generated if +``CONFIG_KCSAN_REPORT_RACE_UNKNOWN_ORIGIN=y`` (selected by default). + +Selective analysis +~~~~~~~~~~~~~~~~~~ + +It may be desirable to disable data race detection for specific accesses, +functions, compilation units, or entire subsystems. For static blacklisting, +the below options are available: + +* KCSAN understands the ``data_race(expr)`` annotation, which tells KCSAN that + any data races due to accesses in ``expr`` should be ignored and resulting + behaviour when encountering a data race is deemed safe. + +* Disabling data race detection for entire functions can be accomplished by + using the function attribute ``__no_kcsan``:: + + __no_kcsan + void foo(void) { + ... + + To dynamically limit for which functions to generate reports, see the + `DebugFS interface`_ blacklist/whitelist feature. + + For ``__always_inline`` functions, replace ``__always_inline`` with + ``__no_kcsan_or_inline`` (which implies ``__always_inline``):: + + static __no_kcsan_or_inline void foo(void) { + ... + +* To disable data race detection for a particular compilation unit, add to the + ``Makefile``:: + + KCSAN_SANITIZE_file.o := n + +* To disable data race detection for all compilation units listed in a + ``Makefile``, add to the respective ``Makefile``:: + + KCSAN_SANITIZE := n + +Furthermore, it is possible to tell KCSAN to show or hide entire classes of +data races, depending on preferences. These can be changed via the following +Kconfig options: + +* ``CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY``: If enabled and a conflicting write + is observed via a watchpoint, but the data value of the memory location was + observed to remain unchanged, do not report the data race. + +* ``CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC``: Assume that plain aligned writes + up to word size are atomic by default. Assumes that such writes are not + subject to unsafe compiler optimizations resulting in data races. The option + causes KCSAN to not report data races due to conflicts where the only plain + accesses are aligned writes up to word size. + +DebugFS interface +~~~~~~~~~~~~~~~~~ + +The file ``/sys/kernel/debug/kcsan`` provides the following interface: + +* Reading ``/sys/kernel/debug/kcsan`` returns various runtime statistics. + +* Writing ``on`` or ``off`` to ``/sys/kernel/debug/kcsan`` allows turning KCSAN + on or off, respectively. + +* Writing ``!some_func_name`` to ``/sys/kernel/debug/kcsan`` adds + ``some_func_name`` to the report filter list, which (by default) blacklists + reporting data races where either one of the top stackframes are a function + in the list. + +* Writing either ``blacklist`` or ``whitelist`` to ``/sys/kernel/debug/kcsan`` + changes the report filtering behaviour. For example, the blacklist feature + can be used to silence frequently occurring data races; the whitelist feature + can help with reproduction and testing of fixes. + +Tuning performance +~~~~~~~~~~~~~~~~~~ + +Core parameters that affect KCSAN's overall performance and bug detection +ability are exposed as kernel command-line arguments whose defaults can also be +changed via the corresponding Kconfig options. + +* ``kcsan.skip_watch`` (``CONFIG_KCSAN_SKIP_WATCH``): Number of per-CPU memory + operations to skip, before another watchpoint is set up. Setting up + watchpoints more frequently will result in the likelihood of races to be + observed to increase. This parameter has the most significant impact on + overall system performance and race detection ability. + +* ``kcsan.udelay_task`` (``CONFIG_KCSAN_UDELAY_TASK``): For tasks, the + microsecond delay to stall execution after a watchpoint has been set up. + Larger values result in the window in which we may observe a race to + increase. + +* ``kcsan.udelay_interrupt`` (``CONFIG_KCSAN_UDELAY_INTERRUPT``): For + interrupts, the microsecond delay to stall execution after a watchpoint has + been set up. Interrupts have tighter latency requirements, and their delay + should generally be smaller than the one chosen for tasks. + +They may be tweaked at runtime via ``/sys/module/kcsan/parameters/``. + +Data Races +---------- + +In an execution, two memory accesses form a *data race* if they *conflict*, +they happen concurrently in different threads, and at least one of them is a +*plain access*; they *conflict* if both access the same memory location, and at +least one is a write. For a more thorough discussion and definition, see `"Plain +Accesses and Data Races" in the LKMM`_. + +.. _"Plain Accesses and Data Races" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/explanation.txt#n1922 + +Relationship with the Linux-Kernel Memory Consistency Model (LKMM) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The LKMM defines the propagation and ordering rules of various memory +operations, which gives developers the ability to reason about concurrent code. +Ultimately this allows to determine the possible executions of concurrent code, +and if that code is free from data races. + +KCSAN is aware of *marked atomic operations* (``READ_ONCE``, ``WRITE_ONCE``, +``atomic_*``, etc.), but is oblivious of any ordering guarantees and simply +assumes that memory barriers are placed correctly. In other words, KCSAN +assumes that as long as a plain access is not observed to race with another +conflicting access, memory operations are correctly ordered. + +This means that KCSAN will not report *potential* data races due to missing +memory ordering. Developers should therefore carefully consider the required +memory ordering requirements that remain unchecked. If, however, missing +memory ordering (that is observable with a particular compiler and +architecture) leads to an observable data race (e.g. entering a critical +section erroneously), KCSAN would report the resulting data race. + +Race Detection Beyond Data Races +-------------------------------- + +For code with complex concurrency design, race-condition bugs may not always +manifest as data races. Race conditions occur if concurrently executing +operations result in unexpected system behaviour. On the other hand, data races +are defined at the C-language level. The following macros can be used to check +properties of concurrent code where bugs would not manifest as data races. + +.. kernel-doc:: include/linux/kcsan-checks.h + :functions: ASSERT_EXCLUSIVE_WRITER ASSERT_EXCLUSIVE_WRITER_SCOPED + ASSERT_EXCLUSIVE_ACCESS ASSERT_EXCLUSIVE_ACCESS_SCOPED + ASSERT_EXCLUSIVE_BITS + +Implementation Details +---------------------- + +KCSAN relies on observing that two accesses happen concurrently. Crucially, we +want to (a) increase the chances of observing races (especially for races that +manifest rarely), and (b) be able to actually observe them. We can accomplish +(a) by injecting various delays, and (b) by using address watchpoints (or +breakpoints). + +If we deliberately stall a memory access, while we have a watchpoint for its +address set up, and then observe the watchpoint to fire, two accesses to the +same address just raced. Using hardware watchpoints, this is the approach taken +in `DataCollider +<http://usenix.org/legacy/events/osdi10/tech/full_papers/Erickson.pdf>`_. +Unlike DataCollider, KCSAN does not use hardware watchpoints, but instead +relies on compiler instrumentation and "soft watchpoints". + +In KCSAN, watchpoints are implemented using an efficient encoding that stores +access type, size, and address in a long; the benefits of using "soft +watchpoints" are portability and greater flexibility. KCSAN then relies on the +compiler instrumenting plain accesses. For each instrumented plain access: + +1. Check if a matching watchpoint exists; if yes, and at least one access is a + write, then we encountered a racing access. + +2. Periodically, if no matching watchpoint exists, set up a watchpoint and + stall for a small randomized delay. + +3. Also check the data value before the delay, and re-check the data value + after delay; if the values mismatch, we infer a race of unknown origin. + +To detect data races between plain and marked accesses, KCSAN also annotates +marked accesses, but only to check if a watchpoint exists; i.e. KCSAN never +sets up a watchpoint on marked accesses. By never setting up watchpoints for +marked operations, if all accesses to a variable that is accessed concurrently +are properly marked, KCSAN will never trigger a watchpoint and therefore never +report the accesses. + +Key Properties +~~~~~~~~~~~~~~ + +1. **Memory Overhead:** The overall memory overhead is only a few MiB + depending on configuration. The current implementation uses a small array of + longs to encode watchpoint information, which is negligible. + +2. **Performance Overhead:** KCSAN's runtime aims to be minimal, using an + efficient watchpoint encoding that does not require acquiring any shared + locks in the fast-path. For kernel boot on a system with 8 CPUs: + + - 5.0x slow-down with the default KCSAN config; + - 2.8x slow-down from runtime fast-path overhead only (set very large + ``KCSAN_SKIP_WATCH`` and unset ``KCSAN_SKIP_WATCH_RANDOMIZE``). + +3. **Annotation Overheads:** Minimal annotations are required outside the KCSAN + runtime. As a result, maintenance overheads are minimal as the kernel + evolves. + +4. **Detects Racy Writes from Devices:** Due to checking data values upon + setting up watchpoints, racy writes from devices can also be detected. + +5. **Memory Ordering:** KCSAN is *not* explicitly aware of the LKMM's ordering + rules; this may result in missed data races (false negatives). + +6. **Analysis Accuracy:** For observed executions, due to using a sampling + strategy, the analysis is *unsound* (false negatives possible), but aims to + be complete (no false positives). + +Alternatives Considered +----------------------- + +An alternative data race detection approach for the kernel can be found in the +`Kernel Thread Sanitizer (KTSAN) <https://github.com/google/ktsan/wiki>`_. +KTSAN is a happens-before data race detector, which explicitly establishes the +happens-before order between memory operations, which can then be used to +determine data races as defined in `Data Races`_. + +To build a correct happens-before relation, KTSAN must be aware of all ordering +rules of the LKMM and synchronization primitives. Unfortunately, any omission +leads to large numbers of false positives, which is especially detrimental in +the context of the kernel which includes numerous custom synchronization +mechanisms. To track the happens-before relation, KTSAN's implementation +requires metadata for each memory location (shadow memory), which for each page +corresponds to 4 pages of shadow memory, and can translate into overhead of +tens of GiB on a large system.
diff --git a/Documentation/dev-tools/kgdb.rst b/Documentation/dev-tools/kgdb.rst index d38be58..61293f4 100644 --- a/Documentation/dev-tools/kgdb.rst +++ b/Documentation/dev-tools/kgdb.rst
@@ -274,6 +274,30 @@ on the initial connect, or to use a debugger proxy that allows an unmodified gdb to do the debugging. +Kernel parameter: ``kgdboc_earlycon`` +------------------------------------- + +If you specify the kernel parameter ``kgdboc_earlycon`` and your serial +driver registers a boot console that supports polling (doesn't need +interrupts and implements a nonblocking read() function) kgdb will attempt +to work using the boot console until it can transition to the regular +tty driver specified by the ``kgdboc`` parameter. + +Normally there is only one boot console (especially that implements the +read() function) so just adding ``kgdboc_earlycon`` on its own is +sufficient to make this work. If you have more than one boot console you +can add the boot console's name to differentiate. Note that names that +are registered through the boot console layer and the tty layer are not +the same for the same port. + +For instance, on one board to be explicit you might do:: + + kgdboc_earlycon=qcom_geni kgdboc=ttyMSM0 + +If the only boot console on the device was "qcom_geni", you could simplify:: + + kgdboc_earlycon kgdboc=ttyMSM0 + Kernel parameter: ``kgdbwait`` ------------------------------
diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst index 61ae13c..469d115 100644 --- a/Documentation/dev-tools/kselftest.rst +++ b/Documentation/dev-tools/kselftest.rst
@@ -151,6 +151,29 @@ $ cd kselftest $ ./run_kselftest.sh +Packaging selftests +=================== + +In some cases packaging is desired, such as when tests need to run on a +different system. To package selftests, run:: + + $ make -C tools/testing/selftests gen_tar + +This generates a tarball in the `INSTALL_PATH/kselftest-packages` directory. By +default, `.gz` format is used. The tar format can be overridden by specifying +a `FORMAT` make variable. Any value recognized by `tar's auto-compress`_ option +is supported, such as:: + + $ make -C tools/testing/selftests gen_tar FORMAT=.xz + +`make gen_tar` invokes `make install` so you can use it to package a subset of +tests by using variables specified in `Running a subset of selftests`_ +section:: + + $ make -C tools/testing/selftests gen_tar TARGETS="bpf" FORMAT=.xz + +.. _tar's auto-compress: https://www.gnu.org/software/tar/manual/html_node/gzip.html#auto_002dcompress + Contributing new tests ====================== @@ -301,7 +324,8 @@ .. kernel-doc:: tools/testing/selftests/kselftest_harness.h :functions: TH_LOG TEST TEST_SIGNAL FIXTURE FIXTURE_DATA FIXTURE_SETUP - FIXTURE_TEARDOWN TEST_F TEST_HARNESS_MAIN + FIXTURE_TEARDOWN TEST_F TEST_HARNESS_MAIN FIXTURE_VARIANT + FIXTURE_VARIANT_ADD Operators ---------
diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst index e1c5ce8..bb112cf 100644 --- a/Documentation/dev-tools/kunit/start.rst +++ b/Documentation/dev-tools/kunit/start.rst
@@ -32,15 +32,17 @@ options required by the tests. A good starting point for a ``.kunitconfig`` is the KUnit defconfig: + .. code-block:: bash cd $PATH_TO_LINUX_REPO cp arch/um/configs/kunit_defconfig .kunitconfig You can then add any other Kconfig options you wish, e.g.: + .. code-block:: none - CONFIG_LIST_KUNIT_TEST=y + CONFIG_LIST_KUNIT_TEST=y :doc:`kunit_tool <kunit-tool>` will ensure that all config options set in ``.kunitconfig`` are set in the kernel ``.config`` before running the tests. @@ -54,8 +56,8 @@ other tools (such as make menuconfig) to adjust other config options. -Running the tests ------------------ +Running the tests (KUnit Wrapper) +--------------------------------- To make sure that everything is set up correctly, simply invoke the Python wrapper from your kernel repo: @@ -105,8 +107,9 @@ KUnit and KUnit tests can be compiled as modules: in this case the tests in a module will be run when the module is loaded. -Running the tests ------------------ + +Running the tests (w/o KUnit Wrapper) +------------------------------------- Build and run your kernel as usual. Test output will be written to the kernel log in `TAP <https://testanything.org/>`_ format.
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index 473a236..3c3fe8b 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst
@@ -595,7 +595,7 @@ KUnit debugfs representation ============================ When kunit test suites are initialized, they create an associated directory -in /sys/kernel/debug/kunit/<test-suite>. The directory contains one file +in ``/sys/kernel/debug/kunit/<test-suite>``. The directory contains one file - results: "cat results" displays results of each test case and the results of the entire suite for the last test run. @@ -604,4 +604,4 @@ run in a native environment, either as modules or builtin. Having a way to display results like this is valuable as otherwise results can be intermixed with other events in dmesg output. The maximum size of each -results file is KUNIT_LOG_SIZE bytes (defined in include/kunit/test.h). +results file is KUNIT_LOG_SIZE bytes (defined in ``include/kunit/test.h``).
diff --git a/Documentation/devicetree/bindings/ABI.rst b/Documentation/devicetree/bindings/ABI.rst new file mode 100644 index 0000000..a885713c --- /dev/null +++ b/Documentation/devicetree/bindings/ABI.rst
@@ -0,0 +1,42 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================== +Devicetree (DT) ABI +=================== + +I. Regarding stable bindings/ABI, we quote from the 2013 ARM mini-summit + summary document: + + "That still leaves the question of, what does a stable binding look + like? Certainly a stable binding means that a newer kernel will not + break on an older device tree, but that doesn't mean the binding is + frozen for all time. Grant said there are ways to change bindings that + don't result in breakage. For instance, if a new property is added, + then default to the previous behaviour if it is missing. If a binding + truly needs an incompatible change, then change the compatible string + at the same time. The driver can bind against both the old and the + new. These guidelines aren't new, but they desperately need to be + documented." + +II. General binding rules + + 1) Maintainers, don't let perfect be the enemy of good. Don't hold up a + binding because it isn't perfect. + + 2) Use specific compatible strings so that if we need to add a feature (DMA) + in the future, we can create a new compatible string. See I. + + 3) Bindings can be augmented, but the driver shouldn't break when given + the old binding. ie. add additional properties, but don't change the + meaning of an existing property. For drivers, default to the original + behaviour when a newly added property is missing. + + 4) Don't submit bindings for staging or unstable. That will be decided by + the devicetree maintainers *after* discussion on the mailinglist. + +III. Notes + + 1) This document is intended as a general familiarization with the process as + decided at the 2013 Kernel Summit. When in doubt, the current word of the + devicetree maintainers overrules this document. In that situation, a patch + updating this document would be appreciated.
diff --git a/Documentation/devicetree/bindings/ABI.txt b/Documentation/devicetree/bindings/ABI.txt deleted file mode 100644 index d25f8d3..0000000 --- a/Documentation/devicetree/bindings/ABI.txt +++ /dev/null
@@ -1,39 +0,0 @@ - - Devicetree (DT) ABI - -I. Regarding stable bindings/ABI, we quote from the 2013 ARM mini-summit - summary document: - - "That still leaves the question of, what does a stable binding look - like? Certainly a stable binding means that a newer kernel will not - break on an older device tree, but that doesn't mean the binding is - frozen for all time. Grant said there are ways to change bindings that - don't result in breakage. For instance, if a new property is added, - then default to the previous behaviour if it is missing. If a binding - truly needs an incompatible change, then change the compatible string - at the same time. The driver can bind against both the old and the - new. These guidelines aren't new, but they desperately need to be - documented." - -II. General binding rules - - 1) Maintainers, don't let perfect be the enemy of good. Don't hold up a - binding because it isn't perfect. - - 2) Use specific compatible strings so that if we need to add a feature (DMA) - in the future, we can create a new compatible string. See I. - - 3) Bindings can be augmented, but the driver shouldn't break when given - the old binding. ie. add additional properties, but don't change the - meaning of an existing property. For drivers, default to the original - behaviour when a newly added property is missing. - - 4) Don't submit bindings for staging or unstable. That will be decided by - the devicetree maintainers *after* discussion on the mailinglist. - -III. Notes - - 1) This document is intended as a general familiarization with the process as - decided at the 2013 Kernel Summit. When in doubt, the current word of the - devicetree maintainers overrules this document. In that situation, a patch - updating this document would be appreciated.
diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index 1df680d..a638989 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile
@@ -2,27 +2,38 @@ DT_DOC_CHECKER ?= dt-doc-validate DT_EXTRACT_EX ?= dt-extract-example DT_MK_SCHEMA ?= dt-mk-schema +DT_MK_SCHEMA_USERONLY_FLAG := $(if $(DT_SCHEMA_FILES), -u) + +DT_SCHEMA_MIN_VERSION = 2020.5 + +PHONY += check_dtschema_version +check_dtschema_version: + @{ echo $(DT_SCHEMA_MIN_VERSION); \ + $(DT_DOC_CHECKER) --version 2>/dev/null || echo 0; } | sort -VC || \ + { echo "ERROR: dtschema minimum version is v$(DT_SCHEMA_MIN_VERSION)" >&2; false; } quiet_cmd_chk_binding = CHKDT $(patsubst $(srctree)/%,%,$<) cmd_chk_binding = $(DT_DOC_CHECKER) -u $(srctree)/$(src) $< ; \ $(DT_EXTRACT_EX) $< > $@ -$(obj)/%.example.dts: $(src)/%.yaml FORCE +$(obj)/%.example.dts: $(src)/%.yaml check_dtschema_version FORCE $(call if_changed,chk_binding) # Use full schemas when checking %.example.dts DT_TMP_SCHEMA := $(obj)/processed-schema-examples.yaml -quiet_cmd_mk_schema = SCHEMA $@ - cmd_mk_schema = $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $(real-prereqs) - -DT_DOCS = $(addprefix $(src)/, \ - $(shell \ - cd $(srctree)/$(src) && \ - find * \( -name '*.yaml' ! \ +find_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \ -name 'processed-schema*' ! \ - -name '*.example.dt.yaml' \) \ - )) + -name '*.example.dt.yaml' \) + +quiet_cmd_mk_schema = SCHEMA $@ + cmd_mk_schema = rm -f $@ ; \ + $(if $(DT_MK_SCHEMA_FLAGS), \ + echo $(real-prereqs), \ + $(find_cmd)) | \ + xargs $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) >> $@ + +DT_DOCS = $(shell $(find_cmd) | sed -e 's|^$(srctree)/||') DT_SCHEMA_FILES ?= $(DT_DOCS) @@ -34,11 +45,11 @@ -Wno-avoid_unnecessary_addr_size \ -Wno-graph_child_address -$(obj)/processed-schema-examples.yaml: $(DT_DOCS) FORCE +$(obj)/processed-schema-examples.yaml: $(DT_DOCS) check_dtschema_version FORCE $(call if_changed,mk_schema) -$(obj)/processed-schema.yaml: DT_MK_SCHEMA_FLAGS := -u -$(obj)/processed-schema.yaml: $(DT_SCHEMA_FILES) FORCE +$(obj)/processed-schema.yaml: DT_MK_SCHEMA_FLAGS := $(DT_MK_SCHEMA_USERONLY_FLAG) +$(obj)/processed-schema.yaml: $(DT_SCHEMA_FILES) check_dtschema_version FORCE $(call if_changed,mk_schema) extra-y += processed-schema.yaml
diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml index 49e0362..b388c5aa 100644 --- a/Documentation/devicetree/bindings/arm/altera.yaml +++ b/Documentation/devicetree/bindings/arm/altera.yaml
@@ -13,8 +13,8 @@ compatible: items: - enum: - - altr,socfpga-cyclone5 - - altr,socfpga-arria5 - - altr,socfpga-arria10 + - altr,socfpga-cyclone5 + - altr,socfpga-arria5 + - altr,socfpga-arria10 - const: altr,socfpga ...
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index f74aba4..378229f 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -17,7 +17,7 @@ any time. Be sure to use a device tree binary and a kernel image generated from the same source tree. - Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of a + Please refer to Documentation/devicetree/bindings/ABI.rst for a definition of a stable binding/ABI. properties: @@ -107,6 +107,7 @@ - amlogic,p231 - libretech,aml-s905d-pc - phicomm,n1 + - smartlabs,sml5442tw - const: amlogic,s905d - const: amlogic,meson-gxl @@ -148,6 +149,8 @@ - description: Boards with the Amlogic Meson G12B S922X SoC items: - enum: + - azw,gtking + - azw,gtking-pro - hardkernel,odroid-n2 - khadas,vim3 - ugoos,am6 @@ -159,6 +162,7 @@ - enum: - seirobotics,sei610 - khadas,vim3l + - hardkernel,odroid-c4 - const: amlogic,sm1 - description: Boards with the Amlogic Meson A1 A113L SoC
diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml index 66213bd..6cc7452 100644 --- a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
@@ -25,7 +25,7 @@ properties: compatible: - items: + items: - const: amlogic,meson-gx-ao-secure - const: syscon
diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt index dc102c4e..1f293ea 100644 --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt
@@ -14,7 +14,7 @@ The scmi node with the following properties shall be under the /firmware/ node. -- compatible : shall be "arm,scmi" +- compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports - mboxes: List of phandle and mailbox channel specifiers. It should contain exactly one or two mailboxes, one for transmitting messages("tx") and another optional for receiving the notifications("rx") if @@ -25,6 +25,7 @@ protocol identifier for a given sub-node. - #size-cells : should be '0' as 'reg' property doesn't have any size associated with it. +- arm,smc-id : SMC id required when using smc or hvc transports Optional properties:
diff --git a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml index 8c06a73..a3420c8 100644 --- a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml +++ b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml
@@ -131,26 +131,23 @@ 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. - allOf: - - $ref: '/schemas/types.yaml#/definitions/uint32' - - minimum: 0 - maximum: 15 + $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. - allOf: - - $ref: '/schemas/types.yaml#/definitions/uint32' - - minimum: 0 - maximum: 3 + $ref: '/schemas/types.yaml#/definitions/uint32' + minimum: 0 + maximum: 3 arm,vexpress,dcc: description: When describing tiles consisting of more than one DCC, its number can be specified with this attribute. - allOf: - - $ref: '/schemas/types.yaml#/definitions/uint32' - - minimum: 0 - maximum: 3 + $ref: '/schemas/types.yaml#/definitions/uint32' + minimum: 0 + maximum: 3 patternProperties: "^bus@[0-9a-f]+$": @@ -162,8 +159,7 @@ "simple-bus". If the compatible is placed in the "motherboard" node, it is stricter and always has two compatibles. type: object - allOf: - - $ref: '/schemas/simple-bus.yaml' + $ref: '/schemas/simple-bus.yaml' properties: compatible: @@ -195,11 +191,11 @@ - const: simple-bus arm,v2m-memory-map: description: This describes the memory map type. - allOf: - - $ref: '/schemas/types.yaml#/definitions/string' - - enum: - - rs1 - - rs2 + $ref: '/schemas/types.yaml#/definitions/string' + enum: + - rs1 + - rs2 + required: - compatible required:
diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml index 0357314..31b0c54 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
@@ -82,6 +82,13 @@ - const: atmel,sama5d2 - const: atmel,sama5 + - description: Microchip SAMA5D2 Industrial Connectivity Platform + items: + - const: microchip,sama5d2-icp + - const: atmel,sama5d27 + - const: atmel,sama5d2 + - const: atmel,sama5 + - description: SAM9X60-EK board items: - const: microchip,sam9x60ek
diff --git a/Documentation/devicetree/bindings/arm/bitmain.yaml b/Documentation/devicetree/bindings/arm/bitmain.yaml index 0efdb4ac..5cd5b36 100644 --- a/Documentation/devicetree/bindings/arm/bitmain.yaml +++ b/Documentation/devicetree/bindings/arm/bitmain.yaml
@@ -13,6 +13,6 @@ compatible: items: - enum: - - bitmain,sophon-edge + - bitmain,sophon-edge - const: bitmain,bm1880 ...
diff --git a/Documentation/devicetree/bindings/arm/calxeda/hb-sregs.yaml b/Documentation/devicetree/bindings/arm/calxeda/hb-sregs.yaml new file mode 100644 index 0000000..dfdc970 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/calxeda/hb-sregs.yaml
@@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/calxeda/hb-sregs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Calxeda Highbank system registers + +description: | + The Calxeda Highbank system has a block of MMIO registers controlling + several generic system aspects. Those can be used to control some power + management, they also contain some gate and PLL clocks. + +maintainers: + - Andre Przywara <andre.przywara@arm.com> + +properties: + compatible: + const: calxeda,hb-sregs + + reg: + maxItems: 1 + + clocks: + type: object + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + sregs@fff3c000 { + compatible = "calxeda,hb-sregs"; + reg = <0xfff3c000 0x1000>; + + clocks { + #address-cells = <1>; + #size-cells = <0>; + + osc: oscillator { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <33333000>; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/arm/calxeda/l2ecc.txt b/Documentation/devicetree/bindings/arm/calxeda/l2ecc.txt deleted file mode 100644 index 94e642a..0000000 --- a/Documentation/devicetree/bindings/arm/calxeda/l2ecc.txt +++ /dev/null
@@ -1,15 +0,0 @@ -Calxeda Highbank L2 cache ECC - -Properties: -- compatible : Should be "calxeda,hb-sregs-l2-ecc" -- reg : Address and size for ECC error interrupt clear registers. -- interrupts : Should be single bit error interrupt, then double bit error - interrupt. - -Example: - - sregs@fff3c200 { - compatible = "calxeda,hb-sregs-l2-ecc"; - reg = <0xfff3c200 0x100>; - interrupts = <0 71 4 0 72 4>; - };
diff --git a/Documentation/devicetree/bindings/arm/calxeda/l2ecc.yaml b/Documentation/devicetree/bindings/arm/calxeda/l2ecc.yaml new file mode 100644 index 0000000..a9fe012 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/calxeda/l2ecc.yaml
@@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/calxeda/l2ecc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Calxeda Highbank L2 cache ECC + +description: | + Binding for the Calxeda Highbank L2 cache controller ECC device. + This does not cover the actual L2 cache controller control registers, + but just the error reporting functionality. + +maintainers: + - Andre Przywara <andre.przywara@arm.com> + +properties: + compatible: + const: "calxeda,hb-sregs-l2-ecc" + + reg: + maxItems: 1 + + interrupts: + items: + - description: single bit error interrupt + - description: double bit error interrupt + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + sregs@fff3c200 { + compatible = "calxeda,hb-sregs-l2-ecc"; + reg = <0xfff3c200 0x100>; + interrupts = <0 71 4>, <0 72 4>; + };
diff --git a/Documentation/devicetree/bindings/arm/coresight-cti.yaml b/Documentation/devicetree/bindings/arm/coresight-cti.yaml index 3db3642..17df5cd 100644 --- a/Documentation/devicetree/bindings/arm/coresight-cti.yaml +++ b/Documentation/devicetree/bindings/arm/coresight-cti.yaml
@@ -140,16 +140,14 @@ maxItems: 1 arm,trig-in-sigs: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 maxItems: 32 description: List of CTI trigger in signal numbers in use by a trig-conns node. arm,trig-in-types: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 maxItems: 32 description: @@ -159,16 +157,14 @@ completely, then the types will default to GEN_IO. arm,trig-out-sigs: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 maxItems: 32 description: List of CTI trigger out signal numbers in use by a trig-conns node. arm,trig-out-types: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 maxItems: 32 description: @@ -178,8 +174,7 @@ or omitted completely, then the types will default to GEN_IO. arm,trig-filters: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 maxItems: 32 description: @@ -187,8 +182,7 @@ active, unless filtering is disabled on the driver. arm,trig-conn-name: - allOf: - - $ref: /schemas/types.yaml#/definitions/string + $ref: /schemas/types.yaml#/definitions/string description: Defines a connection name that will be displayed, if the cpu or arm,cs-dev-assoc properties are not being used in this connection. @@ -301,7 +295,7 @@ - | cti@20110000 { compatible = "arm,coresight-cti", "arm,primecell"; - reg = <0 0x20110000 0 0x1000>; + reg = <0x20110000 0x1000>; clocks = <&soc_smc50mhz>; clock-names = "apb_pclk";
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index a018147..40f692c 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -167,53 +167,53 @@ - qcom,kryo260 - qcom,kryo280 - qcom,kryo385 + - qcom,kryo468 - qcom,kryo485 - qcom,scorpion enable-method: - allOf: - - $ref: '/schemas/types.yaml#/definitions/string' - - oneOf: - # On ARM v8 64-bit this property is required - - enum: - - psci - - spin-table - # On ARM 32-bit systems this property is optional - - enum: - - actions,s500-smp - - allwinner,sun6i-a31 - - allwinner,sun8i-a23 - - allwinner,sun9i-a80-smp - - allwinner,sun8i-a83t-smp - - amlogic,meson8-smp - - amlogic,meson8b-smp - - arm,realview-smp - - aspeed,ast2600-smp - - brcm,bcm11351-cpu-method - - brcm,bcm23550 - - brcm,bcm2836-smp - - brcm,bcm63138 - - brcm,bcm-nsp-smp - - brcm,brahma-b15 - - marvell,armada-375-smp - - marvell,armada-380-smp - - marvell,armada-390-smp - - marvell,armada-xp-smp - - marvell,98dx3236-smp - - marvell,mmp3-smp - - mediatek,mt6589-smp - - mediatek,mt81xx-tz-smp - - qcom,gcc-msm8660 - - qcom,kpss-acc-v1 - - qcom,kpss-acc-v2 - - renesas,apmu - - renesas,r9a06g032-smp - - rockchip,rk3036-smp - - rockchip,rk3066-smp - - socionext,milbeaut-m10v-smp - - ste,dbx500-smp - - ti,am3352 - - ti,am4372 + $ref: '/schemas/types.yaml#/definitions/string' + oneOf: + # On ARM v8 64-bit this property is required + - enum: + - psci + - spin-table + # On ARM 32-bit systems this property is optional + - enum: + - actions,s500-smp + - allwinner,sun6i-a31 + - allwinner,sun8i-a23 + - allwinner,sun9i-a80-smp + - allwinner,sun8i-a83t-smp + - amlogic,meson8-smp + - amlogic,meson8b-smp + - arm,realview-smp + - aspeed,ast2600-smp + - brcm,bcm11351-cpu-method + - brcm,bcm23550 + - brcm,bcm2836-smp + - brcm,bcm63138 + - brcm,bcm-nsp-smp + - brcm,brahma-b15 + - marvell,armada-375-smp + - marvell,armada-380-smp + - marvell,armada-390-smp + - marvell,armada-xp-smp + - marvell,98dx3236-smp + - marvell,mmp3-smp + - mediatek,mt6589-smp + - mediatek,mt81xx-tz-smp + - qcom,gcc-msm8660 + - qcom,kpss-acc-v1 + - qcom,kpss-acc-v2 + - renesas,apmu + - renesas,r9a06g032-smp + - rockchip,rk3036-smp + - rockchip,rk3066-smp + - socionext,milbeaut-m10v-smp + - ste,dbx500-smp + - ti,am3352 + - ti,am4372 cpu-release-addr: $ref: '/schemas/types.yaml#/definitions/uint64'
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index 623fedf..7150474 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -108,7 +108,8 @@ Required properties: - compatible: Should be one of: "fsl,imx8qm-iomuxc", - "fsl,imx8qxp-iomuxc". + "fsl,imx8qxp-iomuxc", + "fsl,imx8dxl-iomuxc". Required properties for Pinctrl sub nodes: - fsl,pins: Each entry consists of 3 integers which represents @@ -116,7 +117,8 @@ integers <pin_id mux_mode> are specified using a PIN_FUNC_ID macro, which can be found in <dt-bindings/pinctrl/pads-imx8qm.h>, - <dt-bindings/pinctrl/pads-imx8qxp.h>. + <dt-bindings/pinctrl/pads-imx8qxp.h>, + <dt-bindings/pinctrl/pads-imx8dxl.h>. The last integer CONFIG is the pad setting value like pull-up on this pin.
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index cd3fbe7..05906e2 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -119,6 +119,7 @@ - fsl,imx6q-sabreauto - fsl,imx6q-sabrelite - fsl,imx6q-sabresd + - kontron,imx6q-samx6i # Kontron i.MX6 Dual/Quad SMARC Module - technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf - technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit - technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph @@ -170,6 +171,7 @@ - emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base - fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board - fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board + - kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module - technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf - technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit - technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph @@ -177,7 +179,9 @@ - technologic,imx6dl-ts4900 - technologic,imx6dl-ts7970 - toradex,colibri_imx6dl # Colibri iMX6 Module + - toradex,colibri_imx6dl-v1_1 # Colibri iMX6 Module V1.1 - toradex,colibri_imx6dl-eval-v3 # Colibri iMX6 Module on Colibri Evaluation Board V3 + - toradex,colibri_imx6dl-v1_1-eval-v3 # Colibri iMX6 Module V1.1 on Colibri Evaluation Board V3 - ysoft,imx6dl-yapp4-draco # i.MX6 DualLite Y Soft IOTA Draco board - ysoft,imx6dl-yapp4-hydra # i.MX6 DualLite Y Soft IOTA Hydra board - ysoft,imx6dl-yapp4-ursa # i.MX6 Solo Y Soft IOTA Ursa board
diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.yaml b/Documentation/devicetree/bindings/arm/l2c2x0.yaml index 5d1d50e..6b8f4d4 100644 --- a/Documentation/devicetree/bindings/arm/l2c2x0.yaml +++ b/Documentation/devicetree/bindings/arm/l2c2x0.yaml
@@ -70,43 +70,39 @@ description: Cycles of latency for Data RAM accesses. Specifies 3 cells of read, write and setup latencies. Minimum valid values are 1. Controllers without setup latency control should use a value of 0. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 2 - maxItems: 3 - items: - minimum: 0 - maximum: 8 + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 3 + items: + minimum: 0 + maximum: 8 arm,tag-latency: description: Cycles of latency for Tag RAM accesses. Specifies 3 cells of read, write and setup latencies. Controllers without setup latency control should use 0. Controllers without separate read and write Tag RAM latency values should only use the first cell. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 1 - maxItems: 3 - items: - minimum: 0 - maximum: 8 + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 3 + items: + minimum: 0 + maximum: 8 arm,dirty-latency: description: Cycles of latency for Dirty RAMs. This is a single cell. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 1 - maximum: 8 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 8 arm,filter-ranges: description: <start length> Starting address and length of window to filter. Addresses in the filter window are directed to the M1 port. Other addresses will go to the M0 port. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - items: - minItems: 2 - maxItems: 2 + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + minItems: 2 + maxItems: 2 arm,io-coherent: description: indicates that the system is operating in an hardware @@ -131,36 +127,31 @@ arm,double-linefill: description: Override double linefill enable setting. Enable if non-zero, disable if zero. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 0, 1 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] arm,double-linefill-incr: description: Override double linefill on INCR read. Enable if non-zero, disable if zero. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 0, 1 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] arm,double-linefill-wrap: description: Override double linefill on WRAP read. Enable if non-zero, disable if zero. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 0, 1 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] arm,prefetch-drop: description: Override prefetch drop enable setting. Enable if non-zero, disable if zero. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 0, 1 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] arm,prefetch-offset: description: Override prefetch offset value. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 0, 1, 2, 3, 4, 5, 6, 7, 15, 23, 31 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5, 6, 7, 15, 23, 31] arm,shared-override: description: The default behavior of the L220 or PL310 cache @@ -193,35 +184,31 @@ description: | Data prefetch. Value: <0> (forcibly disable), <1> (forcibly enable), property absent (retain settings set by firmware) - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 0, 1 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] prefetch-instr: description: | Instruction prefetch. Value: <0> (forcibly disable), <1> (forcibly enable), property absent (retain settings set by firmware) - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 0, 1 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] arm,dynamic-clock-gating: description: | L2 dynamic clock gating. Value: <0> (forcibly disable), <1> (forcibly enable), property absent (OS specific behavior, preferably retain firmware settings) - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 0, 1 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] arm,standby-mode: description: L2 standby mode enable. Value <0> (forcibly disable), <1> (forcibly enable), property absent (OS specific behavior, preferably retain firmware settings) - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 0, 1 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] arm,early-bresp-disable: description: Disable the CA9 optimization Early BRESP (PL310)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 4043c50..abc544d 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -84,6 +84,28 @@ - enum: - mediatek,mt8135-evbp1 - const: mediatek,mt8135 + - description: Google Elm (Acer Chromebook R13) + items: + - const: google,elm-rev8 + - const: google,elm-rev7 + - const: google,elm-rev6 + - const: google,elm-rev5 + - const: google,elm-rev4 + - const: google,elm-rev3 + - const: google,elm + - const: mediatek,mt8173 + - description: Google Hana (Lenovo Chromebook N23 Yoga, C330, 300e,...) + items: + - const: google,hana-rev6 + - const: google,hana-rev5 + - const: google,hana-rev4 + - const: google,hana-rev3 + - const: google,hana + - const: mediatek,mt8173 + - description: Google Hana rev7 (Poin2 Chromebook 11C) + items: + - const: google,hana-rev7 + - const: mediatek,mt8173 - items: - enum: - mediatek,mt8173-evb
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt index ff000cc..bd7a0fa 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
@@ -8,6 +8,7 @@ - compatible: Should be one of: - "mediatek,mt2701-apmixedsys" - "mediatek,mt2712-apmixedsys", "syscon" + - "mediatek,mt6765-apmixedsys", "syscon" - "mediatek,mt6779-apmixedsys", "syscon" - "mediatek,mt6797-apmixedsys" - "mediatek,mt7622-apmixedsys"
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt index e4ca7b7..38309db 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
@@ -7,6 +7,7 @@ - compatible: Should be one of: - "mediatek,mt2701-audsys", "syscon" + - "mediatek,mt6765-audsys", "syscon" - "mediatek,mt6779-audio", "syscon" - "mediatek,mt7622-audsys", "syscon" - "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon"
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt index 1f4aaa1..a0ce820 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
@@ -6,6 +6,7 @@ Required Properties: - compatible: Should be one of: + - "mediatek,mt6765-camsys", "syscon" - "mediatek,mt6779-camsys", "syscon" - "mediatek,mt8183-camsys", "syscon" - #clock-cells: Must be 1
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt index 2b693e3..1e1f007 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
@@ -8,6 +8,7 @@ - compatible: Should be one of: - "mediatek,mt2701-imgsys", "syscon" - "mediatek,mt2712-imgsys", "syscon" + - "mediatek,mt6765-imgsys", "syscon" - "mediatek,mt6779-imgsys", "syscon" - "mediatek,mt6797-imgsys", "syscon" - "mediatek,mt7623-imgsys", "mediatek,mt2701-imgsys", "syscon"
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt index db2f4fd..49a968b 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
@@ -9,6 +9,7 @@ - compatible: Should be one of: - "mediatek,mt2701-infracfg", "syscon" - "mediatek,mt2712-infracfg", "syscon" + - "mediatek,mt6765-infracfg", "syscon" - "mediatek,mt6779-infracfg_ao", "syscon" - "mediatek,mt6797-infracfg", "syscon" - "mediatek,mt7622-infracfg", "syscon"
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt new file mode 100644 index 0000000..8be5978 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt
@@ -0,0 +1,28 @@ +Mediatek mipi0a (mipi_rx_ana_csi0a) controller +============================ + +The Mediatek mipi0a controller provides various clocks +to the system. + +Required Properties: + +- compatible: Should be one of: + - "mediatek,mt6765-mipi0a", "syscon" +- #clock-cells: Must be 1 + +The mipi0a controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +The mipi0a controller also uses the common power domain from +Documentation/devicetree/bindings/soc/mediatek/scpsys.txt +The available power doamins are defined in dt-bindings/power/mt*-power.h. + +Example: + +mipi0a: clock-controller@11c10000 { + compatible = "mediatek,mt6765-mipi0a", "syscon"; + reg = <0 0x11c10000 0 0x1000>; + power-domains = <&scpsys MT6765_POWER_DOMAIN_CAM>; + #clock-cells = <1>; +};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt index 301eefb..d8c9108 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -1,13 +1,15 @@ Mediatek mmsys controller ============================ -The Mediatek mmsys controller provides various clocks to the system. +The Mediatek mmsys system controller provides clock control, routing control, +and miscellaneous control in mmsys partition. Required Properties: - compatible: Should be one of: - "mediatek,mt2701-mmsys", "syscon" - "mediatek,mt2712-mmsys", "syscon" + - "mediatek,mt6765-mmsys", "syscon" - "mediatek,mt6779-mmsys", "syscon" - "mediatek,mt6797-mmsys", "syscon" - "mediatek,mt7623-mmsys", "mediatek,mt2701-mmsys", "syscon" @@ -15,13 +17,13 @@ - "mediatek,mt8183-mmsys", "syscon" - #clock-cells: Must be 1 -The mmsys controller uses the common clk binding from +For the clock control, the mmsys controller uses the common clk binding from Documentation/devicetree/bindings/clock/clock-bindings.txt The available clocks are defined in dt-bindings/clock/mt*-clk.h. Example: -mmsys: clock-controller@14000000 { +mmsys: syscon@14000000 { compatible = "mediatek,mt8173-mmsys", "syscon"; reg = <0 0x14000000 0 0x1000>; #clock-cells = <1>;
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt deleted file mode 100644 index ecf027a..0000000 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt +++ /dev/null
@@ -1,36 +0,0 @@ -Mediatek pericfg controller -=========================== - -The Mediatek pericfg controller provides various clocks and reset -outputs to the system. - -Required Properties: - -- compatible: Should be one of: - - "mediatek,mt2701-pericfg", "syscon" - - "mediatek,mt2712-pericfg", "syscon" - - "mediatek,mt7622-pericfg", "syscon" - - "mediatek,mt7623-pericfg", "mediatek,mt2701-pericfg", "syscon" - - "mediatek,mt7629-pericfg", "syscon" - - "mediatek,mt8135-pericfg", "syscon" - - "mediatek,mt8173-pericfg", "syscon" - - "mediatek,mt8183-pericfg", "syscon" -- #clock-cells: Must be 1 -- #reset-cells: Must be 1 - -The pericfg controller uses the common clk binding from -Documentation/devicetree/bindings/clock/clock-bindings.txt -The available clocks are defined in dt-bindings/clock/mt*-clk.h. -Also it uses the common reset controller binding from -Documentation/devicetree/bindings/reset/reset.txt. -The available reset outputs are defined in -dt-bindings/reset/mt*-resets.h - -Example: - -pericfg: power-controller@10003000 { - compatible = "mediatek,mt8173-pericfg", "syscon"; - reg = <0 0x10003000 0 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; -};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml new file mode 100644 index 0000000..e271c46 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
@@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,pericfg.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek Peripheral Configuration Controller + +maintainers: + - Bartosz Golaszewski <bgolaszewski@baylibre.com> + +description: + The Mediatek pericfg controller provides various clocks and reset outputs + to the system. + +properties: + compatible: + oneOf: + - items: + - enum: + - mediatek,mt2701-pericfg + - mediatek,mt2712-pericfg + - mediatek,mt6765-pericfg + - mediatek,mt7622-pericfg + - mediatek,mt7629-pericfg + - mediatek,mt8135-pericfg + - mediatek,mt8173-pericfg + - mediatek,mt8183-pericfg + - mediatek,mt8516-pericfg + - const: syscon + - items: + # Special case for mt7623 for backward compatibility + - const: mediatek,mt7623-pericfg + - const: mediatek,mt2701-pericfg + - const: syscon + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + +required: + - compatible + - reg + +examples: + - | + pericfg@10003000 { + compatible = "mediatek,mt8173-pericfg", "syscon"; + reg = <0x10003000 0x1000>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + + - | + pericfg@10003000 { + compatible = "mediatek,mt7623-pericfg", "mediatek,mt2701-pericfg", "syscon"; + reg = <0x10003000 0x1000>; + #clock-cells = <1>; + #reset-cells = <1>; + };
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt index 0293d69..9b0394c 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
@@ -8,6 +8,7 @@ - compatible: Should be one of: - "mediatek,mt2701-topckgen" - "mediatek,mt2712-topckgen", "syscon" + - "mediatek,mt6765-topckgen", "syscon" - "mediatek,mt6779-topckgen", "syscon" - "mediatek,mt6797-topckgen" - "mediatek,mt7622-topckgen"
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt new file mode 100644 index 0000000..c877bcc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt
@@ -0,0 +1,27 @@ +Mediatek vcodecsys controller +============================ + +The Mediatek vcodecsys controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be one of: + - "mediatek,mt6765-vcodecsys", "syscon" +- #clock-cells: Must be 1 + +The vcodecsys controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +The vcodecsys controller also uses the common power domain from +Documentation/devicetree/bindings/soc/mediatek/scpsys.txt +The available power doamins are defined in dt-bindings/power/mt*-power.h. + +Example: + +venc_gcon: clock-controller@17000000 { + compatible = "mediatek,mt6765-vcodecsys", "syscon"; + reg = <0 0x17000000 0 0x10000>; + power-domains = <&scpsys MT6765_POWER_DOMAIN_VCODEC>; + #clock-cells = <1>; +};
diff --git a/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml b/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml index 07f39d3..f7f0249 100644 --- a/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml +++ b/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml
@@ -17,9 +17,8 @@ - nxp,lpc3230 - nxp,lpc3240 - items: - - enum: - - ea,ea3250 - - phytec,phy3250 - - const: nxp,lpc3250 - + - enum: + - ea,ea3250 + - phytec,phy3250 + - const: nxp,lpc3250 ...
diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml index 9247b58..8b77cf8 100644 --- a/Documentation/devicetree/bindings/arm/psci.yaml +++ b/Documentation/devicetree/bindings/arm/psci.yaml
@@ -69,13 +69,11 @@ method: description: The method of calling the PSCI firmware. - allOf: - - $ref: /schemas/types.yaml#/definitions/string-array - - enum: - # SMC #0, with the register assignments specified in this binding. - - smc - # HVC #0, with the register assignments specified in this binding. - - hvc + $ref: /schemas/types.yaml#/definitions/string-array + enum: + - smc + # HVC #0, with the register assignments specified in this binding. + - hvc cpu_suspend: $ref: /schemas/types.yaml#/definitions/uint32 @@ -107,8 +105,8 @@ patternProperties: "^power-domain-": - allOf: - - $ref: "../power/power-domain.yaml#" + $ref: "../power/power-domain.yaml#" + type: object description: | ARM systems can have multiple cores, sometimes in an hierarchical
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 64ddae3..6031aee 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -37,6 +37,8 @@ msm8994 msm8996 sc7180 + sdm630 + sdm660 sdm845 The 'board' element must be one of the following strings: @@ -155,6 +157,11 @@ - items: - enum: + - xiaomi,lavender + - const: qcom,sdm660 + + - items: + - enum: - qcom,ipq6018-cp01-c1 - const: qcom,ipq6018
diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml index ab59de1..845f9c7 100644 --- a/Documentation/devicetree/bindings/arm/realtek.yaml +++ b/Documentation/devicetree/bindings/arm/realtek.yaml
@@ -14,6 +14,13 @@ const: '/' compatible: oneOf: + # RTD1195 SoC based boards + - items: + - enum: + - mele,x1000 # MeLE X1000 + - realtek,horseradish # Realtek Horseradish EVB + - const: realtek,rtd1195 + # RTD1293 SoC based boards - items: - enum: @@ -25,6 +32,7 @@ - enum: - mele,v9 # MeLE V9 - probox2,ava # ProBox2 AVA + - xnano,x5 # Xnano X5 - zidoo,x9s # Zidoo X9S - const: realtek,rtd1295 @@ -33,4 +41,17 @@ - enum: - synology,ds418 # Synology DiskStation DS418 - const: realtek,rtd1296 + + # RTD1395 SoC based boards + - items: + - enum: + - bananapi,bpi-m4 # Banana Pi BPI-M4 + - realtek,lion-skin # Realtek Lion Skin EVB + - const: realtek,rtd1395 + + # RTD1619 SoC based boards + - items: + - enum: + - realtek,mjolnir # Realtek Mjolnir EVB + - const: realtek,rtd1619 ...
diff --git a/Documentation/devicetree/bindings/arm/renesas,prr.yaml b/Documentation/devicetree/bindings/arm/renesas,prr.yaml index dd08764..1f80767 100644 --- a/Documentation/devicetree/bindings/arm/renesas,prr.yaml +++ b/Documentation/devicetree/bindings/arm/renesas,prr.yaml
@@ -33,5 +33,5 @@ - | prr: chipid@ff000044 { compatible = "renesas,prr"; - reg = <0 0xff000044 0 4>; + reg = <0xff000044 4>; };
diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index 611094d..b7d2e92 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml
@@ -54,6 +54,16 @@ - description: RZ/G1H (R8A77420) items: + - enum: + # iWave Systems RZ/G1H Qseven System On Module (iW-RainboW-G21M-Qseven) + - iwave,g21m + - const: renesas,r8a7742 + + - items: + - enum: + # iWave Systems RZ/G1H Qseven Development Platform (iW-RainboW-G21D-Qseven) + - iwave,g21d + - const: iwave,g21m - const: renesas,r8a7742 - description: RZ/G1M (R8A77430)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 715586d..d4a4045 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -358,6 +358,11 @@ - const: haoyu,marsboard-rk3066 - const: rockchip,rk3066a + - description: Hardkernel Odroid Go Advance + items: + - const: hardkernel,rk3326-odroid-go2 + - const: rockchip,rk3326 + - description: Hugsun X99 TV Box items: - const: hugsun,x99
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml index 0425d33..f99c0c6 100644 --- a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml
@@ -22,9 +22,8 @@ Adaptive Supply Voltage bin selection. This can be used to determine the ASV bin of an SoC if respective information is missing in the CHIPID registers or in the OTP memory. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 0, 1, 2, 3 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] required: - compatible
diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml index 63acd57..eb92f9e 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
@@ -52,6 +52,7 @@ items: - enum: - insignal,origen # Insignal Origen + - samsung,i9100 # Samsung Galaxy S2 (GT-I9100) - samsung,smdkv310 # Samsung SMDKV310 eval - samsung,trats # Samsung Tizen Reference - samsung,universal_c210 # Samsung C210
diff --git a/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml b/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml index 65ad6d8..6caf1f9 100644 --- a/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml +++ b/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml
@@ -17,45 +17,46 @@ - description: LD4 SoC boards items: - enum: - - socionext,uniphier-ld4-ref + - socionext,uniphier-ld4-ref - const: socionext,uniphier-ld4 - description: Pro4 SoC boards items: - enum: - - socionext,uniphier-pro4-ace - - socionext,uniphier-pro4-ref - - socionext,uniphier-pro4-sanji + - socionext,uniphier-pro4-ace + - socionext,uniphier-pro4-ref + - socionext,uniphier-pro4-sanji - const: socionext,uniphier-pro4 - description: sLD8 SoC boards items: - enum: - - socionext,uniphier-sld8-ref + - socionext,uniphier-sld8-ref - const: socionext,uniphier-sld8 - description: PXs2 SoC boards items: - enum: - - socionext,uniphier-pxs2-gentil - - socionext,uniphier-pxs2-vodka + - socionext,uniphier-pxs2-gentil + - socionext,uniphier-pxs2-vodka - const: socionext,uniphier-pxs2 - description: LD6b SoC boards items: - enum: - - socionext,uniphier-ld6b-ref + - socionext,uniphier-ld6b-ref - const: socionext,uniphier-ld6b - description: LD11 SoC boards items: - enum: - - socionext,uniphier-ld11-global - - socionext,uniphier-ld11-ref + - socionext,uniphier-ld11-global + - socionext,uniphier-ld11-ref - const: socionext,uniphier-ld11 - description: LD20 SoC boards items: - enum: - - socionext,uniphier-ld20-global - - socionext,uniphier-ld20-ref + - socionext,uniphier-ld20-akebi96 + - socionext,uniphier-ld20-global + - socionext,uniphier-ld20-ref - const: socionext,uniphier-ld20 - description: PXs3 SoC boards items: - enum: - - socionext,uniphier-pxs3-ref + - socionext,uniphier-pxs3-ref - const: socionext,uniphier-pxs3
diff --git a/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml b/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml index 55f7938..9f276bc9 100644 --- a/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml
@@ -20,7 +20,7 @@ [2]: https://wiki.st.com/stm32mpu/wiki/STM32MP15_RAM_mapping allOf: - - $ref: /schemas/simple-bus.yaml# + - $ref: /schemas/simple-bus.yaml# properties: compatible:
diff --git a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml index baff801..cf5db5e 100644 --- a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
@@ -14,9 +14,9 @@ compatible: oneOf: - items: - - enum: - - st,stm32mp157-syscfg - - const: syscon + - enum: + - st,stm32mp157-syscfg + - const: syscon reg: maxItems: 1
diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 1fcf306..790e6dd 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
@@ -38,6 +38,9 @@ - items: - enum: - arrow,stm32mp157a-avenger96 # Avenger96 + - lxa,stm32mp157c-mc1 + - shiratech,stm32mp157a-iot-box # IoT Box + - shiratech,stm32mp157a-stinger96 # Stinger96 - st,stm32mp157c-ed1 - st,stm32mp157a-dk1 - st,stm32mp157c-dk2
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index abf2d97..87817ff 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -561,6 +561,11 @@ - const: olimex,a20-olinuxino-lime - const: allwinner,sun7i-a20 + - description: Olimex A20-OlinuXino LIME (with eMMC) + items: + - const: olimex,a20-olinuxino-lime-emmc + - const: allwinner,sun7i-a20 + - description: Olimex A20-OlinuXino LIME2 items: - const: olimex,a20-olinuxino-lime2
diff --git a/Documentation/devicetree/bindings/arm/syna.txt b/Documentation/devicetree/bindings/arm/syna.txt index 2face46..d8b48f2e 100644 --- a/Documentation/devicetree/bindings/arm/syna.txt +++ b/Documentation/devicetree/bindings/arm/syna.txt
@@ -13,7 +13,7 @@ time. Be sure to use a device tree binary and a kernel image generated from the same source tree. -Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of a +Please refer to Documentation/devicetree/bindings/ABI.rst for a definition of a stable binding/ABI. ---------------------------------------------------------------
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml index f17bb35..b71a20a 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml
@@ -85,9 +85,8 @@ CPU power good signal from external PMIC to PMC is enabled. nvidia,suspend-mode: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [0, 1, 2] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] description: The suspend mode that the platform should use. Mode 0 is for LP0, CPU + Core voltage off and DRAM in self-refresh @@ -323,7 +322,7 @@ tegra_pmc: pmc@7000e400 { compatible = "nvidia,tegra210-pmc"; - reg = <0x0 0x7000e400 0x0 0x400>; + reg = <0x7000e400 0x400>; clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>; clock-names = "pclk", "clk32k_in"; #clock-cells = <1>;
diff --git a/Documentation/devicetree/bindings/ata/faraday,ftide010.yaml b/Documentation/devicetree/bindings/ata/faraday,ftide010.yaml index bfc6357..6451928 100644 --- a/Documentation/devicetree/bindings/ata/faraday,ftide010.yaml +++ b/Documentation/devicetree/bindings/ata/faraday,ftide010.yaml
@@ -26,8 +26,8 @@ oneOf: - const: faraday,ftide010 - items: - - const: cortina,gemini-pata - - const: faraday,ftide010 + - const: cortina,gemini-pata + - const: faraday,ftide010 reg: maxItems: 1
diff --git a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml index 7b69831..d06096a 100644 --- a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml +++ b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml
@@ -17,6 +17,7 @@ - renesas,sata-r8a7779 # R-Car H1 - items: - enum: + - renesas,sata-r8a7742 # RZ/G1H - renesas,sata-r8a7790-es1 # R-Car H2 ES1 - renesas,sata-r8a7790 # R-Car H2 other than ES1 - renesas,sata-r8a7791 # R-Car M2-W
diff --git a/Documentation/devicetree/bindings/ata/sata_highbank.txt b/Documentation/devicetree/bindings/ata/sata_highbank.txt deleted file mode 100644 index aa83407..0000000 --- a/Documentation/devicetree/bindings/ata/sata_highbank.txt +++ /dev/null
@@ -1,44 +0,0 @@ -* Calxeda AHCI SATA Controller - -SATA nodes are defined to describe on-chip Serial ATA controllers. -The Calxeda SATA controller mostly conforms to the AHCI interface -with some special extensions to add functionality. -Each SATA controller should have its own node. - -Required properties: -- compatible : compatible list, contains "calxeda,hb-ahci" -- interrupts : <interrupt mapping for SATA IRQ> -- reg : <registers mapping> - -Optional properties: -- dma-coherent : Present if dma operations are coherent -- calxeda,port-phys : phandle-combophy and lane assignment, which maps each - SATA port to a combophy and a lane within that - combophy -- calxeda,sgpio-gpio: phandle-gpio bank, bit offset, and default on or off, - which indicates that the driver supports SGPIO - indicator lights using the indicated GPIOs -- calxeda,led-order : a u32 array that map port numbers to offsets within the - SGPIO bitstream. -- calxeda,tx-atten : a u32 array that contains TX attenuation override - codes, one per port. The upper 3 bytes are always - 0 and thus ignored. -- calxeda,pre-clocks : a u32 that indicates the number of additional clock - cycles to transmit before sending an SGPIO pattern -- calxeda,post-clocks: a u32 that indicates the number of additional clock - cycles to transmit after sending an SGPIO pattern - -Example: - sata@ffe08000 { - compatible = "calxeda,hb-ahci"; - reg = <0xffe08000 0x1000>; - interrupts = <115>; - dma-coherent; - calxeda,port-phys = <&combophy5 0 &combophy0 0 &combophy0 1 - &combophy0 2 &combophy0 3>; - calxeda,sgpio-gpio =<&gpioh 5 1 &gpioh 6 1 &gpioh 7 1>; - calxeda,led-order = <4 0 1 2 3>; - calxeda,tx-atten = <0xff 22 0xff 0xff 23>; - calxeda,pre-clocks = <10>; - calxeda,post-clocks = <0>; - };
diff --git a/Documentation/devicetree/bindings/ata/sata_highbank.yaml b/Documentation/devicetree/bindings/ata/sata_highbank.yaml new file mode 100644 index 0000000..5e2a239 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/sata_highbank.yaml
@@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/sata_highbank.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Calxeda AHCI SATA Controller + +description: | + The Calxeda SATA controller mostly conforms to the AHCI interface + with some special extensions to add functionality, to map GPIOs for + activity LEDs and for mapping the ComboPHYs. + +maintainers: + - Andre Przywara <andre.przywara@arm.com> + +properties: + compatible: + const: calxeda,hb-ahci + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + dma-coherent: true + + calxeda,pre-clocks: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Indicates the number of additional clock cycles to transmit before + sending an SGPIO pattern. + + calxeda,post-clocks: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Indicates the number of additional clock cycles to transmit after + sending an SGPIO pattern. + + calxeda,led-order: + description: Maps port numbers to offsets within the SGPIO bitstream. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + + calxeda,port-phys: + description: | + phandle-combophy and lane assignment, which maps each SATA port to a + combophy and a lane within that combophy + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 8 + + calxeda,tx-atten: + description: | + Contains TX attenuation override codes, one per port. + The upper 24 bits of each entry are always 0 and thus ignored. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + + calxeda,sgpio-gpio: + description: | + phandle-gpio bank, bit offset, and default on or off, which indicates + that the driver supports SGPIO indicator lights using the indicated + GPIOs. + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + sata@ffe08000 { + compatible = "calxeda,hb-ahci"; + reg = <0xffe08000 0x1000>; + interrupts = <115>; + dma-coherent; + calxeda,port-phys = <&combophy5 0>, <&combophy0 0>, <&combophy0 1>, + <&combophy0 2>, <&combophy0 3>; + calxeda,sgpio-gpio =<&gpioh 5 1>, <&gpioh 6 1>, <&gpioh 7 1>; + calxeda,led-order = <4 0 1 2 3>; + calxeda,tx-atten = <0xff 22 0xff 0xff 23>; + calxeda,pre-clocks = <10>; + calxeda,post-clocks = <0>; + }; + +...
diff --git a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt deleted file mode 100644 index 2aa24b88..0000000 --- a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt +++ /dev/null
@@ -1,45 +0,0 @@ -DT bindings for the Hitachi HD44780 Character LCD Controller - -The Hitachi HD44780 Character LCD Controller is commonly used on character LCDs -that can display one or more lines of text. It exposes an M6800 bus interface, -which can be used in either 4-bit or 8-bit mode. - -Required properties: - - compatible: Must contain "hit,hd44780", - - data-gpios: Must contain an array of either 4 or 8 GPIO specifiers, - referring to the GPIO pins connected to the data signal lines DB0-DB7 - (8-bit mode) or DB4-DB7 (4-bit mode) of the LCD Controller's bus interface, - - enable-gpios: Must contain a GPIO specifier, referring to the GPIO pin - connected to the "E" (Enable) signal line of the LCD Controller's bus - interface, - - rs-gpios: Must contain a GPIO specifier, referring to the GPIO pin - connected to the "RS" (Register Select) signal line of the LCD Controller's - bus interface, - - display-height-chars: Height of the display, in character cells, - - display-width-chars: Width of the display, in character cells. - -Optional properties: - - rw-gpios: Must contain a GPIO specifier, referring to the GPIO pin - connected to the "RW" (Read/Write) signal line of the LCD Controller's bus - interface, - - backlight-gpios: Must contain a GPIO specifier, referring to the GPIO pin - used for enabling the LCD's backlight, - - internal-buffer-width: Internal buffer width (default is 40 for displays - with 1 or 2 lines, and display-width-chars for displays with more than 2 - lines). - -Example: - - auxdisplay { - compatible = "hit,hd44780"; - - data-gpios = <&hc595 0 GPIO_ACTIVE_HIGH>, - <&hc595 1 GPIO_ACTIVE_HIGH>, - <&hc595 2 GPIO_ACTIVE_HIGH>, - <&hc595 3 GPIO_ACTIVE_HIGH>; - enable-gpios = <&hc595 4 GPIO_ACTIVE_HIGH>; - rs-gpios = <&hc595 5 GPIO_ACTIVE_HIGH>; - - display-height-chars = <2>; - display-width-chars = <16>; - };
diff --git a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml new file mode 100644 index 0000000..9222b06 --- /dev/null +++ b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
@@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/auxdisplay/hit,hd44780.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Hitachi HD44780 Character LCD Controller + +maintainers: + - Geert Uytterhoeven <geert@linux-m68k.org> + +description: + The Hitachi HD44780 Character LCD Controller is commonly used on character + LCDs that can display one or more lines of text. It exposes an M6800 bus + interface, which can be used in either 4-bit or 8-bit mode. + +properties: + compatible: + const: hit,hd44780 + + data-gpios: + description: + GPIO pins connected to the data signal lines DB0-DB7 (8-bit mode) or + DB4-DB7 (4-bit mode) of the LCD Controller's bus interface. + oneOf: + - maxItems: 4 + - maxItems: 8 + + enable-gpios: + description: + GPIO pin connected to the "E" (Enable) signal line of the LCD + Controller's bus interface. + maxItems: 1 + + rs-gpios: + description: + GPIO pin connected to the "RS" (Register Select) signal line of the LCD + Controller's bus interface. + maxItems: 1 + + rw-gpios: + description: + GPIO pin connected to the "RW" (Read/Write) signal line of the LCD + Controller's bus interface. + maxItems: 1 + + backlight-gpios: + description: GPIO pin used for enabling the LCD's backlight. + maxItems: 1 + + display-height-chars: + description: Height of the display, in character cells, + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 4 + + display-width-chars: + description: Width of the display, in character cells. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 64 + + internal-buffer-width: + description: + Internal buffer width (default is 40 for displays with 1 or 2 lines, and + display-width-chars for displays with more than 2 lines). + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 64 + +required: + - compatible + - data-gpios + - enable-gpios + - rs-gpios + - display-height-chars + - display-width-chars + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + auxdisplay { + compatible = "hit,hd44780"; + + data-gpios = <&hc595 0 GPIO_ACTIVE_HIGH>, + <&hc595 1 GPIO_ACTIVE_HIGH>, + <&hc595 2 GPIO_ACTIVE_HIGH>, + <&hc595 3 GPIO_ACTIVE_HIGH>; + enable-gpios = <&hc595 4 GPIO_ACTIVE_HIGH>; + rs-gpios = <&hc595 5 GPIO_ACTIVE_HIGH>; + + display-height-chars = <2>; + display-width-chars = <16>; + };
diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml index f0b3d30f..0503651 100644 --- a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml +++ b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
@@ -31,12 +31,11 @@ maxItems: 1 allwinner,sram: - allOf: - - $ref: /schemas/types.yaml#definitions/phandle-array - - maxItems: 1 description: The SRAM that needs to be claimed to access the display engine bus. + $ref: /schemas/types.yaml#definitions/phandle-array + maxItems: 1 ranges: true
diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml index 8097361..32d33b9 100644 --- a/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml +++ b/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml
@@ -21,8 +21,8 @@ oneOf: - const: allwinner,sun8i-a23-rsb - items: - - const: allwinner,sun8i-a83t-rsb - - const: allwinner,sun8i-a23-rsb + - const: allwinner,sun8i-a83t-rsb + - const: allwinner,sun8i-a23-rsb reg: maxItems: 1
diff --git a/Documentation/devicetree/bindings/bus/arm,integrator-ap-lm.yaml b/Documentation/devicetree/bindings/bus/arm,integrator-ap-lm.yaml new file mode 100644 index 0000000..4722742 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/arm,integrator-ap-lm.yaml
@@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/arm,integrator-ap-lm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Integrator/AP Logic Module extension bus + +maintainers: + - Linus Walleij <linusw@kernel.org> + +description: The Integrator/AP is a prototyping platform and as such has a + site for stacking up to four logic modules (LM) designed specifically for + use with this platform. A special system controller register can be read to + determine if a logic module is connected at index 0, 1, 2 or 3. The logic + module connector is described in this binding. The logic modules per se + then have their own specific per-module bindings and they will be described + as subnodes under this logic module extension bus. + +properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + compatible: + items: + - const: arm,integrator-ap-lm + + ranges: true + dma-ranges: true + +patternProperties: + "^bus(@[0-9a-f]*)?$": + description: Nodes on the Logic Module bus represent logic modules + and are named with bus. The first module is at 0xc0000000, the second + at 0xd0000000 and so on until the top of the memory of the system at + 0xffffffff. All information about the memory used by the module is + in ranges and dma-ranges. + type: object + + required: + - compatible + +required: + - compatible + +examples: + - | + bus@c0000000 { + compatible = "arm,integrator-ap-lm"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0xc0000000 0xc0000000 0x40000000>; + dma-ranges; + + bus@c0000000 { + compatible = "simple-bus"; + ranges = <0x00000000 0xc0000000 0x10000000>; + /* The Logic Modules sees the Core Module 0 RAM @80000000 */ + dma-ranges = <0x00000000 0x80000000 0x10000000>; + #address-cells = <1>; + #size-cells = <1>; + + serial@100000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x00100000 0x1000>; + interrupts-extended = <&impd1_vic 1>; + }; + + impd1_vic: interrupt-controller@3000000 { + compatible = "arm,pl192-vic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x03000000 0x1000>; + valid-mask = <0x00000bff>; + interrupts-extended = <&pic 9>; + }; + }; + }; + +additionalProperties: false
diff --git a/Documentation/devicetree/bindings/bus/baikal,bt1-apb.yaml b/Documentation/devicetree/bindings/bus/baikal,bt1-apb.yaml new file mode 100644 index 0000000..68b0131 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/baikal,bt1-apb.yaml
@@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/baikal,bt1-apb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Baikal-T1 APB-bus + +maintainers: + - Serge Semin <fancer.lancer@gmail.com> + +description: | + Baikal-T1 CPU or DMAC MMIO requests are handled by the AMBA 3 AXI Interconnect + which routes them to the AXI-APB bridge. This interface is a single master + multiple slaves bus in turn serializing IO accesses and routing them to the + addressed APB slave devices. In case of any APB protocol collisions, slave + device not responding on timeout an IRQ is raised with an erroneous address + reported to the APB terminator (APB Errors Handler Block). + +allOf: + - $ref: /schemas/simple-bus.yaml# + +properties: + compatible: + contains: + const: baikal,bt1-apb + + reg: + items: + - description: APB EHB MMIO registers + - description: APB MMIO region with no any device mapped + + reg-names: + items: + - const: ehb + - const: nodev + + interrupts: + maxItems: 1 + + clocks: + items: + - description: APB reference clock + + clock-names: + items: + - const: pclk + + resets: + items: + - description: APB domain reset line + + reset-names: + items: + - const: prst + +unevaluatedProperties: false + +required: + - compatible + - reg + - reg-names + - interrupts + - clocks + - clock-names + +examples: + - | + #include <dt-bindings/interrupt-controller/mips-gic.h> + + bus@1f059000 { + compatible = "baikal,bt1-apb", "simple-bus"; + reg = <0x1f059000 0x1000>, + <0x1d000000 0x2040000>; + reg-names = "ehb", "nodev"; + #address-cells = <1>; + #size-cells = <1>; + + ranges; + + interrupts = <GIC_SHARED 16 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&ccu_sys 1>; + clock-names = "pclk"; + + resets = <&ccu_sys 1>; + reset-names = "prst"; + }; +...
diff --git a/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml b/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml new file mode 100644 index 0000000..29e1aae --- /dev/null +++ b/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml
@@ -0,0 +1,107 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/baikal,bt1-axi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Baikal-T1 AXI-bus + +maintainers: + - Serge Semin <fancer.lancer@gmail.com> + +description: | + AXI3-bus is the main communication bus of Baikal-T1 SoC connecting all + high-speed peripheral IP-cores with RAM controller and with MIPS P5600 + cores. Traffic arbitration is done by means of DW AXI Interconnect (so + called AXI Main Interconnect) routing IO requests from one block to + another: from CPU to SoC peripherals and between some SoC peripherals + (mostly between peripheral devices and RAM, but also between DMA and + some peripherals). In case of any protocol error, device not responding + an IRQ is raised and a faulty situation is reported to the AXI EHB + (Errors Handler Block) embedded on top of the DW AXI Interconnect and + accessible by means of the Baikal-T1 System Controller. + +allOf: + - $ref: /schemas/simple-bus.yaml# + +properties: + compatible: + contains: + const: baikal,bt1-axi + + reg: + minItems: 1 + items: + - description: Synopsys DesignWare AXI Interconnect QoS registers + - description: AXI EHB MMIO system controller registers + + reg-names: + minItems: 1 + items: + - const: qos + - const: ehb + + '#interconnect-cells': + const: 1 + + syscon: + $ref: /schemas/types.yaml#definitions/phandle + description: Phandle to the Baikal-T1 System Controller DT node + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Main Interconnect uplink reference clock + + clock-names: + items: + - const: aclk + + resets: + items: + - description: Main Interconnect reset line + + reset-names: + items: + - const: arst + +unevaluatedProperties: false + +required: + - compatible + - reg + - reg-names + - syscon + - interrupts + - clocks + - clock-names + +examples: + - | + #include <dt-bindings/interrupt-controller/mips-gic.h> + + bus@1f05a000 { + compatible = "baikal,bt1-axi", "simple-bus"; + reg = <0x1f05a000 0x1000>, + <0x1f04d110 0x8>; + reg-names = "qos", "ehb"; + #address-cells = <1>; + #size-cells = <1>; + #interconnect-cells = <1>; + + syscon = <&syscon>; + + ranges; + + interrupts = <GIC_SHARED 127 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&ccu_axi 0>; + clock-names = "aclk"; + + resets = <&ccu_axi 0>; + reset-names = "arst"; + }; +...
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-gates-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-gates-clk.yaml index ed1b212..9a37a357 100644 --- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-gates-clk.yaml +++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-gates-clk.yaml
@@ -52,12 +52,12 @@ - const: allwinner,sun4i-a10-dram-gates-clk - items: - - const: allwinner,sun5i-a13-dram-gates-clk - - const: allwinner,sun4i-a10-gates-clk + - const: allwinner,sun5i-a13-dram-gates-clk + - const: allwinner,sun4i-a10-gates-clk - items: - - const: allwinner,sun8i-h3-apb0-gates-clk - - const: allwinner,sun4i-a10-gates-clk + - const: allwinner,sun8i-h3-apb0-gates-clk + - const: allwinner,sun4i-a10-gates-clk reg: maxItems: 1
diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml new file mode 100644 index 0000000..2821425 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml
@@ -0,0 +1,188 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/baikal,bt1-ccu-div.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Baikal-T1 Clock Control Unit Dividers + +maintainers: + - Serge Semin <fancer.lancer@gmail.com> + +description: | + Clocks Control Unit is the core of Baikal-T1 SoC System Controller + responsible for the chip subsystems clocking and resetting. The CCU is + connected with an external fixed rate oscillator, which signal is transformed + into clocks of various frequencies and then propagated to either individual + IP-blocks or to groups of blocks (clock domains). The transformation is done + by means of an embedded into CCU PLLs and gateable/non-gateable dividers. The + later ones are described in this binding. Each clock domain can be also + individually reset by using the domain clocks divider configuration + registers. Baikal-T1 CCU is logically divided into the next components: + 1) External oscillator (normally XTAL's 25 MHz crystal oscillator, but + in general can provide any frequency supported by the CCU PLLs). + 2) PLLs clocks generators (PLLs). + 3) AXI-bus clock dividers (AXI) - described in this binding file. + 4) System devices reference clock dividers (SYS) - described in this binding + file. + which are connected with each other as shown on the next figure: + + +---------------+ + | Baikal-T1 CCU | + | +----+------|- MIPS P5600 cores + | +-|PLLs|------|- DDR controller + | | +----+ | + +----+ | | | | | + |XTAL|--|-+ | | +---+-| + +----+ | | | +-|AXI|-|- AXI-bus + | | | +---+-| + | | | | + | | +----+---+-|- APB-bus + | +-------|SYS|-|- Low-speed Devices + | +---+-|- High-speed Devices + +---------------+ + + Each sub-block is represented as a separate DT node and has an individual + driver to be bound with. + + In order to create signals of wide range frequencies the external oscillator + output is primarily connected to a set of CCU PLLs. Some of PLLs CLKOUT are + then passed over CCU dividers to create signals required for the target clock + domain (like AXI-bus or System Device consumers). The dividers have the + following structure: + + +--------------+ + CLKIN --|->+----+ 1|\ | + SETCLK--|--|/DIV|->| | | + CLKDIV--|--| | | |-|->CLKLOUT + LOCK----|--+----+ | | | + | |/ | + | | | + EN------|-----------+ | + RST-----|--------------|->RSTOUT + +--------------+ + + where CLKIN is the reference clock coming either from CCU PLLs or from an + external clock oscillator, SETCLK - a command to update the output clock in + accordance with a set divider, CLKDIV - clocks divider, LOCK - a signal of + the output clock stabilization, EN - enable/disable the divider block, + RST/RSTOUT - reset clocks domain signal. Depending on the consumer IP-core + peculiarities the dividers may lack of some functionality depicted on the + figure above (like EN, CLKDIV/LOCK/SETCLK). In this case the corresponding + clock provider just doesn't expose either switching functions, or the rate + configuration, or both of them. + + The clock dividers, which output clock is then consumed by the SoC individual + devices, are united into a single clocks provider called System Devices CCU. + Similarly the dividers with output clocks utilized as AXI-bus reference clocks + are called AXI-bus CCU. Both of them use the common clock bindings with no + custom properties. The list of exported clocks and reset signals can be found + in the files: 'include/dt-bindings/clock/bt1-ccu.h' and + 'include/dt-bindings/reset/bt1-ccu.h'. Since System Devices and AXI-bus CCU + are a part of the Baikal-T1 SoC System Controller their DT nodes are supposed + to be a children of later one. + +if: + properties: + compatible: + contains: + const: baikal,bt1-ccu-axi + +then: + properties: + clocks: + items: + - description: CCU SATA PLL output clock + - description: CCU PCIe PLL output clock + - description: CCU Ethernet PLL output clock + + clock-names: + items: + - const: sata_clk + - const: pcie_clk + - const: eth_clk + +else: + properties: + clocks: + items: + - description: External reference clock + - description: CCU SATA PLL output clock + - description: CCU PCIe PLL output clock + - description: CCU Ethernet PLL output clock + + clock-names: + items: + - const: ref_clk + - const: sata_clk + - const: pcie_clk + - const: eth_clk + +properties: + compatible: + enum: + - baikal,bt1-ccu-axi + - baikal,bt1-ccu-sys + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + +unevaluatedProperties: false + +required: + - compatible + - "#clock-cells" + - clocks + - clock-names + +examples: + # AXI-bus Clock Control Unit node: + - | + #include <dt-bindings/clock/bt1-ccu.h> + + clock-controller@1f04d030 { + compatible = "baikal,bt1-ccu-axi"; + reg = <0x1f04d030 0x030>; + #clock-cells = <1>; + #reset-cells = <1>; + + clocks = <&ccu_pll CCU_SATA_PLL>, + <&ccu_pll CCU_PCIE_PLL>, + <&ccu_pll CCU_ETH_PLL>; + clock-names = "sata_clk", "pcie_clk", "eth_clk"; + }; + # System Devices Clock Control Unit node: + - | + #include <dt-bindings/clock/bt1-ccu.h> + + clock-controller@1f04d060 { + compatible = "baikal,bt1-ccu-sys"; + reg = <0x1f04d060 0x0a0>; + #clock-cells = <1>; + #reset-cells = <1>; + + clocks = <&clk25m>, + <&ccu_pll CCU_SATA_PLL>, + <&ccu_pll CCU_PCIE_PLL>, + <&ccu_pll CCU_ETH_PLL>; + clock-names = "ref_clk", "sata_clk", "pcie_clk", + "eth_clk"; + }; + # Required Clock Control Unit PLL node: + - | + ccu_pll: clock-controller@1f04d000 { + compatible = "baikal,bt1-ccu-pll"; + reg = <0x1f04d000 0x028>; + #clock-cells = <1>; + + clocks = <&clk25m>; + clock-names = "ref_clk"; + }; +...
diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml new file mode 100644 index 0000000..97131bf --- /dev/null +++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
@@ -0,0 +1,131 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/baikal,bt1-ccu-pll.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Baikal-T1 Clock Control Unit PLL + +maintainers: + - Serge Semin <fancer.lancer@gmail.com> + +description: | + Clocks Control Unit is the core of Baikal-T1 SoC System Controller + responsible for the chip subsystems clocking and resetting. The CCU is + connected with an external fixed rate oscillator, which signal is transformed + into clocks of various frequencies and then propagated to either individual + IP-blocks or to groups of blocks (clock domains). The transformation is done + by means of PLLs and gateable/non-gateable dividers embedded into the CCU. + It's logically divided into the next components: + 1) External oscillator (normally XTAL's 25 MHz crystal oscillator, but + in general can provide any frequency supported by the CCU PLLs). + 2) PLLs clocks generators (PLLs) - described in this binding file. + 3) AXI-bus clock dividers (AXI). + 4) System devices reference clock dividers (SYS). + which are connected with each other as shown on the next figure: + + +---------------+ + | Baikal-T1 CCU | + | +----+------|- MIPS P5600 cores + | +-|PLLs|------|- DDR controller + | | +----+ | + +----+ | | | | | + |XTAL|--|-+ | | +---+-| + +----+ | | | +-|AXI|-|- AXI-bus + | | | +---+-| + | | | | + | | +----+---+-|- APB-bus + | +-------|SYS|-|- Low-speed Devices + | +---+-|- High-speed Devices + +---------------+ + + Each CCU sub-block is represented as a separate dts-node and has an + individual driver to be bound with. + + In order to create signals of wide range frequencies the external oscillator + output is primarily connected to a set of CCU PLLs. There are five PLLs + to create a clock for the MIPS P5600 cores, the embedded DDR controller, + SATA, Ethernet and PCIe domains. The last three domains though named by the + biggest system interfaces in fact include nearly all of the rest SoC + peripherals. Each of the PLLs is based on True Circuits TSMC CLN28HPM core + with an interface wrapper (so called safe PLL' clocks switcher) to simplify + the PLL configuration procedure. The PLLs work as depicted on the next + diagram: + + +--------------------------+ + | | + +-->+---+ +---+ +---+ | +---+ 0|\ + CLKF--->|/NF|--->|PFD|...|VCO|-+->|/OD|--->| | + +---+ +->+---+ +---+ /->+---+ | |--->CLKOUT + CLKOD---------C----------------+ 1| | + +--------C--------------------------->|/ + | | ^ + Rclk-+->+---+ | | + CLKR--->|/NR|-+ | + +---+ | + BYPASS--------------------------------------+ + BWADJ---> + + where Rclk is the reference clock coming from XTAL, NR - reference clock + divider, NF - PLL clock multiplier, OD - VCO output clock divider, CLKOUT - + output clock, BWADJ is the PLL bandwidth adjustment parameter. At this moment + the binding supports the PLL dividers configuration in accordance with a + requested rate, while bypassing and bandwidth adjustment settings can be + added in future if it gets to be necessary. + + The PLLs CLKOUT is then either directly connected with the corresponding + clocks consumer (like P5600 cores or DDR controller) or passed over a CCU + divider to create a signal required for the clock domain. + + The CCU PLL dts-node uses the common clock bindings with no custom + parameters. The list of exported clocks can be found in + 'include/dt-bindings/clock/bt1-ccu.h'. Since CCU PLL is a part of the + Baikal-T1 SoC System Controller its DT node is supposed to be a child of + later one. + +properties: + compatible: + const: baikal,bt1-ccu-pll + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + clocks: + description: External reference clock + maxItems: 1 + + clock-names: + const: ref_clk + +unevaluatedProperties: false + +required: + - compatible + - "#clock-cells" + - clocks + - clock-names + +examples: + # Clock Control Unit PLL node: + - | + clock-controller@1f04d000 { + compatible = "baikal,bt1-ccu-pll"; + reg = <0x1f04d000 0x028>; + #clock-cells = <1>; + + clocks = <&clk25m>; + clock-names = "ref_clk"; + }; + # Required external oscillator: + - | + clk25m: clock-oscillator-25m { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <25000000>; + clock-output-names = "clk25m"; + }; +...
diff --git a/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml index 8559fe8..228c931 100644 --- a/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml +++ b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml
@@ -65,7 +65,7 @@ - | uart0: serial@58018000 { compatible = "snps,dw-apb-uart"; - reg = <0x0 0x58018000 0x0 0x2000>; + reg = <0x58018000 0x2000>; clocks = <&clk 45>, <&clk 46>; clock-names = "baudclk", "apb_pclk"; interrupts = <0 9 4>;
diff --git a/Documentation/devicetree/bindings/clock/calxeda.txt b/Documentation/devicetree/bindings/clock/calxeda.txt deleted file mode 100644 index 0a6ac1b..0000000 --- a/Documentation/devicetree/bindings/clock/calxeda.txt +++ /dev/null
@@ -1,17 +0,0 @@ -Device Tree Clock bindings for Calxeda highbank platform - -This binding uses the common clock binding[1]. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt - -Required properties: -- compatible : shall be one of the following: - "calxeda,hb-pll-clock" - for a PLL clock - "calxeda,hb-a9periph-clock" - The A9 peripheral clock divided from the - A9 clock. - "calxeda,hb-a9bus-clock" - The A9 bus clock divided from the A9 clock. - "calxeda,hb-emmc-clock" - Divided clock for MMC/SD controller. -- reg : shall be the control register offset from SYSREGs base for the clock. -- clocks : shall be the input parent clock phandle for the clock. This is - either an oscillator or a pll output. -- #clock-cells : from common clock binding; shall be set to 0.
diff --git a/Documentation/devicetree/bindings/clock/calxeda.yaml b/Documentation/devicetree/bindings/clock/calxeda.yaml new file mode 100644 index 0000000..a34cbf3 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/calxeda.yaml
@@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/calxeda.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Device Tree Clock bindings for Calxeda highbank platform + +description: | + This binding covers the Calxeda SoC internal peripheral and bus clocks + as used by peripherals. The clocks live inside the "system register" + region of the SoC, so are typically presented as children of an + "hb-sregs" node. + +maintainers: + - Andre Przywara <andre.przywara@arm.com> + +properties: + "#clock-cells": + const: 0 + + compatible: + enum: + - calxeda,hb-pll-clock + - calxeda,hb-a9periph-clock + - calxeda,hb-a9bus-clock + - calxeda,hb-emmc-clock + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - "#clock-cells" + - compatible + - clocks + - reg + +additionalProperties: false + +examples: + - | + sregs@3fffc000 { + compatible = "calxeda,hb-sregs"; + reg = <0x3fffc000 0x1000>; + + clocks { + #address-cells = <1>; + #size-cells = <0>; + + osc: oscillator { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <33333000>; + }; + + ddrpll: ddrpll@108 { + #clock-cells = <0>; + compatible = "calxeda,hb-pll-clock"; + clocks = <&osc>; + reg = <0x108>; + }; + + a9pll: a9pll@100 { + #clock-cells = <0>; + compatible = "calxeda,hb-pll-clock"; + clocks = <&osc>; + reg = <0x100>; + }; + + a9periphclk: a9periphclk@104 { + #clock-cells = <0>; + compatible = "calxeda,hb-a9periph-clock"; + clocks = <&a9pll>; + reg = <0x104>; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/clock/cirrus,lochnagar.txt b/Documentation/devicetree/bindings/clock/cirrus,lochnagar.txt deleted file mode 100644 index 52a064c..0000000 --- a/Documentation/devicetree/bindings/clock/cirrus,lochnagar.txt +++ /dev/null
@@ -1,94 +0,0 @@ -Cirrus Logic Lochnagar Audio Development Board - -Lochnagar is an evaluation and development board for Cirrus Logic -Smart CODEC and Amp devices. It allows the connection of most Cirrus -Logic devices on mini-cards, as well as allowing connection of -various application processor systems to provide a full evaluation -platform. Audio system topology, clocking and power can all be -controlled through the Lochnagar, allowing the device under test -to be used in a variety of possible use cases. - -This binding document describes the binding for the clock portion of -the driver. - -Also see these documents for generic binding information: - [1] Clock : ../clock/clock-bindings.txt - -And these for relevant defines: - [2] include/dt-bindings/clock/lochnagar.h - -This binding must be part of the Lochnagar MFD binding: - [3] ../mfd/cirrus,lochnagar.txt - -Required properties: - - - compatible : One of the following strings: - "cirrus,lochnagar1-clk" - "cirrus,lochnagar2-clk" - - - #clock-cells : Must be 1. The first cell indicates the clock - number, see [2] for available clocks and [1]. - -Optional properties: - - - clocks : Must contain an entry for each clock in clock-names. - - clock-names : May contain entries for each of the following - clocks: - - ln-cdc-clkout : Output clock from CODEC card. - - ln-dsp-clkout : Output clock from DSP card. - - ln-gf-mclk1,ln-gf-mclk2,ln-gf-mclk3,ln-gf-mclk4 : Optional - input audio clocks from host system. - - ln-psia1-mclk, ln-psia2-mclk : Optional input audio clocks from - external connector. - - ln-spdif-mclk : Optional input audio clock from SPDIF. - - ln-spdif-clkout : Optional input audio clock from SPDIF. - - ln-adat-mclk : Optional input audio clock from ADAT. - - ln-pmic-32k : On board fixed clock. - - ln-clk-12m : On board fixed clock. - - ln-clk-11m : On board fixed clock. - - ln-clk-24m : On board fixed clock. - - ln-clk-22m : On board fixed clock. - - ln-clk-8m : On board fixed clock. - - ln-usb-clk-24m : On board fixed clock. - - ln-usb-clk-12m : On board fixed clock. - - - assigned-clocks : A list of Lochnagar clocks to be reparented, see - [2] for available clocks. - - assigned-clock-parents : Parents to be assigned to the clocks - listed in "assigned-clocks". - -Optional nodes: - - - fixed-clock nodes may be registered for the following on board clocks: - - ln-pmic-32k : 32768 Hz - - ln-clk-12m : 12288000 Hz - - ln-clk-11m : 11298600 Hz - - ln-clk-24m : 24576000 Hz - - ln-clk-22m : 22579200 Hz - - ln-clk-8m : 8192000 Hz - - ln-usb-clk-24m : 24576000 Hz - - ln-usb-clk-12m : 12288000 Hz - -Example: - -lochnagar { - lochnagar-clk { - compatible = "cirrus,lochnagar2-clk"; - - #clock-cells = <1>; - - clocks = <&clk-audio>, <&clk_pmic>; - clock-names = "ln-gf-mclk2", "ln-pmic-32k"; - - assigned-clocks = <&lochnagar-clk LOCHNAGAR_CDC_MCLK1>, - <&lochnagar-clk LOCHNAGAR_CDC_MCLK2>; - assigned-clock-parents = <&clk-audio>, - <&clk-pmic>; - }; - - clk-pmic: clk-pmic { - compatible = "fixed-clock"; - clock-cells = <0>; - clock-frequency = <32768>; - }; -};
diff --git a/Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml new file mode 100644 index 0000000..59de125 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml
@@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/cirrus,lochnagar.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic Lochnagar Audio Development Board + +maintainers: + - patches@opensource.cirrus.com + +description: | + Lochnagar is an evaluation and development board for Cirrus Logic + Smart CODEC and Amp devices. It allows the connection of most Cirrus + Logic devices on mini-cards, as well as allowing connection of various + application processor systems to provide a full evaluation platform. + Audio system topology, clocking and power can all be controlled through + the Lochnagar, allowing the device under test to be used in a variety of + possible use cases. + + This binding document describes the binding for the clock portion of the + driver. + + Also see these documents for generic binding information: + [1] Clock : ../clock/clock-bindings.txt + + And these for relevant defines: + [2] include/dt-bindings/clock/lochnagar.h + + This binding must be part of the Lochnagar MFD binding: + [3] ../mfd/cirrus,lochnagar.yaml + +properties: + compatible: + enum: + - cirrus,lochnagar1-clk + - cirrus,lochnagar2-clk + + '#clock-cells': + description: + The first cell indicates the clock number, see [2] for available + clocks and [1]. + const: 1 + + clock-names: + items: + enum: + - ln-cdc-clkout # Output clock from CODEC card. + - ln-dsp-clkout # Output clock from DSP card. + - ln-gf-mclk1 # Optional input clock from host system. + - ln-gf-mclk2 # Optional input clock from host system. + - ln-gf-mclk3 # Optional input clock from host system. + - ln-gf-mclk4 # Optional input clock from host system. + - ln-psia1-mclk # Optional input clock from external connector. + - ln-psia2-mclk # Optional input clock from external connector. + - ln-spdif-mclk # Optional input clock from SPDIF. + - ln-spdif-clkout # Optional input clock from SPDIF. + - ln-adat-mclk # Optional input clock from ADAT. + - ln-pmic-32k # On board fixed clock. + - ln-clk-12m # On board fixed clock. + - ln-clk-11m # On board fixed clock. + - ln-clk-24m # On board fixed clock. + - ln-clk-22m # On board fixed clock. + - ln-clk-8m # On board fixed clock. + - ln-usb-clk-24m # On board fixed clock. + - ln-usb-clk-12m # On board fixed clock. + minItems: 1 + maxItems: 19 + + clocks: true + assigned-clocks: true + assigned-clock-parents: true + +additionalProperties: false + +required: + - compatible + - '#clock-cells'
diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml b/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml index b567f80..f415845 100644 --- a/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml
@@ -24,9 +24,8 @@ clock-div: description: Fixed divider - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 1 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 clock-mult: description: Fixed multiplier
diff --git a/Documentation/devicetree/bindings/clock/fsl,plldig.yaml b/Documentation/devicetree/bindings/clock/fsl,plldig.yaml index a203d5d..9ac716d 100644 --- a/Documentation/devicetree/bindings/clock/fsl,plldig.yaml +++ b/Documentation/devicetree/bindings/clock/fsl,plldig.yaml
@@ -28,15 +28,14 @@ const: 0 fsl,vco-hz: - description: Optional for VCO frequency of the PLL in Hertz. - The VCO frequency of this PLL cannot be changed during runtime - only at startup. Therefore, the output frequencies are very - limited and might not even closely match the requested frequency. - To work around this restriction the user may specify its own - desired VCO frequency for the PLL. - minimum: 650000000 - maximum: 1300000000 - default: 1188000000 + description: Optional for VCO frequency of the PLL in Hertz. The VCO frequency + of this PLL cannot be changed during runtime only at startup. Therefore, + the output frequencies are very limited and might not even closely match + the requested frequency. To work around this restriction the user may specify + its own desired VCO frequency for the PLL. + minimum: 650000000 + maximum: 1300000000 + default: 1188000000 required: - compatible @@ -51,7 +50,7 @@ - | dpclk: clock-display@f1f0000 { compatible = "fsl,ls1028a-plldig"; - reg = <0x0 0xf1f0000 0x0 0xffff>; + reg = <0xf1f0000 0xffff>; #clock-cells = <0>; clocks = <&osc_27m>; };
diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt index 05a245c..bcff681 100644 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
@@ -12,6 +12,7 @@ "idt,5p49v5933" "idt,5p49v5935" "idt,5p49v6901" + "idt,5p49v6965" - reg: i2c device address, shall be 0x68 or 0x6a. - #clock-cells: from common clock binding; shall be set to 1. - clocks: from common clock binding; list of parent clock handles,
diff --git a/Documentation/devicetree/bindings/clock/imx1-clock.txt b/Documentation/devicetree/bindings/clock/imx1-clock.txt deleted file mode 100644 index 9823baf..0000000 --- a/Documentation/devicetree/bindings/clock/imx1-clock.txt +++ /dev/null
@@ -1,26 +0,0 @@ -* Clock bindings for Freescale i.MX1 CPUs - -Required properties: -- compatible: Should be "fsl,imx1-ccm". -- reg: Address and length of the register set. -- #clock-cells: Should be <1>. - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx1-clock.h -for the full list of i.MX1 clock IDs. - -Examples: - clks: ccm@21b000 { - #clock-cells = <1>; - compatible = "fsl,imx1-ccm"; - reg = <0x0021b000 0x1000>; - }; - - pwm: pwm@208000 { - #pwm-cells = <2>; - compatible = "fsl,imx1-pwm"; - reg = <0x00208000 0x1000>; - interrupts = <34>; - clocks = <&clks IMX1_CLK_DUMMY>, <&clks IMX1_CLK_PER1>; - clock-names = "ipg", "per"; - };
diff --git a/Documentation/devicetree/bindings/clock/imx1-clock.yaml b/Documentation/devicetree/bindings/clock/imx1-clock.yaml new file mode 100644 index 0000000..f4833a2 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx1-clock.yaml
@@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx1-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX1 CPUs + +maintainers: + - Alexander Shiyan <shc_work@mail.ru> + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx1-clock.h + for the full list of i.MX1 clock IDs. + +properties: + compatible: + const: fsl,imx1-ccm + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx1-clock.h> + + clock-controller@21b000 { + #clock-cells = <1>; + compatible = "fsl,imx1-ccm"; + reg = <0x0021b000 0x1000>; + }; + + pwm@208000 { + #pwm-cells = <2>; + compatible = "fsl,imx1-pwm"; + reg = <0x00208000 0x1000>; + interrupts = <34>; + clocks = <&clks IMX1_CLK_DUMMY>, <&clks IMX1_CLK_PER1>; + clock-names = "ipg", "per"; + };
diff --git a/Documentation/devicetree/bindings/clock/imx21-clock.txt b/Documentation/devicetree/bindings/clock/imx21-clock.txt deleted file mode 100644 index 806f63d..0000000 --- a/Documentation/devicetree/bindings/clock/imx21-clock.txt +++ /dev/null
@@ -1,27 +0,0 @@ -* Clock bindings for Freescale i.MX21 - -Required properties: -- compatible : Should be "fsl,imx21-ccm". -- reg : Address and length of the register set. -- interrupts : Should contain CCM interrupt. -- #clock-cells: Should be <1>. - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx21-clock.h -for the full list of i.MX21 clock IDs. - -Examples: - clks: ccm@10027000{ - compatible = "fsl,imx21-ccm"; - reg = <0x10027000 0x800>; - #clock-cells = <1>; - }; - - uart1: serial@1000a000 { - compatible = "fsl,imx21-uart"; - reg = <0x1000a000 0x1000>; - interrupts = <20>; - clocks = <&clks IMX21_CLK_UART1_IPG_GATE>, - <&clks IMX21_CLK_PER1>; - clock-names = "ipg", "per"; - };
diff --git a/Documentation/devicetree/bindings/clock/imx21-clock.yaml b/Documentation/devicetree/bindings/clock/imx21-clock.yaml new file mode 100644 index 0000000..518ad9a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx21-clock.yaml
@@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx21-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX21 + +maintainers: + - Alexander Shiyan <shc_work@mail.ru> + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx21-clock.h + for the full list of i.MX21 clock IDs. + +properties: + compatible: + const: fsl,imx21-ccm + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx21-clock.h> + + clock-controller@10027000 { + compatible = "fsl,imx21-ccm"; + reg = <0x10027000 0x800>; + #clock-cells = <1>; + }; + + serial@1000a000 { + compatible = "fsl,imx21-uart"; + reg = <0x1000a000 0x1000>; + interrupts = <20>; + clocks = <&clks IMX21_CLK_UART1_IPG_GATE>, + <&clks IMX21_CLK_PER1>; + clock-names = "ipg", "per"; + };
diff --git a/Documentation/devicetree/bindings/clock/imx23-clock.txt b/Documentation/devicetree/bindings/clock/imx23-clock.txt deleted file mode 100644 index 8385348..0000000 --- a/Documentation/devicetree/bindings/clock/imx23-clock.txt +++ /dev/null
@@ -1,70 +0,0 @@ -* Clock bindings for Freescale i.MX23 - -Required properties: -- compatible: Should be "fsl,imx23-clkctrl" -- reg: Address and length of the register set -- #clock-cells: Should be <1> - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. The following is a full list of i.MX23 -clocks and IDs. - - Clock ID - ------------------ - ref_xtal 0 - pll 1 - ref_cpu 2 - ref_emi 3 - ref_pix 4 - ref_io 5 - saif_sel 6 - lcdif_sel 7 - gpmi_sel 8 - ssp_sel 9 - emi_sel 10 - cpu 11 - etm_sel 12 - cpu_pll 13 - cpu_xtal 14 - hbus 15 - xbus 16 - lcdif_div 17 - ssp_div 18 - gpmi_div 19 - emi_pll 20 - emi_xtal 21 - etm_div 22 - saif_div 23 - clk32k_div 24 - rtc 25 - adc 26 - spdif_div 27 - clk32k 28 - dri 29 - pwm 30 - filt 31 - uart 32 - ssp 33 - gpmi 34 - spdif 35 - emi 36 - saif 37 - lcdif 38 - etm 39 - usb 40 - usb_phy 41 - -Examples: - -clks: clkctrl@80040000 { - compatible = "fsl,imx23-clkctrl"; - reg = <0x80040000 0x2000>; - #clock-cells = <1>; -}; - -auart0: serial@8006c000 { - compatible = "fsl,imx23-auart"; - reg = <0x8006c000 0x2000>; - interrupts = <24 25 23>; - clocks = <&clks 32>; -};
diff --git a/Documentation/devicetree/bindings/clock/imx23-clock.yaml b/Documentation/devicetree/bindings/clock/imx23-clock.yaml new file mode 100644 index 0000000..66cb238 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx23-clock.yaml
@@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx23-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX23 + +maintainers: + - Shawn Guo <shawn.guo@linaro.org> + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. The following is a full list of i.MX23 + clocks and IDs. + + Clock ID + ------------------ + ref_xtal 0 + pll 1 + ref_cpu 2 + ref_emi 3 + ref_pix 4 + ref_io 5 + saif_sel 6 + lcdif_sel 7 + gpmi_sel 8 + ssp_sel 9 + emi_sel 10 + cpu 11 + etm_sel 12 + cpu_pll 13 + cpu_xtal 14 + hbus 15 + xbus 16 + lcdif_div 17 + ssp_div 18 + gpmi_div 19 + emi_pll 20 + emi_xtal 21 + etm_div 22 + saif_div 23 + clk32k_div 24 + rtc 25 + adc 26 + spdif_div 27 + clk32k 28 + dri 29 + pwm 30 + filt 31 + uart 32 + ssp 33 + gpmi 34 + spdif 35 + emi 36 + saif 37 + lcdif 38 + etm 39 + usb 40 + usb_phy 41 + +properties: + compatible: + const: fsl,imx23-clkctrl + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@80040000 { + compatible = "fsl,imx23-clkctrl"; + reg = <0x80040000 0x2000>; + #clock-cells = <1>; + }; + + serial@8006c000 { + compatible = "fsl,imx23-auart"; + reg = <0x8006c000 0x2000>; + interrupts = <24 25 23>; + clocks = <&clks 32>; + };
diff --git a/Documentation/devicetree/bindings/clock/imx25-clock.txt b/Documentation/devicetree/bindings/clock/imx25-clock.txt deleted file mode 100644 index f8135ea..0000000 --- a/Documentation/devicetree/bindings/clock/imx25-clock.txt +++ /dev/null
@@ -1,160 +0,0 @@ -* Clock bindings for Freescale i.MX25 - -Required properties: -- compatible: Should be "fsl,imx25-ccm" -- reg: Address and length of the register set -- interrupts: Should contain CCM interrupt -- #clock-cells: Should be <1> - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. The following is a full list of i.MX25 -clocks and IDs. - - Clock ID - --------------------------- - dummy 0 - osc 1 - mpll 2 - upll 3 - mpll_cpu_3_4 4 - cpu_sel 5 - cpu 6 - ahb 7 - usb_div 8 - ipg 9 - per0_sel 10 - per1_sel 11 - per2_sel 12 - per3_sel 13 - per4_sel 14 - per5_sel 15 - per6_sel 16 - per7_sel 17 - per8_sel 18 - per9_sel 19 - per10_sel 20 - per11_sel 21 - per12_sel 22 - per13_sel 23 - per14_sel 24 - per15_sel 25 - per0 26 - per1 27 - per2 28 - per3 29 - per4 30 - per5 31 - per6 32 - per7 33 - per8 34 - per9 35 - per10 36 - per11 37 - per12 38 - per13 39 - per14 40 - per15 41 - csi_ipg_per 42 - epit_ipg_per 43 - esai_ipg_per 44 - esdhc1_ipg_per 45 - esdhc2_ipg_per 46 - gpt_ipg_per 47 - i2c_ipg_per 48 - lcdc_ipg_per 49 - nfc_ipg_per 50 - owire_ipg_per 51 - pwm_ipg_per 52 - sim1_ipg_per 53 - sim2_ipg_per 54 - ssi1_ipg_per 55 - ssi2_ipg_per 56 - uart_ipg_per 57 - ata_ahb 58 - reserved 59 - csi_ahb 60 - emi_ahb 61 - esai_ahb 62 - esdhc1_ahb 63 - esdhc2_ahb 64 - fec_ahb 65 - lcdc_ahb 66 - rtic_ahb 67 - sdma_ahb 68 - slcdc_ahb 69 - usbotg_ahb 70 - reserved 71 - reserved 72 - reserved 73 - reserved 74 - can1_ipg 75 - can2_ipg 76 - csi_ipg 77 - cspi1_ipg 78 - cspi2_ipg 79 - cspi3_ipg 80 - dryice_ipg 81 - ect_ipg 82 - epit1_ipg 83 - epit2_ipg 84 - reserved 85 - esdhc1_ipg 86 - esdhc2_ipg 87 - fec_ipg 88 - reserved 89 - reserved 90 - reserved 91 - gpt1_ipg 92 - gpt2_ipg 93 - gpt3_ipg 94 - gpt4_ipg 95 - reserved 96 - reserved 97 - reserved 98 - iim_ipg 99 - reserved 100 - reserved 101 - kpp_ipg 102 - lcdc_ipg 103 - reserved 104 - pwm1_ipg 105 - pwm2_ipg 106 - pwm3_ipg 107 - pwm4_ipg 108 - rngb_ipg 109 - reserved 110 - scc_ipg 111 - sdma_ipg 112 - sim1_ipg 113 - sim2_ipg 114 - slcdc_ipg 115 - spba_ipg 116 - ssi1_ipg 117 - ssi2_ipg 118 - tsc_ipg 119 - uart1_ipg 120 - uart2_ipg 121 - uart3_ipg 122 - uart4_ipg 123 - uart5_ipg 124 - reserved 125 - wdt_ipg 126 - cko_div 127 - cko_sel 128 - cko 129 - -Examples: - -clks: ccm@53f80000 { - compatible = "fsl,imx25-ccm"; - reg = <0x53f80000 0x4000>; - interrupts = <31>; -}; - -uart1: serial@43f90000 { - compatible = "fsl,imx25-uart", "fsl,imx21-uart"; - reg = <0x43f90000 0x4000>; - interrupts = <45>; - clocks = <&clks 79>, <&clks 50>; - clock-names = "ipg", "per"; -};
diff --git a/Documentation/devicetree/bindings/clock/imx25-clock.yaml b/Documentation/devicetree/bindings/clock/imx25-clock.yaml new file mode 100644 index 0000000..2a2b107 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx25-clock.yaml
@@ -0,0 +1,186 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx25-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX25 + +maintainers: + - Sascha Hauer <s.hauer@pengutronix.de> + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. The following is a full list of i.MX25 + clocks and IDs. + + Clock ID + -------------------------- + dummy 0 + osc 1 + mpll 2 + upll 3 + mpll_cpu_3_4 4 + cpu_sel 5 + cpu 6 + ahb 7 + usb_div 8 + ipg 9 + per0_sel 10 + per1_sel 11 + per2_sel 12 + per3_sel 13 + per4_sel 14 + per5_sel 15 + per6_sel 16 + per7_sel 17 + per8_sel 18 + per9_sel 19 + per10_sel 20 + per11_sel 21 + per12_sel 22 + per13_sel 23 + per14_sel 24 + per15_sel 25 + per0 26 + per1 27 + per2 28 + per3 29 + per4 30 + per5 31 + per6 32 + per7 33 + per8 34 + per9 35 + per10 36 + per11 37 + per12 38 + per13 39 + per14 40 + per15 41 + csi_ipg_per 42 + epit_ipg_per 43 + esai_ipg_per 44 + esdhc1_ipg_per 45 + esdhc2_ipg_per 46 + gpt_ipg_per 47 + i2c_ipg_per 48 + lcdc_ipg_per 49 + nfc_ipg_per 50 + owire_ipg_per 51 + pwm_ipg_per 52 + sim1_ipg_per 53 + sim2_ipg_per 54 + ssi1_ipg_per 55 + ssi2_ipg_per 56 + uart_ipg_per 57 + ata_ahb 58 + reserved 59 + csi_ahb 60 + emi_ahb 61 + esai_ahb 62 + esdhc1_ahb 63 + esdhc2_ahb 64 + fec_ahb 65 + lcdc_ahb 66 + rtic_ahb 67 + sdma_ahb 68 + slcdc_ahb 69 + usbotg_ahb 70 + reserved 71 + reserved 72 + reserved 73 + reserved 74 + can1_ipg 75 + can2_ipg 76 + csi_ipg 77 + cspi1_ipg 78 + cspi2_ipg 79 + cspi3_ipg 80 + dryice_ipg 81 + ect_ipg 82 + epit1_ipg 83 + epit2_ipg 84 + reserved 85 + esdhc1_ipg 86 + esdhc2_ipg 87 + fec_ipg 88 + reserved 89 + reserved 90 + reserved 91 + gpt1_ipg 92 + gpt2_ipg 93 + gpt3_ipg 94 + gpt4_ipg 95 + reserved 96 + reserved 97 + reserved 98 + iim_ipg 99 + reserved 100 + reserved 101 + kpp_ipg 102 + lcdc_ipg 103 + reserved 104 + pwm1_ipg 105 + pwm2_ipg 106 + pwm3_ipg 107 + pwm4_ipg 108 + rngb_ipg 109 + reserved 110 + scc_ipg 111 + sdma_ipg 112 + sim1_ipg 113 + sim2_ipg 114 + slcdc_ipg 115 + spba_ipg 116 + ssi1_ipg 117 + ssi2_ipg 118 + tsc_ipg 119 + uart1_ipg 120 + uart2_ipg 121 + uart3_ipg 122 + uart4_ipg 123 + uart5_ipg 124 + reserved 125 + wdt_ipg 126 + cko_div 127 + cko_sel 128 + cko 129 + +properties: + compatible: + const: fsl,imx25-ccm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - interrupts + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@53f80000 { + compatible = "fsl,imx25-ccm"; + reg = <0x53f80000 0x4000>; + interrupts = <31>; + #clock-cells = <1>; + }; + + serial@43f90000 { + compatible = "fsl,imx25-uart", "fsl,imx21-uart"; + reg = <0x43f90000 0x4000>; + interrupts = <45>; + clocks = <&clks 79>, <&clks 50>; + clock-names = "ipg", "per"; + };
diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.txt b/Documentation/devicetree/bindings/clock/imx27-clock.txt deleted file mode 100644 index 4c95c04..0000000 --- a/Documentation/devicetree/bindings/clock/imx27-clock.txt +++ /dev/null
@@ -1,27 +0,0 @@ -* Clock bindings for Freescale i.MX27 - -Required properties: -- compatible: Should be "fsl,imx27-ccm" -- reg: Address and length of the register set -- interrupts: Should contain CCM interrupt -- #clock-cells: Should be <1> - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx27-clock.h -for the full list of i.MX27 clock IDs. - -Examples: - clks: ccm@10027000{ - compatible = "fsl,imx27-ccm"; - reg = <0x10027000 0x1000>; - #clock-cells = <1>; - }; - - uart1: serial@1000a000 { - compatible = "fsl,imx27-uart", "fsl,imx21-uart"; - reg = <0x1000a000 0x1000>; - interrupts = <20>; - clocks = <&clks IMX27_CLK_UART1_IPG_GATE>, - <&clks IMX27_CLK_PER1_GATE>; - clock-names = "ipg", "per"; - };
diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.yaml b/Documentation/devicetree/bindings/clock/imx27-clock.yaml new file mode 100644 index 0000000..b5f3ed0 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx27-clock.yaml
@@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx27-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX27 + +maintainers: + - Fabio Estevam <fabio.estevam@freescale.com> + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx27-clock.h + for the full list of i.MX27 clock IDs. + +properties: + compatible: + const: fsl,imx27-ccm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx27-clock.h> + + clock-controller@10027000 { + compatible = "fsl,imx27-ccm"; + reg = <0x10027000 0x1000>; + interrupts = <31>; + #clock-cells = <1>; + }; + + serial@1000a000 { + compatible = "fsl,imx27-uart", "fsl,imx21-uart"; + reg = <0x1000a000 0x1000>; + interrupts = <20>; + clocks = <&clks IMX27_CLK_UART1_IPG_GATE>, + <&clks IMX27_CLK_PER1_GATE>; + clock-names = "ipg", "per"; + };
diff --git a/Documentation/devicetree/bindings/clock/imx28-clock.txt b/Documentation/devicetree/bindings/clock/imx28-clock.txt deleted file mode 100644 index d84a37d..0000000 --- a/Documentation/devicetree/bindings/clock/imx28-clock.txt +++ /dev/null
@@ -1,93 +0,0 @@ -* Clock bindings for Freescale i.MX28 - -Required properties: -- compatible: Should be "fsl,imx28-clkctrl" -- reg: Address and length of the register set -- #clock-cells: Should be <1> - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. The following is a full list of i.MX28 -clocks and IDs. - - Clock ID - ------------------ - ref_xtal 0 - pll0 1 - pll1 2 - pll2 3 - ref_cpu 4 - ref_emi 5 - ref_io0 6 - ref_io1 7 - ref_pix 8 - ref_hsadc 9 - ref_gpmi 10 - saif0_sel 11 - saif1_sel 12 - gpmi_sel 13 - ssp0_sel 14 - ssp1_sel 15 - ssp2_sel 16 - ssp3_sel 17 - emi_sel 18 - etm_sel 19 - lcdif_sel 20 - cpu 21 - ptp_sel 22 - cpu_pll 23 - cpu_xtal 24 - hbus 25 - xbus 26 - ssp0_div 27 - ssp1_div 28 - ssp2_div 29 - ssp3_div 30 - gpmi_div 31 - emi_pll 32 - emi_xtal 33 - lcdif_div 34 - etm_div 35 - ptp 36 - saif0_div 37 - saif1_div 38 - clk32k_div 39 - rtc 40 - lradc 41 - spdif_div 42 - clk32k 43 - pwm 44 - uart 45 - ssp0 46 - ssp1 47 - ssp2 48 - ssp3 49 - gpmi 50 - spdif 51 - emi 52 - saif0 53 - saif1 54 - lcdif 55 - etm 56 - fec 57 - can0 58 - can1 59 - usb0 60 - usb1 61 - usb0_phy 62 - usb1_phy 63 - enet_out 64 - -Examples: - -clks: clkctrl@80040000 { - compatible = "fsl,imx28-clkctrl"; - reg = <0x80040000 0x2000>; - #clock-cells = <1>; -}; - -auart0: serial@8006a000 { - compatible = "fsl,imx28-auart", "fsl,imx23-auart"; - reg = <0x8006a000 0x2000>; - interrupts = <112 70 71>; - clocks = <&clks 45>; -};
diff --git a/Documentation/devicetree/bindings/clock/imx28-clock.yaml b/Documentation/devicetree/bindings/clock/imx28-clock.yaml new file mode 100644 index 0000000..72328d5 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx28-clock.yaml
@@ -0,0 +1,115 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx28-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX28 + +maintainers: + - Shawn Guo <shawn.guo@linaro.org> + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. The following is a full list of i.MX28 + clocks and IDs. + + Clock ID + ------------------ + ref_xtal 0 + pll0 1 + pll1 2 + pll2 3 + ref_cpu 4 + ref_emi 5 + ref_io0 6 + ref_io1 7 + ref_pix 8 + ref_hsadc 9 + ref_gpmi 10 + saif0_sel 11 + saif1_sel 12 + gpmi_sel 13 + ssp0_sel 14 + ssp1_sel 15 + ssp2_sel 16 + ssp3_sel 17 + emi_sel 18 + etm_sel 19 + lcdif_sel 20 + cpu 21 + ptp_sel 22 + cpu_pll 23 + cpu_xtal 24 + hbus 25 + xbus 26 + ssp0_div 27 + ssp1_div 28 + ssp2_div 29 + ssp3_div 30 + gpmi_div 31 + emi_pll 32 + emi_xtal 33 + lcdif_div 34 + etm_div 35 + ptp 36 + saif0_div 37 + saif1_div 38 + clk32k_div 39 + rtc 40 + lradc 41 + spdif_div 42 + clk32k 43 + pwm 44 + uart 45 + ssp0 46 + ssp1 47 + ssp2 48 + ssp3 49 + gpmi 50 + spdif 51 + emi 52 + saif0 53 + saif1 54 + lcdif 55 + etm 56 + fec 57 + can0 58 + can1 59 + usb0 60 + usb1 61 + usb0_phy 62 + usb1_phy 63 + enet_out 64 + +properties: + compatible: + const: fsl,imx28-clkctrl + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@80040000 { + compatible = "fsl,imx28-clkctrl"; + reg = <0x80040000 0x2000>; + #clock-cells = <1>; + }; + + serial@8006a000 { + compatible = "fsl,imx28-auart", "fsl,imx23-auart"; + reg = <0x8006a000 0x2000>; + interrupts = <112 70 71>; + clocks = <&clks 45>; + };
diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt b/Documentation/devicetree/bindings/clock/imx31-clock.txt deleted file mode 100644 index 0a29109..0000000 --- a/Documentation/devicetree/bindings/clock/imx31-clock.txt +++ /dev/null
@@ -1,90 +0,0 @@ -* Clock bindings for Freescale i.MX31 - -Required properties: -- compatible: Should be "fsl,imx31-ccm" -- reg: Address and length of the register set -- interrupts: Should contain CCM interrupt -- #clock-cells: Should be <1> - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. The following is a full list of i.MX31 -clocks and IDs. - - Clock ID - ----------------------- - dummy 0 - ckih 1 - ckil 2 - mpll 3 - spll 4 - upll 5 - mcu_main 6 - hsp 7 - ahb 8 - nfc 9 - ipg 10 - per_div 11 - per 12 - csi_sel 13 - fir_sel 14 - csi_div 15 - usb_div_pre 16 - usb_div_post 17 - fir_div_pre 18 - fir_div_post 19 - sdhc1_gate 20 - sdhc2_gate 21 - gpt_gate 22 - epit1_gate 23 - epit2_gate 24 - iim_gate 25 - ata_gate 26 - sdma_gate 27 - cspi3_gate 28 - rng_gate 29 - uart1_gate 30 - uart2_gate 31 - ssi1_gate 32 - i2c1_gate 33 - i2c2_gate 34 - i2c3_gate 35 - hantro_gate 36 - mstick1_gate 37 - mstick2_gate 38 - csi_gate 39 - rtc_gate 40 - wdog_gate 41 - pwm_gate 42 - sim_gate 43 - ect_gate 44 - usb_gate 45 - kpp_gate 46 - ipu_gate 47 - uart3_gate 48 - uart4_gate 49 - uart5_gate 50 - owire_gate 51 - ssi2_gate 52 - cspi1_gate 53 - cspi2_gate 54 - gacc_gate 55 - emi_gate 56 - rtic_gate 57 - firi_gate 58 - -Examples: - -clks: ccm@53f80000{ - compatible = "fsl,imx31-ccm"; - reg = <0x53f80000 0x4000>; - interrupts = <31>, <53>; - #clock-cells = <1>; -}; - -uart1: serial@43f90000 { - compatible = "fsl,imx31-uart", "fsl,imx21-uart"; - reg = <0x43f90000 0x4000>; - interrupts = <45>; - clocks = <&clks 10>, <&clks 30>; - clock-names = "ipg", "per"; -};
diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.yaml b/Documentation/devicetree/bindings/clock/imx31-clock.yaml new file mode 100644 index 0000000..1b6f75d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx31-clock.yaml
@@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx31-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX31 + +maintainers: + - Fabio Estevam <fabio.estevam@freescale.com> + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. The following is a full list of i.MX31 + clocks and IDs. + + Clock ID + ----------------------- + dummy 0 + ckih 1 + ckil 2 + mpll 3 + spll 4 + upll 5 + mcu_main 6 + hsp 7 + ahb 8 + nfc 9 + ipg 10 + per_div 11 + per 12 + csi_sel 13 + fir_sel 14 + csi_div 15 + usb_div_pre 16 + usb_div_post 17 + fir_div_pre 18 + fir_div_post 19 + sdhc1_gate 20 + sdhc2_gate 21 + gpt_gate 22 + epit1_gate 23 + epit2_gate 24 + iim_gate 25 + ata_gate 26 + sdma_gate 27 + cspi3_gate 28 + rng_gate 29 + uart1_gate 30 + uart2_gate 31 + ssi1_gate 32 + i2c1_gate 33 + i2c2_gate 34 + i2c3_gate 35 + hantro_gate 36 + mstick1_gate 37 + mstick2_gate 38 + csi_gate 39 + rtc_gate 40 + wdog_gate 41 + pwm_gate 42 + sim_gate 43 + ect_gate 44 + usb_gate 45 + kpp_gate 46 + ipu_gate 47 + uart3_gate 48 + uart4_gate 49 + uart5_gate 50 + owire_gate 51 + ssi2_gate 52 + cspi1_gate 53 + cspi2_gate 54 + gacc_gate 55 + emi_gate 56 + rtic_gate 57 + firi_gate 58 + +properties: + compatible: + const: fsl,imx31-ccm + + reg: + maxItems: 1 + + interrupts: + description: CCM provides 2 interrupt requests, request 1 is to generate + interrupt for DVFS when a frequency change is requested, request 2 is + to generate interrupt for DPTC when a voltage change is requested. + items: + - description: CCM DVFS interrupt request 1 + - description: CCM DPTC interrupt request 2 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - interrupts + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@53f80000 { + compatible = "fsl,imx31-ccm"; + reg = <0x53f80000 0x4000>; + interrupts = <31>, <53>; + #clock-cells = <1>; + }; + + serial@43f90000 { + compatible = "fsl,imx31-uart", "fsl,imx21-uart"; + reg = <0x43f90000 0x4000>; + interrupts = <45>; + clocks = <&clks 10>, <&clks 30>; + clock-names = "ipg", "per"; + };
diff --git a/Documentation/devicetree/bindings/clock/imx35-clock.txt b/Documentation/devicetree/bindings/clock/imx35-clock.txt deleted file mode 100644 index f497832..0000000 --- a/Documentation/devicetree/bindings/clock/imx35-clock.txt +++ /dev/null
@@ -1,114 +0,0 @@ -* Clock bindings for Freescale i.MX35 - -Required properties: -- compatible: Should be "fsl,imx35-ccm" -- reg: Address and length of the register set -- interrupts: Should contain CCM interrupt -- #clock-cells: Should be <1> - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. The following is a full list of i.MX35 -clocks and IDs. - - Clock ID - --------------------------- - ckih 0 - mpll 1 - ppll 2 - mpll_075 3 - arm 4 - hsp 5 - hsp_div 6 - hsp_sel 7 - ahb 8 - ipg 9 - arm_per_div 10 - ahb_per_div 11 - ipg_per 12 - uart_sel 13 - uart_div 14 - esdhc_sel 15 - esdhc1_div 16 - esdhc2_div 17 - esdhc3_div 18 - spdif_sel 19 - spdif_div_pre 20 - spdif_div_post 21 - ssi_sel 22 - ssi1_div_pre 23 - ssi1_div_post 24 - ssi2_div_pre 25 - ssi2_div_post 26 - usb_sel 27 - usb_div 28 - nfc_div 29 - asrc_gate 30 - pata_gate 31 - audmux_gate 32 - can1_gate 33 - can2_gate 34 - cspi1_gate 35 - cspi2_gate 36 - ect_gate 37 - edio_gate 38 - emi_gate 39 - epit1_gate 40 - epit2_gate 41 - esai_gate 42 - esdhc1_gate 43 - esdhc2_gate 44 - esdhc3_gate 45 - fec_gate 46 - gpio1_gate 47 - gpio2_gate 48 - gpio3_gate 49 - gpt_gate 50 - i2c1_gate 51 - i2c2_gate 52 - i2c3_gate 53 - iomuxc_gate 54 - ipu_gate 55 - kpp_gate 56 - mlb_gate 57 - mshc_gate 58 - owire_gate 59 - pwm_gate 60 - rngc_gate 61 - rtc_gate 62 - rtic_gate 63 - scc_gate 64 - sdma_gate 65 - spba_gate 66 - spdif_gate 67 - ssi1_gate 68 - ssi2_gate 69 - uart1_gate 70 - uart2_gate 71 - uart3_gate 72 - usbotg_gate 73 - wdog_gate 74 - max_gate 75 - admux_gate 76 - csi_gate 77 - csi_div 78 - csi_sel 79 - iim_gate 80 - gpu2d_gate 81 - ckli_gate 82 - -Examples: - -clks: ccm@53f80000 { - compatible = "fsl,imx35-ccm"; - reg = <0x53f80000 0x4000>; - interrupts = <31>; - #clock-cells = <1>; -}; - -esdhc1: esdhc@53fb4000 { - compatible = "fsl,imx35-esdhc"; - reg = <0x53fb4000 0x4000>; - interrupts = <7>; - clocks = <&clks 9>, <&clks 8>, <&clks 43>; - clock-names = "ipg", "ahb", "per"; -};
diff --git a/Documentation/devicetree/bindings/clock/imx35-clock.yaml b/Documentation/devicetree/bindings/clock/imx35-clock.yaml new file mode 100644 index 0000000..bd871da --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx35-clock.yaml
@@ -0,0 +1,139 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx35-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX35 + +maintainers: + - Steffen Trumtrar <s.trumtrar@pengutronix.de> + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. The following is a full list of i.MX35 + clocks and IDs. + + Clock ID + --------------------------- + ckih 0 + mpll 1 + ppll 2 + mpll_075 3 + arm 4 + hsp 5 + hsp_div 6 + hsp_sel 7 + ahb 8 + ipg 9 + arm_per_div 10 + ahb_per_div 11 + ipg_per 12 + uart_sel 13 + uart_div 14 + esdhc_sel 15 + esdhc1_div 16 + esdhc2_div 17 + esdhc3_div 18 + spdif_sel 19 + spdif_div_pre 20 + spdif_div_post 21 + ssi_sel 22 + ssi1_div_pre 23 + ssi1_div_post 24 + ssi2_div_pre 25 + ssi2_div_post 26 + usb_sel 27 + usb_div 28 + nfc_div 29 + asrc_gate 30 + pata_gate 31 + audmux_gate 32 + can1_gate 33 + can2_gate 34 + cspi1_gate 35 + cspi2_gate 36 + ect_gate 37 + edio_gate 38 + emi_gate 39 + epit1_gate 40 + epit2_gate 41 + esai_gate 42 + esdhc1_gate 43 + esdhc2_gate 44 + esdhc3_gate 45 + fec_gate 46 + gpio1_gate 47 + gpio2_gate 48 + gpio3_gate 49 + gpt_gate 50 + i2c1_gate 51 + i2c2_gate 52 + i2c3_gate 53 + iomuxc_gate 54 + ipu_gate 55 + kpp_gate 56 + mlb_gate 57 + mshc_gate 58 + owire_gate 59 + pwm_gate 60 + rngc_gate 61 + rtc_gate 62 + rtic_gate 63 + scc_gate 64 + sdma_gate 65 + spba_gate 66 + spdif_gate 67 + ssi1_gate 68 + ssi2_gate 69 + uart1_gate 70 + uart2_gate 71 + uart3_gate 72 + usbotg_gate 73 + wdog_gate 74 + max_gate 75 + admux_gate 76 + csi_gate 77 + csi_div 78 + csi_sel 79 + iim_gate 80 + gpu2d_gate 81 + ckli_gate 82 + +properties: + compatible: + const: fsl,imx35-ccm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - interrupts + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@53f80000 { + compatible = "fsl,imx35-ccm"; + reg = <0x53f80000 0x4000>; + interrupts = <31>; + #clock-cells = <1>; + }; + + esdhc@53fb4000 { + compatible = "fsl,imx35-esdhc"; + reg = <0x53fb4000 0x4000>; + interrupts = <7>; + clocks = <&clks 9>, <&clks 8>, <&clks 43>; + clock-names = "ipg", "ahb", "per"; + };
diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt deleted file mode 100644 index a24ca9e..0000000 --- a/Documentation/devicetree/bindings/clock/imx5-clock.txt +++ /dev/null
@@ -1,28 +0,0 @@ -* Clock bindings for Freescale i.MX5 - -Required properties: -- compatible: Should be "fsl,<soc>-ccm" , where <soc> can be imx51 or imx53 -- reg: Address and length of the register set -- interrupts: Should contain CCM interrupt -- #clock-cells: Should be <1> - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx5-clock.h -for the full list of i.MX5 clock IDs. - -Examples (for mx53): - -clks: ccm@53fd4000{ - compatible = "fsl,imx53-ccm"; - reg = <0x53fd4000 0x4000>; - interrupts = <0 71 0x04 0 72 0x04>; - #clock-cells = <1>; -}; - -can1: can@53fc8000 { - compatible = "fsl,imx53-flexcan", "fsl,p1010-flexcan"; - reg = <0x53fc8000 0x4000>; - interrupts = <82>; - clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>, <&clks IMX5_CLK_CAN1_SERIAL_GATE>; - clock-names = "ipg", "per"; -};
diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.yaml b/Documentation/devicetree/bindings/clock/imx5-clock.yaml new file mode 100644 index 0000000..f5c2b3d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx5-clock.yaml
@@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx5-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX5 + +maintainers: + - Fabio Estevam <fabio.estevam@freescale.com> + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx5-clock.h + for the full list of i.MX5 clock IDs. + +properties: + compatible: + enum: + - fsl,imx53-ccm + - fsl,imx51-ccm + - fsl,imx50-ccm + + reg: + maxItems: 1 + + interrupts: + description: CCM provides 2 interrupt requests, request 1 is to generate + interrupt for frequency or mux change, request 2 is to generate + interrupt for oscillator read or PLL lock. + items: + - description: CCM interrupt request 1 + - description: CCM interrupt request 2 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - interrupts + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx5-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + clock-controller@53fd4000{ + compatible = "fsl,imx53-ccm"; + reg = <0x53fd4000 0x4000>; + interrupts = <0 71 IRQ_TYPE_LEVEL_HIGH>, + <0 72 IRQ_TYPE_LEVEL_HIGH>; + #clock-cells = <1>; + }; + + can@53fc8000 { + compatible = "fsl,imx53-flexcan", "fsl,p1010-flexcan"; + reg = <0x53fc8000 0x4000>; + interrupts = <82>; + clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>, <&clks IMX5_CLK_CAN1_SERIAL_GATE>; + clock-names = "ipg", "per"; + };
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt deleted file mode 100644 index 13d36d4..0000000 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt +++ /dev/null
@@ -1,41 +0,0 @@ -* Clock bindings for Freescale i.MX6 Quad - -Required properties: -- compatible: Should be "fsl,imx6q-ccm" -- reg: Address and length of the register set -- interrupts: Should contain CCM interrupt -- #clock-cells: Should be <1> - -Optional properties: -- fsl,pmic-stby-poweroff: Configure CCM to assert PMIC_STBY_REQ signal - on power off. - Use this property if the SoC should be powered off by external power - management IC (PMIC) triggered via PMIC_STBY_REQ signal. - Boards that are designed to initiate poweroff on PMIC_ON_REQ signal should - be using "syscon-poweroff" driver instead. -- clocks: list of clock specifiers, must contain an entry for each entry - in clock-names -- clock-names: valid names are "osc", "ckil", "ckih1", "anaclk1" and "anaclk2" - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6qdl-clock.h -for the full list of i.MX6 Quad and DualLite clock IDs. - -Examples: - -#include <dt-bindings/clock/imx6qdl-clock.h> - -clks: ccm@20c4000 { - compatible = "fsl,imx6q-ccm"; - reg = <0x020c4000 0x4000>; - interrupts = <0 87 0x04 0 88 0x04>; - #clock-cells = <1>; -}; - -uart1: serial@2020000 { - compatible = "fsl,imx6q-uart", "fsl,imx21-uart"; - reg = <0x02020000 0x4000>; - interrupts = <0 26 0x04>; - clocks = <&clks IMX6QDL_CLK_UART_IPG>, <&clks IMX6QDL_CLK_UART_SERIAL>; - clock-names = "ipg", "per"; -};
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.yaml b/Documentation/devicetree/bindings/clock/imx6q-clock.yaml new file mode 100644 index 0000000..92a8e54 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.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/imx6q-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX6 Quad + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +properties: + compatible: + const: fsl,imx6q-ccm + + reg: + maxItems: 1 + + interrupts: + description: CCM provides 2 interrupt requests, request 1 is to generate + interrupt for frequency or mux change, request 2 is to generate + interrupt for oscillator read or PLL lock. + items: + - description: CCM interrupt request 1 + - description: CCM interrupt request 2 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: 24m osc + - description: 32k osc + - description: ckih1 clock input + - description: anaclk1 clock input + - description: anaclk2 clock input + + clock-names: + items: + - const: osc + - const: ckil + - const: ckih1 + - const: anaclk1 + - const: anaclk2 + + fsl,pmic-stby-poweroff: + $ref: /schemas/types.yaml#/definitions/flag + description: | + Use this property if the SoC should be powered off by external power + management IC (PMIC) triggered via PMIC_STBY_REQ signal. + Boards that are designed to initiate poweroff on PMIC_ON_REQ signal should + be using "syscon-poweroff" driver instead. + +required: + - compatible + - reg + - interrupts + - '#clock-cells' + +examples: + # Clock Control Module node: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + clock-controller@20c4000 { + compatible = "fsl,imx6q-ccm"; + reg = <0x020c4000 0x4000>; + interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>, + <0 88 IRQ_TYPE_LEVEL_HIGH>; + #clock-cells = <1>; + };
diff --git a/Documentation/devicetree/bindings/clock/imx6sl-clock.txt b/Documentation/devicetree/bindings/clock/imx6sl-clock.txt deleted file mode 100644 index 15e40bd..0000000 --- a/Documentation/devicetree/bindings/clock/imx6sl-clock.txt +++ /dev/null
@@ -1,10 +0,0 @@ -* Clock bindings for Freescale i.MX6 SoloLite - -Required properties: -- compatible: Should be "fsl,imx6sl-ccm" -- reg: Address and length of the register set -- #clock-cells: Should be <1> - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6sl-clock.h -for the full list of i.MX6 SoloLite clock IDs.
diff --git a/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml b/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml new file mode 100644 index 0000000..c97bf95 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml
@@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx6sl-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX6 SoloLite + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +properties: + compatible: + const: fsl,imx6sl-ccm + + reg: + maxItems: 1 + + interrupts: + description: CCM provides 2 interrupt requests, request 1 is to generate + interrupt for frequency or mux change, request 2 is to generate + interrupt for oscillator read or PLL lock. + items: + - description: CCM interrupt request 1 + - description: CCM interrupt request 2 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - interrupts + - '#clock-cells' + +examples: + # Clock Control Module node: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + clock-controller@20c4000 { + compatible = "fsl,imx6sl-ccm"; + reg = <0x020c4000 0x4000>; + interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>, + <0 88 IRQ_TYPE_LEVEL_HIGH>; + #clock-cells = <1>; + };
diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt deleted file mode 100644 index fee849d..0000000 --- a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt +++ /dev/null
@@ -1,36 +0,0 @@ -* Clock bindings for Freescale i.MX6 SLL - -Required properties: -- compatible: Should be "fsl,imx6sll-ccm" -- reg: Address and length of the register set -- #clock-cells: Should be <1> -- clocks: list of clock specifiers, must contain an entry for each required - entry in clock-names -- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1" - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6sll-clock.h -for the full list of i.MX6 SLL clock IDs. - -Examples: - -#include <dt-bindings/clock/imx6sll-clock.h> - -clks: clock-controller@20c4000 { - compatible = "fsl,imx6sll-ccm"; - reg = <0x020c4000 0x4000>; - interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>; - #clock-cells = <1>; - clocks = <&ckil>, <&osc>, <&ipp_di0>, <&ipp_di1>; - clock-names = "ckil", "osc", "ipp_di0", "ipp_di1"; -}; - -uart1: serial@2020000 { - compatible = "fsl,imx6sl-uart", "fsl,imx6q-uart", "fsl,imx21-uart"; - reg = <0x02020000 0x4000>; - interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clks IMX6SLL_CLK_UART1_IPG>, - <&clks IMX6SLL_CLK_UART1_SERIAL>; - clock-names = "ipg", "per"; -};
diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml b/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml new file mode 100644 index 0000000..de48924 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml
@@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx6sll-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX6 SLL + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +properties: + compatible: + const: fsl,imx6sll-ccm + + reg: + maxItems: 1 + + interrupts: + description: CCM provides 2 interrupt requests, request 1 is to generate + interrupt for frequency or mux change, request 2 is to generate + interrupt for oscillator read or PLL lock. + items: + - description: CCM interrupt request 1 + - description: CCM interrupt request 2 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: 32k osc + - description: 24m osc + - description: ipp_di0 clock input + - description: ipp_di1 clock input + + clock-names: + items: + - const: ckil + - const: osc + - const: ipp_di0 + - const: ipp_di1 + +required: + - compatible + - reg + - interrupts + - '#clock-cells' + - clocks + - clock-names + +examples: + # Clock Control Module node: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + clock-controller@20c4000 { + compatible = "fsl,imx6sll-ccm"; + reg = <0x020c4000 0x4000>; + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>; + #clock-cells = <1>; + clocks = <&ckil>, <&osc>, <&ipp_di0>, <&ipp_di1>; + clock-names = "ckil", "osc", "ipp_di0", "ipp_di1"; + };
diff --git a/Documentation/devicetree/bindings/clock/imx6sx-clock.txt b/Documentation/devicetree/bindings/clock/imx6sx-clock.txt deleted file mode 100644 index 22362b9..0000000 --- a/Documentation/devicetree/bindings/clock/imx6sx-clock.txt +++ /dev/null
@@ -1,13 +0,0 @@ -* Clock bindings for Freescale i.MX6 SoloX - -Required properties: -- compatible: Should be "fsl,imx6sx-ccm" -- reg: Address and length of the register set -- #clock-cells: Should be <1> -- clocks: list of clock specifiers, must contain an entry for each required - entry in clock-names -- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1" - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6sx-clock.h -for the full list of i.MX6 SoloX clock IDs.
diff --git a/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml b/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml new file mode 100644 index 0000000..e50cdde --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml
@@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx6sx-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX6 SoloX + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +properties: + compatible: + const: fsl,imx6sx-ccm + + reg: + maxItems: 1 + + interrupts: + description: CCM provides 2 interrupt requests, request 1 is to generate + interrupt for frequency or mux change, request 2 is to generate + interrupt for oscillator read or PLL lock. + items: + - description: CCM interrupt request 1 + - description: CCM interrupt request 2 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: 32k osc + - description: 24m osc + - description: ipp_di0 clock input + - description: ipp_di1 clock input + - description: anaclk1 clock input + - description: anaclk2 clock input + + clock-names: + items: + - const: ckil + - const: osc + - const: ipp_di0 + - const: ipp_di1 + - const: anaclk1 + - const: anaclk2 + +required: + - compatible + - reg + - interrupts + - '#clock-cells' + - clocks + - clock-names + +examples: + # Clock Control Module node: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + clock-controller@20c4000 { + compatible = "fsl,imx6sx-ccm"; + reg = <0x020c4000 0x4000>; + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>; + #clock-cells = <1>; + clocks = <&ckil>, <&osc>, <&ipp_di0>, <&ipp_di1>, <&anaclk1>, <&anaclk2>; + clock-names = "ckil", "osc", "ipp_di0", "ipp_di1", "anaclk1", "anaclk2"; + };
diff --git a/Documentation/devicetree/bindings/clock/imx6ul-clock.txt b/Documentation/devicetree/bindings/clock/imx6ul-clock.txt deleted file mode 100644 index 571d503..0000000 --- a/Documentation/devicetree/bindings/clock/imx6ul-clock.txt +++ /dev/null
@@ -1,13 +0,0 @@ -* Clock bindings for Freescale i.MX6 UltraLite - -Required properties: -- compatible: Should be "fsl,imx6ul-ccm" -- reg: Address and length of the register set -- #clock-cells: Should be <1> -- clocks: list of clock specifiers, must contain an entry for each required - entry in clock-names -- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1" - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6ul-clock.h -for the full list of i.MX6 UltraLite clock IDs.
diff --git a/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml b/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml new file mode 100644 index 0000000..36ce766 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml
@@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx6ul-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX6 UltraLite + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +properties: + compatible: + const: fsl,imx6ul-ccm + + reg: + maxItems: 1 + + interrupts: + description: CCM provides 2 interrupt requests, request 1 is to generate + interrupt for frequency or mux change, request 2 is to generate + interrupt for oscillator read or PLL lock. + items: + - description: CCM interrupt request 1 + - description: CCM interrupt request 2 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: 32k osc + - description: 24m osc + - description: ipp_di0 clock input + - description: ipp_di1 clock input + + clock-names: + items: + - const: ckil + - const: osc + - const: ipp_di0 + - const: ipp_di1 + +required: + - compatible + - reg + - interrupts + - '#clock-cells' + - clocks + - clock-names + +examples: + # Clock Control Module node: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + clock-controller@20c4000 { + compatible = "fsl,imx6ul-ccm"; + reg = <0x020c4000 0x4000>; + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>; + #clock-cells = <1>; + clocks = <&ckil>, <&osc>, <&ipp_di0>, <&ipp_di1>; + clock-names = "ckil", "osc", "ipp_di0", "ipp_di1"; + };
diff --git a/Documentation/devicetree/bindings/clock/imx7d-clock.txt b/Documentation/devicetree/bindings/clock/imx7d-clock.txt deleted file mode 100644 index 9d3026d..0000000 --- a/Documentation/devicetree/bindings/clock/imx7d-clock.txt +++ /dev/null
@@ -1,13 +0,0 @@ -* Clock bindings for Freescale i.MX7 Dual - -Required properties: -- compatible: Should be "fsl,imx7d-ccm" -- reg: Address and length of the register set -- #clock-cells: Should be <1> -- clocks: list of clock specifiers, must contain an entry for each required - entry in clock-names -- clock-names: should include entries "ckil", "osc" - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx7d-clock.h -for the full list of i.MX7 Dual clock IDs.
diff --git a/Documentation/devicetree/bindings/clock/imx7d-clock.yaml b/Documentation/devicetree/bindings/clock/imx7d-clock.yaml new file mode 100644 index 0000000..cefb61d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx7d-clock.yaml
@@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx7d-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX7 Dual + +maintainers: + - Frank Li <Frank.Li@nxp.com> + - Anson Huang <Anson.Huang@nxp.com> + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx7d-clock.h + for the full list of i.MX7 Dual clock IDs. + +properties: + compatible: + const: fsl,imx7d-ccm + + reg: + maxItems: 1 + + interrupts: + items: + - description: CCM interrupt request 1 + - description: CCM interrupt request 2 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: 32k osc + - description: 24m osc + + clock-names: + items: + - const: ckil + - const: osc + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + clock-controller@30380000 { + compatible = "fsl,imx7d-ccm"; + reg = <0x30380000 0x10000>; + interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>; + #clock-cells = <1>; + clocks = <&ckil>, <&osc>; + clock-names = "ckil", "osc"; + };
diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt deleted file mode 100644 index 965cfa4..0000000 --- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt +++ /dev/null
@@ -1,51 +0,0 @@ -* NXP i.MX8QXP LPCG (Low-Power Clock Gating) Clock bindings - -The Low-Power Clock Gate (LPCG) modules contain a local programming -model to control the clock gates for the peripherals. An LPCG module -is used to locally gate the clocks for the associated peripheral. - -Note: -This level of clock gating is provided after the clocks are generated -by the SCU resources and clock controls. Thus even if the clock is -enabled by these control bits, it might still not be running based -on the base resource. - -Required properties: -- compatible: Should be one of: - "fsl,imx8qxp-lpcg-adma", - "fsl,imx8qxp-lpcg-conn", - "fsl,imx8qxp-lpcg-dc", - "fsl,imx8qxp-lpcg-dsp", - "fsl,imx8qxp-lpcg-gpu", - "fsl,imx8qxp-lpcg-hsio", - "fsl,imx8qxp-lpcg-img", - "fsl,imx8qxp-lpcg-lsio", - "fsl,imx8qxp-lpcg-vpu" -- reg: Address and length of the register set -- #clock-cells: Should be <1> - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. -See the full list of clock IDs from: -include/dt-bindings/clock/imx8qxp-clock.h - -Examples: - -#include <dt-bindings/clock/imx8qxp-clock.h> - -conn_lpcg: clock-controller@5b200000 { - compatible = "fsl,imx8qxp-lpcg-conn"; - reg = <0x5b200000 0xb0000>; - #clock-cells = <1>; -}; - -usdhc1: mmc@5b010000 { - compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc"; - interrupt-parent = <&gic>; - interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>; - reg = <0x5b010000 0x10000>; - clocks = <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_IPG_CLK>, - <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_PER_CLK>, - <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_HCLK>; - clock-names = "ipg", "per", "ahb"; -};
diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml new file mode 100644 index 0000000..33f3010 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
@@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx8qxp-lpcg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8QXP LPCG (Low-Power Clock Gating) Clock bindings + +maintainers: + - Aisheng Dong <aisheng.dong@nxp.com> + +description: | + The Low-Power Clock Gate (LPCG) modules contain a local programming + model to control the clock gates for the peripherals. An LPCG module + is used to locally gate the clocks for the associated peripheral. + + This level of clock gating is provided after the clocks are generated + by the SCU resources and clock controls. Thus even if the clock is + enabled by these control bits, it might still not be running based + on the base resource. + + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See the full list of clock IDs from: + include/dt-bindings/clock/imx8-clock.h + +properties: + compatible: + enum: + - fsl,imx8qxp-lpcg-adma + - fsl,imx8qxp-lpcg-conn + - fsl,imx8qxp-lpcg-dc + - fsl,imx8qxp-lpcg-dsp + - fsl,imx8qxp-lpcg-gpu + - fsl,imx8qxp-lpcg-hsio + - fsl,imx8qxp-lpcg-img + - fsl,imx8qxp-lpcg-lsio + - fsl,imx8qxp-lpcg-vpu + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8-clock.h> + #include <dt-bindings/firmware/imx/rsrc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + clock-controller@5b200000 { + compatible = "fsl,imx8qxp-lpcg-conn"; + reg = <0x5b200000 0xb0000>; + #clock-cells = <1>; + }; + + mmc@5b010000 { + compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc"; + interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x5b010000 0x10000>; + clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>, + <&conn_lpcg IMX_CONN_LPCG_SDHC0_PER_CLK>, + <&conn_lpcg IMX_CONN_LPCG_SDHC0_HCLK>; + clock-names = "ipg", "per", "ahb"; + power-domains = <&pd IMX_SC_R_SDHC_0>; + };
diff --git a/Documentation/devicetree/bindings/clock/ingenic,cgu.txt b/Documentation/devicetree/bindings/clock/ingenic,cgu.txt deleted file mode 100644 index 75598e6..0000000 --- a/Documentation/devicetree/bindings/clock/ingenic,cgu.txt +++ /dev/null
@@ -1,57 +0,0 @@ -Ingenic SoC CGU binding - -The CGU in an Ingenic SoC provides all the clocks generated on-chip. It -typically includes a variety of PLLs, multiplexers, dividers & gates in order -to provide many different clock signals derived from only 2 external source -clocks. - -Required properties: -- compatible : Should be one of: - * ingenic,jz4740-cgu - * ingenic,jz4725b-cgu - * ingenic,jz4770-cgu - * ingenic,jz4780-cgu - * ingenic,x1000-cgu -- reg : The address & length of the CGU registers. -- clocks : List of phandle & clock specifiers for clocks external to the CGU. - Two such external clocks should be specified - first the external crystal - "ext" and second the RTC clock source "rtc". -- clock-names : List of name strings for the external clocks. -- #clock-cells: Should be 1. - Clock consumers specify this argument to identify a clock. The valid values - may be found in <dt-bindings/clock/<soctype>-cgu.h>. - -Example SoC include file: - -/ { - cgu: jz4740-cgu { - compatible = "ingenic,jz4740-cgu"; - reg = <0x10000000 0x100>; - #clock-cells = <1>; - }; - - uart0: serial@10030000 { - clocks = <&cgu JZ4740_CLK_UART0>; - }; -}; - -Example board file: - -/ { - ext: clock@0 { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <12000000>; - }; - - rtc: clock@1 { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <32768>; - }; - - &cgu { - clocks = <&ext> <&rtc>; - clock-names: "ext", "rtc"; - }; -};
diff --git a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml new file mode 100644 index 0000000..a952d58 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml
@@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/ingenic,cgu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs CGU devicetree bindings + +description: | + The CGU in an Ingenic SoC provides all the clocks generated on-chip. It + typically includes a variety of PLLs, multiplexers, dividers & gates in order + to provide many different clock signals derived from only 2 external source + clocks. + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +select: + properties: + compatible: + contains: + enum: + - ingenic,jz4740-cgu + - ingenic,jz4725b-cgu + - ingenic,jz4770-cgu + - ingenic,jz4780-cgu + - ingenic,x1000-cgu + - ingenic,x1830-cgu + required: + - compatible + +properties: + $nodename: + pattern: "^clock-controller@[0-9a-f]+$" + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + "#clock-cells": + const: 1 + + ranges: true + + compatible: + items: + - enum: + - ingenic,jz4740-cgu + - ingenic,jz4725b-cgu + - ingenic,jz4770-cgu + - ingenic,jz4780-cgu + - ingenic,x1000-cgu + - ingenic,x1830-cgu + - const: simple-mfd + minItems: 1 + + reg: + maxItems: 1 + + clocks: + items: + - description: External oscillator clock + - description: Internal 32 kHz RTC clock + + clock-names: + items: + - const: ext + - enum: + - rtc + - osc32k # Different name, same clock + + assigned-clocks: + minItems: 1 + maxItems: 64 + + assigned-clock-parents: + minItems: 1 + maxItems: 64 + + assigned-clock-rates: + minItems: 1 + maxItems: 64 + +required: + - "#clock-cells" + - compatible + - reg + - clocks + - clock-names + +patternProperties: + "^usb-phy@[a-f0-9]+$": + allOf: [ $ref: "../usb/ingenic,jz4770-phy.yaml#" ] + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/jz4770-cgu.h> + cgu: clock-controller@10000000 { + compatible = "ingenic,jz4770-cgu", "simple-mfd"; + reg = <0x10000000 0x100>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x10000000 0x100>; + + clocks = <&ext>, <&osc32k>; + clock-names = "ext", "osc32k"; + + #clock-cells = <1>; + + otg_phy: usb-phy@3c { + compatible = "ingenic,jz4770-phy"; + reg = <0x3c 0x10>; + + clocks = <&cgu JZ4770_CLK_OTG_PHY>; + + vcc-supply = <&ldo5>; + + #phy-cells = <0>; + }; + };
diff --git a/Documentation/devicetree/bindings/clock/intel,agilex.yaml b/Documentation/devicetree/bindings/clock/intel,agilex.yaml new file mode 100644 index 0000000..cf5a9eb --- /dev/null +++ b/Documentation/devicetree/bindings/clock/intel,agilex.yaml
@@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/intel,agilex.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel SoCFPGA Agilex platform clock controller binding + +maintainers: + - Dinh Nguyen <dinguyen@kernel.org> + +description: + The Intel Agilex Clock controller is an integrated clock controller, which + generates and supplies to all modules. + +properties: + compatible: + const: intel,agilex-clkmgr + + '#clock-cells': + const: 1 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - '#clock-cells' + +additionalProperties: false + +examples: + # Clock controller node: + - | + clkmgr: clock-controller@ffd10000 { + compatible = "intel,agilex-clkmgr"; + reg = <0xffd10000 0x1000>; + clocks = <&osc1>; + #clock-cells = <1>; + }; +...
diff --git a/Documentation/devicetree/bindings/clock/intel,cgu-lgm.yaml b/Documentation/devicetree/bindings/clock/intel,cgu-lgm.yaml new file mode 100644 index 0000000..6dc1414 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/intel,cgu-lgm.yaml
@@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/intel,cgu-lgm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel Lightning Mountain SoC's Clock Controller(CGU) Binding + +maintainers: + - Rahul Tanwar <rahul.tanwar@linux.intel.com> + +description: | + Lightning Mountain(LGM) SoC's Clock Generation Unit(CGU) driver provides + all means to access the CGU hardware module in order to generate a series + of clocks for the whole system and individual peripherals. + + Please refer to include/dt-bindings/clock/intel,lgm-clk.h header file, it + defines all available clocks as macros. These macros can be used in device + tree sources. + +properties: + compatible: + const: intel,cgu-lgm + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +examples: + - | + cgu: clock-controller@e0200000 { + compatible = "intel,cgu-lgm"; + reg = <0xe0200000 0x33c>; + #clock-cells = <1>; + }; + +...
diff --git a/Documentation/devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml new file mode 100644 index 0000000..dffa734 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/marvell,mmp2-audio-clock.yaml
@@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/marvell,mmp2-audio-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell MMP2 Audio Clock Controller + +maintainers: + - Lubomir Rintel <lkundrak@v3.sk> + +description: | + The audio clock controller generates and supplies the clocks to the audio + codec. + + Each clock is assigned an identifier and client nodes use this identifier + to specify the clock which they consume. + + All these identifiers could be found in + <dt-bindings/clock/marvell,mmp2-audio.h>. + +properties: + compatible: + enum: + - marvell,mmp2-audio-clock + + reg: + maxItems: 1 + + clocks: + items: + - description: Audio subsystem clock + - description: The crystal oscillator clock + - description: First I2S clock + - description: Second I2S clock + + clock-names: + items: + - const: audio + - const: vctcxo + - const: i2s0 + - const: i2s1 + + '#clock-cells': + const: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/marvell,mmp2-audio.h> + #include <dt-bindings/clock/marvell,mmp2.h> + #include <dt-bindings/power/marvell,mmp2.h> + + clock-controller@d42a0c30 { + compatible = "marvell,mmp2-audio-clock"; + reg = <0xd42a0c30 0x10>; + clock-names = "audio", "vctcxo", "i2s0", "i2s1"; + clocks = <&soc_clocks MMP2_CLK_AUDIO>, + <&soc_clocks MMP2_CLK_VCTCXO>, + <&soc_clocks MMP2_CLK_I2S0>, + <&soc_clocks MMP2_CLK_I2S1>; + power-domains = <&soc_clocks MMP2_POWER_DOMAIN_AUDIO>; + #clock-cells = <1>; + };
diff --git a/Documentation/devicetree/bindings/clock/marvell,mmp2-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,mmp2-clock.yaml index e2b6ac9..d68f0d1 100644 --- a/Documentation/devicetree/bindings/clock/marvell,mmp2-clock.yaml +++ b/Documentation/devicetree/bindings/clock/marvell,mmp2-clock.yaml
@@ -42,12 +42,16 @@ '#reset-cells': const: 1 + '#power-domain-cells': + const: 1 + required: - compatible - reg - reg-names - '#clock-cells' - '#reset-cells' + - '#power-domain-cells' additionalProperties: false @@ -61,4 +65,5 @@ reg-names = "mpmu", "apmu", "apbc"; #clock-cells = <1>; #reset-cells = <1>; + #power-domain-cells = <1>; };
diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.txt b/Documentation/devicetree/bindings/clock/qcom,a53pll.txt deleted file mode 100644 index e3fa811..0000000 --- a/Documentation/devicetree/bindings/clock/qcom,a53pll.txt +++ /dev/null
@@ -1,22 +0,0 @@ -Qualcomm MSM8916 A53 PLL Binding --------------------------------- -The A53 PLL on MSM8916 platforms is the main CPU PLL used used for frequencies -above 1GHz. - -Required properties : -- compatible : Shall contain only one of the following: - - "qcom,msm8916-a53pll" - -- reg : shall contain base register location and length - -- #clock-cells : must be set to <0> - -Example: - - a53pll: clock@b016000 { - compatible = "qcom,msm8916-a53pll"; - reg = <0xb016000 0x40>; - #clock-cells = <0>; - }; -
diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml new file mode 100644 index 0000000..20d2638 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
@@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,a53pll.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm A53 PLL Binding + +maintainers: + - Sivaprakash Murugesan <sivaprak@codeaurora.org> + +description: + The A53 PLL on few Qualcomm platforms is the main CPU PLL used used for + frequencies above 1GHz. + +properties: + compatible: + const: qcom,msm8916-a53pll + + reg: + maxItems: 1 + + '#clock-cells': + const: 0 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + #Example 1 - A53 PLL found on MSM8916 devices + - | + a53pll: clock@b016000 { + compatible = "qcom,msm8916-a53pll"; + reg = <0xb016000 0x40>; + #clock-cells = <0>; + };
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml index a345320..a404c8f 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml
@@ -65,7 +65,7 @@ #include <dt-bindings/clock/qcom,rpmh.h> clock-controller@100000 { compatible = "qcom,gcc-sc7180"; - reg = <0 0x00100000 0 0x1f0000>; + reg = <0x00100000 0x1f0000>; clocks = <&rpmhcc RPMH_CXO_CLK>, <&rpmhcc RPMH_CXO_CLK_A>, <&sleep_clk>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml index 36f3b36..12766a8 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml
@@ -63,7 +63,7 @@ #include <dt-bindings/clock/qcom,rpmh.h> clock-controller@100000 { compatible = "qcom,gcc-sm8150"; - reg = <0 0x00100000 0 0x1f0000>; + reg = <0x00100000 0x1f0000>; clocks = <&rpmhcc RPMH_CXO_CLK>, <&sleep_clk>; clock-names = "bi_tcxo", "sleep_clk";
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml index 2c40a8a..a5766ff 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml
@@ -61,7 +61,7 @@ #include <dt-bindings/clock/qcom,rpmh.h> clock-controller@100000 { compatible = "qcom,gcc-sm8250"; - reg = <0 0x00100000 0 0x1f0000>; + reg = <0x00100000 0x1f0000>; clocks = <&rpmhcc RPMH_CXO_CLK>, <&sleep_clk>; clock-names = "bi_tcxo", "sleep_clk";
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml index e533bb0..ee0467f 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml
@@ -22,6 +22,8 @@ - dt-bindings/reset/qcom,gcc-ipq6018.h - dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) - dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) + - dt-bindings/clock/qcom,gcc-msm8939.h + - dt-bindings/reset/qcom,gcc-msm8939.h - dt-bindings/clock/qcom,gcc-msm8660.h - dt-bindings/reset/qcom,gcc-msm8660.h - dt-bindings/clock/qcom,gcc-msm8974.h @@ -41,6 +43,7 @@ - qcom,gcc-ipq8064 - qcom,gcc-msm8660 - qcom,gcc-msm8916 + - qcom,gcc-msm8939 - qcom,gcc-msm8960 - qcom,gcc-msm8974 - qcom,gcc-msm8974pro
diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml index f684fe6..1b16a86 100644 --- a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
@@ -15,15 +15,15 @@ power domains. properties: - compatible : + compatible: enum: - - qcom,mmcc-apq8064 - - qcom,mmcc-apq8084 - - qcom,mmcc-msm8660 - - qcom,mmcc-msm8960 - - qcom,mmcc-msm8974 - - qcom,mmcc-msm8996 - - qcom,mmcc-msm8998 + - qcom,mmcc-apq8064 + - qcom,mmcc-apq8084 + - qcom,mmcc-msm8660 + - qcom,mmcc-msm8960 + - qcom,mmcc-msm8974 + - qcom,mmcc-msm8996 + - qcom,mmcc-msm8998 clocks: items: @@ -67,6 +67,10 @@ description: Protected clock specifier list as per common clock binding + vdd-gfx-supply: + description: + Regulator supply for the GPU_GX GDSC + required: - compatible - reg
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml index 58cdfd59..e94847f 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml
@@ -66,7 +66,7 @@ #include <dt-bindings/clock/qcom,rpmh.h> clock-controller@af00000 { compatible = "qcom,sc7180-dispcc"; - reg = <0 0x0af00000 0 0x200000>; + reg = <0x0af00000 0x200000>; clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_DISP_GPLL0_CLK_SRC>, <&dsi_phy 0>,
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml index 8635e35..fe08461f 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml
@@ -60,7 +60,7 @@ #include <dt-bindings/clock/qcom,rpmh.h> clock-controller@5090000 { compatible = "qcom,sc7180-gpucc"; - reg = <0 0x05090000 0 0x9000>; + reg = <0x05090000 0x9000>; clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPU_GPLL0_CLK_SRC>, <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml index 0dd5d25..9700309 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml
@@ -50,7 +50,7 @@ #include <dt-bindings/clock/qcom,gcc-sc7180.h> clock-controller@41a8000 { compatible = "qcom,sc7180-mss"; - reg = <0 0x041a8000 0 0x8000>; + reg = <0x041a8000 0x8000>; clocks = <&gcc GCC_MSS_MFAB_AXIS_CLK>, <&gcc GCC_MSS_NAV_AXI_CLK>, <&gcc GCC_MSS_CFG_AHB_CLK>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-videocc.yaml index 0071b97..2feea2b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7180-videocc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-videocc.yaml
@@ -55,7 +55,7 @@ #include <dt-bindings/clock/qcom,rpmh.h> clock-controller@ab00000 { compatible = "qcom,sc7180-videocc"; - reg = <0 0x0ab00000 0 0x10000>; + reg = <0x0ab00000 0x10000>; clocks = <&rpmhcc RPMH_CXO_CLK>; clock-names = "bi_tcxo"; #clock-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml index ad47d74..4a3be73 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml
@@ -75,7 +75,7 @@ #include <dt-bindings/clock/qcom,rpmh.h> clock-controller@af00000 { compatible = "qcom,sdm845-dispcc"; - reg = <0 0x0af00000 0 0x10000>; + reg = <0x0af00000 0x10000>; clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_DISP_GPLL0_CLK_SRC>, <&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>,
diff --git a/Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml index 7a052ac..8a0c576 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml
@@ -60,7 +60,7 @@ #include <dt-bindings/clock/qcom,rpmh.h> clock-controller@5090000 { compatible = "qcom,sdm845-gpucc"; - reg = <0 0x05090000 0 0x9000>; + reg = <0x05090000 0x9000>; clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPU_GPLL0_CLK_SRC>, <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,sdm845-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdm845-videocc.yaml index 2a6a81a..f7a0cf5 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sdm845-videocc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sdm845-videocc.yaml
@@ -55,7 +55,7 @@ #include <dt-bindings/clock/qcom,rpmh.h> clock-controller@ab00000 { compatible = "qcom,sdm845-videocc"; - reg = <0 0x0ab00000 0 0x10000>; + reg = <0x0ab00000 0x10000>; clocks = <&rpmhcc RPMH_CXO_CLK>; clock-names = "bi_tcxo"; #clock-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml new file mode 100644 index 0000000..c55a7c4 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml
@@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/renesas,cpg-div6-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas CPG DIV6 Clock + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: + The CPG DIV6 clocks are variable factor clocks provided by the Clock Pulse + Generator (CPG). Their clock input is divided by a configurable factor from 1 + to 64. + +properties: + compatible: + items: + - enum: + - renesas,r8a73a4-div6-clock # R-Mobile APE6 + - renesas,r8a7740-div6-clock # R-Mobile A1 + - renesas,sh73a0-div6-clock # SH-Mobile AG5 + - const: renesas,cpg-div6-clock + + reg: + maxItems: 1 + + clocks: + oneOf: + - maxItems: 1 + - maxItems: 4 + - maxItems: 8 + description: + For clocks with multiple parents, invalid settings must be specified as + "<0>". + + '#clock-cells': + const: 0 + + clock-output-names: true + +required: + - compatible + - reg + - clocks + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a73a4-clock.h> + sdhi2_clk: sdhi2_clk@e615007c { + compatible = "renesas,r8a73a4-div6-clock", "renesas,cpg-div6-clock"; + reg = <0xe615007c 4>; + clocks = <&pll1_div2_clk>, <&cpg_clocks R8A73A4_CLK_PLL2S>, <0>, + <&extal2_clk>; + #clock-cells = <0>; + };
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt deleted file mode 100644 index ae36ab8..0000000 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt +++ /dev/null
@@ -1,40 +0,0 @@ -* Renesas CPG DIV6 Clock - -The CPG DIV6 clocks are variable factor clocks provided by the Clock Pulse -Generator (CPG). Their clock input is divided by a configurable factor from 1 -to 64. - -Required Properties: - - - compatible: Must be one of the following - - "renesas,r8a73a4-div6-clock" for R8A73A4 (R-Mobile APE6) DIV6 clocks - - "renesas,r8a7740-div6-clock" for R8A7740 (R-Mobile A1) DIV6 clocks - - "renesas,r8a7790-div6-clock" for R8A7790 (R-Car H2) DIV6 clocks - - "renesas,r8a7791-div6-clock" for R8A7791 (R-Car M2-W) DIV6 clocks - - "renesas,r8a7793-div6-clock" for R8A7793 (R-Car M2-N) DIV6 clocks - - "renesas,r8a7794-div6-clock" for R8A7794 (R-Car E2) DIV6 clocks - - "renesas,sh73a0-div6-clock" for SH73A0 (SH-Mobile AG5) DIV6 clocks - and "renesas,cpg-div6-clock" as a fallback. - - reg: Base address and length of the memory resource used by the DIV6 clock - - clocks: Reference to the parent clock(s); either one, four, or eight - clocks must be specified. For clocks with multiple parents, invalid - settings must be specified as "<0>". - - #clock-cells: Must be 0 - - -Optional Properties: - - - clock-output-names: The name of the clock as a free-form string - - -Example -------- - - sdhi2_clk: sdhi2_clk@e615007c { - compatible = "renesas,r8a73a4-div6-clock", "renesas,cpg-div6-clock"; - reg = <0 0xe615007c 0 4>; - clocks = <&pll1_div2_clk>, <&cpg_clocks R8A73A4_CLK_PLL2S>, - <0>, <&extal2_clk>; - #clock-cells = <0>; - clock-output-names = "sdhi2ck"; - };
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml index 9cd102e..c745bd6 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml
@@ -25,6 +25,7 @@ compatible: enum: - renesas,r7s9210-cpg-mssr # RZ/A2 + - renesas,r8a7742-cpg-mssr # RZ/G1H - renesas,r8a7743-cpg-mssr # RZ/G1M - renesas,r8a7744-cpg-mssr # RZ/G1N - renesas,r8a7745-cpg-mssr # RZ/G1E
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt deleted file mode 100644 index da578eb..0000000 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt +++ /dev/null
@@ -1,60 +0,0 @@ -* Renesas CPG Module Stop (MSTP) Clocks - -The CPG can gate SoC device clocks. The gates are organized in groups of up to -32 gates. - -This device tree binding describes a single 32 gate clocks group per node. -Clocks are referenced by user nodes by the MSTP node phandle and the clock -index in the group, from 0 to 31. - -Required Properties: - - - compatible: Must be one of the following - - "renesas,r7s72100-mstp-clocks" for R7S72100 (RZ) MSTP gate clocks - - "renesas,r8a73a4-mstp-clocks" for R8A73A4 (R-Mobile APE6) MSTP gate clocks - - "renesas,r8a7740-mstp-clocks" for R8A7740 (R-Mobile A1) MSTP gate clocks - - "renesas,r8a7778-mstp-clocks" for R8A7778 (R-Car M1) MSTP gate clocks - - "renesas,r8a7779-mstp-clocks" for R8A7779 (R-Car H1) MSTP gate clocks - - "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks - - "renesas,r8a7791-mstp-clocks" for R8A7791 (R-Car M2-W) MSTP gate clocks - - "renesas,r8a7792-mstp-clocks" for R8A7792 (R-Car V2H) MSTP gate clocks - - "renesas,r8a7793-mstp-clocks" for R8A7793 (R-Car M2-N) MSTP gate clocks - - "renesas,r8a7794-mstp-clocks" for R8A7794 (R-Car E2) MSTP gate clocks - - "renesas,sh73a0-mstp-clocks" for SH73A0 (SH-MobileAG5) MSTP gate clocks - and "renesas,cpg-mstp-clocks" as a fallback. - - reg: Base address and length of the I/O mapped registers used by the MSTP - clocks. The first register is the clock control register and is mandatory. - The second register is the clock status register and is optional when not - implemented in hardware. - - clocks: Reference to the parent clocks, one per output clock. The parents - must appear in the same order as the output clocks. - - #clock-cells: Must be 1 - - clock-output-names: The name of the clocks as free-form strings - - clock-indices: Indices of the gate clocks into the group (0 to 31) - -The clocks, clock-output-names and clock-indices properties contain one entry -per gate clock. The MSTP groups are sparsely populated. Unimplemented gate -clocks must not be declared. - - -Example -------- - - #include <dt-bindings/clock/r8a7790-clock.h> - - mstp3_clks: mstp3_clks@e615013c { - compatible = "renesas,r8a7790-mstp-clocks", "renesas,cpg-mstp-clocks"; - reg = <0 0xe615013c 0 4>, <0 0xe6150048 0 4>; - clocks = <&cp_clk>, <&mmc1_clk>, <&sd3_clk>, <&sd2_clk>, - <&cpg_clocks R8A7790_CLK_SD1>, <&cpg_clocks R8A7790_CLK_SD0>, - <&mmc0_clk>; - #clock-cells = <1>; - clock-output-names = - "tpu0", "mmcif1", "sdhi3", "sdhi2", - "sdhi1", "sdhi0", "mmcif0"; - clock-indices = < - R8A7790_CLK_TPU0 R8A7790_CLK_MMCIF1 R8A7790_CLK_SDHI3 - R8A7790_CLK_SDHI2 R8A7790_CLK_SDHI1 R8A7790_CLK_SDHI0 - R8A7790_CLK_MMCIF0 - >; - };
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.yaml new file mode 100644 index 0000000..9752ac6 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.yaml
@@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/renesas,cpg-mstp-clocks.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas Clock Pulse Generator (CPG) Module Stop (MSTP) Clocks + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: + The Clock Pulse Generator (CPG) can gate SoC device clocks. The gates are + organized in groups of up to 32 gates. + + This device tree binding describes a single 32 gate clocks group per node. + Clocks are referenced by user nodes by the Module Stop (MSTP) node phandle + and the clock index in the group, from 0 to 31. + +properties: + compatible: + items: + - enum: + - renesas,r7s72100-mstp-clocks # RZ/A1 + - renesas,r8a73a4-mstp-clocks # R-Mobile APE6 + - renesas,r8a7740-mstp-clocks # R-Mobile A1 + - renesas,r8a7778-mstp-clocks # R-Car M1 + - renesas,r8a7779-mstp-clocks # R-Car H1 + - renesas,sh73a0-mstp-clocks # SH-Mobile AG5 + - const: renesas,cpg-mstp-clocks + + reg: + minItems: 1 + items: + - description: Module Stop Control Register (MSTPCR) + - description: Module Stop Status Register (MSTPSR) + + clocks: + minItems: 1 + maxItems: 32 + + '#clock-cells': + const: 1 + + clock-indices: + minItems: 1 + maxItems: 32 + + clock-output-names: + minItems: 1 + maxItems: 32 + +required: + - compatible + - reg + - clocks + - '#clock-cells' + - clock-indices + - clock-output-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a73a4-clock.h> + mstp2_clks: mstp2_clks@e6150138 { + compatible = "renesas,r8a73a4-mstp-clocks", + "renesas,cpg-mstp-clocks"; + reg = <0xe6150138 4>, <0xe6150040 4>; + clocks = <&mp_clk>, <&mp_clk>, <&mp_clk>, <&mp_clk>, <&mp_clk>, + <&mp_clk>, <&cpg_clocks R8A73A4_CLK_HP>; + #clock-cells = <1>; + clock-indices = < + R8A73A4_CLK_SCIFA0 R8A73A4_CLK_SCIFA1 + R8A73A4_CLK_SCIFB0 R8A73A4_CLK_SCIFB1 + R8A73A4_CLK_SCIFB2 R8A73A4_CLK_SCIFB3 + R8A73A4_CLK_DMAC + >; + clock-output-names = + "scifa0", "scifa1", "scifb0", "scifb1", "scifb2", "scifb3", + "dmac"; + };
diff --git a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt index 4bf6f53..da92f57 100644 --- a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt +++ b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt
@@ -27,7 +27,9 @@ - compatible: "renesas,r8a7795-rcar-usb2-clock-sel" if the device is a part of an R8A7795 SoC. "renesas,r8a7796-rcar-usb2-clock-sel" if the device if a part of - an R8A7796 SoC. + an R8A77960 SoC. + "renesas,r8a77961-rcar-usb2-clock-sel" if the device if a part of + an R8A77961 SoC. "renesas,rcar-gen3-usb2-clock-sel" for a generic R-Car Gen3 compatible device.
diff --git a/Documentation/devicetree/bindings/clock/silabs,si5341.txt b/Documentation/devicetree/bindings/clock/silabs,si5341.txt index a70c333..504cce3 100644 --- a/Documentation/devicetree/bindings/clock/silabs,si5341.txt +++ b/Documentation/devicetree/bindings/clock/silabs,si5341.txt
@@ -1,15 +1,21 @@ -Binding for Silicon Labs Si5341 and Si5340 programmable i2c clock generator. +Binding for Silicon Labs Si5340, Si5341 Si5342, Si5344 and Si5345 programmable +i2c clock generator. Reference [1] Si5341 Data Sheet https://www.silabs.com/documents/public/data-sheets/Si5341-40-D-DataSheet.pdf [2] Si5341 Reference Manual https://www.silabs.com/documents/public/reference-manuals/Si5341-40-D-RM.pdf +[3] Si5345 Reference Manual + https://www.silabs.com/documents/public/reference-manuals/Si5345-44-42-D-RM.pdf The Si5341 and Si5340 are programmable i2c clock generators with up to 10 output clocks. The chip contains a PLL that sources 5 (or 4) multisynth clocks, which in turn can be directed to any of the 10 (or 4) outputs through a divider. The internal structure of the clock generators can be found in [2]. +The Si5345 is similar to the Si5341 with the addition of fractional input +dividers and automatic input selection, as described in [3]. +The Si5342 and Si5344 are smaller versions of the Si5345, with 2 or 4 outputs. The driver can be used in "as is" mode, reading the current settings from the chip at boot, in case you have a (pre-)programmed device. If the PLL is not @@ -28,6 +34,9 @@ - compatible: shall be one of the following: "silabs,si5340" - Si5340 A/B/C/D "silabs,si5341" - Si5341 A/B/C/D + "silabs,si5342" - Si5342 A/B/C/D + "silabs,si5344" - Si5344 A/B/C/D + "silabs,si5345" - Si5345 A/B/C/D - reg: i2c device address, usually 0x74 - #clock-cells: from common clock binding; shall be set to 2. The first value is "0" for outputs, "1" for synthesizers.
diff --git a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml index bb3a78d..2981387 100644 --- a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml +++ b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml
@@ -28,6 +28,7 @@ - sprd,sc9863a-rpll - sprd,sc9863a-dpll - sprd,sc9863a-mm-gate + - sprd,sc9863a-mm-clk - sprd,sc9863a-apapb-gate clocks: @@ -76,29 +77,24 @@ - | ap_clk: clock-controller@21500000 { compatible = "sprd,sc9863a-ap-clk"; - reg = <0 0x21500000 0 0x1000>; + reg = <0x21500000 0x1000>; clocks = <&ext_26m>, <&ext_32k>; clock-names = "ext-26m", "ext-32k"; #clock-cells = <1>; }; - | - soc { - #address-cells = <2>; - #size-cells = <2>; + syscon@20e00000 { + compatible = "sprd,sc9863a-glbregs", "syscon", "simple-mfd"; + reg = <0x20e00000 0x4000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x20e00000 0x4000>; - ap_ahb_regs: syscon@20e00000 { - compatible = "sprd,sc9863a-glbregs", "syscon", "simple-mfd"; - reg = <0 0x20e00000 0 0x4000>; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0 0x20e00000 0x4000>; - - apahb_gate: apahb-gate@0 { - compatible = "sprd,sc9863a-apahb-gate"; - reg = <0x0 0x1020>; - #clock-cells = <1>; - }; + apahb_gate: apahb-gate@0 { + compatible = "sprd,sc9863a-apahb-gate"; + reg = <0x0 0x1020>; + #clock-cells = <1>; }; };
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 4638d7a..9bd52e6 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -15,10 +15,15 @@ properties: compatible: - enum: - - usb-a-connector - - usb-b-connector - - usb-c-connector + oneOf: + - enum: + - usb-a-connector + - usb-b-connector + - usb-c-connector + + - items: + - const: gpio-usb-b-connector + - const: usb-b-connector label: description: Symbolic name for the connector. @@ -27,8 +32,8 @@ description: Size of the connector, should be specified in case of non-fullsize 'usb-a-connector' or 'usb-b-connector' compatible connectors. - allOf: - - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#definitions/string + enum: - mini - micro @@ -57,8 +62,8 @@ power-role: description: Determines the power role that the Type C connector will support. "dual" refers to Dual Role Port (DRP). - allOf: - - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#definitions/string + enum: - source - sink @@ -66,18 +71,18 @@ try-power-role: description: Preferred power role. - allOf: - - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#definitions/string + enum: - - source - - sink - - dual + - source + - sink + - dual data-role: description: Data role if Type C connector supports USB data. "dual" refers Dual Role Device (DRD). - allOf: - - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#definitions/string + enum: - host - device @@ -95,8 +100,7 @@ defined in dt-bindings/usb/pd.h. minItems: 1 maxItems: 7 - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array sink-pdos: description: An array of u32 with each entry providing supported power sink @@ -108,8 +112,7 @@ in dt-bindings/usb/pd.h. minItems: 1 maxItems: 7 - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array op-sink-microwatt: description: Sink required operating power in microwatt, if source can't @@ -142,9 +145,22 @@ required: - compatible +allOf: + - if: + properties: + compatible: + contains: + const: gpio-usb-b-connector + then: + anyOf: + - required: + - vbus-gpios + - required: + - id-gpios + examples: # Micro-USB connector with HS lines routed via controller (MUIC). - - |+ + - | muic-max77843 { usb_con1: connector { compatible = "usb-b-connector"; @@ -156,7 +172,7 @@ # USB-C connector attached to CC controller (s2mm005), HS lines routed # to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort. # DisplayPort video lines are routed to the connector via SS mux in USB3 PHY. - - |+ + - | ccic: s2mm005 { usb_con2: connector { compatible = "usb-c-connector"; @@ -190,7 +206,7 @@ # USB-C connector attached to a typec port controller(ptn5110), which has # power delivery support and enables drp. - - |+ + - | #include <dt-bindings/usb/pd.h> typec: ptn5110 { usb_con3: connector { @@ -204,3 +220,16 @@ op-sink-microwatt = <10000000>; }; }; + + # USB connector with GPIO control lines + - | + #include <dt-bindings/gpio/gpio.h> + + usb { + connector { + compatible = "gpio-usb-b-connector", "usb-b-connector"; + type = "micro"; + id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>; + vbus-supply = <&usb_p0_vbus>; + }; + };
diff --git a/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt new file mode 100644 index 0000000..daeca6a --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
@@ -0,0 +1,56 @@ +Binding for NVIDIA Tegra20 CPUFreq +================================== + +Required properties: +- clocks: Must contain an entry for the CPU clock. + See ../clocks/clock-bindings.txt for details. +- operating-points-v2: See ../bindings/opp/opp.txt for details. +- #cooling-cells: Should be 2. See ../thermal/thermal.txt for details. + +For each opp entry in 'operating-points-v2' table: +- opp-supported-hw: Two bitfields indicating: + On Tegra20: + 1. CPU process ID mask + 2. SoC speedo ID mask + + On Tegra30: + 1. CPU process ID mask + 2. CPU speedo ID mask + + A bitwise AND is performed against these values and if any bit + matches, the OPP gets enabled. + +- opp-microvolt: CPU voltage triplet. + +Optional properties: +- cpu-supply: Phandle to the CPU power supply. + +Example: + regulators { + cpu_reg: regulator0 { + regulator-name = "vdd_cpu"; + }; + }; + + cpu0_opp_table: opp_table0 { + compatible = "operating-points-v2"; + + opp@456000000 { + clock-latency-ns = <125000>; + opp-microvolt = <825000 825000 1125000>; + opp-supported-hw = <0x03 0x0001>; + opp-hz = /bits/ 64 <456000000>; + }; + + ... + }; + + cpus { + cpu@0 { + compatible = "arm,cortex-a9"; + clocks = <&tegra_car TEGRA20_CLK_CCLK>; + operating-points-v2 = <&cpu0_opp_table>; + cpu-supply = <&cpu_reg>; + #cooling-cells = <2>; + }; + };
diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml index 8b9a8f3..fc82357 100644 --- a/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml +++ b/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml
@@ -15,16 +15,16 @@ oneOf: - const: allwinner,sun4i-a10-crypto - items: - - const: allwinner,sun5i-a13-crypto - - const: allwinner,sun4i-a10-crypto + - const: allwinner,sun5i-a13-crypto + - const: allwinner,sun4i-a10-crypto - items: - - const: allwinner,sun6i-a31-crypto - - const: allwinner,sun4i-a10-crypto + - const: allwinner,sun6i-a31-crypto + - const: allwinner,sun4i-a10-crypto - items: - - const: allwinner,sun7i-a20-crypto - - const: allwinner,sun4i-a10-crypto + - const: allwinner,sun7i-a20-crypto + - const: allwinner,sun4i-a10-crypto - items: - - const: allwinner,sun8i-a33-crypto + - const: allwinner,sun8i-a33-crypto reg: maxItems: 1
diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml index 2c459b8..7a60d84 100644 --- a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml +++ b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
@@ -50,16 +50,16 @@ const: allwinner,sun50i-h6-crypto then: properties: - clocks: - minItems: 3 - clock-names: - minItems: 3 + clocks: + minItems: 3 + clock-names: + minItems: 3 else: properties: - clocks: - maxItems: 2 - clock-names: - maxItems: 2 + clocks: + maxItems: 2 + clock-names: + maxItems: 2 required: - compatible
diff --git a/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml b/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml index 5becc60..ecf98a9 100644 --- a/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml +++ b/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml
@@ -12,7 +12,7 @@ properties: compatible: items: - - const: amlogic,gxl-crypto + - const: amlogic,gxl-crypto reg: maxItems: 1 @@ -45,7 +45,7 @@ crypto: crypto-engine@c883e000 { compatible = "amlogic,gxl-crypto"; - reg = <0x0 0xc883e000 0x0 0x36>; + reg = <0xc883e000 0x36>; interrupts = <GIC_SPI 188 IRQ_TYPE_EDGE_RISING>, <GIC_SPI 189 IRQ_TYPE_EDGE_RISING>; clocks = <&clkc CLKID_BLKMV>; clock-names = "blkmv";
diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml index 57ae1c0..6dd658f 100644 --- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml +++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
@@ -36,11 +36,10 @@ dma-maxburst: description: Set number of maximum dma burst supported - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - - maximum: 2 - - default: 0 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 2 + default: 0 required: - compatible
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml index 944ff2f..e77523b 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml
@@ -66,10 +66,9 @@ - allwinner,sun50i-h6-display-engine allwinner,pipelines: - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle-array - - minItems: 1 - maxItems: 2 + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 2 description: | Available display engine frontends (DE 1.0) or mixers (DE 2.0/3.0) available.
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml index 5d4915a..75e6479 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml
@@ -21,8 +21,8 @@ - const: allwinner,sun5i-a10s-hdmi - const: allwinner,sun6i-a31-hdmi - items: - - const: allwinner,sun7i-a20-hdmi - - const: allwinner,sun5i-a10s-hdmi + - const: allwinner,sun7i-a20-hdmi + - const: allwinner,sun5i-a10s-hdmi reg: maxItems: 1 @@ -33,32 +33,32 @@ clocks: oneOf: - items: - - description: The HDMI interface clock - - description: The HDMI module clock - - description: The first video PLL - - description: The second video PLL + - description: The HDMI interface clock + - description: The HDMI module clock + - description: The first video PLL + - description: The second video PLL - items: - - description: The HDMI interface clock - - description: The HDMI module clock - - description: The HDMI DDC clock - - description: The first video PLL - - description: The second video PLL + - description: The HDMI interface clock + - description: The HDMI module clock + - description: The HDMI DDC clock + - description: The first video PLL + - description: The second video PLL clock-names: oneOf: - items: - - const: ahb - - const: mod - - const: pll-0 - - const: pll-1 + - const: ahb + - const: mod + - const: pll-0 + - const: pll-1 - items: - - const: ahb - - const: mod - - const: ddc - - const: pll-0 - - const: pll-1 + - const: ahb + - const: mod + - const: ddc + - const: pll-0 + - const: pll-1 resets: maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml index e5344c4..4c15a26 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
@@ -35,26 +35,26 @@ - const: allwinner,sun9i-a80-tcon-tv - items: - - enum: - - allwinner,sun7i-a20-tcon0 - - allwinner,sun7i-a20-tcon1 - - const: allwinner,sun7i-a20-tcon + - enum: + - allwinner,sun7i-a20-tcon0 + - allwinner,sun7i-a20-tcon1 + - const: allwinner,sun7i-a20-tcon - items: - - enum: - - allwinner,sun50i-a64-tcon-lcd - - const: allwinner,sun8i-a83t-tcon-lcd + - enum: + - allwinner,sun50i-a64-tcon-lcd + - const: allwinner,sun8i-a83t-tcon-lcd - items: - - enum: - - allwinner,sun8i-h3-tcon-tv - - allwinner,sun50i-a64-tcon-tv - - const: allwinner,sun8i-a83t-tcon-tv + - enum: + - allwinner,sun8i-h3-tcon-tv + - allwinner,sun50i-a64-tcon-tv + - const: allwinner,sun8i-a83t-tcon-tv - items: - - enum: - - allwinner,sun50i-h6-tcon-tv - - const: allwinner,sun8i-r40-tcon-tv + - enum: + - allwinner,sun50i-h6-tcon-tv + - const: allwinner,sun8i-r40-tcon-tv reg: maxItems: 1 @@ -71,11 +71,10 @@ maxItems: 4 clock-output-names: - allOf: - - $ref: /schemas/types.yaml#/definitions/string-array - - maxItems: 1 description: Name of the LCD pixel clock created. + $ref: /schemas/types.yaml#/definitions/string-array + maxItems: 1 dmas: maxItems: 1 @@ -83,37 +82,37 @@ resets: anyOf: - items: - - description: TCON Reset Line + - description: TCON Reset Line - items: - - description: TCON Reset Line - - description: TCON LVDS Reset Line + - description: TCON Reset Line + - description: TCON LVDS Reset Line - items: - - description: TCON Reset Line - - description: TCON eDP Reset Line + - description: TCON Reset Line + - description: TCON eDP Reset Line - items: - - description: TCON Reset Line - - description: TCON eDP Reset Line - - description: TCON LVDS Reset Line + - description: TCON Reset Line + - description: TCON eDP Reset Line + - description: TCON LVDS Reset Line reset-names: oneOf: - const: lcd - items: - - const: lcd - - const: lvds + - const: lcd + - const: lvds - items: - - const: lcd - - const: edp + - const: lcd + - const: edp - items: - - const: lcd - - const: edp - - const: lvds + - const: lcd + - const: edp + - const: lvds ports: type: object
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml index 9e90c2b..63f9481 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
@@ -76,28 +76,28 @@ allOf: - if: properties: - compatible: - contains: - const: allwinner,sun6i-a31-mipi-dsi + compatible: + contains: + const: allwinner,sun6i-a31-mipi-dsi then: - properties: - clocks: - minItems: 2 + properties: + clocks: + minItems: 2 - required: - - clock-names + required: + - clock-names - if: properties: - compatible: - contains: - const: allwinner,sun50i-a64-mipi-dsi + compatible: + contains: + const: allwinner,sun50i-a64-mipi-dsi then: - properties: - clocks: - minItems: 1 + properties: + clocks: + minItems: 1 additionalProperties: false @@ -119,7 +119,7 @@ panel@0 { compatible = "bananapi,lhr050h41", "ilitek,ili9881c"; reg = <0>; - power-gpios = <&pio 1 7 0>; /* PB07 */ + power-supply = <®_display>; reset-gpios = <&r_pio 0 5 1>; /* PL05 */ backlight = <&pwm_bl>; };
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml index 4d67956..fa4769a 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml
@@ -29,11 +29,11 @@ - const: allwinner,sun50i-h6-dw-hdmi - items: - - enum: - - allwinner,sun8i-h3-dw-hdmi - - allwinner,sun8i-r40-dw-hdmi - - allwinner,sun50i-a64-dw-hdmi - - const: allwinner,sun8i-a83t-dw-hdmi + - enum: + - allwinner,sun8i-h3-dw-hdmi + - allwinner,sun8i-r40-dw-hdmi + - allwinner,sun50i-a64-dw-hdmi + - const: allwinner,sun8i-a83t-dw-hdmi reg: maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt deleted file mode 100644 index d3c2a49..0000000 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt +++ /dev/null
@@ -1,50 +0,0 @@ -Analog Devices ADV7123 Video DAC --------------------------------- - -The ADV7123 is a digital-to-analog converter that outputs VGA signals from a -parallel video input. - -Required properties: - -- compatible: Should be "adi,adv7123" - -Optional properties: - -- psave-gpios: Power save control GPIO - -Required nodes: - -The ADV7123 has two video ports. Their connections are modeled using the OF -graph bindings specified in Documentation/devicetree/bindings/graph.txt. - -- Video port 0 for DPI input -- Video port 1 for VGA output - - -Example -------- - - adv7123: encoder@0 { - compatible = "adi,adv7123"; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - adv7123_in: endpoint@0 { - remote-endpoint = <&dpi_out>; - }; - }; - - port@1 { - reg = <1>; - - adv7123_out: endpoint@0 { - remote-endpoint = <&vga_connector_in>; - }; - }; - }; - };
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml new file mode 100644 index 0000000..3ba477a --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
@@ -0,0 +1,119 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/analogix,anx7814.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analogix ANX7814 SlimPort (Full-HD Transmitter) + +maintainers: + - Enric Balletbo i Serra <enric.balletbo@collabora.com> + +properties: + compatible: + enum: + - analogix,anx7808 + - analogix,anx7812 + - analogix,anx7814 + - analogix,anx7818 + + reg: + maxItems: 1 + description: I2C address of the device. + + interrupts: + maxItems: 1 + description: Should contain the INTP interrupt. + + hpd-gpios: + deprecated: true + maxItems: 1 + description: Which GPIO to use for hpd. + + pd-gpios: + maxItems: 1 + description: Which GPIO to use for power down. + + reset-gpios: + maxItems: 1 + description: Which GPIO to use for reset. + + dvdd10-supply: + description: Regulator for 1.0V digital core power. + + ports: + type: object + description: + A node containing input and output port nodes with endpoint + definitions as documented in + Documentation/devicetree/bindings/media/video-interfaces.txt + Documentation/devicetree/bindings/graph.txt + + properties: + port@0: + type: object + description: Video port for HDMI input. + + properties: + reg: + const: 0 + + port@1: + type: object + description: + Video port for SlimPort, DisplayPort, eDP or MyDP output. + + properties: + reg: + const: 1 + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + anx7814: bridge@38 { + compatible = "analogix,anx7814"; + reg = <0x38>; + interrupt-parent = <&gpio0>; + interrupts = <99 IRQ_TYPE_LEVEL_LOW>; /* INTP */ + pd-gpios = <&pio 33 GPIO_ACTIVE_HIGH>; + reset-gpios = <&pio 98 GPIO_ACTIVE_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + anx7814_in: endpoint { + remote-endpoint = <&hdmi0_out>; + }; + }; + + port@1 { + reg = <1>; + anx7814_out: endpoint { + remote-endpoint = <&edp_out>; + }; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml index c211038..8c0e4f28 100644 --- a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml +++ b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml
@@ -37,6 +37,12 @@ type: object properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + port@0: type: object description: | @@ -51,6 +57,8 @@ required: - port@0 + additionalProperties: false + required: - compatible - reg
diff --git a/Documentation/devicetree/bindings/display/bridge/anx7814.txt b/Documentation/devicetree/bindings/display/bridge/anx7814.txt deleted file mode 100644 index 1725874..0000000 --- a/Documentation/devicetree/bindings/display/bridge/anx7814.txt +++ /dev/null
@@ -1,42 +0,0 @@ -Analogix ANX7814 SlimPort (Full-HD Transmitter) ------------------------------------------------ - -The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter -designed for portable devices. - -Required properties: - - - compatible : Must be one of: - "analogix,anx7808" - "analogix,anx7812" - "analogix,anx7814" - "analogix,anx7818" - - reg : I2C address of the device - - interrupts : Should contain the INTP interrupt - - hpd-gpios : Which GPIO to use for hpd - - pd-gpios : Which GPIO to use for power down - - reset-gpios : Which GPIO to use for reset - -Optional properties: - - - dvdd10-supply : Regulator for 1.0V digital core power. - - Video port for HDMI input, using the DT bindings defined in [1]. - -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - - anx7814: anx7814@38 { - compatible = "analogix,anx7814"; - reg = <0x38>; - interrupt-parent = <&gpio0>; - interrupts = <99 IRQ_TYPE_LEVEL_LOW>; /* INTP */ - hpd-gpios = <&pio 36 GPIO_ACTIVE_HIGH>; - pd-gpios = <&pio 33 GPIO_ACTIVE_HIGH>; - reset-gpios = <&pio 98 GPIO_ACTIVE_HIGH>; - port { - anx7814_in: endpoint { - remote-endpoint = <&hdmi0_out>; - }; - }; - };
diff --git a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml new file mode 100644 index 0000000..9f38f55 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
@@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2019,2020 Lubomir Rintel <lkundrak@v3.sk> +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/chrontel,ch7033.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Chrontel CH7033 Video Encoder Device Tree Bindings + +maintainers: + - Lubomir Rintel <lkundrak@v3.sk> + +properties: + compatible: + const: chrontel,ch7033 + + reg: + maxItems: 1 + description: I2C address of the device + + ports: + type: object + + properties: + port@0: + type: object + description: | + Video port for RGB input. + + port@1: + type: object + description: | + DVI port, should be connected to a node compatible with the + dvi-connector binding. + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - ports + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + vga-dvi-encoder@76 { + compatible = "chrontel,ch7033"; + reg = <0x76>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&lcd0_rgb_out>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&dvi_in>; + }; + }; + + }; + }; + };
diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt deleted file mode 100644 index 164cbb1..0000000 --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt +++ /dev/null
@@ -1,50 +0,0 @@ -Dumb RGB to VGA DAC bridge ---------------------------- - -This binding is aimed for dumb RGB to VGA DAC based bridges that do not require -any configuration. - -Required properties: - -- compatible: Must be "dumb-vga-dac" - -Required nodes: - -This device has two video ports. Their connections are modelled using the OF -graph bindings specified in Documentation/devicetree/bindings/graph.txt. - -- Video port 0 for RGB input -- Video port 1 for VGA output - -Optional properties: -- vdd-supply: Power supply for DAC - -Example -------- - -bridge { - compatible = "dumb-vga-dac"; - #address-cells = <1>; - #size-cells = <0>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - vga_bridge_in: endpoint { - remote-endpoint = <&tcon0_out_vga>; - }; - }; - - port@1 { - reg = <1>; - - vga_bridge_out: endpoint { - remote-endpoint = <&vga_con_in>; - }; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt deleted file mode 100644 index b13adf3..0000000 --- a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt +++ /dev/null
@@ -1,32 +0,0 @@ -Synopsys DesignWare MIPI DSI host controller -============================================ - -This document defines device tree properties for the Synopsys DesignWare MIPI -DSI host controller. It doesn't constitue a device tree binding specification -by itself but is meant to be referenced by platform-specific device tree -bindings. - -When referenced from platform device tree bindings the properties defined in -this document are defined as follows. The platform device tree bindings are -responsible for defining whether each optional property is used or not. - -- reg: Memory mapped base address and length of the DesignWare MIPI DSI - host controller registers. (mandatory) - -- clocks: References to all the clocks specified in the clock-names property - as specified in [1]. (mandatory) - -- clock-names: - - "pclk" is the peripheral clock for either AHB and APB. (mandatory) - - "px_clk" is the pixel clock for the DPI/RGB input. (optional) - -- resets: References to all the resets specified in the reset-names property - as specified in [2]. (optional) - -- reset-names: string reset name, must be "apb" if used. (optional) - -- panel or bridge node: see [3]. (mandatory) - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/reset/reset.txt -[3] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml new file mode 100644 index 0000000..2c50016 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
@@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ite,it6505.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ITE it6505 Device Tree Bindings + +maintainers: + - Allen Chen <allen.chen@ite.com.tw> + +description: | + The IT6505 is a high-performance DisplayPort 1.1a transmitter, + fully compliant with DisplayPort 1.1a, HDCP 1.3 specifications. + The IT6505 supports color depth of up to 36 bits (12 bits/color) + and ensures robust transmission of high-quality uncompressed video + content, along with uncompressed and compressed digital audio content. + + Aside from the various video output formats supported, the IT6505 + also encodes and transmits up to 8 channels of I2S digital audio, + with sampling rate up to 192kHz and sample size up to 24 bits. + In addition, an S/PDIF input port takes in compressed audio of up to + 192kHz frame rate. + + Each IT6505 chip comes preprogrammed with an unique HDCP key, + in compliance with the HDCP 1.3 standard so as to provide secure + transmission of high-definition content. Users of the IT6505 need not + purchase any HDCP keys or ROMs. + +properties: + compatible: + const: ite,it6505 + + ovdd-supply: + maxItems: 1 + description: I/O voltage + + pwr18-supply: + maxItems: 1 + description: core voltage + + interrupts: + maxItems: 1 + description: interrupt specifier of INT pin + + reset-gpios: + maxItems: 1 + description: gpio specifier of RESET pin + + extcon: + maxItems: 1 + description: extcon specifier for the Power Delivery + + port: + type: object + description: A port node pointing to DPI host port node + +required: + - compatible + - ovdd-supply + - pwr18-supply + - interrupts + - reset-gpios + - extcon + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + dp-bridge@5c { + compatible = "ite,it6505"; + interrupts = <152 IRQ_TYPE_EDGE_FALLING 152 0>; + reg = <0x5c>; + pinctrl-names = "default"; + pinctrl-0 = <&it6505_pins>; + ovdd-supply = <&mt6358_vsim1_reg>; + pwr18-supply = <&it6505_pp18_reg>; + reset-gpios = <&pio 179 1>; + extcon = <&usbc_extcon>; + + port { + it6505_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index 8f37302..68951d5 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -32,17 +32,17 @@ compatible: oneOf: - items: - - enum: - - ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer - - ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer - - ti,sn75lvds83 # For the TI SN75LVDS83 FlatLink transmitter - - const: lvds-encoder # Generic LVDS encoder compatible fallback + - enum: + - ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer + - ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer + - ti,sn75lvds83 # For the TI SN75LVDS83 FlatLink transmitter + - const: lvds-encoder # Generic LVDS encoder compatible fallback - items: - - enum: - - ti,ds90cf384a # For the DS90CF384A FPD-Link LVDS Receiver - - const: lvds-decoder # Generic LVDS decoders compatible fallback + - enum: + - ti,ds90cf384a # For the DS90CF384A FPD-Link LVDS Receiver + - const: lvds-decoder # Generic LVDS decoders compatible fallback - enum: - - thine,thc63lvdm83d # For the THC63LVDM83D LVDS serializer + - thine,thc63lvdm83d # For the THC63LVDM83D LVDS serializer ports: type: object @@ -50,6 +50,12 @@ This device has two video ports. Their connections are modeled using the OF graph bindings specified in Documentation/devicetree/bindings/graph.txt properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + port@0: type: object description: | @@ -66,6 +72,8 @@ - port@0 - port@1 + additionalProperties: false + powerdown-gpios: description: The GPIO used to control the power down line of this device.
diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml new file mode 100644 index 0000000..8aff2d6 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
@@ -0,0 +1,226 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Northwest Logic MIPI-DSI controller on i.MX SoCs + +maintainers: + - Guido Gúnther <agx@sigxcpu.org> + - Robert Chiras <robert.chiras@nxp.com> + +description: | + NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi bridge for + the SOCs NWL MIPI-DSI host controller. + +properties: + compatible: + const: fsl,imx8mq-nwl-dsi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + clocks: + items: + - description: DSI core clock + - description: RX_ESC clock (used in escape mode) + - description: TX_ESC clock (used in escape mode) + - description: PHY_REF clock + - description: LCDIF clock + + clock-names: + items: + - const: core + - const: rx_esc + - const: tx_esc + - const: phy_ref + - const: lcdif + + mux-controls: + description: + mux controller node to use for operating the input mux + + phys: + maxItems: 1 + description: + A phandle to the phy module representing the DPHY + + phy-names: + items: + - const: dphy + + power-domains: + maxItems: 1 + + resets: + items: + - description: dsi byte reset line + - description: dsi dpi reset line + - description: dsi esc reset line + - description: dsi pclk reset line + + reset-names: + items: + - const: byte + - const: dpi + - const: esc + - const: pclk + + ports: + type: object + description: + A node containing DSI input & output port nodes with endpoint + definitions as documented in + Documentation/devicetree/bindings/graph.txt. + properties: + port@0: + type: object + description: + Input port node to receive pixel data from the + display controller. Exactly one endpoint must be + specified. + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + endpoint@0: + description: sub-node describing the input from LCDIF + type: object + + endpoint@1: + description: sub-node describing the input from DCSS + type: object + + reg: + const: 0 + + required: + - '#address-cells' + - '#size-cells' + - reg + + oneOf: + - required: + - endpoint@0 + - required: + - endpoint@1 + + additionalProperties: false + + port@1: + type: object + description: + DSI output port node to the panel or the next bridge + in the chain + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + required: + - '#address-cells' + - '#size-cells' + - port@0 + - port@1 + + additionalProperties: false + +patternProperties: + "^panel@[0-9]+$": + type: object + +required: + - '#address-cells' + - '#size-cells' + - clock-names + - clocks + - compatible + - interrupts + - mux-controls + - phy-names + - phys + - ports + - reg + - reset-names + - resets + +additionalProperties: false + +examples: + - | + + #include <dt-bindings/clock/imx8mq-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/reset/imx8mq-reset.h> + + mipi_dsi: mipi_dsi@30a00000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx8mq-nwl-dsi"; + reg = <0x30A00000 0x300>; + clocks = <&clk IMX8MQ_CLK_DSI_CORE>, + <&clk IMX8MQ_CLK_DSI_AHB>, + <&clk IMX8MQ_CLK_DSI_IPG_DIV>, + <&clk IMX8MQ_CLK_DSI_PHY_REF>, + <&clk IMX8MQ_CLK_LCDIF_PIXEL>; + clock-names = "core", "rx_esc", "tx_esc", "phy_ref", "lcdif"; + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>; + mux-controls = <&mux 0>; + power-domains = <&pgc_mipi>; + resets = <&src IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N>, + <&src IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N>, + <&src IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N>, + <&src IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N>; + reset-names = "byte", "dpi", "esc", "pclk"; + phys = <&dphy>; + phy-names = "dphy"; + + panel@0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "rocktech,jh057n00900"; + reg = <0>; + port@0 { + reg = <0>; + panel_in: endpoint { + remote-endpoint = <&mipi_dsi_out>; + }; + }; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + #size-cells = <0>; + #address-cells = <1>; + reg = <0>; + mipi_dsi_in: endpoint@0 { + reg = <0>; + remote-endpoint = <&lcdif_mipi_dsi>; + }; + }; + port@1 { + reg = <1>; + mipi_dsi_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml index 5dff936..7e27cfc 100644 --- a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
@@ -50,6 +50,12 @@ Documentation/devicetree/bindings/media/video-interfaces.txt Documentation/devicetree/bindings/graph.txt properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + port@0: type: object description: | @@ -63,6 +69,8 @@ required: - port@0 + additionalProperties: false + required: - compatible - reg
diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml new file mode 100644 index 0000000..0880cbf --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
@@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/simple-bridge.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Transparent non-programmable DRM bridges + +maintainers: + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> + - Maxime Ripard <mripard@kernel.org> + +description: | + This binding supports transparent non-programmable bridges that don't require + any configuration, with a single input and a single output. + +properties: + compatible: + oneOf: + - items: + - enum: + - ti,ths8134a + - ti,ths8134b + - const: ti,ths8134 + - enum: + - adi,adv7123 + - dumb-vga-dac + - ti,opa362 + - ti,ths8134 + - ti,ths8135 + + ports: + type: object + description: | + This device has two video ports. Their connections are modeled using the + OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + port@0: + type: object + description: The bridge input + + port@1: + type: object + description: The bridge output + + required: + - port@0 + - port@1 + + additionalProperties: false + + enable-gpios: + maxItems: 1 + description: GPIO controlling bridge enable + + vdd-supply: + maxItems: 1 + description: Power supply for the bridge + +required: + - compatible + - ports + +additionalProperties: false + +examples: + - | + bridge { + compatible = "ti,ths8134a", "ti,ths8134"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + vga_bridge_in: endpoint { + remote-endpoint = <&tcon0_out_vga>; + }; + }; + + port@1 { + reg = <1>; + + vga_bridge_out: endpoint { + remote-endpoint = <&vga_con_in>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml new file mode 100644 index 0000000..012aa8e --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml
@@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/snps,dw-mipi-dsi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare MIPI DSI host controller + +maintainers: + - Philippe CORNU <philippe.cornu@st.com> + +description: | + This document defines device tree properties for the Synopsys DesignWare MIPI + DSI host controller. It doesn't constitue a device tree binding specification + by itself but is meant to be referenced by platform-specific device tree + bindings. + + When referenced from platform device tree bindings the properties defined in + this document are defined as follows. The platform device tree bindings are + responsible for defining whether each property is required or optional. + +allOf: + - $ref: ../dsi-controller.yaml# + +properties: + reg: + maxItems: 1 + + clocks: + items: + - description: Module clock + - description: DSI bus clock for either AHB and APB + - description: Pixel clock for the DPI/RGB input + minItems: 2 + + clock-names: + items: + - const: ref + - const: pclk + - const: px_clk + minItems: 2 + + resets: + maxItems: 1 + + reset-names: + const: apb + + ports: + type: object + + properties: + port@0: + type: object + description: Input node to receive pixel data. + port@1: + type: object + description: DSI output node to panel. + + required: + - port@0 + - port@1 + +required: + - clock-names + - clocks + - ports + - reg
diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt deleted file mode 100644 index d17d1e5..0000000 --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt +++ /dev/null
@@ -1,66 +0,0 @@ -Thine Electronics THC63LVD1024 LVDS decoder -------------------------------------------- - -The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams -to parallel data outputs. The chip supports single/dual input/output modes, -handling up to two LVDS input streams and up to two digital CMOS/TTL outputs. - -Single or dual operation mode, output data mapping and DDR output modes are -configured through input signals and the chip does not expose any control bus. - -Required properties: -- compatible: Shall be "thine,thc63lvd1024" -- vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input, - PPL and digital circuitry - -Optional properties: -- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low -- oe-gpios: Output enable GPIO signal, pin name "OE". Active high - -The THC63LVD1024 video port connections are modeled according -to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt - -Required video port nodes: -- port@0: First LVDS input port -- port@2: First digital CMOS/TTL parallel output - -Optional video port nodes: -- port@1: Second LVDS input port -- port@3: Second digital CMOS/TTL parallel output - -The device can operate in single-link mode or dual-link mode. In single-link -mode, all pixels are received on port@0, and port@1 shall not contain any -endpoint. In dual-link mode, even-numbered pixels are received on port@0 and -odd-numbered pixels on port@1, and both port@0 and port@1 shall contain -endpoints. - -Example: --------- - - thc63lvd1024: lvds-decoder { - compatible = "thine,thc63lvd1024"; - - vcc-supply = <®_lvds_vcc>; - powerdown-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - lvds_dec_in_0: endpoint { - remote-endpoint = <&lvds_out>; - }; - }; - - port@2{ - reg = <2>; - - lvds_dec_out_2: endpoint { - remote-endpoint = <&adv7511_in>; - }; - }; - }; - };
diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml new file mode 100644 index 0000000..469ac4a --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml
@@ -0,0 +1,121 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/thine,thc63lvd1024.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Thine Electronics THC63LVD1024 LVDS Decoder + +maintainers: + - Jacopo Mondi <jacopo+renesas@jmondi.org> + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> + +description: | + The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS + streams to parallel data outputs. The chip supports single/dual input/output + modes, handling up to two LVDS input streams and up to two digital CMOS/TTL + outputs. + + Single or dual operation mode, output data mapping and DDR output modes are + configured through input signals and the chip does not expose any control + bus. + +properties: + compatible: + const: thine,thc63lvd1024 + + ports: + type: object + description: | + This device has four video ports. Their connections are modeled using the + OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. + + The device can operate in single-link mode or dual-link mode. In + single-link mode, all pixels are received on port@0, and port@1 shall not + contain any endpoint. In dual-link mode, even-numbered pixels are + received on port@0 and odd-numbered pixels on port@1, and both port@0 and + port@1 shall contain endpoints. + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + port@0: + type: object + description: First LVDS input port + + port@1: + type: object + description: Second LVDS input port + + port@2: + type: object + description: First digital CMOS/TTL parallel output + + port@3: + type: object + description: Second digital CMOS/TTL parallel output + + required: + - port@0 + - port@2 + + additionalProperties: false + + oe-gpios: + maxItems: 1 + description: Output enable GPIO signal, pin name "OE", active high. + + powerdown-gpios: + maxItems: 1 + description: Power down GPIO signal, pin name "/PDWN", active low. + + vcc-supply: + maxItems: 1 + description: + Power supply for the TTL output, TTL CLOCKOUT signal, LVDS input, PLL and + digital circuitry. + +required: + - compatible + - ports + - vcc-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + lvds-decoder { + compatible = "thine,thc63lvd1024"; + + vcc-supply = <®_lvds_vcc>; + powerdown-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + lvds_dec_in_0: endpoint { + remote-endpoint = <&lvds_out>; + }; + }; + + port@2 { + reg = <2>; + + lvds_dec_out_2: endpoint { + remote-endpoint = <&adv7511_in>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt deleted file mode 100644 index df3d7c1..0000000 --- a/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt +++ /dev/null
@@ -1,51 +0,0 @@ -THS8134 and THS8135 Video DAC ------------------------------ - -This is the binding for Texas Instruments THS8134, THS8134A, THS8134B and -THS8135 Video DAC bridges. - -Required properties: - -- compatible: Must be one of - "ti,ths8134" - "ti,ths8134a," "ti,ths8134" - "ti,ths8134b", "ti,ths8134" - "ti,ths8135" - -Required nodes: - -This device has two video ports. Their connections are modelled using the OF -graph bindings specified in Documentation/devicetree/bindings/graph.txt. - -- Video port 0 for RGB input -- Video port 1 for VGA output - -Example -------- - -vga-bridge { - compatible = "ti,ths8135"; - #address-cells = <1>; - #size-cells = <0>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - vga_bridge_in: endpoint { - remote-endpoint = <&lcdc_out_vga>; - }; - }; - - port@1 { - reg = <1>; - - vga_bridge_out: endpoint { - remote-endpoint = <&vga_con_in>; - }; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/display/dsi-controller.yaml b/Documentation/devicetree/bindings/display/dsi-controller.yaml index fd986c3..85b71b1 100644 --- a/Documentation/devicetree/bindings/display/dsi-controller.yaml +++ b/Documentation/devicetree/bindings/display/dsi-controller.yaml
@@ -28,7 +28,7 @@ properties: $nodename: - pattern: "^dsi-controller(@.*)?$" + pattern: "^dsi(@.*)?$" "#address-cells": const: 1 @@ -76,7 +76,7 @@ examples: - | #include <dt-bindings/gpio/gpio.h> - dsi-controller@a0351000 { + dsi@a0351000 { reg = <0xa0351000 0x1000>; #address-cells = <1>; #size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt index 58914cf..77def44 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
@@ -17,6 +17,9 @@ Documentation/devicetree/bindings/graph.txt. This port should be connected to the input port of an attached HDMI or LVDS encoder chip. +Optional properties: +- pinctrl-names: Contain "default" and "sleep". + Example: dpi0: dpi@1401d000 { @@ -27,6 +30,9 @@ <&mmsys CLK_MM_DPI_ENGINE>, <&apmixedsys CLK_APMIXED_TVDPLL>; clock-names = "pixel", "engine", "pll"; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&dpi_pin_func>; + pinctrl-1 = <&dpi_pin_idle>; port { dpi0_out: endpoint {
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt index a19a6cc..8e4729d 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
@@ -33,6 +33,13 @@ - #clock-cells: must be <0>; - #phy-cells: must be <0>. +Optional properties: +- drive-strength-microamp: adjust driving current, should be 3000 ~ 6000. And + the step is 200. +- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If + unspecified default values shall be used. +- nvmem-cell-names: Should be "calibration-data" + Example: mipi_tx0: mipi-dphy@10215000 { @@ -42,6 +49,9 @@ clock-output-names = "mipi_tx0_pll"; #clock-cells = <0>; #phy-cells = <0>; + drive-strength-microamp = <4600>; + nvmem-cells= <&mipi_tx_calibration>; + nvmem-cell-names = "calibration-data"; }; dsi0: dsi@1401b000 {
diff --git a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt deleted file mode 100644 index 0601a9e..0000000 --- a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt +++ /dev/null
@@ -1,31 +0,0 @@ -ARM Versatile TFT Panels - -These panels are connected to the daughterboards found on the -ARM Versatile reference designs. - -This device node must appear as a child to a "syscon"-compatible -node. - -Required properties: -- compatible: should be "arm,versatile-tft-panel" - -Required subnodes: -- port: see display/panel/panel-common.yaml, graph.txt - - -Example: - -sysreg@0 { - compatible = "arm,versatile-sysreg", "syscon", "simple-mfd"; - reg = <0x00000 0x1000>; - - panel: display@0 { - compatible = "arm,versatile-tft-panel"; - - port { - panel_in: endpoint { - remote-endpoint = <&foo>; - }; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml new file mode 100644 index 0000000..41fd571 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
@@ -0,0 +1,54 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/arm,versatile-tft-panel.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Versatile TFT Panels + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + These panels are connected to the daughterboards found on the + ARM Versatile reference designs. + + This device node must appear as a child to a "syscon"-compatible + node. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: arm,versatile-tft-panel + + port: true + +required: + - compatible + - port + +additionalProperties: false + +examples: + - | + sysreg { + compatible = "arm,versatile-sysreg", "syscon", "simple-mfd"; + reg = <0x00000 0x1000>; + + #address-cells = <1>; + #size-cells = <0>; + + panel { + compatible = "arm,versatile-tft-panel"; + + port { + panel_in: endpoint { + remote-endpoint = <&foo>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml b/Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml new file mode 100644 index 0000000..083d2b9d --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.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/asus,z00t-tm5p5-nt35596.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASUS Z00T TM5P5 NT35596 5.5" 1080×1920 LCD Panel + +maintainers: + - Konrad Dybcio <konradybcio@gmail.com> + +description: |+ + This panel seems to only be found in the Asus Z00T + smartphone and we have no straightforward way of + actually getting the correct model number, + as no schematics are released publicly. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: asus,z00t-tm5p5-n35596 + reg: true + reset-gpios: true + vdd-supply: + description: core voltage supply + vddio-supply: + description: vddio supply + +required: + - compatible + - reg + - vdd-supply + - vddio-supply + - reset-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + reg = <0>; + + compatible = "asus,z00t-tm5p5-n35596"; + + vdd-supply = <&pm8916_l8>; + vddio-supply = <&pm8916_l6>; + reset-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>; + }; + };
diff --git a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt deleted file mode 100644 index 3caea21..0000000 --- a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt +++ /dev/null
@@ -1,24 +0,0 @@ -Boe Himax8279d 1200x1920 TFT LCD panel - -Required properties: -- compatible: should be "boe,himax8279d8p" and one of: "boe,himax8279d10p" -- reg: DSI virtual channel of the peripheral -- enable-gpios: panel enable gpio -- pp33-gpios: a GPIO phandle for the 3.3v pin that provides the supply voltage -- pp18-gpios: a GPIO phandle for the 1.8v pin that provides the supply voltage - -Optional properties: -- backlight: phandle of the backlight device attached to the panel - -Example: - - &mipi_dsi { - panel { - compatible = "boe,himax8279d8p", "boe,himax8279d10p"; - reg = <0>; - backlight = <&backlight>; - enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>; - pp33-gpios = <&gpio 35 GPIO_ACTIVE_HIGH>; - pp18-gpios = <&gpio 36 GPIO_ACTIVE_HIGH>; - }; - };
diff --git a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml new file mode 100644 index 0000000..272a3a0 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml
@@ -0,0 +1,59 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/boe,himax8279d.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Boe Himax8279d 1200x1920 TFT LCD panel + +maintainers: + - Jerry Han <jerry.han.hq@gmail.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - const: boe,himax8279d8p + - const: boe,himax8279d10p + + backlight: true + enable-gpios: true + reg: true + + pp33-gpios: + maxItems: 1 + description: GPIO for the 3.3v pin that provides the supply voltage + + pp18-gpios: + maxItems: 1 + description: GPIO for the 1.8v pin that provides the supply voltage + +required: + - compatible + - reg + - enable-gpios + - pp33-gpios + - pp18-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "boe,himax8279d8p", "boe,himax8279d10p"; + reg = <0>; + backlight = <&backlight>; + enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>; + pp33-gpios = <&gpio 35 GPIO_ACTIVE_HIGH>; + pp18-gpios = <&gpio 36 GPIO_ACTIVE_HIGH>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml index 7402134..7f5df58 100644 --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
@@ -24,6 +24,8 @@ - boe,tv101wum-n53 # AUO B101UAN08.3 10.1" WUXGA TFT LCD panel - auo,b101uan08.3 + # BOE TV105WUM-NW0 10.5" WUXGA TFT LCD panel + - boe,tv105wum-nw0 reg: description: the virtual channel number of a DSI peripheral
diff --git a/Documentation/devicetree/bindings/display/panel/display-timings.yaml b/Documentation/devicetree/bindings/display/panel/display-timings.yaml index c8c0c9c..56903de 100644 --- a/Documentation/devicetree/bindings/display/panel/display-timings.yaml +++ b/Documentation/devicetree/bindings/display/panel/display-timings.yaml
@@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/display/panel/display-timings.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: display timing bindings +title: display timings bindings maintainers: - Thierry Reding <thierry.reding@gmail.com> @@ -14,7 +14,7 @@ description: | A display panel may be able to handle several display timings, with different resolutions. - The display-timings node makes it possible to specify the timing + The display-timings node makes it possible to specify the timings and to specify the timing that is native for the display. properties: @@ -25,8 +25,8 @@ $ref: /schemas/types.yaml#/definitions/phandle description: | The default display timing is the one specified as native-mode. - If no native-mode is specified then the first node is assumed the - native mode. + If no native-mode is specified then the first node is assumed + to be the native mode. patternProperties: "^timing":
diff --git a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt deleted file mode 100644 index 82caa7b..0000000 --- a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt +++ /dev/null
@@ -1,20 +0,0 @@ -Feiyang FY07024DI26A30-D 7" MIPI-DSI LCD Panel - -Required properties: -- compatible: must be "feiyang,fy07024di26a30d" -- reg: DSI virtual channel used by that screen -- avdd-supply: analog regulator dc1 switch -- dvdd-supply: 3v3 digital regulator -- reset-gpios: a GPIO phandle for the reset pin - -Optional properties: -- backlight: phandle for the backlight control. - -panel@0 { - compatible = "feiyang,fy07024di26a30d"; - reg = <0>; - avdd-supply = <®_dc1sw>; - dvdd-supply = <®_dldo2>; - reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */ - backlight = <&backlight>; -};
diff --git a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml new file mode 100644 index 0000000..95acf9e --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml
@@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/feiyang,fy07024di26a30d.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Feiyang FY07024DI26A30-D 7" MIPI-DSI LCD Panel + +maintainers: + - Jagan Teki <jagan@amarulasolutions.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: feiyang,fy07024di26a30d + + reg: + description: DSI virtual channel used by that screen + maxItems: 1 + + avdd-supply: + description: analog regulator dc1 switch + + dvdd-supply: + description: 3v3 digital regulator + + reset-gpios: true + + backlight: true + +required: + - compatible + - reg + - avdd-supply + - dvdd-supply + - reset-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "feiyang,fy07024di26a30d"; + reg = <0>; + avdd-supply = <®_dc1sw>; + dvdd-supply = <®_dldo2>; + reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */ + backlight = <&backlight>; + }; + };
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt deleted file mode 100644 index 3d5ce6a..0000000 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt +++ /dev/null
@@ -1,49 +0,0 @@ -Ilitek ILI9322 TFT panel driver with SPI control bus - -This is a driver for 320x240 TFT panels, accepting a variety of input -streams that get adapted and scaled to the panel. The panel output has -960 TFT source driver pins and 240 TFT gate driver pins, VCOM, VCOML and -VCOMH outputs. - -Required properties: - - compatible: "dlink,dir-685-panel", "ilitek,ili9322" - (full system-specific compatible is always required to look up configuration) - - reg: address of the panel on the SPI bus - -Optional properties: - - vcc-supply: core voltage supply, see regulator/regulator.txt - - iovcc-supply: voltage supply for the interface input/output signals, - see regulator/regulator.txt - - vci-supply: voltage supply for analog parts, see regulator/regulator.txt - - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt - - The following optional properties only apply to RGB and YUV input modes and - can be omitted for BT.656 input modes: - - - pixelclk-active: see display/panel/display-timing.txt - - de-active: see display/panel/display-timing.txt - - hsync-active: see display/panel/display-timing.txt - - vsync-active: see display/panel/display-timing.txt - -The panel must obey the rules for a SPI slave device as specified in -spi/spi-bus.txt - -The device node can contain one 'port' child node with one child -'endpoint' node, according to the bindings defined in -media/video-interfaces.txt. This node should describe panel's video bus. - -Example: - -panel: display@0 { - compatible = "dlink,dir-685-panel", "ilitek,ili9322"; - reg = <0>; - vcc-supply = <&vdisp>; - iovcc-supply = <&vdisp>; - vci-supply = <&vdisp>; - - port { - panel_in: endpoint { - remote-endpoint = <&display_out>; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml new file mode 100644 index 0000000..177d48c --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml
@@ -0,0 +1,71 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/ilitek,ili9322.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ilitek ILI9322 TFT panel driver with SPI control bus + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + This is a driver for 320x240 TFT panels, accepting a variety of input + streams that get adapted and scaled to the panel. The panel output has + 960 TFT source driver pins and 240 TFT gate driver pins, VCOM, VCOML and + VCOMH outputs. + + The panel must obey the rules for a SPI slave device as specified in + spi/spi-controller.yaml + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + - dlink,dir-685-panel + + - const: ilitek,ili9322 + + reset-gpios: true + port: true + + vcc-supply: + description: Core voltage supply + + iovcc-supply: + description: Voltage supply for the interface input/output signals + + vci-supply: + description: Voltage supply for analog parts + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + panel: display@0 { + compatible = "dlink,dir-685-panel", "ilitek,ili9322"; + reg = <0>; + vcc-supply = <&vdisp>; + iovcc-supply = <&vdisp>; + vci-supply = <&vdisp>; + + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt deleted file mode 100644 index 4a041acb4..0000000 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt +++ /dev/null
@@ -1,20 +0,0 @@ -Ilitek ILI9881c based MIPI-DSI panels - -Required properties: - - compatible: must be "ilitek,ili9881c" and one of: - * "bananapi,lhr050h41" - - reg: DSI virtual channel used by that screen - - power-supply: phandle to the power regulator - - reset-gpios: a GPIO phandle for the reset pin - -Optional properties: - - backlight: phandle to the backlight used - -Example: -panel@0 { - compatible = "bananapi,lhr050h41", "ilitek,ili9881c"; - reg = <0>; - power-supply = <®_display>; - reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */ - backlight = <&pwm_bl>; -};
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml new file mode 100644 index 0000000..a393322 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
@@ -0,0 +1,50 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/ilitek,ili9881c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ilitek ILI9881c based MIPI-DSI panels + +maintainers: + - Maxime Ripard <mripard@kernel.org> + +properties: + compatible: + items: + - enum: + - bananapi,lhr050h41 + + - const: ilitek,ili9881c + + backlight: true + power-supply: true + reg: true + reset-gpios: true + +required: + - compatible + - power-supply + - reg + - reset-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "bananapi,lhr050h41", "ilitek,ili9881c"; + reg = <0>; + power-supply = <®_display>; + reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */ + backlight = <&pwm_bl>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt b/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt deleted file mode 100644 index d1cab3a..0000000 --- a/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt +++ /dev/null
@@ -1,24 +0,0 @@ -Innolux P097PFG 9.7" 1536x2048 TFT LCD panel - -Required properties: -- compatible: should be "innolux,p097pfg" -- reg: DSI virtual channel of the peripheral -- avdd-supply: phandle of the regulator that provides positive voltage -- avee-supply: phandle of the regulator that provides negative voltage -- enable-gpios: panel enable gpio - -Optional properties: -- backlight: phandle of the backlight device attached to the panel - -Example: - - &mipi_dsi { - panel@0 { - compatible = "innolux,p079zca"; - reg = <0>; - avdd-supply = <...>; - avee-supply = <...>; - backlight = <&backlight>; - enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>; - }; - };
diff --git a/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.yaml b/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.yaml new file mode 100644 index 0000000..5a5f071 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.yaml
@@ -0,0 +1,56 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/innolux,p097pfg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Innolux P097PFG 9.7" 1536x2048 TFT LCD panel + +maintainers: + - Lin Huang <hl@rock-chips.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: innolux,p097pfg + + backlight: true + enable-gpios: true + reg: true + + avdd-supply: + description: The regulator that provides positive voltage + + avee-supply: + description: The regulator that provides negative voltage + +required: + - compatible + - reg + - avdd-supply + - avee-supply + - enable-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "innolux,p097pfg"; + reg = <0>; + avdd-supply = <&avdd>; + avee-supply = <&avee>; + backlight = <&backlight>; + enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt deleted file mode 100644 index 513f034..0000000 --- a/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt +++ /dev/null
@@ -1,22 +0,0 @@ -Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. - -Required properties: -- compatible: should be "innolux,p120zdg-bf1" -- power-supply: regulator to provide the supply voltage - -Optional properties: -- enable-gpios: GPIO pin to enable or disable the panel -- backlight: phandle of the backlight device attached to the panel -- no-hpd: If HPD isn't hooked up; add this property. - -Example: - panel_edp: panel-edp { - compatible = "innolux,p120zdg-bf1"; - enable-gpios = <&msmgpio 31 GPIO_ACTIVE_LOW>; - power-supply = <&pm8916_l2>; - backlight = <&backlight>; - no-hpd; - };
diff --git a/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml new file mode 100644 index 0000000..243dac2 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml
@@ -0,0 +1,43 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/innolux,p120zdg-bf1.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel + +maintainers: + - Sandeep Panda <spanda@codeaurora.org> + - Douglas Anderson <dianders@chromium.org> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: innolux,p120zdg-bf1 + + enable-gpios: true + power-supply: true + backlight: true + no-hpd: true + +required: + - compatible + - power-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + panel_edp: panel-edp { + compatible = "innolux,p120zdg-bf1"; + enable-gpios = <&msmgpio 31 GPIO_ACTIVE_LOW>; + power-supply = <&pm8916_l2>; + backlight = <&backlight>; + no-hpd; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt deleted file mode 100644 index 4989c91d..0000000 --- a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt +++ /dev/null
@@ -1,31 +0,0 @@ -JDI model LT070ME05000 1200x1920 7" DSI Panel - -Required properties: -- compatible: should be "jdi,lt070me05000" -- vddp-supply: phandle of the regulator that provides the supply voltage - Power IC supply (3-5V) -- iovcc-supply: phandle of the regulator that provides the supply voltage - IOVCC , power supply for LCM (1.8V) -- enable-gpios: phandle of gpio for enable line - LED_EN, LED backlight enable, High active -- reset-gpios: phandle of gpio for reset line - This should be 8mA, gpio can be configured using mux, pinctrl, pinctrl-names - XRES, Reset, Low active -- dcdc-en-gpios: phandle of the gpio for power ic line - Power IC supply enable, High active - -Example: - - dsi0: qcom,mdss_dsi@4700000 { - panel@0 { - compatible = "jdi,lt070me05000"; - reg = <0>; - - vddp-supply = <&pm8921_l17>; - iovcc-supply = <&pm8921_lvs7>; - - enable-gpios = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>; - reset-gpios = <&tlmm_pinmux 54 GPIO_ACTIVE_LOW>; - dcdc-en-gpios = <&pm8921_gpio 23 GPIO_ACTIVE_HIGH>; - }; - };
diff --git a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml new file mode 100644 index 0000000..b8b9435 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml
@@ -0,0 +1,69 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/jdi,lt070me05000.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: JDI model LT070ME05000 1200x1920 7" DSI Panel + +maintainers: + - Vinay Simha BN <simhavcs@gmail.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: jdi,lt070me05000 + + enable-gpios: true + reg: true + reset-gpios: true + + vddp-supply: + description: | + The regulator that provides the supply voltage Power IC supply (3-5V) + + iovcc-supply: + description: | + The regulator that provides the supply voltage IOVCC, + power supply for LCM (1.8V) + + dcdc-en-gpios: + description: | + phandle of the gpio for power ic line + Power IC supply enable, High active + +required: + - compatible + - reg + - vddp-supply + - iovcc-supply + - enable-gpios + - reset-gpios + - dcdc-en-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "jdi,lt070me05000"; + reg = <0>; + + vddp-supply = <&pm8921_l17>; + iovcc-supply = <&pm8921_lvs7>; + + enable-gpios = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>; + reset-gpios = <&tlmm_pinmux 54 GPIO_ACTIVE_LOW>; + dcdc-en-gpios = <&pm8921_gpio 23 GPIO_ACTIVE_HIGH>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt deleted file mode 100644 index fa95960..0000000 --- a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt +++ /dev/null
@@ -1,42 +0,0 @@ -King Display KD035G6-54NT 3.5" (320x240 pixels) 24-bit TFT LCD panel - -Required properties: -- compatible: should be "kingdisplay,kd035g6-54nt" -- power-supply: See panel-common.txt -- reset-gpios: See panel-common.txt - -Optional properties: -- backlight: see panel-common.txt - -The generic bindings for the SPI slaves documented in [1] also apply. - -The device node can contain one 'port' child node with one child -'endpoint' node, according to the bindings defined in [2]. This -node should describe panel's video bus. - -[1]: Documentation/devicetree/bindings/spi/spi-bus.txt -[2]: Documentation/devicetree/bindings/graph.txt - -Example: - -&spi { - panel@0 { - compatible = "kingdisplay,kd035g6-54nt"; - reg = <0>; - - spi-max-frequency = <3125000>; - spi-3wire; - spi-cs-high; - - reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>; - - backlight = <&backlight>; - power-supply = <&ldo6>; - - port { - panel_input: endpoint { - remote-endpoint = <&panel_output>; - }; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml new file mode 100644 index 0000000..6960036 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml
@@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/kingdisplay,kd035g6-54nt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: King Display KD035G6-54NT 3.5" (320x240 pixels) 24-bit TFT LCD panel + +description: | + The panel must obey the rules for a SPI slave device as specified in + spi/spi-controller.yaml + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: kingdisplay,kd035g6-54nt + + backlight: true + port: true + power-supply: true + reg: true + reset-gpios: true + +required: + - compatible + - power-supply + - reset-gpios + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "kingdisplay,kd035g6-54nt"; + reg = <0>; + + spi-max-frequency = <3125000>; + spi-3wire; + spi-cs-high; + + reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>; + + backlight = <&backlight>; + power-supply = <&ldo6>; + + port { + panel_input: endpoint { + remote-endpoint = <&panel_output>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt deleted file mode 100644 index cfefff6..0000000 --- a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt +++ /dev/null
@@ -1,22 +0,0 @@ -Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel - -Required properties: -- compatible: should be "kingdisplay,kd097d04" -- reg: DSI virtual channel of the peripheral -- power-supply: phandle of the regulator that provides the supply voltage -- enable-gpios: panel enable gpio - -Optional properties: -- backlight: phandle of the backlight device attached to the panel - -Example: - - &mipi_dsi { - panel@0 { - compatible = "kingdisplay,kd097d04"; - reg = <0>; - power-supply = <...>; - backlight = <&backlight>; - enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>; - }; - };
diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml new file mode 100644 index 0000000..a372bdc --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
@@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/leadtek,ltk050h3146w.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Leadtek LTK050H3146W 5.0in 720x1280 DSI panel + +maintainers: + - Heiko Stuebner <heiko.stuebner@theobroma-systems.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + enum: + - leadtek,ltk050h3146w + - leadtek,ltk050h3146w-a2 + reg: true + backlight: true + reset-gpios: true + iovcc-supply: + description: regulator that supplies the iovcc voltage + vci-supply: + description: regulator that supplies the vci voltage + +required: + - compatible + - reg + - backlight + - iovcc-supply + - vci-supply + +additionalProperties: false + +examples: + - | + dsi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "leadtek,ltk050h3146w"; + reg = <0>; + backlight = <&backlight>; + iovcc-supply = <&vcc_1v8>; + vci-supply = <&vcc3v3_lcd>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml index fd931b29..b900973 100644 --- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
@@ -37,7 +37,6 @@ dsi { #address-cells = <1>; #size-cells = <0>; - reg = <0xff450000 0x1000>; panel@0 { compatible = "leadtek,ltk500hd1829";
diff --git a/Documentation/devicetree/bindings/display/panel/lg,acx467akm-7.txt b/Documentation/devicetree/bindings/display/panel/lg,acx467akm-7.txt deleted file mode 100644 index fc1e1b3..0000000 --- a/Documentation/devicetree/bindings/display/panel/lg,acx467akm-7.txt +++ /dev/null
@@ -1,7 +0,0 @@ -LG ACX467AKM-7 4.95" 1080×1920 LCD Panel - -Required properties: -- compatible: must be "lg,acx467akm-7" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.txt b/Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.txt deleted file mode 100644 index 5e649cb..0000000 --- a/Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.txt +++ /dev/null
@@ -1,7 +0,0 @@ -LG Corporation 7" WXGA TFT LCD panel - -Required properties: -- compatible: should be "lg,ld070wx3-sl01" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/lg,lg4573.txt b/Documentation/devicetree/bindings/display/panel/lg,lg4573.txt deleted file mode 100644 index 824441f..0000000 --- a/Documentation/devicetree/bindings/display/panel/lg,lg4573.txt +++ /dev/null
@@ -1,19 +0,0 @@ -LG LG4573 TFT Liquid Crystal Display with SPI control bus - -Required properties: - - compatible: "lg,lg4573" - - reg: address of the panel on the SPI bus - -The panel must obey rules for SPI slave device specified in document [1]. - -[1]: Documentation/devicetree/bindings/spi/spi-bus.txt - -Example: - - lcd_panel: display@0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "lg,lg4573"; - spi-max-frequency = <10000000>; - reg = <0>; - };
diff --git a/Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml b/Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml new file mode 100644 index 0000000..b4314ce --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml
@@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/lg,lg4573.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LG LG4573 TFT Liquid Crystal Display with SPI control bus + +description: | + The panel must obey the rules for a SPI slave device as specified in + spi/spi-controller.yaml + +maintainers: + - Heiko Schocher <hs@denx.de> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: lg,lg4573 + + reg: true + spi-max-frequency: true + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + lcd_panel: display@0 { + compatible = "lg,lg4573"; + spi-max-frequency = <10000000>; + reg = <0>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/lg,lh500wx1-sd03.txt b/Documentation/devicetree/bindings/display/panel/lg,lh500wx1-sd03.txt deleted file mode 100644 index a04fd2b..0000000 --- a/Documentation/devicetree/bindings/display/panel/lg,lh500wx1-sd03.txt +++ /dev/null
@@ -1,7 +0,0 @@ -LG Corporation 5" HD TFT LCD panel - -Required properties: -- compatible: should be "lg,lh500wx1-sd03" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.txt b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.txt deleted file mode 100644 index 1a1e653..0000000 --- a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.txt +++ /dev/null
@@ -1,33 +0,0 @@ -LG.Philips LB035Q02 Panel -========================= - -Required properties: -- compatible: "lgphilips,lb035q02" -- enable-gpios: panel enable gpio - -Optional properties: -- label: a symbolic name for the panel - -Required nodes: -- Video port for DPI input - -Example -------- - -lcd-panel: panel@0 { - compatible = "lgphilips,lb035q02"; - reg = <0>; - spi-max-frequency = <100000>; - spi-cpol; - spi-cpha; - - label = "lcd"; - - enable-gpios = <&gpio7 7 0>; - - port { - lcd_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml new file mode 100644 index 0000000..830e335 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml
@@ -0,0 +1,59 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/lgphilips,lb035q02.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LG.Philips LB035Q02 Panel + +description: | + The panel must obey the rules for a SPI slave device as specified in + spi/spi-controller.yaml + +maintainers: + - Tomi Valkeinen <tomi.valkeinen@ti.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: lgphilips,lb035q02 + + label: true + enable-gpios: true + port: true + +required: + - compatible + - enable-gpios + - port + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + panel: panel@0 { + compatible = "lgphilips,lb035q02"; + reg = <0>; + spi-max-frequency = <100000>; + spi-cpol; + spi-cpha; + + label = "lcd"; + + enable-gpios = <&gpio7 7 0>; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/panel/lvds.yaml index d008330..946dd35 100644 --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -96,12 +96,20 @@ If set, reverse the bit order described in the data mappings below on all data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6. + port: true + ports: true + required: - compatible - data-mapping - width-mm - height-mm - panel-timing - - port + +oneOf: + - required: + - port + - required: + - ports ...
diff --git a/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt b/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt deleted file mode 100644 index a89f9c8..0000000 --- a/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt +++ /dev/null
@@ -1,42 +0,0 @@ -Binding for Olimex Ltd. LCD-OLinuXino bridge panel. - -This device can be used as bridge between a host controller and LCD panels. -Currently supported LCDs are: - - LCD-OLinuXino-4.3TS - - LCD-OLinuXino-5 - - LCD-OLinuXino-7 - - LCD-OLinuXino-10 - -The panel itself contains: - - AT24C16C EEPROM holding panel identification and timing requirements - - AR1021 resistive touch screen controller (optional) - - FT5x6 capacitive touch screnn controller (optional) - - GT911/GT928 capacitive touch screen controller (optional) - -The above chips share same I2C bus. The EEPROM is factory preprogrammed with -device information (id, serial, etc.) and timing requirements. - -Touchscreen bingings can be found in these files: - - input/touchscreen/goodix.txt - - input/touchscreen/edt-ft5x06.txt - - input/touchscreen/ar1021.txt - -Required properties: - - compatible: should be "olimex,lcd-olinuxino" - - reg: address of the configuration EEPROM, should be <0x50> - - power-supply: phandle of the regulator that provides the supply voltage - -Optional properties: - - enable-gpios: GPIO pin to enable or disable the panel - - backlight: phandle of the backlight device attacked to the panel - -Example: -&i2c2 { - panel@50 { - compatible = "olimex,lcd-olinuxino"; - reg = <0x50>; - power-supply = <®_vcc5v0>; - enable-gpios = <&pio 7 8 GPIO_ACTIVE_HIGH>; - backlight = <&backlight>; - }; -};
diff --git a/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml b/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml new file mode 100644 index 0000000..2329d96 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml
@@ -0,0 +1,70 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/olimex,lcd-olinuxino.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for Olimex Ltd. LCD-OLinuXino bridge panel. + +maintainers: + - Stefan Mavrodiev <stefan@olimex.com> + +description: | + This device can be used as bridge between a host controller and LCD panels. + Currently supported LCDs are: + - LCD-OLinuXino-4.3TS + - LCD-OLinuXino-5 + - LCD-OLinuXino-7 + - LCD-OLinuXino-10 + + The panel itself contains: + - AT24C16C EEPROM holding panel identification and timing requirements + - AR1021 resistive touch screen controller (optional) + - FT5x6 capacitive touch screnn controller (optional) + - GT911/GT928 capacitive touch screen controller (optional) + + The above chips share same I2C bus. The EEPROM is factory preprogrammed with + device information (id, serial, etc.) and timing requirements. + + Touchscreen bingings can be found in these files: + - input/touchscreen/goodix.yaml + - input/touchscreen/edt-ft5x06.txt + - input/touchscreen/ar1021.txt + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: olimex,lcd-olinuxino + + backlight: true + enable-gpios: true + power-supply: true + reg: true + +required: + - compatible + - reg + - power-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + panel@50 { + compatible = "olimex,lcd-olinuxino"; + reg = <0x50>; + power-supply = <®_vcc5v0>; + enable-gpios = <&pio 7 8 GPIO_ACTIVE_HIGH>; + backlight = <&backlight>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/osddisplays,osd101t2587-53ts.txt b/Documentation/devicetree/bindings/display/panel/osddisplays,osd101t2587-53ts.txt deleted file mode 100644 index 9d88e96..0000000 --- a/Documentation/devicetree/bindings/display/panel/osddisplays,osd101t2587-53ts.txt +++ /dev/null
@@ -1,14 +0,0 @@ -One Stop Displays OSD101T2587-53TS 10.1" 1920x1200 panel - -The panel is similar to OSD101T2045-53TS, but it needs additional -MIPI_DSI_TURN_ON_PERIPHERAL message from the host. - -Required properties: -- compatible: should be "osddisplays,osd101t2587-53ts" -- power-supply: as specified in the base binding - -Optional properties: -- backlight: as specified in the base binding - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml index ed051ba..45fe8fe 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
@@ -48,9 +48,8 @@ rotation: description: Display rotation in degrees counter clockwise (0,90,180,270) - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 0, 90, 180, 270 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 90, 180, 270] # Display Timings panel-timing: @@ -58,16 +57,14 @@ Most display panels are restricted to a single resolution and require specific display timings. The panel-timing subnode expresses those timings. - allOf: - - $ref: panel-timing.yaml# + $ref: panel-timing.yaml# display-timings: description: - Some display panels supports several resolutions with different timing. + Some display panels support several resolutions with different timings. The display-timings bindings supports specifying several timings and - optional specify which is the native mode. - allOf: - - $ref: display-timings.yaml# + optionally specifying which is the native mode. + $ref: display-timings.yaml# # Connectivity port: @@ -96,6 +93,12 @@ (hot plug detect) signal, but the signal isn't hooked up so we should hardcode the max delay from the panel spec when powering up the panel. + hpd-gpios: + maxItems: 1 + description: + If Hot Plug Detect (HPD) is connected to a GPIO in the system rather + than a dedicated HPD pin the pin can be specified here. + # Control I/Os # Many display panels can be controlled through pins driven by GPIOs. The nature @@ -124,6 +127,13 @@ while active. Active high reset signals can be supported by inverting the GPIO specifier polarity flag. + te-gpios: + maxItems: 1 + description: + GPIO spec for the tearing effect synchronization signal. + The tearing effect signal is active high. Active low signals can be + supported by inverting the GPIO specifier polarity flag. + # Power power-supply: description:
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index b2e8742..16778ce 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
@@ -29,6 +29,20 @@ # compatible must be listed in alphabetical order, ordered by compatible. # The description in the comment is mandatory for each compatible. + # AU Optronics Corporation 8.0" WUXGA TFT LCD panel + - auo,b080uan01 + # Boe Corporation 8.0" WUXGA TFT LCD panel + - boe,tv080wum-nl0 + # Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel + - kingdisplay,kd097d04 + # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel + - lg,acx467akm-7 + # LG Corporation 7" WXGA TFT LCD panel + - lg,ld070wx3-sl01 + # One Stop Displays OSD101T2587-53TS 10.1" 1920x1200 panel + - osddisplays,osd101t2587-53ts + # Panasonic 10" WUXGA TFT LCD panel + - panasonic,vvx10f004b00 # Panasonic 10" WUXGA TFT LCD panel - panasonic,vvx10f034n00
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 393ffc6..d6cca14 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -33,8 +33,6 @@ - ampire,am-480272h3tmqw-t01h # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel - ampire,am800480r3tmqwa1h - # AU Optronics Corporation 8.0" WUXGA TFT LCD panel - - auo,b080uan01 # AU Optronics Corporation 10.1" WSVGA TFT LCD panel - auo,b101aw03 # AU Optronics Corporation 10.1" WSVGA TFT LCD panel @@ -55,10 +53,16 @@ - auo,g101evn010 # AU Optronics Corporation 10.4" (800x600) color TFT LCD panel - auo,g104sn02 + # AU Optronics Corporation 12.1" (1280x800) TFT LCD panel + - auo,g121ean01 # AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel - auo,g133han01 + # AU Optronics Corporation 15.6" (1366x768) TFT LCD panel + - auo,g156xtn01 # AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel - auo,g185han01 + # AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel + - auo,g190ean01 # AU Optronics Corporation 31.5" FHD (1920x1080) TFT LCD panel - auo,p320hvn03 # AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel @@ -69,10 +73,12 @@ - boe,hv070wsa-100 # BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel - boe,nv101wxmn51 + # BOE NV133FHM-N61 13.3" FHD (1920x1080) TFT LCD Panel + - boe,nv133fhm-n61 + # BOE NV133FHM-N62 13.3" FHD (1920x1080) TFT LCD Panel + - boe,nv133fhm-n62 # BOE NV140FHM-N49 14.0" FHD a-Si FT panel - boe,nv140fhmn49 - # Boe Corporation 8.0" WUXGA TFT LCD panel - - boe,tv080wum-nl0 # CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel - cdtech,s043wq26h-ct7 # CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel @@ -82,6 +88,8 @@ # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel - chunghwa,claa101wa01a # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel + - chunghwa,claa101wb01 + # Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel - chunghwa,claa101wb03 # DataImage, Inc. 7" WVGA (800x480) TFT LCD panel with 24-bit parallel interface. - dataimage,scf0700c48ggu18 @@ -127,6 +135,8 @@ - hannstar,hsd100pxn1 # Hitachi Ltd. Corporation 9" WVGA (800x480) TFT LCD panel - hit,tx23d38vm0caa + # InfoVision Optoelectronics M133NWF4 R0 13.3" FHD (1920x1080) TFT LCD panel + - ivo,m133nwf4-r0 # Innolux AT043TN24 4.3" WQVGA TFT LCD panel - innolux,at043tn24 # Innolux AT070TN92 7.0" WQVGA TFT LCD panel @@ -155,6 +165,8 @@ - lemaker,bl035-rgb-002 # LG 7" (800x480 pixels) TFT LCD panel - lg,lb070wv8 + # LG Corporation 5" HD TFT LCD panel + - lg,lh500wx1-sd03 # LG LP079QX1-SP0V 7.9" (1536x2048 pixels) TFT LCD panel - lg,lp079qx1-sp0v # LG 9.7" (2048x1536 pixels) TFT LCD panel @@ -227,6 +239,8 @@ - sharp,ls020b1dd01d # Shelly SCA07010-BFN-LNN 7.0" WVGA TFT LCD panel - shelly,sca07010-bfn-lnn + # Starry KR070PE2T 7" WVGA TFT LCD panel + - starry,kr070pe2t # Starry 12.2" (1920x1200 pixels) TFT LCD panel - starry,kr122ea0sra # Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel
diff --git a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml index bd558ad..182c19c 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml
@@ -72,92 +72,80 @@ hfront-porch: description: Horizontal front porch panel timing oneOf: - - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - maxItems: 1 - items: - description: typical number of pixels - - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 3 - maxItems: 3 - items: - description: min, typ, max number of pixels + - $ref: /schemas/types.yaml#/definitions/uint32 + maxItems: 1 + items: + description: typical number of pixels + - $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 3 + maxItems: 3 + items: + description: min, typ, max number of pixels hback-porch: description: Horizontal back porch timing oneOf: - - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - maxItems: 1 - items: - description: typical number of pixels - - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 3 - maxItems: 3 - items: - description: min, typ, max number of pixels + - $ref: /schemas/types.yaml#/definitions/uint32 + maxItems: 1 + items: + description: typical number of pixels + - $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 3 + maxItems: 3 + items: + description: min, typ, max number of pixels hsync-len: description: Horizontal sync length panel timing oneOf: - - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - maxItems: 1 - items: - description: typical number of pixels - - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 3 - maxItems: 3 - items: - description: min, typ, max number of pixels + - $ref: /schemas/types.yaml#/definitions/uint32 + maxItems: 1 + items: + description: typical number of pixels + - $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 3 + maxItems: 3 + items: + description: min, typ, max number of pixels vfront-porch: description: Vertical front porch panel timing oneOf: - - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - maxItems: 1 - items: - description: typical number of lines - - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 3 - maxItems: 3 - items: - description: min, typ, max number of lines + - $ref: /schemas/types.yaml#/definitions/uint32 + maxItems: 1 + items: + description: typical number of lines + - $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 3 + maxItems: 3 + items: + description: min, typ, max number of lines vback-porch: description: Vertical back porch panel timing oneOf: - - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - maxItems: 1 - items: - description: typical number of lines - - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 3 - maxItems: 3 - items: - description: min, typ, max number of lines + - $ref: /schemas/types.yaml#/definitions/uint32 + maxItems: 1 + items: + description: typical number of lines + - $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 3 + maxItems: 3 + items: + description: min, typ, max number of lines vsync-len: description: Vertical sync length panel timing oneOf: - - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - maxItems: 1 - items: - description: typical number of lines - - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 3 - maxItems: 3 - items: - description: min, typ, max number of lines + - $ref: /schemas/types.yaml#/definitions/uint32 + maxItems: 1 + items: + description: typical number of lines + - $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 3 + maxItems: 3 + items: + description: min, typ, max number of lines hsync-active: description: |
diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt deleted file mode 100644 index 1042469..0000000 --- a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt +++ /dev/null
@@ -1,41 +0,0 @@ -Raydium RM67171 OLED LCD panel with MIPI-DSI protocol - -Required properties: -- compatible: "raydium,rm67191" -- reg: virtual channel for MIPI-DSI protocol - must be <0> -- dsi-lanes: number of DSI lanes to be used - must be <3> or <4> -- port: input port node with endpoint definition as - defined in Documentation/devicetree/bindings/graph.txt; - the input port should be connected to a MIPI-DSI device - driver - -Optional properties: -- reset-gpios: a GPIO spec for the RST_B GPIO pin -- v3p3-supply: phandle to 3.3V regulator that powers the VDD_3V3 pin -- v1p8-supply: phandle to 1.8V regulator that powers the VDD_1V8 pin -- width-mm: see panel-common.txt -- height-mm: see panel-common.txt -- video-mode: 0 - burst-mode - 1 - non-burst with sync event - 2 - non-burst with sync pulse - -Example: - - panel@0 { - compatible = "raydium,rm67191"; - reg = <0>; - pinctrl-0 = <&pinctrl_mipi_dsi_0_1_en>; - pinctrl-names = "default"; - reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; - dsi-lanes = <4>; - width-mm = <68>; - height-mm = <121>; - - port { - panel_in: endpoint { - remote-endpoint = <&mipi_out>; - }; - }; - };
diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml new file mode 100644 index 0000000..745dd247 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml
@@ -0,0 +1,75 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/raydium,rm67191.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Raydium RM67171 OLED LCD panel with MIPI-DSI protocol + +maintainers: + - Robert Chiras <robert.chiras@nxp.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: raydium,rm67191 + + reg: true + port: true + reset-gpios: true + width-mm: true + height-mm: true + + dsi-lanes: + description: Number of DSI lanes to be used must be <3> or <4> + enum: [3, 4] + + v3p3-supply: + description: phandle to 3.3V regulator that powers the VDD_3V3 pin + + v1p8-supply: + description: phandle to 1.8V regulator that powers the VDD_1V8 pin + + video-mode: + description: | + 0 - burst-mode + 1 - non-burst with sync event + 2 - non-burst with sync pulse + enum: [0, 1, 2] + +required: + - compatible + - reg + - dsi-lanes + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "raydium,rm67191"; + reg = <0>; + reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; + dsi-lanes = <4>; + width-mm = <68>; + height-mm = <121>; + video-mode = <1>; + + port { + panel_in: endpoint { + remote-endpoint = <&mipi_out>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml new file mode 100644 index 0000000..96bdde9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml
@@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,amoled-mipi-dsi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung AMOLED MIPI-DSI panels + +maintainers: + - Hoegeun Kwon <hoegeun.kwon@samsung.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + enum: + # Samsung S6E63J0X03 1.63" 320x320 AMOLED panel + - samsung,s6e63j0x03 + # Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel + - samsung,s6e3ha2 + # Samsung S6E3HF2 5.65" 1600x2560 AMOLED panel + - samsung,s6e3hf2 + + reg: true + reset-gpios: true + enable-gpios: true + te-gpios: true + + vdd3-supply: + description: I/O voltage supply + + vci-supply: + description: voltage supply for analog circuits + +required: + - compatible + - reg + - vdd3-supply + - vci-supply + - reset-gpios + - enable-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "samsung,s6e3ha2"; + reg = <0>; + vdd3-supply = <&ldo27_reg>; + vci-supply = <&ldo28_reg>; + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>; + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>; + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.txt b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.txt deleted file mode 100644 index 354d4d1..0000000 --- a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.txt +++ /dev/null
@@ -1,66 +0,0 @@ -Samsung LD9040 AMOLED LCD parallel RGB panel with SPI control bus - -Required properties: - - compatible: "samsung,ld9040" - - reg: address of the panel on SPI bus - - vdd3-supply: core voltage supply - - vci-supply: voltage supply for analog circuits - - reset-gpios: a GPIO spec for the reset pin - - display-timings: timings for the connected panel according to [1] - -The panel must obey rules for SPI slave device specified in document [2]. - -Optional properties: - - power-on-delay: delay after turning regulators on [ms] - - reset-delay: delay after reset sequence [ms] - - panel-width-mm: physical panel width [mm] - - panel-height-mm: physical panel height [mm] - -The device node can contain one 'port' child node with one child -'endpoint' node, according to the bindings defined in [3]. This -node should describe panel's video bus. - -[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt -[2]: Documentation/devicetree/bindings/spi/spi-bus.txt -[3]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - - lcd@0 { - compatible = "samsung,ld9040"; - reg = <0>; - vdd3-supply = <&ldo7_reg>; - vci-supply = <&ldo17_reg>; - reset-gpios = <&gpy4 5 0>; - spi-max-frequency = <1200000>; - spi-cpol; - spi-cpha; - power-on-delay = <10>; - reset-delay = <10>; - panel-width-mm = <90>; - panel-height-mm = <154>; - - display-timings { - timing { - clock-frequency = <23492370>; - hactive = <480>; - vactive = <800>; - hback-porch = <16>; - hfront-porch = <16>; - vback-porch = <2>; - vfront-porch = <28>; - hsync-len = <2>; - vsync-len = <1>; - hsync-active = <0>; - vsync-active = <0>; - de-active = <0>; - pixelclk-active = <0>; - }; - }; - - port { - lcd_ep: endpoint { - remote-endpoint = <&fimd_dpi_ep>; - }; - }; - };
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml new file mode 100644 index 0000000..060ee27 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml
@@ -0,0 +1,107 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,ld9040.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung LD9040 AMOLED LCD parallel RGB panel with SPI control bus + +description: | + The panel must obey the rules for a SPI slave device as specified in + spi/spi-controller.yaml + +maintainers: + - Andrzej Hajda <a.hajda@samsung.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,ld9040 + + display-timings: true + port: true + reg: true + reset-gpios: true + + vdd3-supply: + description: core voltage supply + + vci-supply: + description: voltage supply for analog circuits + + power-on-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + description: delay after turning regulators on [ms] + + reset-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + description: delay after reset sequence [ms] + + panel-width-mm: + description: physical panel width [mm] + + panel-height-mm: + description: physical panel height [mm] + +required: + - compatible + - reg + - vdd3-supply + - vci-supply + - reset-gpios + - display-timings + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + lcd@0 { + compatible = "samsung,ld9040"; + #address-cells = <1>; + #size-cells = <0>; + + reg = <0>; + vdd3-supply = <&ldo7_reg>; + vci-supply = <&ldo17_reg>; + reset-gpios = <&gpy4 5 0>; + spi-max-frequency = <1200000>; + spi-cpol; + spi-cpha; + power-on-delay = <10>; + reset-delay = <10>; + panel-width-mm = <90>; + panel-height-mm = <154>; + + display-timings { + timing { + clock-frequency = <23492370>; + hactive = <480>; + vactive = <800>; + hback-porch = <16>; + hfront-porch = <16>; + vback-porch = <2>; + vfront-porch = <28>; + hsync-len = <2>; + vsync-len = <1>; + hsync-active = <0>; + vsync-active = <0>; + de-active = <0>; + pixelclk-active = <0>; + }; + }; + + port { + lcd_ep: endpoint { + remote-endpoint = <&fimd_dpi_ep>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6d16d0.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6d16d0.txt deleted file mode 100644 index b94e366..0000000 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6d16d0.txt +++ /dev/null
@@ -1,30 +0,0 @@ -Samsung S6D16D0 4" 864x480 AMOLED panel - -Required properties: - - compatible: should be: - "samsung,s6d16d0", - - reg: the virtual channel number of a DSI peripheral - - vdd1-supply: I/O voltage supply - - reset-gpios: a GPIO spec for the reset pin (active low) - -The device node can contain one 'port' child node with one child -'endpoint' node, according to the bindings defined in -media/video-interfaces.txt. This node should describe panel's video bus. - -Example: -&dsi { - ... - - panel@0 { - compatible = "samsung,s6d16d0"; - reg = <0>; - vdd1-supply = <&foo>; - reset-gpios = <&foo_gpio 0 GPIO_ACTIVE_LOW>; - - port { - panel_in: endpoint { - remote-endpoint = <&dsi_out>; - }; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6d16d0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6d16d0.yaml new file mode 100644 index 0000000..66d1474 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6d16d0.yaml
@@ -0,0 +1,56 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,s6d16d0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S6D16D0 4" 864x480 AMOLED panel + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,s6d16d0 + + port: true + reg: true + reset-gpios: true + + vdd1-supply: + description: I/O voltage supply + +required: + - compatible + - reg + - vdd1-supply + - reset-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "samsung,s6d16d0"; + reg = <0>; + vdd1-supply = <&foo>; + reset-gpios = <&foo_gpio 0 GPIO_ACTIVE_LOW>; + + port { + panel_in: endpoint { + remote-endpoint = <&dsi_out>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt deleted file mode 100644 index 4acea25..0000000 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt +++ /dev/null
@@ -1,31 +0,0 @@ -Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel -Samsung S6E3HF2 5.65" 1600x2560 AMOLED panel - -Required properties: - - compatible: should be one of: - "samsung,s6e3ha2", - "samsung,s6e3hf2". - - reg: the virtual channel number of a DSI peripheral - - vdd3-supply: I/O voltage supply - - vci-supply: voltage supply for analog circuits - - reset-gpios: a GPIO spec for the reset pin (active low) - - enable-gpios: a GPIO spec for the panel enable pin (active high) - -Optional properties: - - te-gpios: a GPIO spec for the tearing effect synchronization signal - gpio pin (active high) - -Example: -&dsi { - ... - - panel@0 { - compatible = "samsung,s6e3ha2"; - reg = <0>; - vdd3-supply = <&ldo27_reg>; - vci-supply = <&ldo28_reg>; - reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>; - enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>; - te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>; - }; -};
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt deleted file mode 100644 index 3f1a839..0000000 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt +++ /dev/null
@@ -1,24 +0,0 @@ -Samsung S6E63J0X03 1.63" 320x320 AMOLED panel (interface: MIPI-DSI command mode) - -Required properties: - - compatible: "samsung,s6e63j0x03" - - reg: the virtual channel number of a DSI peripheral - - vdd3-supply: I/O voltage supply - - vci-supply: voltage supply for analog circuits - - reset-gpios: a GPIO spec for the reset pin (active low) - - te-gpios: a GPIO spec for the tearing effect synchronization signal - gpio pin (active high) - -Example: -&dsi { - ... - - panel@0 { - compatible = "samsung,s6e63j0x03"; - reg = <0>; - vdd3-supply = <&ldo16_reg>; - vci-supply = <&ldo20_reg>; - reset-gpios = <&gpe0 1 GPIO_ACTIVE_LOW>; - te-gpios = <&gpx0 6 GPIO_ACTIVE_HIGH>; - }; -};
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt deleted file mode 100644 index 9fb9ebee..0000000 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt +++ /dev/null
@@ -1,33 +0,0 @@ -Samsung s6e63m0 AMOLED LCD panel - -Required properties: - - compatible: "samsung,s6e63m0" - - reset-gpios: GPIO spec for reset pin - - vdd3-supply: VDD regulator - - vci-supply: VCI regulator - -The panel must obey rules for SPI slave device specified in document [1]. - -The device node can contain one 'port' child node with one child -'endpoint' node, according to the bindings defined in [2]. This -node should describe panel's video bus. - -[1]: Documentation/devicetree/bindings/spi/spi-bus.txt -[2]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - - s6e63m0: display@0 { - compatible = "samsung,s6e63m0"; - reg = <0>; - reset-gpio = <&mp05 5 1>; - vdd3-supply = <&ldo12_reg>; - vci-supply = <&ldo11_reg>; - spi-max-frequency = <1200000>; - - port { - lcd_ep: endpoint { - remote-endpoint = <&fimd_ep>; - }; - }; - };
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml new file mode 100644 index 0000000..1dab80a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml
@@ -0,0 +1,60 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,s6e63m0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung s6e63m0 AMOLED LCD panel + +maintainers: + - Jonathan Bakker <xc-racer2@live.ca> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,s6e63m0 + + reg: true + reset-gpios: true + port: true + + vdd3-supply: + description: VDD regulator + + vci-supply: + description: VCI regulator + +required: + - compatible + - reset-gpios + - vdd3-supply + - vci-supply + - port + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + display@0 { + compatible = "samsung,s6e63m0"; + reg = <0>; + reset-gpios = <&mp05 5 1>; + vdd3-supply = <&ldo12_reg>; + vci-supply = <&ldo11_reg>; + spi-max-frequency = <1200000>; + + port { + lcd_ep: endpoint { + remote-endpoint = <&fimd_ep>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt deleted file mode 100644 index aae57ef3..0000000 --- a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt +++ /dev/null
@@ -1,23 +0,0 @@ -Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel - -Required properties: -- compatible: should be "sii,43wvf1g". -- "dvdd-supply": 3v3 digital regulator. -- "avdd-supply": 5v analog regulator. - -Optional properties: -- backlight: phandle for the backlight control. - -Example: - - panel { - compatible = "sii,43wvf1g"; - backlight = <&backlight_display>; - dvdd-supply = <®_lcd_3v3>; - avdd-supply = <®_lcd_5v>; - port { - panel_in: endpoint { - remote-endpoint = <&display_out>; - }; - }; - };
diff --git a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml new file mode 100644 index 0000000..cfaa50c --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml
@@ -0,0 +1,50 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/seiko,43wvf1g.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel + +maintainers: + - Marco Franchi <marco.franchi@nxp.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: sii,43wvf1g + + backlight: true + port: true + + dvdd-supply: + description: 3v3 digital regulator + + avdd-supply: + description: 5v analog regulator + +required: + - compatible + - dvdd-supply + - avdd-supply + +additionalProperties: false + +examples: + - | + panel { + compatible = "sii,43wvf1g"; + + backlight = <&backlight_display>; + dvdd-supply = <®_lcd_3v3>; + avdd-supply = <®_lcd_5v>; + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt deleted file mode 100644 index 0f57c31..0000000 --- a/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt +++ /dev/null
@@ -1,36 +0,0 @@ -Sharp 15" LQ150X1LG11 XGA TFT LCD panel - -Required properties: -- compatible: should be "sharp,lq150x1lg11" -- power-supply: regulator to provide the VCC supply voltage (3.3 volts) - -Optional properties: -- backlight: phandle of the backlight device -- rlud-gpios: a single GPIO for the RL/UD (rotate 180 degrees) pin. -- sellvds-gpios: a single GPIO for the SELLVDS pin. - -If rlud-gpios and/or sellvds-gpios are not specified, the RL/UD and/or SELLVDS -pins are assumed to be handled appropriately by the hardware. - -Example: - - backlight: backlight { - compatible = "pwm-backlight"; - pwms = <&pwm 0 100000>; /* VBR */ - - brightness-levels = <0 20 40 60 80 100>; - default-brightness-level = <2>; - - power-supply = <&vdd_12v_reg>; /* VDD */ - enable-gpios = <&gpio 42 GPIO_ACTIVE_HIGH>; /* XSTABY */ - }; - - panel { - compatible = "sharp,lq150x1lg11"; - - power-supply = <&vcc_3v3_reg>; /* VCC */ - - backlight = <&backlight>; - rlud-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>; /* RL/UD */ - sellvds-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>; /* SELLVDS */ - };
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.yaml b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.yaml new file mode 100644 index 0000000..92f2d12f --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.yaml
@@ -0,0 +1,58 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/sharp,lq150x1lg11.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sharp 15" LQ150X1LG11 XGA TFT LCD panel + +maintainers: + - Peter Rosin <peda@axentia.se> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: sharp,lq150x1lg11 + + power-supply: true + backlight: true + + rlud-gpios: + maxItems: 1 + description: | + GPIO for the RL/UD (rotate 180 degrees) pin. + If rlud-gpios and/or sellvds-gpios are not specified, + the RL/UD and/or SELLVDS pins are assumed to be handled + appropriately by the hardware. + + sellvds-gpios: + maxItems: 1 + description: | + GPIO for the SELLVDS pin. + If rlud-gpios and/or sellvds-gpios are not specified, + the RL/UD and/or SELLVDS pins are assumed to be handled + appropriately by the hardware. + +required: + - compatible + - power-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + panel { + compatible = "sharp,lq150x1lg11"; + + power-supply = <&vcc_3v3_reg>; /* VCC */ + + backlight = <&backlight>; + rlud-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>; /* RL/UD */ + sellvds-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>; /* SELLVDS */ + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/display/panel/sharp,ls037v7dw01.txt deleted file mode 100644 index 0cc8981..0000000 --- a/Documentation/devicetree/bindings/display/panel/sharp,ls037v7dw01.txt +++ /dev/null
@@ -1,43 +0,0 @@ -SHARP LS037V7DW01 TFT-LCD panel -=================================== - -Required properties: -- compatible: "sharp,ls037v7dw01" - -Optional properties: -- label: a symbolic name for the panel -- enable-gpios: a GPIO spec for the optional enable pin. - This pin is the INI pin as specified in the LS037V7DW01.pdf file. -- reset-gpios: a GPIO spec for the optional reset pin. - This pin is the RESB pin as specified in the LS037V7DW01.pdf file. -- mode-gpios: a GPIO - ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file. - -Required nodes: -- Video port for DPI input - -This panel can have zero to five GPIOs to configure to change configuration -between QVGA and VGA mode and the scan direction. As these pins can be also -configured with external pulls, all the GPIOs are considered optional with holes -in the array. - -Example -------- - -Example when connected to a omap2+ based device: - -lcd0: display { - compatible = "sharp,ls037v7dw01"; - power-supply = <&lcd_3v3>; - enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */ - reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */ - mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */ - &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */ - &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */ - - port { - lcd_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,ls037v7dw01.yaml b/Documentation/devicetree/bindings/display/panel/sharp,ls037v7dw01.yaml new file mode 100644 index 0000000..8c47a9b --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sharp,ls037v7dw01.yaml
@@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/sharp,ls037v7dw01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SHARP LS037V7DW01 TFT-LCD panel + +description: | + This panel can have zero to five GPIOs to configure to change configuration + between QVGA and VGA mode and the scan direction. As these pins can be also + configured with external pulls, all the GPIOs are considered optional with holes + in the array. + +maintainers: + - Tony Lindgren <tony@atomide.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: sharp,ls037v7dw01 + + label: true + enable-gpios: true + reset-gpios: true + port: true + power-supply: true + + mode-gpios: + minItems: 1 + maxItems: 3 + description: | + GPIO ordered MO, LR, and UD as specified in LS037V7DW01.pdf + This panel can have zero to three GPIOs to configure to + change configuration between QVGA and VGA mode and the + scan direction. As these pins can be also configured + with external pulls, all the GPIOs are considered + optional with holes in the array. + +required: + - compatible + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + lcd0: display { + compatible = "sharp,ls037v7dw01"; + power-supply = <&lcd_3v3>; + enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */ + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */ + mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */ + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */ + &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */ + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt b/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt deleted file mode 100644 index 3770a11..0000000 --- a/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt +++ /dev/null
@@ -1,22 +0,0 @@ -Sharp Microelectronics 4.3" qHD TFT LCD panel - -Required properties: -- compatible: should be "sharp,ls043t1le01-qhd" -- reg: DSI virtual channel of the peripheral -- power-supply: phandle of the regulator that provides the supply voltage - -Optional properties: -- backlight: phandle of the backlight device attached to the panel -- reset-gpios: a GPIO spec for the reset pin - -Example: - - mdss_dsi@fd922800 { - panel@0 { - compatible = "sharp,ls043t1le01-qhd"; - reg = <0>; - avdd-supply = <&pm8941_l22>; - backlight = <&pm8941_wled>; - reset-gpios = <&pm8941_gpios 19 GPIO_ACTIVE_HIGH>; - }; - };
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.yaml b/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.yaml new file mode 100644 index 0000000..a90d0d8 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.yaml
@@ -0,0 +1,51 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/sharp,ls043t1le01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sharp Microelectronics 4.3" qHD TFT LCD panel + +maintainers: + - Werner Johansson <werner.johansson@sonymobile.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: sharp,ls043t1le01-qhd + + reg: true + backlight: true + reset-gpios: true + port: true + + avdd-supply: + description: handle of the regulator that provides the supply voltage + +required: + - compatible + - reg + - avdd-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "sharp,ls043t1le01-qhd"; + reg = <0>; + avdd-supply = <&pm8941_l22>; + backlight = <&pm8941_wled>; + reset-gpios = <&pm8941_gpios 19 GPIO_ACTIVE_HIGH>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt deleted file mode 100644 index e11208f..0000000 --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt +++ /dev/null
@@ -1 +0,0 @@ -See panel-common.yaml in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt deleted file mode 100644 index ccd1759..0000000 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt +++ /dev/null
@@ -1,30 +0,0 @@ -Sitronix ST7701 based LCD panels - -ST7701 designed for small and medium sizes of TFT LCD display, is -capable of supporting up to 480RGBX864 in resolution. It provides -several system interfaces like MIPI/RGB/SPI. - -Techstar TS8550B is 480x854, 2-lane MIPI DSI LCD panel which has -inbuilt ST7701 chip. - -Required properties: -- compatible: must be "sitronix,st7701" and one of - * "techstar,ts8550b" -- reset-gpios: a GPIO phandle for the reset pin - -Required properties for techstar,ts8550b: -- reg: DSI virtual channel used by that screen -- VCC-supply: analog regulator for MIPI circuit -- IOVCC-supply: I/O system regulator - -Optional properties: -- backlight: phandle for the backlight control. - -panel@0 { - compatible = "techstar,ts8550b", "sitronix,st7701"; - reg = <0>; - VCC-supply = <®_dldo2>; - IOVCC-supply = <®_dldo2>; - reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */ - backlight = <&backlight>; -};
diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml new file mode 100644 index 0000000..6dff59f --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
@@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/sitronix,st7701.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sitronix ST7701 based LCD panels + +maintainers: + - Jagan Teki <jagan@amarulasolutions.com> + +description: | + ST7701 designed for small and medium sizes of TFT LCD display, is + capable of supporting up to 480RGBX864 in resolution. It provides + several system interfaces like MIPI/RGB/SPI. + + Techstar TS8550B is 480x854, 2-lane MIPI DSI LCD panel which has + inbuilt ST7701 chip. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + - techstar,ts8550b + - const: sitronix,st7701 + + reg: + description: DSI virtual channel used by that screen + maxItems: 1 + + VCC-supply: + description: analog regulator for MIPI circuit + + IOVCC-supply: + description: I/O system regulator + + reset-gpios: true + + backlight: true + +required: + - compatible + - reg + - VCC-supply + - IOVCC-supply + - reset-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "techstar,ts8550b", "sitronix,st7701"; + reg = <0>; + VCC-supply = <®_dldo2>; + IOVCC-supply = <®_dldo2>; + reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */ + backlight = <&backlight>; + }; + };
diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt deleted file mode 100644 index c6995dd..0000000 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt +++ /dev/null
@@ -1,37 +0,0 @@ -Sitronix ST7789V RGB panel with SPI control bus - -Required properties: - - compatible: "sitronix,st7789v" - - reg: Chip select of the panel on the SPI bus - - reset-gpios: a GPIO phandle for the reset pin - - power-supply: phandle of the regulator that provides the supply voltage - -Optional properties: - - backlight: phandle to the backlight used - -The generic bindings for the SPI slaves documented in [1] also applies - -The device node can contain one 'port' child node with one child -'endpoint' node, according to the bindings defined in [2]. This -node should describe panel's video bus. - -[1]: Documentation/devicetree/bindings/spi/spi-bus.txt -[2]: Documentation/devicetree/bindings/graph.txt - -Example: - -panel@0 { - compatible = "sitronix,st7789v"; - reg = <0>; - reset-gpios = <&pio 6 11 GPIO_ACTIVE_LOW>; - backlight = <&pwm_bl>; - spi-max-frequency = <100000>; - spi-cpol; - spi-cpha; - - port { - panel_input: endpoint { - remote-endpoint = <&tcon0_out_panel>; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml new file mode 100644 index 0000000..fa46d15 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml
@@ -0,0 +1,63 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/sitronix,st7789v.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sitronix ST7789V RGB panel with SPI control bus + +description: | + The panel must obey the rules for a SPI slave device as specified in + spi/spi-controller.yaml + +maintainers: + - Maxime Ripard <mripard@kernel.org> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: sitronix,st7789v + + reg: true + reset-gpios: true + power-supply: true + backlight: true + port: true + +required: + - compatible + - reg + - reset-gpios + - power-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "sitronix,st7789v"; + reg = <0>; + reset-gpios = <&pio 6 11 GPIO_ACTIVE_LOW>; + backlight = <&pwm_bl>; + power-supply = <&power>; + spi-max-frequency = <100000>; + spi-cpol; + spi-cpha; + + port { + panel_input: endpoint { + remote-endpoint = <&tcon0_out_panel>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml index 185dcc8..78d06009 100644 --- a/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml +++ b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
@@ -18,7 +18,7 @@ reg: true reset-gpios: true vddi-supply: - description: regulator that supplies the vddi voltage + description: regulator that supplies the vddi voltage enforce-video-mode: true required:
diff --git a/Documentation/devicetree/bindings/display/panel/sony,acx565akm.txt b/Documentation/devicetree/bindings/display/panel/sony,acx565akm.txt deleted file mode 100644 index e123332..0000000 --- a/Documentation/devicetree/bindings/display/panel/sony,acx565akm.txt +++ /dev/null
@@ -1,30 +0,0 @@ -Sony ACX565AKM SDI Panel -======================== - -Required properties: -- compatible: "sony,acx565akm" - -Optional properties: -- label: a symbolic name for the panel -- reset-gpios: panel reset gpio - -Required nodes: -- Video port for SDI input - -Example -------- - -acx565akm@2 { - compatible = "sony,acx565akm"; - spi-max-frequency = <6000000>; - reg = <2>; - - label = "lcd"; - reset-gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */ - - port { - lcd_in: endpoint { - remote-endpoint = <&sdi_out>; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml b/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml new file mode 100644 index 0000000..95d053c --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml
@@ -0,0 +1,57 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/sony,acx565akm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sony ACX565AKM SDI Panel + +description: | + The panel must obey the rules for a SPI slave device as specified in + spi/spi-controller.yaml + +maintainers: + - Tomi Valkeinen <tomi.valkeinen@ti.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: sony,acx565akm + + label: true + reset-gpios: true + port: true + +required: + - compatible + - port + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + panel@2 { + compatible = "sony,acx565akm"; + spi-max-frequency = <6000000>; + reg = <2>; + + label = "lcd"; + reset-gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */ + + port { + lcd_in: endpoint { + remote-endpoint = <&sdi_out>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.txt b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.txt deleted file mode 100644 index 70cd8d1..0000000 --- a/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.txt +++ /dev/null
@@ -1,4 +0,0 @@ -Startek Electronic Technology Co. KD050C 5.0" WVGA TFT LCD panel - -Required properties: -- compatible: should be "startek,startek-kd050c"
diff --git a/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.yaml b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.yaml new file mode 100644 index 0000000..fd66864 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.yaml
@@ -0,0 +1,33 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/startek,startek-kd050c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Startek Electronic Technology Co. KD050C 5.0" WVGA TFT LCD panel + +maintainers: + - Nikita Kiryanov <nikita@compulab.co.il> + +allOf: + - $ref: panel-dpi.yaml# + +properties: + compatible: + items: + - const: startek,startek-kd050c + - {} # panel-dpi, but not listed here to avoid false select + + backlight: true + enable-gpios: true + height-mm: true + label: true + panel-timing: true + port: true + power-supply: true + reset-gpios: true + width-mm: true + +additionalProperties: false + +...
diff --git a/Documentation/devicetree/bindings/display/panel/tpo,td.yaml b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml new file mode 100644 index 0000000..4aa6056 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml
@@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/tpo,td.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Toppoly TD Panels + +description: | + The panel must obey the rules for a SPI slave device as specified in + spi/spi-controller.yaml + +maintainers: + - Marek Belisko <marek@goldelico.com> + - H. Nikolaus Schaller <hns@goldelico.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + enum: + # Toppoly TD028TTEC1 Panel + - tpo,td028ttec1 + # Toppoly TD043MTEA1 Panel + - tpo,td043mtea1 + + reg: true + label: true + reset-gpios: true + backlight: true + port: true + +required: + - compatible + - port + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + panel: panel@0 { + compatible = "tpo,td043mtea1"; + reg = <0>; + spi-max-frequency = <100000>; + spi-cpol; + spi-cpha; + + label = "lcd"; + + reset-gpios = <&gpio7 7 0>; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt deleted file mode 100644 index 898e06e..0000000 --- a/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt +++ /dev/null
@@ -1,32 +0,0 @@ -Toppoly TD028TTEC1 Panel -======================== - -Required properties: -- compatible: "tpo,td028ttec1" - -Optional properties: -- label: a symbolic name for the panel -- backlight: phandle of the backlight device - -Required nodes: -- Video port for DPI input - -Example -------- - -lcd-panel: td028ttec1@0 { - compatible = "tpo,td028ttec1"; - reg = <0>; - spi-max-frequency = <100000>; - spi-cpol; - spi-cpha; - - label = "lcd"; - backlight = <&backlight>; - port { - lcd_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; -}; -
diff --git a/Documentation/devicetree/bindings/display/panel/tpo,td043mtea1.txt b/Documentation/devicetree/bindings/display/panel/tpo,td043mtea1.txt deleted file mode 100644 index ec6d629..0000000 --- a/Documentation/devicetree/bindings/display/panel/tpo,td043mtea1.txt +++ /dev/null
@@ -1,33 +0,0 @@ -TPO TD043MTEA1 Panel -==================== - -Required properties: -- compatible: "tpo,td043mtea1" -- reset-gpios: panel reset gpio - -Optional properties: -- label: a symbolic name for the panel - -Required nodes: -- Video port for DPI input - -Example -------- - -lcd-panel: panel@0 { - compatible = "tpo,td043mtea1"; - reg = <0>; - spi-max-frequency = <100000>; - spi-cpol; - spi-cpha; - - label = "lcd"; - - reset-gpios = <&gpio7 7 0>; - - port { - lcd_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml new file mode 100644 index 0000000..b36f39f --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
@@ -0,0 +1,57 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/visionox,rm69299.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Visionox model RM69299 Panels Device Tree Bindings. + +maintainers: + - Harigovindan P <harigovi@codeaurora.org> + +description: | + This binding is for display panels using a Visionox RM692999 panel. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: visionox,rm69299-1080p-display + + vdda-supply: + description: | + Phandle of the regulator that provides the vdda supply voltage. + + vdd3p3-supply: + description: | + Phandle of the regulator that provides the vdd3p3 supply voltage. + + port: true + reset-gpios: true + +additionalProperties: false + +required: + - compatible + - vdda-supply + - vdd3p3-supply + - reset-gpios + - port + +examples: + - | + panel { + compatible = "visionox,rm69299-1080p-display"; + + vdda-supply = <&src_pp1800_l8c>; + vdd3p3-supply = <&src_pp2800_l18a>; + + reset-gpios = <&pm6150l_gpio 3 0>; + port { + panel0_in: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml index d9fdb58..d5c46a3 100644 --- a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml +++ b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
@@ -19,9 +19,9 @@ backlight: true reset-gpios: true iovcc-supply: - description: regulator that supplies the iovcc voltage + description: regulator that supplies the iovcc voltage vci-supply: - description: regulator that supplies the vci voltage + description: regulator that supplies the vci voltage required: - compatible @@ -37,7 +37,6 @@ dsi { #address-cells = <1>; #size-cells = <0>; - reg = <0xff450000 0x1000>; panel@0 { compatible = "xinpeng,xpp055c272";
diff --git a/Documentation/devicetree/bindings/display/renesas,cmm.yaml b/Documentation/devicetree/bindings/display/renesas,cmm.yaml index a57037b..561efaa 100644 --- a/Documentation/devicetree/bindings/display/renesas,cmm.yaml +++ b/Documentation/devicetree/bindings/display/renesas,cmm.yaml
@@ -21,15 +21,15 @@ compatible: oneOf: - items: - - enum: - - renesas,r8a7795-cmm - - renesas,r8a7796-cmm - - renesas,r8a77965-cmm - - renesas,r8a77990-cmm - - renesas,r8a77995-cmm - - const: renesas,rcar-gen3-cmm + - enum: + - renesas,r8a7795-cmm + - renesas,r8a7796-cmm + - renesas,r8a77965-cmm + - renesas,r8a77990-cmm + - renesas,r8a77995-cmm + - const: renesas,rcar-gen3-cmm - items: - - const: renesas,rcar-gen2-cmm + - const: renesas,rcar-gen2-cmm reg: maxItems: 1 @@ -60,7 +60,7 @@ cmm0: cmm@fea40000 { compatible = "renesas,r8a7796-cmm", "renesas,rcar-gen3-cmm"; - reg = <0 0xfea40000 0 0x1000>; + reg = <0xfea40000 0x1000>; power-domains = <&sysc R8A7796_PD_ALWAYS_ON>; clocks = <&cpg CPG_MOD 711>; resets = <&cpg 711>;
diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt index eb4ae41..51cd4d1 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.txt +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -50,6 +50,14 @@ VSP instance that serves the DU channel, and the channel index identifies the LIF instance in that VSP. +Optional properties: + - resets: A list of phandle + reset-specifier pairs, one for each entry in + the reset-names property. + - reset-names: Names of the resets. This property is model-dependent. + - All but R8A7779 use one reset for a group of one or more successive + channels. The resets must be named "du.x" with "x" being the numerical + index of the lowest channel in the group. + Required nodes: The connections to the DU output video ports are modeled using the OF graph @@ -96,6 +104,8 @@ <&cpg CPG_MOD 722>, <&cpg CPG_MOD 721>; clock-names = "du.0", "du.1", "du.2", "du.3"; + resets = <&cpg 724>, <&cpg 722>; + reset-names = "du.0", "du.2"; renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>; renesas,vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt deleted file mode 100644 index d1ad31bc..0000000 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt +++ /dev/null
@@ -1,72 +0,0 @@ -Rockchip specific extensions for rk3066 HDMI -============================================ - -Required properties: -- compatible: - "rockchip,rk3066-hdmi"; -- reg: - Physical base address and length of the controller's registers. -- clocks, clock-names: - Phandle to HDMI controller clock, name should be "hclk". -- interrupts: - HDMI interrupt number. -- power-domains: - Phandle to the RK3066_PD_VIO power domain. -- rockchip,grf: - This soc uses GRF regs to switch the HDMI TX input between vop0 and vop1. -- ports: - Contains one port node with two endpoints, numbered 0 and 1, - connected respectively to vop0 and vop1. - Contains one port node with one endpoint - connected to a hdmi-connector node. -- pinctrl-0, pinctrl-name: - Switch the iomux for the HPD/I2C pins to HDMI function. - -Example: - hdmi: hdmi@10116000 { - compatible = "rockchip,rk3066-hdmi"; - reg = <0x10116000 0x2000>; - interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cru HCLK_HDMI>; - clock-names = "hclk"; - power-domains = <&power RK3066_PD_VIO>; - rockchip,grf = <&grf>; - pinctrl-names = "default"; - pinctrl-0 = <&hdmii2c_xfer>, <&hdmi_hpd>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - hdmi_in: port@0 { - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - hdmi_in_vop0: endpoint@0 { - reg = <0>; - remote-endpoint = <&vop0_out_hdmi>; - }; - hdmi_in_vop1: endpoint@1 { - reg = <1>; - remote-endpoint = <&vop1_out_hdmi>; - }; - }; - hdmi_out: port@1 { - reg = <1>; - hdmi_out_con: endpoint { - remote-endpoint = <&hdmi_con_in>; - }; - }; - }; - }; - -&pinctrl { - hdmi { - hdmi_hpd: hdmi-hpd { - rockchip,pins = <0 RK_PA0 1 &pcfg_pull_default>; - }; - hdmii2c_xfer: hdmii2c-xfer { - rockchip,pins = <0 RK_PA1 1 &pcfg_pull_none>, - <0 RK_PA2 1 &pcfg_pull_none>; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml new file mode 100644 index 0000000..4110d00 --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
@@ -0,0 +1,140 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/rockchip/rockchip,rk3066-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip rk3066 HDMI controller + +maintainers: + - Sandy Huang <hjc@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + const: rockchip,rk3066-hdmi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: hclk + + pinctrl-0: + maxItems: 2 + + pinctrl-names: + const: default + description: + Switch the iomux for the HPD/I2C pins to HDMI function. + + power-domains: + maxItems: 1 + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + This soc uses GRF regs to switch the HDMI TX input between vop0 and vop1. + + ports: + type: object + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + port@0: + type: object + description: + Port node with two endpoints, numbered 0 and 1, + connected respectively to vop0 and vop1. + + port@1: + type: object + description: + Port node with one endpoint connected to a hdmi-connector node. + + required: + - "#address-cells" + - "#size-cells" + - port@0 + - port@1 + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - pinctrl-0 + - pinctrl-names + - power-domains + - rockchip,grf + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3066a-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/pinctrl/rockchip.h> + #include <dt-bindings/power/rk3066-power.h> + hdmi: hdmi@10116000 { + compatible = "rockchip,rk3066-hdmi"; + reg = <0x10116000 0x2000>; + interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru HCLK_HDMI>; + clock-names = "hclk"; + pinctrl-0 = <&hdmii2c_xfer>, <&hdmi_hpd>; + pinctrl-names = "default"; + power-domains = <&power RK3066_PD_VIO>; + rockchip,grf = <&grf>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + hdmi_in: port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + hdmi_in_vop0: endpoint@0 { + reg = <0>; + remote-endpoint = <&vop0_out_hdmi>; + }; + hdmi_in_vop1: endpoint@1 { + reg = <1>; + remote-endpoint = <&vop1_out_hdmi>; + }; + }; + hdmi_out: port@1 { + reg = <1>; + hdmi_out_con: endpoint { + remote-endpoint = <&hdmi_con_in>; + }; + }; + }; + }; + + pinctrl { + hdmi { + hdmi_hpd: hdmi-hpd { + rockchip,pins = <0 RK_PA0 1 &pcfg_pull_default>; + }; + hdmii2c_xfer: hdmii2c-xfer { + rockchip,pins = <0 RK_PA1 1 &pcfg_pull_none>, + <0 RK_PA2 1 &pcfg_pull_none>; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt deleted file mode 100644 index 8b3a5f5..0000000 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt +++ /dev/null
@@ -1,74 +0,0 @@ -device-tree bindings for rockchip soc display controller (vop) - -VOP (Visual Output Processor) is the Display Controller for the Rockchip -series of SoCs which transfers the image data from a video memory -buffer to an external LCD interface. - -Required properties: -- compatible: value should be one of the following - "rockchip,rk3036-vop"; - "rockchip,rk3126-vop"; - "rockchip,px30-vop-lit"; - "rockchip,px30-vop-big"; - "rockchip,rk3066-vop"; - "rockchip,rk3188-vop"; - "rockchip,rk3288-vop"; - "rockchip,rk3368-vop"; - "rockchip,rk3366-vop"; - "rockchip,rk3399-vop-big"; - "rockchip,rk3399-vop-lit"; - "rockchip,rk3228-vop"; - "rockchip,rk3328-vop"; - -- reg: Must contain one entry corresponding to the base address and length - of the register space. Can optionally contain a second entry - corresponding to the CRTC gamma LUT address. - -- interrupts: should contain a list of all VOP IP block interrupts in the - order: VSYNC, LCD_SYSTEM. The interrupt specifier - format depends on the interrupt controller used. - -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. - -- clock-names: Must contain - aclk_vop: for ddr buffer transfer. - hclk_vop: for ahb bus to R/W the phy regs. - dclk_vop: pixel clock. - -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names: Must include the following entries: - - axi - - ahb - - dclk - -- iommus: required a iommu node - -- port: A port node with endpoint definitions as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt. - -Example: -SoC specific DT entry: - vopb: vopb@ff930000 { - compatible = "rockchip,rk3288-vop"; - reg = <0x0 0xff930000 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>; - interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>; - clock-names = "aclk_vop", "dclk_vop", "hclk_vop"; - resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru SRST_LCDC1_DCLK>; - reset-names = "axi", "ahb", "dclk"; - iommus = <&vopb_mmu>; - vopb_out: port { - #address-cells = <1>; - #size-cells = <0>; - vopb_out_edp: endpoint@0 { - reg = <0>; - remote-endpoint=<&edp_in_vopb>; - }; - vopb_out_hdmi: endpoint@1 { - reg = <1>; - remote-endpoint=<&hdmi_in_vopb>; - }; - }; - };
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml new file mode 100644 index 0000000..ed8148e --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
@@ -0,0 +1,134 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/rockchip/rockchip-vop.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip SoC display controller (VOP) + +description: + VOP (Video Output Processor) is the display controller for the Rockchip + series of SoCs which transfers the image data from a video memory + buffer to an external LCD interface. + +maintainers: + - Sandy Huang <hjc@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + enum: + - rockchip,px30-vop-big + - rockchip,px30-vop-lit + - rockchip,rk3036-vop + - rockchip,rk3066-vop + - rockchip,rk3126-vop + - rockchip,rk3188-vop + - rockchip,rk3228-vop + - rockchip,rk3288-vop + - rockchip,rk3328-vop + - rockchip,rk3366-vop + - rockchip,rk3368-vop + - rockchip,rk3399-vop-big + - rockchip,rk3399-vop-lit + + reg: + minItems: 1 + items: + - description: + Must contain one entry corresponding to the base address and length + of the register space. + - description: + Can optionally contain a second entry corresponding to + the CRTC gamma LUT address. + + interrupts: + maxItems: 1 + description: + The VOP interrupt is shared by several interrupt sources, such as + frame start (VSYNC), line flag and other status interrupts. + + clocks: + items: + - description: Clock for ddr buffer transfer. + - description: Pixel clock. + - description: Clock for the ahb bus to R/W the phy regs. + + clock-names: + items: + - const: aclk_vop + - const: dclk_vop + - const: hclk_vop + + resets: + maxItems: 3 + + reset-names: + items: + - const: axi + - const: ahb + - const: dclk + + port: + type: object + description: + A port node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + + assigned-clocks: + maxItems: 2 + + assigned-clock-rates: + maxItems: 2 + + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - reset-names + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3288-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/rk3288-power.h> + vopb: vopb@ff930000 { + compatible = "rockchip,rk3288-vop"; + reg = <0xff930000 0x19c>, + <0xff931000 0x1000>; + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru ACLK_VOP0>, + <&cru DCLK_VOP0>, + <&cru HCLK_VOP0>; + clock-names = "aclk_vop", "dclk_vop", "hclk_vop"; + power-domains = <&power RK3288_PD_VIO>; + resets = <&cru SRST_LCDC1_AXI>, + <&cru SRST_LCDC1_AHB>, + <&cru SRST_LCDC1_DCLK>; + reset-names = "axi", "ahb", "dclk"; + iommus = <&vopb_mmu>; + vopb_out: port { + #address-cells = <1>; + #size-cells = <0>; + vopb_out_edp: endpoint@0 { + reg = <0>; + remote-endpoint=<&edp_in_vopb>; + }; + vopb_out_hdmi: endpoint@1 { + reg = <1>; + remote-endpoint=<&hdmi_in_vopb>; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt index 9999255..4731921 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
@@ -40,14 +40,30 @@ Required properties: - compatible: "nvidia,tegra<chip>-vi" - - reg: Physical base address and length of the controller's registers. + - reg: Physical base address and length of the controller registers. - interrupts: The interrupt outputs from the controller. - - clocks: Must contain one entry, for the module clock. + - clocks: clocks: Must contain one entry, for the module clock. See ../clocks/clock-bindings.txt for details. - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - vi + - Tegra20/Tegra30/Tegra114/Tegra124: + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - vi + - Tegra210: + - power-domains: Must include venc powergate node as vi is in VE partition. + - Tegra210 has CSI part of VI sharing same host interface and register space. + So, VI device node should have CSI child node. + + - csi: mipi csi interface to vi + + Required properties: + - compatible: "nvidia,tegra210-csi" + - reg: Physical base address offset to parent and length of the controller + registers. + - clocks: Must contain entries csi, cilab, cilcd, cile, csi_tpg clocks. + See ../clocks/clock-bindings.txt for details. + - power-domains: Must include sor powergate node as csicil is in + SOR partition. - epp: encoder pre-processor @@ -309,13 +325,44 @@ reset-names = "mpe"; }; - vi { - compatible = "nvidia,tegra20-vi"; - reg = <0x54080000 0x00040000>; - interrupts = <0 69 0x04>; - clocks = <&tegra_car TEGRA20_CLK_VI>; - resets = <&tegra_car 100>; - reset-names = "vi"; + vi@54080000 { + compatible = "nvidia,tegra210-vi"; + reg = <0x0 0x54080000 0x0 0x700>; + interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; + assigned-clocks = <&tegra_car TEGRA210_CLK_VI>; + assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_C4_OUT0>; + + clocks = <&tegra_car TEGRA210_CLK_VI>; + power-domains = <&pd_venc>; + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x0 0x0 0x54080000 0x2000>; + + csi@838 { + compatible = "nvidia,tegra210-csi"; + reg = <0x838 0x1300>; + assigned-clocks = <&tegra_car TEGRA210_CLK_CILAB>, + <&tegra_car TEGRA210_CLK_CILCD>, + <&tegra_car TEGRA210_CLK_CILE>, + <&tegra_car TEGRA210_CLK_CSI_TPG>; + assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_P>, + <&tegra_car TEGRA210_CLK_PLL_P>, + <&tegra_car TEGRA210_CLK_PLL_P>; + assigned-clock-rates = <102000000>, + <102000000>, + <102000000>, + <972000000>; + + clocks = <&tegra_car TEGRA210_CLK_CSI>, + <&tegra_car TEGRA210_CLK_CILAB>, + <&tegra_car TEGRA210_CLK_CILCD>, + <&tegra_car TEGRA210_CLK_CILE>, + <&tegra_car TEGRA210_CLK_CSI_TPG>; + clock-names = "csi", "cilab", "cilcd", "cile", "csi_tpg"; + power-domains = <&pd_sor>; + }; }; epp {
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index eb04c23..4f91854 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -88,9 +88,8 @@ - "#size-cells" ti,am65x-oldi-io-ctrl: - allOf: - - $ref: "/schemas/types.yaml#/definitions/phandle-array" - - maxItems: 1 + $ref: "/schemas/types.yaml#/definitions/phandle-array" + maxItems: 1 description: phandle to syscon device node mapping OLDI IO_CTRL registers. The mapped range should point to OLDI_DAT0_IO_CTRL, map it and @@ -123,13 +122,13 @@ dss: dss@4a00000 { compatible = "ti,am65x-dss"; - reg = <0x0 0x04a00000 0x0 0x1000>, /* common */ - <0x0 0x04a02000 0x0 0x1000>, /* vidl1 */ - <0x0 0x04a06000 0x0 0x1000>, /* vid */ - <0x0 0x04a07000 0x0 0x1000>, /* ovr1 */ - <0x0 0x04a08000 0x0 0x1000>, /* ovr2 */ - <0x0 0x04a0a000 0x0 0x1000>, /* vp1 */ - <0x0 0x04a0b000 0x0 0x1000>; /* vp2 */ + reg = <0x04a00000 0x1000>, /* common */ + <0x04a02000 0x1000>, /* vidl1 */ + <0x04a06000 0x1000>, /* vid */ + <0x04a07000 0x1000>, /* ovr1 */ + <0x04a08000 0x1000>, /* ovr2 */ + <0x04a0a000 0x1000>, /* vp1 */ + <0x04a0b000 0x1000>; /* vp2 */ reg-names = "common", "vidl1", "vid", "ovr1", "ovr2", "vp1", "vp2"; ti,am65x-oldi-io-ctrl = <&dss_oldi_io_ctrl>;
diff --git a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml index eb4b1a2..bbd76591 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
@@ -156,23 +156,23 @@ dss: dss@4a00000 { compatible = "ti,j721e-dss"; - reg = <0x00 0x04a00000 0x00 0x10000>, /* common_m */ - <0x00 0x04a10000 0x00 0x10000>, /* common_s0*/ - <0x00 0x04b00000 0x00 0x10000>, /* common_s1*/ - <0x00 0x04b10000 0x00 0x10000>, /* common_s2*/ - <0x00 0x04a20000 0x00 0x10000>, /* vidl1 */ - <0x00 0x04a30000 0x00 0x10000>, /* vidl2 */ - <0x00 0x04a50000 0x00 0x10000>, /* vid1 */ - <0x00 0x04a60000 0x00 0x10000>, /* vid2 */ - <0x00 0x04a70000 0x00 0x10000>, /* ovr1 */ - <0x00 0x04a90000 0x00 0x10000>, /* ovr2 */ - <0x00 0x04ab0000 0x00 0x10000>, /* ovr3 */ - <0x00 0x04ad0000 0x00 0x10000>, /* ovr4 */ - <0x00 0x04a80000 0x00 0x10000>, /* vp1 */ - <0x00 0x04aa0000 0x00 0x10000>, /* vp2 */ - <0x00 0x04ac0000 0x00 0x10000>, /* vp3 */ - <0x00 0x04ae0000 0x00 0x10000>, /* vp4 */ - <0x00 0x04af0000 0x00 0x10000>; /* wb */ + reg = <0x04a00000 0x10000>, /* common_m */ + <0x04a10000 0x10000>, /* common_s0*/ + <0x04b00000 0x10000>, /* common_s1*/ + <0x04b10000 0x10000>, /* common_s2*/ + <0x04a20000 0x10000>, /* vidl1 */ + <0x04a30000 0x10000>, /* vidl2 */ + <0x04a50000 0x10000>, /* vid1 */ + <0x04a60000 0x10000>, /* vid2 */ + <0x04a70000 0x10000>, /* ovr1 */ + <0x04a90000 0x10000>, /* ovr2 */ + <0x04ab0000 0x10000>, /* ovr3 */ + <0x04ad0000 0x10000>, /* ovr4 */ + <0x04a80000 0x10000>, /* vp1 */ + <0x04aa0000 0x10000>, /* vp2 */ + <0x04ac0000 0x10000>, /* vp3 */ + <0x04ae0000 0x10000>, /* vp4 */ + <0x04af0000 0x10000>; /* wb */ reg-names = "common_m", "common_s0", "common_s1", "common_s2", "vidl1", "vidl2","vid1","vid2",
diff --git a/Documentation/devicetree/bindings/dma/dma-common.yaml b/Documentation/devicetree/bindings/dma/dma-common.yaml index 02a34ba..c365926 100644 --- a/Documentation/devicetree/bindings/dma/dma-common.yaml +++ b/Documentation/devicetree/bindings/dma/dma-common.yaml
@@ -31,8 +31,7 @@ kernel. i.e. first channel corresponds to LSB. The first item in the array is for channels 0-31, the second is for channels 32-63, etc. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array items: minItems: 1 # Should be enough
diff --git a/Documentation/devicetree/bindings/dma/fsl-edma.txt b/Documentation/devicetree/bindings/dma/fsl-edma.txt index e77b08e..ee17547 100644 --- a/Documentation/devicetree/bindings/dma/fsl-edma.txt +++ b/Documentation/devicetree/bindings/dma/fsl-edma.txt
@@ -10,7 +10,8 @@ - compatible : - "fsl,vf610-edma" for eDMA used similar to that on Vybrid vf610 SoC - "fsl,imx7ulp-edma" for eDMA2 used similar to that on i.mx7ulp - - "fsl,fsl,ls1028a-edma" for eDMA used similar to that on Vybrid vf610 SoC + - "fsl,ls1028a-edma" followed by "fsl,vf610-edma" for eDMA used on the + LS1028A SoC. - reg : Specifies base physical address(s) and size of the eDMA registers. The 1st region is eDMA control register's address and size. The 2nd and the 3rd regions are programmable channel multiplexing
diff --git a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml new file mode 100644 index 0000000..92794c5 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml
@@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/ingenic,dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs DMA Controller DT bindings + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + enum: + - ingenic,jz4740-dma + - ingenic,jz4725b-dma + - ingenic,jz4770-dma + - ingenic,jz4780-dma + - ingenic,x1000-dma + - ingenic,x1830-dma + + reg: + items: + - description: Channel-specific registers + - description: System control registers + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + "#dma-cells": + const: 2 + description: > + DMA clients must use the format described in dma.txt, giving a phandle + to the DMA controller plus the following 2 integer cells: + + - Request type: The DMA request type for transfers to/from the + device on the allocated channel, as defined in the SoC documentation. + + - Channel: If set to 0xffffffff, any available channel will be allocated + for the client. Otherwise, the exact channel specified will be used. + The channel should be reserved on the DMA controller using the + ingenic,reserved-channels property. + + ingenic,reserved-channels: + $ref: /schemas/types.yaml#definitions/uint32 + description: > + Bitmask of channels to reserve for devices that need a specific + channel. These channels will only be assigned when explicitely + requested by a client. The primary use for this is channels 0 and + 1, which can be configured to have special behaviour for NAND/BCH + when using programmable firmware. + +required: + - compatible + - reg + - interrupts + - clocks + +examples: + - | + #include <dt-bindings/clock/jz4780-cgu.h> + dma: dma-controller@13420000 { + compatible = "ingenic,jz4780-dma"; + reg = <0x13420000 0x400>, <0x13421000 0x40>; + + interrupt-parent = <&intc>; + interrupts = <10>; + + clocks = <&cgu JZ4780_CLK_PDMA>; + + #dma-cells = <2>; + + ingenic,reserved-channels = <0x3>; + };
diff --git a/Documentation/devicetree/bindings/dma/jz4780-dma.txt b/Documentation/devicetree/bindings/dma/jz4780-dma.txt deleted file mode 100644 index 3459e77..0000000 --- a/Documentation/devicetree/bindings/dma/jz4780-dma.txt +++ /dev/null
@@ -1,64 +0,0 @@ -* Ingenic XBurst DMA Controller - -Required properties: - -- compatible: Should be one of: - * ingenic,jz4740-dma - * ingenic,jz4725b-dma - * ingenic,jz4770-dma - * ingenic,jz4780-dma - * ingenic,x1000-dma - * ingenic,x1830-dma -- reg: Should contain the DMA channel registers location and length, followed - by the DMA controller registers location and length. -- interrupts: Should contain the interrupt specifier of the DMA controller. -- clocks: Should contain a clock specifier for the JZ4780/X1000/X1830 PDMA - clock. -- #dma-cells: Must be <2>. Number of integer cells in the dmas property of - DMA clients (see below). - -Optional properties: - -- ingenic,reserved-channels: Bitmask of channels to reserve for devices that - need a specific channel. These channels will only be assigned when explicitly - requested by a client. The primary use for this is channels 0 and 1, which - can be configured to have special behaviour for NAND/BCH when using - programmable firmware. - -Example: - -dma: dma-controller@13420000 { - compatible = "ingenic,jz4780-dma"; - reg = <0x13420000 0x400 - 0x13421000 0x40>; - - interrupt-parent = <&intc>; - interrupts = <10>; - - clocks = <&cgu JZ4780_CLK_PDMA>; - - #dma-cells = <2>; - - ingenic,reserved-channels = <0x3>; -}; - -DMA clients must use the format described in dma.txt, giving a phandle to the -DMA controller plus the following 2 integer cells: - -1. Request type: The DMA request type for transfers to/from the device on - the allocated channel, as defined in the SoC documentation. - -2. Channel: If set to 0xffffffff, any available channel will be allocated for - the client. Otherwise, the exact channel specified will be used. The channel - should be reserved on the DMA controller using the ingenic,reserved-channels - property. - -Example: - -uart0: serial@10030000 { - ... - dmas = <&dma 0x14 0xffffffff - &dma 0x15 0xffffffff>; - dma-names = "tx", "rx"; - ... -};
diff --git a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt b/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt index 5d6f98c..2117db0 100644 --- a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt +++ b/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt
@@ -21,7 +21,8 @@ Examples: apdma: dma-controller@11000400 { - compatible = "mediatek,mt2712-uart-dma"; + compatible = "mediatek,mt2712-uart-dma", + "mediatek,mt6577-uart-dma"; reg = <0 0x11000400 0 0x80>, <0 0x11000480 0 0x80>, <0 0x11000500 0 0x80>,
diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt deleted file mode 100644 index b7f81c6..0000000 --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt +++ /dev/null
@@ -1,117 +0,0 @@ -* Renesas R-Car (RZ/G) DMA Controller Device Tree bindings - -Renesas R-Car (Gen 2/3) and RZ/G SoCs have multiple multi-channel DMA -controller instances named DMAC capable of serving multiple clients. Channels -can be dedicated to specific clients or shared between a large number of -clients. - -Each DMA client is connected to one dedicated port of the DMAC, identified by -an 8-bit port number called the MID/RID. A DMA controller can thus serve up to -256 clients in total. When the number of hardware channels is lower than the -number of clients to be served, channels must be shared between multiple DMA -clients. The association of DMA clients to DMAC channels is fully dynamic and -not described in these device tree bindings. - -Required Properties: - -- compatible: "renesas,dmac-<soctype>", "renesas,rcar-dmac" as fallback. - Examples with soctypes are: - - "renesas,dmac-r8a7743" (RZ/G1M) - - "renesas,dmac-r8a7744" (RZ/G1N) - - "renesas,dmac-r8a7745" (RZ/G1E) - - "renesas,dmac-r8a77470" (RZ/G1C) - - "renesas,dmac-r8a774a1" (RZ/G2M) - - "renesas,dmac-r8a774b1" (RZ/G2N) - - "renesas,dmac-r8a774c0" (RZ/G2E) - - "renesas,dmac-r8a7790" (R-Car H2) - - "renesas,dmac-r8a7791" (R-Car M2-W) - - "renesas,dmac-r8a7792" (R-Car V2H) - - "renesas,dmac-r8a7793" (R-Car M2-N) - - "renesas,dmac-r8a7794" (R-Car E2) - - "renesas,dmac-r8a7795" (R-Car H3) - - "renesas,dmac-r8a7796" (R-Car M3-W) - - "renesas,dmac-r8a77961" (R-Car M3-W+) - - "renesas,dmac-r8a77965" (R-Car M3-N) - - "renesas,dmac-r8a77970" (R-Car V3M) - - "renesas,dmac-r8a77980" (R-Car V3H) - - "renesas,dmac-r8a77990" (R-Car E3) - - "renesas,dmac-r8a77995" (R-Car D3) - -- reg: base address and length of the registers block for the DMAC - -- interrupts: interrupt specifiers for the DMAC, one for each entry in - interrupt-names. -- interrupt-names: one entry for the error interrupt, named "error", plus one - entry per channel, named "ch%u", where %u is the channel number ranging from - zero to the number of channels minus one. - -- clock-names: "fck" for the functional clock -- clocks: a list of phandle + clock-specifier pairs, one for each entry - in clock-names. -- clock-names: must contain "fck" for the functional clock. - -- #dma-cells: must be <1>, the cell specifies the MID/RID of the DMAC port - connected to the DMA client -- dma-channels: number of DMA channels - -Example: R8A7790 (R-Car H2) SYS-DMACs - - dmac0: dma-controller@e6700000 { - compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac"; - reg = <0 0xe6700000 0 0x20000>; - interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH - 0 200 IRQ_TYPE_LEVEL_HIGH - 0 201 IRQ_TYPE_LEVEL_HIGH - 0 202 IRQ_TYPE_LEVEL_HIGH - 0 203 IRQ_TYPE_LEVEL_HIGH - 0 204 IRQ_TYPE_LEVEL_HIGH - 0 205 IRQ_TYPE_LEVEL_HIGH - 0 206 IRQ_TYPE_LEVEL_HIGH - 0 207 IRQ_TYPE_LEVEL_HIGH - 0 208 IRQ_TYPE_LEVEL_HIGH - 0 209 IRQ_TYPE_LEVEL_HIGH - 0 210 IRQ_TYPE_LEVEL_HIGH - 0 211 IRQ_TYPE_LEVEL_HIGH - 0 212 IRQ_TYPE_LEVEL_HIGH - 0 213 IRQ_TYPE_LEVEL_HIGH - 0 214 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "error", - "ch0", "ch1", "ch2", "ch3", - "ch4", "ch5", "ch6", "ch7", - "ch8", "ch9", "ch10", "ch11", - "ch12", "ch13", "ch14"; - clocks = <&mstp2_clks R8A7790_CLK_SYS_DMAC0>; - clock-names = "fck"; - #dma-cells = <1>; - dma-channels = <15>; - }; - - dmac1: dma-controller@e6720000 { - compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac"; - reg = <0 0xe6720000 0 0x20000>; - interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH - 0 216 IRQ_TYPE_LEVEL_HIGH - 0 217 IRQ_TYPE_LEVEL_HIGH - 0 218 IRQ_TYPE_LEVEL_HIGH - 0 219 IRQ_TYPE_LEVEL_HIGH - 0 308 IRQ_TYPE_LEVEL_HIGH - 0 309 IRQ_TYPE_LEVEL_HIGH - 0 310 IRQ_TYPE_LEVEL_HIGH - 0 311 IRQ_TYPE_LEVEL_HIGH - 0 312 IRQ_TYPE_LEVEL_HIGH - 0 313 IRQ_TYPE_LEVEL_HIGH - 0 314 IRQ_TYPE_LEVEL_HIGH - 0 315 IRQ_TYPE_LEVEL_HIGH - 0 316 IRQ_TYPE_LEVEL_HIGH - 0 317 IRQ_TYPE_LEVEL_HIGH - 0 318 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "error", - "ch0", "ch1", "ch2", "ch3", - "ch4", "ch5", "ch6", "ch7", - "ch8", "ch9", "ch10", "ch11", - "ch12", "ch13", "ch14"; - clocks = <&mstp2_clks R8A7790_CLK_SYS_DMAC1>; - clock-names = "fck"; - #dma-cells = <1>; - dma-channels = <15>; - };
diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml new file mode 100644 index 0000000..b842dfd9 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
@@ -0,0 +1,150 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/renesas,rcar-dmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car and RZ/G DMA Controller + +maintainers: + - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + items: + - enum: + - renesas,dmac-r8a7743 # RZ/G1M + - renesas,dmac-r8a7744 # RZ/G1N + - renesas,dmac-r8a7745 # RZ/G1E + - renesas,dmac-r8a77470 # RZ/G1C + - renesas,dmac-r8a774a1 # RZ/G2M + - renesas,dmac-r8a774b1 # RZ/G2N + - renesas,dmac-r8a774c0 # RZ/G2E + - renesas,dmac-r8a7790 # R-Car H2 + - renesas,dmac-r8a7791 # R-Car M2-W + - renesas,dmac-r8a7792 # R-Car V2H + - renesas,dmac-r8a7793 # R-Car M2-N + - renesas,dmac-r8a7794 # R-Car E2 + - renesas,dmac-r8a7795 # R-Car H3 + - renesas,dmac-r8a7796 # R-Car M3-W + - renesas,dmac-r8a77961 # R-Car M3-W+ + - renesas,dmac-r8a77965 # R-Car M3-N + - renesas,dmac-r8a77970 # R-Car V3M + - renesas,dmac-r8a77980 # R-Car V3H + - renesas,dmac-r8a77990 # R-Car E3 + - renesas,dmac-r8a77995 # R-Car D3 + - const: renesas,rcar-dmac + + reg: + maxItems: 1 + + interrupts: + minItems: 9 + maxItems: 17 + + interrupt-names: + minItems: 9 + maxItems: 17 + items: + - const: error + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + - pattern: "^ch([0-9]|1[0-5])$" + + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + items: + - const: fck + + '#dma-cells': + const: 1 + description: + The cell specifies the MID/RID of the DMAC port connected to + the DMA client. + + dma-channels: + minimum: 8 + maximum: 16 + + dma-channel-mask: true + + iommus: + minItems: 8 + maxItems: 16 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - '#dma-cells' + - dma-channels + - power-domains + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7790-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7790-sysc.h> + + dmac0: dma-controller@e6700000 { + compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac"; + reg = <0xe6700000 0x20000>; + interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "error", + "ch0", "ch1", "ch2", "ch3", + "ch4", "ch5", "ch6", "ch7", + "ch8", "ch9", "ch10", "ch11", + "ch12", "ch13", "ch14"; + clocks = <&cpg CPG_MOD 219>; + clock-names = "fck"; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 219>; + #dma-cells = <1>; + dma-channels = <15>; + };
diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt deleted file mode 100644 index e8f6c42..0000000 --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt +++ /dev/null
@@ -1,55 +0,0 @@ -* Renesas USB DMA Controller Device Tree bindings - -Required Properties: --compatible: "renesas,<soctype>-usb-dmac", "renesas,usb-dmac" as fallback. - Examples with soctypes are: - - "renesas,r8a7743-usb-dmac" (RZ/G1M) - - "renesas,r8a7744-usb-dmac" (RZ/G1N) - - "renesas,r8a7745-usb-dmac" (RZ/G1E) - - "renesas,r8a77470-usb-dmac" (RZ/G1C) - - "renesas,r8a774a1-usb-dmac" (RZ/G2M) - - "renesas,r8a774b1-usb-dmac" (RZ/G2N) - - "renesas,r8a774c0-usb-dmac" (RZ/G2E) - - "renesas,r8a7790-usb-dmac" (R-Car H2) - - "renesas,r8a7791-usb-dmac" (R-Car M2-W) - - "renesas,r8a7793-usb-dmac" (R-Car M2-N) - - "renesas,r8a7794-usb-dmac" (R-Car E2) - - "renesas,r8a7795-usb-dmac" (R-Car H3) - - "renesas,r8a7796-usb-dmac" (R-Car M3-W) - - "renesas,r8a77961-usb-dmac" (R-Car M3-W+) - - "renesas,r8a77965-usb-dmac" (R-Car M3-N) - - "renesas,r8a77990-usb-dmac" (R-Car E3) - - "renesas,r8a77995-usb-dmac" (R-Car D3) -- reg: base address and length of the registers block for the DMAC -- interrupts: interrupt specifiers for the DMAC, one for each entry in - interrupt-names. -- interrupt-names: one entry per channel, named "ch%u", where %u is the - channel number ranging from zero to the number of channels minus one. -- clocks: a list of phandle + clock-specifier pairs. -- #dma-cells: must be <1>, the cell specifies the channel number of the DMAC - port connected to the DMA client. -- dma-channels: number of DMA channels - -Example: R8A7790 (R-Car H2) USB-DMACs - - usb_dmac0: dma-controller@e65a0000 { - compatible = "renesas,r8a7790-usb-dmac", "renesas,usb-dmac"; - reg = <0 0xe65a0000 0 0x100>; - interrupts = <0 109 IRQ_TYPE_LEVEL_HIGH - 0 109 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "ch0", "ch1"; - clocks = <&mstp3_clks R8A7790_CLK_USBDMAC0>; - #dma-cells = <1>; - dma-channels = <2>; - }; - - usb_dmac1: dma-controller@e65b0000 { - compatible = "renesas,usb-dmac"; - reg = <0 0xe65b0000 0 0x100>; - interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH - 0 110 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "ch0", "ch1"; - clocks = <&mstp3_clks R8A7790_CLK_USBDMAC1>; - #dma-cells = <1>; - dma-channels = <2>; - };
diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml new file mode 100644 index 0000000..9ca6d8d --- /dev/null +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml
@@ -0,0 +1,102 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/renesas,usb-dmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas USB DMA Controller + +maintainers: + - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + items: + - enum: + - renesas,r8a7743-usb-dmac # RZ/G1M + - renesas,r8a7744-usb-dmac # RZ/G1N + - renesas,r8a7745-usb-dmac # RZ/G1E + - renesas,r8a77470-usb-dmac # RZ/G1C + - renesas,r8a774a1-usb-dmac # RZ/G2M + - renesas,r8a774b1-usb-dmac # RZ/G2N + - renesas,r8a774c0-usb-dmac # RZ/G2E + - renesas,r8a7790-usb-dmac # R-Car H2 + - renesas,r8a7791-usb-dmac # R-Car M2-W + - renesas,r8a7793-usb-dmac # R-Car M2-N + - renesas,r8a7794-usb-dmac # R-Car E2 + - renesas,r8a7795-usb-dmac # R-Car H3 + - renesas,r8a7796-usb-dmac # R-Car M3-W + - renesas,r8a77961-usb-dmac # R-Car M3-W+ + - renesas,r8a77965-usb-dmac # R-Car M3-N + - renesas,r8a77990-usb-dmac # R-Car E3 + - renesas,r8a77995-usb-dmac # R-Car D3 + - const: renesas,usb-dmac + + reg: + maxItems: 1 + + interrupts: + minItems: 2 + maxItems: 2 + + interrupt-names: + items: + - pattern: ch0 + - pattern: ch1 + + clocks: + maxItems: 1 + + '#dma-cells': + const: 1 + description: + The cell specifies the channel number of the DMAC port connected to + the DMA client. + + dma-channels: + const: 2 + + iommus: + minItems: 2 + maxItems: 2 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - '#dma-cells' + - dma-channels + - power-domains + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7790-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7790-sysc.h> + + usb_dmac0: dma-controller@e65a0000 { + compatible = "renesas,r8a7790-usb-dmac", "renesas,usb-dmac"; + reg = <0xe65a0000 0x100>; + interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "ch0", "ch1"; + clocks = <&cpg CPG_MOD 330>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 330>; + #dma-cells = <1>; + dma-channels = <2>; + };
diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml index e7f2ad7..d32a71b 100644 --- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml +++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml
@@ -49,7 +49,7 @@ - | dma@3000000 { compatible = "sifive,fu540-c000-pdma"; - reg = <0x0 0x3000000 0x0 0x8000>; + reg = <0x3000000 0x8000>; interrupts = <23 24 25 26 27 28 29 30>; #dma-cells = <1>; };
diff --git a/Documentation/devicetree/bindings/dma/socionext,uniphier-xdmac.yaml b/Documentation/devicetree/bindings/dma/socionext,uniphier-xdmac.yaml index 86cfb59..371f1877 100644 --- a/Documentation/devicetree/bindings/dma/socionext,uniphier-xdmac.yaml +++ b/Documentation/devicetree/bindings/dma/socionext,uniphier-xdmac.yaml
@@ -22,9 +22,7 @@ const: socionext,uniphier-xdmac reg: - items: - - description: XDMAC base register region (offset and length) - - description: XDMAC extension register region (offset and length) + maxItems: 1 interrupts: maxItems: 1 @@ -49,12 +47,13 @@ - reg - interrupts - "#dma-cells" + - dma-channels examples: - | xdmac: dma-controller@5fc10000 { compatible = "socionext,uniphier-xdmac"; - reg = <0x5fc10000 0x1000>, <0x5fc20000 0x800>; + reg = <0x5fc10000 0x5300>; interrupts = <0 188 4>; #dma-cells = <2>; dma-channels = <16>;
diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml index 0c0ac11..7198787 100644 --- a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml +++ b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
@@ -36,6 +36,11 @@ 0x1: 1/2 full FIFO 0x2: 3/4 full FIFO 0x3: full FIFO + -bit 2: DMA direct mode + 0x0: FIFO mode with threshold selectable with bit 0-1 + 0x1: Direct mode: each DMA request immediately initiates a transfer + from/to the memory, FIFO is bypassed. + maintainers: - Amelie Delaunay <amelie.delaunay@st.com>
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml index 39ea05e..dd70dda 100644 --- a/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml +++ b/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml
@@ -69,34 +69,30 @@ maxItems: 3 reg-names: - items: - - const: gcfg - - const: rchanrt - - const: tchanrt + items: + - const: gcfg + - const: rchanrt + - const: tchanrt msi-parent: true ti,sci: description: phandle to TI-SCI compatible System controller node - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle ti,sci-dev-id: description: TI-SCI device id of UDMAP - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 ti,ringacc: description: phandle to the ring accelerator node - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle ti,sci-rm-range-tchan: description: | Array of UDMA tchan resource subtypes for resource allocation for this host - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 # Should be enough maxItems: 255 @@ -105,8 +101,7 @@ description: | Array of UDMA rchan resource subtypes for resource allocation for this host - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 # Should be enough maxItems: 255 @@ -115,8 +110,7 @@ description: | Array of UDMA rflow resource subtypes for resource allocation for this host - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 # Should be enough maxItems: 255 @@ -142,8 +136,7 @@ properties: ti,udma-atype: description: ATYPE value which should be used by non slave channels - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 required: - ti,udma-atype
diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml index a5dc070..3bbe952 100644 --- a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml +++ b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
@@ -17,6 +17,8 @@ compatible: enum: - fsl,imx8qxp-dsp + - fsl,imx8qm-dsp + - fsl,imx8mp-dsp reg: description: Should contain register location and length
diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml index a15787e..4cee72d 100644 --- a/Documentation/devicetree/bindings/eeprom/at24.yaml +++ b/Documentation/devicetree/bindings/eeprom/at24.yaml
@@ -34,7 +34,7 @@ - minItems: 1 maxItems: 2 items: - - pattern: "^(atmel|catalyst|microchip|nxp|ramtron|renesas|rohm|st),(24(c|cs|mac)[0-9]+|spd)$" + - pattern: "^(atmel|catalyst|microchip|nxp|ramtron|renesas|rohm|st),(24(c|cs|lc|mac)[0-9]+|spd)$" - pattern: "^atmel,(24(c|cs|mac)[0-9]+|spd)$" - oneOf: - items: @@ -118,14 +118,13 @@ maxItems: 1 pagesize: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 description: The length of the pagesize for writing. Please consult the manual of your device, that value varies a lot. A wrong value may result in data loss! If not specified, a safety value of '1' is used which will be very slow. - enum: [ 1, 8, 16, 32, 64, 128, 258 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 8, 16, 32, 64, 128, 256] default: 1 read-only: @@ -148,18 +147,16 @@ wp-gpios: true address-width: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 description: Number of address bits. + $ref: /schemas/types.yaml#/definitions/uint32 default: 8 enum: [ 8, 16 ] num-addresses: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 description: Total number of i2c slave addresses this device takes. + $ref: /schemas/types.yaml#/definitions/uint32 default: 1 minimum: 1 maximum: 8
diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml index 62811a1..c9534d2 100644 --- a/Documentation/devicetree/bindings/example-schema.yaml +++ b/Documentation/devicetree/bindings/example-schema.yaml
@@ -138,12 +138,8 @@ # 'description'. vendor,int-property: description: Vendor specific properties must have a description - # 'allOf' is the json-schema way of subclassing a schema. Here the base - # type schema is referenced and then additional constraints on the values - # are added. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [2, 4, 6, 8, 10] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [2, 4, 6, 8, 10] vendor,bool-property: description: Vendor specific properties must have a description. Boolean @@ -154,11 +150,10 @@ vendor,string-array-property: description: Vendor specific properties should reference a type in the core schema. - allOf: - - $ref: /schemas/types.yaml#/definitions/string-array - - items: - - enum: [ foo, bar ] - - enum: [ baz, boo ] + $ref: /schemas/types.yaml#/definitions/string-array + items: + - enum: [foo, bar] + - enum: [baz, boo] vendor,property-in-standard-units-microvolt: description: Vendor specific properties having a standard unit suffix
diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt deleted file mode 100644 index 208daaf..0000000 --- a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt +++ /dev/null
@@ -1,76 +0,0 @@ -Cirrus Logic Arizona class audio SoCs - -These devices are audio SoCs with extensive digital capabilities and a range -of analogue I/O. - -This document lists Extcon specific bindings, see the primary binding document: - ../mfd/arizona.txt - -Optional properties: - - - wlf,hpdet-channel : Headphone detection channel. - ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL - ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR - If this node is not mentioned or if the value is unknown, then - headphone detection mode is set to HPDETL. - - - wlf,use-jd2 : Use the additional JD input along with JD1 for dual pin jack - detection. - - wlf,use-jd2-nopull : Internal pull on JD2 is disabled when used for - jack detection. - - wlf,jd-invert : Invert the polarity of the jack detection switch - - - wlf,micd-software-compare : Use a software comparison to determine mic - presence - - wlf,micd-detect-debounce : Additional software microphone detection - debounce specified in milliseconds. - - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset - polarity if one exists. - - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to - performing microphone detection, specified as per the ARIZONA_MICD_TIME_XXX - defines. - - wlf,micd-rate : Delay between successive microphone detection measurements, - specified as per the ARIZONA_MICD_TIME_XXX defines. - - wlf,micd-dbtime : Microphone detection hardware debounces specified as the - number of measurements to take, valid values being 2 and 4. - - wlf,micd-timeout-ms : Timeout for microphone detection, specified in - milliseconds. - - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone - detection. - - wlf,micd-configs : Headset polarity configurations (generally used for - detection of CTIA / OMTP headsets), the field can be of variable length - but should always be a multiple of 3 cells long, each three cell group - represents one polarity configuration. - The first cell defines the accessory detection pin, zero will use MICDET1 - and all other values will use MICDET2. - The second cell represents the MICBIAS to be used. - The third cell represents the value of the micd-pol-gpio pin. - - - wlf,gpsw : Settings for the general purpose switch, set as one of the - ARIZONA_GPSW_XXX defines. - -Example: - -codec: wm8280@0 { - compatible = "wlf,wm8280"; - reg = <0>; - ... - - wlf,use-jd2; - wlf,use-jd2-nopull; - wlf,jd-invert; - - wlf,micd-software-compare; - wlf,micd-detect-debounce = <0>; - wlf,micd-pol-gpio = <&codec 2 0>; - wlf,micd-rate = <ARIZONA_MICD_TIME_8MS>; - wlf,micd-dbtime = <4>; - wlf,micd-timeout-ms = <100>; - wlf,micd-force-micbias; - wlf,micd-configs = < - 0 1 0 /* MICDET1 MICBIAS1 GPIO=low */ - 1 2 1 /* MICDET2 MICBIAS2 GPIO=high */ - >; - - wlf,gpsw = <ARIZONA_GPSW_OPEN>; -};
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml b/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml index 9c5849b..20e1ccf 100644 --- a/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml +++ b/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml
@@ -22,8 +22,7 @@ const: google,extcon-usbc-cros-ec google,usb-port-id: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: the port id minimum: 0 maximum: 255
diff --git a/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml b/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml new file mode 100644 index 0000000..f9845dc --- /dev/null +++ b/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml
@@ -0,0 +1,125 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/extcon/wlf,arizona.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic/Wolfson Microelectronics Arizona class audio SoCs + +maintainers: + - patches@opensource.cirrus.com + +description: | + These devices are audio SoCs with extensive digital capabilities and a + range of analogue I/O. + + This document lists Extcon specific bindings, see the primary binding + document ../mfd/arizona.yaml + +properties: + wlf,hpdet-channel: + description: + Headphone detection channel. ARIZONA_ACCDET_MODE_HPL/1 sets the + headphone detect mode to HPDETL, ARIZONA_ACCDET_MODE_HPR/2 sets it + to HPDETR. If this node is not included or if the value is unknown, + then headphone detection mode is set to HPDETL. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 1 + maximum: 2 + + wlf,use-jd2: + description: + Use the additional JD input along with JD1 for dual pin jack detection. + type: boolean + + wlf,use-jd2-nopull: + description: + Internal pull on JD2 is disabled when used for jack detection. + type: boolean + + wlf,jd-invert: + description: + Invert the polarity of the jack detection switch. + type: boolean + + wlf,micd-software-compare: + description: + Use a software comparison to determine mic presence. + type: boolean + + wlf,micd-detect-debounce: + description: + Additional software microphone detection debounce specified in + milliseconds. + $ref: "/schemas/types.yaml#/definitions/uint32" + + wlf,micd-pol-gpio: + description: + GPIO specifier for the GPIO controlling the headset polarity if one + exists. + maxItems: 1 + + wlf,micd-bias-start-time: + description: + Time allowed for MICBIAS to startup prior to performing microphone + detection, specified as per the ARIZONA_MICD_TIME_XXX defines. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 12 + + wlf,micd-rate: + description: + Delay between successive microphone detection measurements, specified + as per the ARIZONA_MICD_TIME_XXX defines. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 12 + + wlf,micd-dbtime: + description: + Microphone detection hardware debounces specified as the number of + measurements to take. + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: [2, 4] + + wlf,micd-timeout-ms: + description: + Timeout for microphone detection, specified in milliseconds. + $ref: "/schemas/types.yaml#/definitions/uint32" + + wlf,micd-force-micbias: + description: + Force MICBIAS continuously on during microphone detection. + type: boolean + + wlf,micd-configs: + description: + Headset polarity configurations (generally used for detection of + CTIA / OMTP headsets), the field can be of variable length but + should always be a multiple of 3 cells long, each three cell group + represents one polarity configuration. + $ref: "/schemas/types.yaml#/definitions/uint32-matrix" + items: + items: + - description: + The first cell defines the accessory detection pin, zero + will use MICDET1 and 0x2000 will use MICDET2. + enum: [ 0, 0x2000 ] + - description: + The second cell represents the MICBIAS to be used. Zero + will use MICVDD, 1-3 will use MICBIASx. + minimum: 0 + maximum: 3 + - description: + The third cell represents the value of the micd-pol-gpio + pin. + minimum: 0 + maximum: 1 + + wlf,gpsw: + description: + Settings for the general purpose switch, set as one of the + ARIZONA_GPSW_XXX defines. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 3
diff --git a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt index 1fa6606..6eff1af 100644 --- a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt +++ b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt
@@ -23,7 +23,7 @@ The svc node has the following mandatory properties, must be located under the firmware node. -- compatible: "intel,stratix10-svc" +- compatible: "intel,stratix10-svc" or "intel,agilex-svc" - method: smc or hvc smc - Secure Monitor Call hvc - Hypervisor Call
diff --git a/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt index 6e03f79..0f87413 100644 --- a/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt +++ b/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt
@@ -4,7 +4,8 @@ The fpga_mgr node has the following mandatory property, must be located under firmware/svc node. -- compatible : should contain "intel,stratix10-soc-fpga-mgr" +- compatible : should contain "intel,stratix10-soc-fpga-mgr" or + "intel,agilex-soc-fpga-mgr" Example:
diff --git a/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml index 5f1ed20e..4f2cbd8 100644 --- a/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml
@@ -27,7 +27,7 @@ gpio-controller: true '#gpio-cells': - const: 2 + const: 2 ngpios: minimum: 0
diff --git a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt deleted file mode 100644 index b4cd9f90..0000000 --- a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt +++ /dev/null
@@ -1,35 +0,0 @@ -* Freescale i.MX/MXC GPIO controller - -Required properties: -- compatible : Should be "fsl,<soc>-gpio" -- reg : Address and length of the register set for the device -- interrupts : Should be the port interrupt shared by all 32 pins, if - one number. If two numbers, the first one is the interrupt shared - by low 16 pins and the second one is for high 16 pins. -- gpio-controller : Marks the device node as a gpio controller. -- #gpio-cells : Should be two. The first cell is the pin number and - the second cell is used to specify the gpio polarity: - 0 = active high - 1 = active low -- interrupt-controller: Marks the device node as an interrupt controller. -- #interrupt-cells : Should be 2. The first cell is the GPIO number. - The second cell bits[3:0] is used to specify trigger type and level flags: - 1 = low-to-high edge triggered. - 2 = high-to-low edge triggered. - 4 = active high level-sensitive. - 8 = active low level-sensitive. - -Optional properties: -- clocks: the clock for clocking the GPIO silicon - -Example: - -gpio0: gpio@73f84000 { - compatible = "fsl,imx51-gpio", "fsl,imx35-gpio"; - reg = <0x73f84000 0x4000>; - interrupts = <50 51>; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; -};
diff --git a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml new file mode 100644 index 0000000..0b223ab --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
@@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/fsl-imx-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX/MXC GPIO controller + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +properties: + compatible: + enum: + - fsl,imx1-gpio + - fsl,imx21-gpio + - fsl,imx31-gpio + - fsl,imx35-gpio + - fsl,imx7d-gpio + + reg: + maxItems: 1 + + interrupts: + description: | + Should be the port interrupt shared by all 32 pins, if one number. + If two numbers, the first one is the interrupt shared by low 16 pins + and the second one is for high 16 pins. + minItems: 1 + maxItems: 2 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + clocks: + maxItems: 1 + + "#gpio-cells": + const: 2 + + gpio-controller: true + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - "#interrupt-cells" + - "#gpio-cells" + - gpio-controller + +additionalProperties: false + +examples: + - | + gpio0: gpio@73f84000 { + compatible = "fsl,imx35-gpio"; + reg = <0x73f84000 0x4000>; + interrupts = <50 51>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + +...
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mxs.txt b/Documentation/devicetree/bindings/gpio/gpio-mxs.txt deleted file mode 100644 index 1e677a4..0000000 --- a/Documentation/devicetree/bindings/gpio/gpio-mxs.txt +++ /dev/null
@@ -1,88 +0,0 @@ -* Freescale MXS GPIO controller - -The Freescale MXS GPIO controller is part of MXS PIN controller. The -GPIOs are organized in port/bank. Each port consists of 32 GPIOs. - -As the GPIO controller is embedded in the PIN controller and all the -GPIO ports share the same IO space with PIN controller, the GPIO node -will be represented as sub-nodes of MXS pinctrl node. - -Required properties for GPIO node: -- compatible : Should be "fsl,<soc>-gpio". The supported SoCs include - imx23 and imx28. -- interrupts : Should be the port interrupt shared by all 32 pins. -- gpio-controller : Marks the device node as a gpio controller. -- #gpio-cells : Should be two. The first cell is the pin number and - the second cell is used to specify the gpio polarity: - 0 = active high - 1 = active low -- interrupt-controller: Marks the device node as an interrupt controller. -- #interrupt-cells : Should be 2. The first cell is the GPIO number. - The second cell bits[3:0] is used to specify trigger type and level flags: - 1 = low-to-high edge triggered. - 2 = high-to-low edge triggered. - 4 = active high level-sensitive. - 8 = active low level-sensitive. - -Note: Each GPIO port should have an alias correctly numbered in "aliases" -node. - -Examples: - -aliases { - gpio0 = &gpio0; - gpio1 = &gpio1; - gpio2 = &gpio2; - gpio3 = &gpio3; - gpio4 = &gpio4; -}; - -pinctrl@80018000 { - compatible = "fsl,imx28-pinctrl", "simple-bus"; - reg = <0x80018000 2000>; - - gpio0: gpio@0 { - compatible = "fsl,imx28-gpio"; - interrupts = <127>; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - }; - - gpio1: gpio@1 { - compatible = "fsl,imx28-gpio"; - interrupts = <126>; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - }; - - gpio2: gpio@2 { - compatible = "fsl,imx28-gpio"; - interrupts = <125>; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - }; - - gpio3: gpio@3 { - compatible = "fsl,imx28-gpio"; - interrupts = <124>; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - }; - - gpio4: gpio@4 { - compatible = "fsl,imx28-gpio"; - interrupts = <123>; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - }; -};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mxs.yaml b/Documentation/devicetree/bindings/gpio/gpio-mxs.yaml new file mode 100644 index 0000000..ccf5b50 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-mxs.yaml
@@ -0,0 +1,136 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-mxs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale MXS GPIO controller + +maintainers: + - Shawn Guo <shawn.guo@linaro.org> + - Anson Huang <Anson.Huang@nxp.com> + +description: | + The Freescale MXS GPIO controller is part of MXS PIN controller. + The GPIOs are organized in port/bank, each port consists of 32 GPIOs. + As the GPIO controller is embedded in the PIN controller and all the + GPIO ports share the same IO space with PIN controller, the GPIO node + will be represented as sub-nodes of MXS pinctrl node. + +properties: + compatible: + enum: + - fsl,imx23-pinctrl + - fsl,imx28-pinctrl + + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + reg: + maxItems: 1 + +patternProperties: + "gpio@[0-9]+$": + type: object + properties: + compatible: + enum: + - fsl,imx23-gpio + - fsl,imx28-gpio + + reg: + maxItems: 1 + + interrupts: + description: Should be the port interrupt shared by all 32 pins. + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + "#gpio-cells": + const: 2 + + gpio-controller: true + + required: + - compatible + - reg + - interrupts + - interrupt-controller + - "#interrupt-cells" + - "#gpio-cells" + - gpio-controller + + additionalProperties: false + +required: + - compatible + - reg + - '#address-cells' + - '#size-cells' + +additionalProperties: false + +examples: + - | + pinctrl@80018000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx28-pinctrl"; + reg = <0x80018000 0x2000>; + + gpio@0 { + compatible = "fsl,imx28-gpio"; + reg = <0>; + interrupts = <127>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio@1 { + compatible = "fsl,imx28-gpio"; + reg = <1>; + interrupts = <126>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio@2 { + compatible = "fsl,imx28-gpio"; + reg = <2>; + interrupts = <125>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio@3 { + compatible = "fsl,imx28-gpio"; + reg = <3>; + interrupts = <124>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio@4 { + compatible = "fsl,imx28-gpio"; + reg = <4>; + interrupts = <123>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + };
diff --git a/Documentation/devicetree/bindings/gpio/renesas,em-gio.yaml b/Documentation/devicetree/bindings/gpio/renesas,em-gio.yaml new file mode 100644 index 0000000..8bdef81 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/renesas,em-gio.yaml
@@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/renesas,em-gio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas EMMA Mobile General Purpose I/O Interface + +maintainers: + - Magnus Damm <magnus.damm@gmail.com> + +properties: + compatible: + const: renesas,em-gio + + reg: + items: + - description: First set of contiguous registers + - description: Second set of contiguous registers + + interrupts: + items: + - description: Interrupt for the first set of 16 GPIO ports + - description: Interrupt for the second set of 16 GPIO ports + + gpio-controller: true + + '#gpio-cells': + const: 2 + + gpio-ranges: + maxItems: 1 + + ngpios: + minimum: 1 + maximum: 32 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + +required: + - compatible + - reg + - interrupts + - gpio-controller + - '#gpio-cells' + - gpio-ranges + - ngpios + - interrupt-controller + - '#interrupt-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + gpio0: gpio@e0050000 { + compatible = "renesas,em-gio"; + reg = <0xe0050000 0x2c>, <0xe0050040 0x20>; + interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pfc 0 0 32>; + ngpios = <32>; + interrupt-controller; + #interrupt-cells = <2>; + };
diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt deleted file mode 100644 index 10dce84b..0000000 --- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt +++ /dev/null
@@ -1,94 +0,0 @@ -* Renesas R-Car GPIO Controller - -Required Properties: - - - compatible: should contain one or more of the following: - - "renesas,gpio-r8a7743": for R8A7743 (RZ/G1M) compatible GPIO controller. - - "renesas,gpio-r8a7744": for R8A7744 (RZ/G1N) compatible GPIO controller. - - "renesas,gpio-r8a7745": for R8A7745 (RZ/G1E) compatible GPIO controller. - - "renesas,gpio-r8a77470": for R8A77470 (RZ/G1C) compatible GPIO controller. - - "renesas,gpio-r8a774a1": for R8A774A1 (RZ/G2M) compatible GPIO controller. - - "renesas,gpio-r8a774b1": for R8A774B1 (RZ/G2N) compatible GPIO controller. - - "renesas,gpio-r8a774c0": for R8A774C0 (RZ/G2E) compatible GPIO controller. - - "renesas,gpio-r8a7778": for R8A7778 (R-Car M1) compatible GPIO controller. - - "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO controller. - - "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO controller. - - "renesas,gpio-r8a7791": for R8A7791 (R-Car M2-W) compatible GPIO controller. - - "renesas,gpio-r8a7792": for R8A7792 (R-Car V2H) compatible GPIO controller. - - "renesas,gpio-r8a7793": for R8A7793 (R-Car M2-N) compatible GPIO controller. - - "renesas,gpio-r8a7794": for R8A7794 (R-Car E2) compatible GPIO controller. - - "renesas,gpio-r8a7795": for R8A7795 (R-Car H3) compatible GPIO controller. - - "renesas,gpio-r8a7796": for R8A77960 (R-Car M3-W) compatible GPIO controller. - - "renesas,gpio-r8a77961": for R8A77961 (R-Car M3-W+) compatible GPIO controller. - - "renesas,gpio-r8a77965": for R8A77965 (R-Car M3-N) compatible GPIO controller. - - "renesas,gpio-r8a77970": for R8A77970 (R-Car V3M) compatible GPIO controller. - - "renesas,gpio-r8a77980": for R8A77980 (R-Car V3H) compatible GPIO controller. - - "renesas,gpio-r8a77990": for R8A77990 (R-Car E3) compatible GPIO controller. - - "renesas,gpio-r8a77995": for R8A77995 (R-Car D3) compatible GPIO controller. - - "renesas,rcar-gen1-gpio": for a generic R-Car Gen1 GPIO controller. - - "renesas,rcar-gen2-gpio": for a generic R-Car Gen2 or RZ/G1 GPIO controller. - - "renesas,rcar-gen3-gpio": for a generic R-Car Gen3 or RZ/G2 GPIO controller. - - "renesas,gpio-rcar": deprecated. - - When compatible with the generic version nodes must list the - SoC-specific version corresponding to the platform first followed by - the generic version. - - - reg: Base address and length of each memory resource used by the GPIO - controller hardware module. - - - interrupts: Interrupt specifier for the controllers interrupt. - - - gpio-controller: Marks the device node as a gpio controller. - - #gpio-cells: Should be 2. The first cell is the GPIO number and the second - cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the - GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. - - gpio-ranges: See gpio.txt. - -Optional properties: - - - clocks: Must contain a reference to the functional clock. The property is - mandatory if the hardware implements a controllable functional clock for - the GPIO instance. - - - gpio-reserved-ranges: See gpio.txt. - -Please refer to gpio.txt in this directory for the common GPIO bindings used by -client devices. - -The GPIO controller also acts as an interrupt controller. It uses the default -two cells specifier as described in Documentation/devicetree/bindings/ -interrupt-controller/interrupts.txt. - -Example: R8A77470 (RZ/G1C) GPIO controller nodes - - gpio0: gpio@e6050000 { - compatible = "renesas,gpio-r8a77470", - "renesas,rcar-gen2-gpio"; - reg = <0 0xe6050000 0 0x50>; - interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>; - #gpio-cells = <2>; - gpio-controller; - gpio-ranges = <&pfc 0 0 23>; - #interrupt-cells = <2>; - interrupt-controller; - clocks = <&cpg CPG_MOD 912>; - power-domains = <&sysc R8A77470_PD_ALWAYS_ON>; - resets = <&cpg 912>; - }; - ... - gpio3: gpio@e6053000 { - compatible = "renesas,gpio-r8a77470", - "renesas,rcar-gen2-gpio"; - reg = <0 0xe6053000 0 0x50>; - interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; - #gpio-cells = <2>; - gpio-controller; - gpio-ranges = <&pfc 0 96 30>; - gpio-reserved-ranges = <17 10>; - #interrupt-cells = <2>; - interrupt-controller; - clocks = <&cpg CPG_MOD 909>; - power-domains = <&sysc R8A77470_PD_ALWAYS_ON>; - resets = <&cpg 909>; - };
diff --git a/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml b/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml new file mode 100644 index 0000000..397d938 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml
@@ -0,0 +1,144 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/renesas,rcar-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car General-Purpose Input/Output Ports (GPIO) + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,gpio-r8a7778 # R-Car M1 + - renesas,gpio-r8a7779 # R-Car H1 + - const: renesas,rcar-gen1-gpio # R-Car Gen1 + + - items: + - enum: + - renesas,gpio-r8a7742 # RZ/G1H + - renesas,gpio-r8a7743 # RZ/G1M + - renesas,gpio-r8a7744 # RZ/G1N + - renesas,gpio-r8a7745 # RZ/G1E + - renesas,gpio-r8a77470 # RZ/G1C + - renesas,gpio-r8a7790 # R-Car H2 + - renesas,gpio-r8a7791 # R-Car M2-W + - renesas,gpio-r8a7792 # R-Car V2H + - renesas,gpio-r8a7793 # R-Car M2-N + - renesas,gpio-r8a7794 # R-Car E2 + - const: renesas,rcar-gen2-gpio # R-Car Gen2 or RZ/G1 + + - items: + - enum: + - renesas,gpio-r8a774a1 # RZ/G2M + - renesas,gpio-r8a774b1 # RZ/G2N + - renesas,gpio-r8a774c0 # RZ/G2E + - renesas,gpio-r8a7795 # R-Car H3 + - renesas,gpio-r8a7796 # R-Car M3-W + - renesas,gpio-r8a77961 # R-Car M3-W+ + - renesas,gpio-r8a77965 # R-Car M3-N + - renesas,gpio-r8a77970 # R-Car V3M + - renesas,gpio-r8a77980 # R-Car V3H + - renesas,gpio-r8a77990 # R-Car E3 + - renesas,gpio-r8a77995 # R-Car D3 + - const: renesas,rcar-gen3-gpio # R-Car Gen3 or RZ/G2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + gpio-ranges: + maxItems: 1 + + gpio-reserved-ranges: + minItems: 1 + maxItems: 8 + +patternProperties: + "^.*$": + if: + type: object + then: + properties: + gpio-hog: true + gpios: true + input: true + output-high: true + output-low: true + line-name: true + + required: + - gpio-hog + - gpios + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - gpio-controller + - '#gpio-cells' + - gpio-ranges + - interrupt-controller + - '#interrupt-cells' + +if: + not: + properties: + compatible: + contains: + enum: + - renesas,rcar-gen1-gpio +then: + required: + - clocks + - power-domains + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a77470-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a77470-sysc.h> + gpio3: gpio@e6053000 { + compatible = "renesas,gpio-r8a77470", "renesas,rcar-gen2-gpio"; + reg = <0xe6053000 0x50>; + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 909>; + power-domains = <&sysc R8A77470_PD_ALWAYS_ON>; + resets = <&cpg 909>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pfc 0 96 30>; + gpio-reserved-ranges = <17 10>; + interrupt-controller; + #interrupt-cells = <2>; + };
diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml index 418e838..a0efd8d 100644 --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
@@ -57,7 +57,7 @@ compatible = "sifive,fu540-c000-gpio", "sifive,gpio0"; interrupt-parent = <&plic>; interrupts = <7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22>; - reg = <0x0 0x10060000 0x0 0x1000>; + reg = <0x10060000 0x1000>; clocks = <&tlclk PRCI_CLK_TLCLK>; gpio-controller; #gpio-cells = <2>;
diff --git a/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml b/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml new file mode 100644 index 0000000..1240f62 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
@@ -0,0 +1,133 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/snps,dw-apb-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare APB GPIO controller + +description: | + Synopsys DesignWare GPIO controllers have a configurable number of ports, + each of which are intended to be represented as child nodes with the generic + GPIO-controller properties as desribed in this bindings file. + +maintainers: + - Hoan Tran <hoan@os.amperecomputing.com> + - Serge Semin <fancer.lancer@gmail.com> + +properties: + $nodename: + pattern: "^gpio@[0-9a-f]+$" + + compatible: + const: snps,dw-apb-gpio + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + reg: + maxItems: 1 + + clocks: + minItems: 1 + items: + - description: APB interface clock source + - description: DW GPIO debounce reference clock source + + clock-names: + minItems: 1 + items: + - const: bus + - const: db + + resets: + maxItems: 1 + +patternProperties: + "^gpio-(port|controller)@[0-9a-f]+$": + type: object + properties: + compatible: + const: snps,dw-apb-gpio-port + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + snps,nr-gpios: + description: The number of GPIO pins exported by the port. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 32 + minimum: 1 + maximum: 32 + + interrupts: + description: | + The interrupts to the parent controller raised when GPIOs generate + the interrupts. If the controller provides one combined interrupt + for all GPIOs, specify a single interrupt. If the controller provides + one interrupt for each GPIO, provide a list of interrupts that + correspond to each of the GPIO pins. + minItems: 1 + maxItems: 32 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + + dependencies: + interrupt-controller: [ interrupts ] + + additionalProperties: false + +additionalProperties: false + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +examples: + - | + gpio: gpio@20000 { + compatible = "snps,dw-apb-gpio"; + reg = <0x20000 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + + porta: gpio-port@0 { + compatible = "snps,dw-apb-gpio-port"; + reg = <0>; + gpio-controller; + #gpio-cells = <2>; + snps,nr-gpios = <8>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&vic1>; + interrupts = <0>; + }; + + portb: gpio-port@1 { + compatible = "snps,dw-apb-gpio-port"; + reg = <1>; + gpio-controller; + #gpio-cells = <2>; + snps,nr-gpios = <8>; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt deleted file mode 100644 index 839dd32..0000000 --- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt +++ /dev/null
@@ -1,65 +0,0 @@ -* Synopsys DesignWare APB GPIO controller - -Required properties: -- compatible : Should contain "snps,dw-apb-gpio" -- reg : Address and length of the register set for the device. -- #address-cells : should be 1 (for addressing port subnodes). -- #size-cells : should be 0 (port subnodes). - -The GPIO controller has a configurable number of ports, each of which are -represented as child nodes with the following properties: - -Required properties: -- compatible : "snps,dw-apb-gpio-port" -- gpio-controller : Marks the device node as a gpio controller. -- #gpio-cells : Should be two. The first cell is the pin number and - the second cell is used to specify the gpio polarity: - 0 = active high - 1 = active low -- reg : The integer port index of the port, a single cell. - -Optional properties: -- interrupt-controller : The first port may be configured to be an interrupt -controller. -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt. Shall be set to 2. The first cell defines the interrupt number, - the second encodes the triger flags encoded as described in - Documentation/devicetree/bindings/interrupt-controller/interrupts.txt -- interrupts : The interrupts to the parent controller raised when GPIOs - generate the interrupts. If the controller provides one combined interrupt - for all GPIOs, specify a single interrupt. If the controller provides one - interrupt for each GPIO, provide a list of interrupts that correspond to each - of the GPIO pins. When specifying multiple interrupts, if any are unconnected, - use the interrupts-extended property to specify the interrupts and set the - interrupt controller handle for unused interrupts to 0. -- snps,nr-gpios : The number of pins in the port, a single cell. -- resets : Reset line for the controller. - -Example: - -gpio: gpio@20000 { - compatible = "snps,dw-apb-gpio"; - reg = <0x20000 0x1000>; - #address-cells = <1>; - #size-cells = <0>; - - porta: gpio@0 { - compatible = "snps,dw-apb-gpio-port"; - gpio-controller; - #gpio-cells = <2>; - snps,nr-gpios = <8>; - reg = <0>; - interrupt-controller; - #interrupt-cells = <2>; - interrupt-parent = <&vic1>; - interrupts = <0>; - }; - - portb: gpio@1 { - compatible = "snps,dw-apb-gpio-port"; - gpio-controller; - #gpio-cells = <2>; - snps,nr-gpios = <8>; - reg = <1>; - }; -};
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 0b229a7..b1844b9 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
@@ -43,9 +43,15 @@ operating-points-v2: true + power-domains: + maxItems: 1 + resets: maxItems: 2 + "#cooling-cells": + const: 2 + required: - compatible - reg
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml index 0407e45..80d519a 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
@@ -16,33 +16,33 @@ oneOf: - items: - enum: - - samsung,exynos5250-mali + - samsung,exynos5250-mali - const: arm,mali-t604 - items: - enum: - - samsung,exynos5420-mali + - samsung,exynos5420-mali - const: arm,mali-t628 - items: - enum: - - allwinner,sun50i-h6-mali + - allwinner,sun50i-h6-mali - const: arm,mali-t720 - items: - enum: - - amlogic,meson-gxm-mali - - realtek,rtd1295-mali + - amlogic,meson-gxm-mali + - realtek,rtd1295-mali - const: arm,mali-t820 - items: - enum: - - arm,juno-mali + - arm,juno-mali - const: arm,mali-t624 - items: - enum: - - rockchip,rk3288-mali - - samsung,exynos5433-mali + - rockchip,rk3288-mali + - samsung,exynos5433-mali - const: arm,mali-t760 - items: - enum: - - rockchip,rk3399-mali + - rockchip,rk3399-mali - const: arm,mali-t860 # "arm,mali-t830" @@ -87,6 +87,8 @@ "#cooling-cells": const: 2 + dma-coherent: true + required: - compatible - reg
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml index f5401cc..6226d31e 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
@@ -41,6 +41,7 @@ - amlogic,meson-gxbb-mali - amlogic,meson-gxl-mali - hisilicon,hi6220-mali + - mediatek,mt7623-mali - rockchip,rk3328-mali - const: arm,mali-450 @@ -107,6 +108,9 @@ operating-points-v2: true + "#cooling-cells": + const: 2 + required: - compatible - reg @@ -130,6 +134,7 @@ - amlogic,meson8-mali - amlogic,meson8b-mali - hisilicon,hi6220-mali + - mediatek,mt7623-mali - rockchip,rk3036-mali - rockchip,rk3066-mali - rockchip,rk3188-mali @@ -164,6 +169,7 @@ clocks = <&ccu 1>, <&ccu 2>; clock-names = "bus", "core"; resets = <&ccu 1>; + #cooling-cells = <2>; }; ...
diff --git a/Documentation/devicetree/bindings/gpu/vivante,gc.yaml b/Documentation/devicetree/bindings/gpu/vivante,gc.yaml index 0bc4b38..e1ac6ff 100644 --- a/Documentation/devicetree/bindings/gpu/vivante,gc.yaml +++ b/Documentation/devicetree/bindings/gpu/vivante,gc.yaml
@@ -9,7 +9,7 @@ description: Vivante GPU core devices maintainers: - - Lucas Stach <l.stach@pengutronix.de> + - Lucas Stach <l.stach@pengutronix.de> properties: compatible:
diff --git a/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml b/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml index 7db7876..af35b77 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml
@@ -34,8 +34,7 @@ description: Value specifying the number of pulses per revolution of the controlled FAN. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 2, 4] required:
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml index 44a63ff..eef6149 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
@@ -38,20 +38,18 @@ the accumulated values, this entry can also have two items which sets energy1/charge1 and energy2/charger2 respectively. Check table 12 of the datasheet for more information on the supported options. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 2 - maxItems: 2 - items: - enum: [0, 1, 2, 3] - default: 0 + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + items: + enum: [0, 1, 2, 3] + default: 0 adi,accumulation-deadband-microamp: description: This property controls the Accumulation Dead band which allows to set the level of current below which no accumulation takes place. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 maximum: 255 default: 0 @@ -61,8 +59,7 @@ active high, setting it to zero makets it active low. When this property is present, the GPIO is automatically configured as output and set to control a fan as a function of measured temperature. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1] default: 0 @@ -74,13 +71,12 @@ registers. Check table 13 of the datasheet for more information on the supported options. This property cannot be used together with adi,gpio-out-pol. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 2 - maxItems: 2 - items: - enum: [0, 1, 2] - default: 0 + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + items: + enum: [0, 1, 2] + default: 0 required: - compatible
diff --git a/Documentation/devicetree/bindings/hwmon/adt7475.yaml b/Documentation/devicetree/bindings/hwmon/adt7475.yaml index 46c4415..dfa821c 100644 --- a/Documentation/devicetree/bindings/hwmon/adt7475.yaml +++ b/Documentation/devicetree/bindings/hwmon/adt7475.yaml
@@ -46,22 +46,20 @@ set to 1 the attenuator is bypassed if set to 0 the attenuator is not bypassed. If the property is absent then the attenuator retains it's configuration from the bios/bootloader. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [0, 1] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] "^adi,pwm-active-state$": description: | Integer array, represents the active state of the pwm outputs If set to 0 the pwm uses a logic low output for 100% duty cycle. If set to 1 the pwm uses a logic high output for 100% duty cycle. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 3 - maxItems: 3 - items: - enum: [0, 1] - default: 1 + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 3 + maxItems: 3 + items: + enum: [0, 1] + default: 1 required: - compatible
diff --git a/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml b/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml new file mode 100644 index 0000000..84ae4cd --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml
@@ -0,0 +1,107 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/baikal,bt1-pvt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Baikal-T1 PVT Sensor + +maintainers: + - Serge Semin <fancer.lancer@gmail.com> + +description: | + Baikal-T1 SoC provides an embedded process, voltage and temperature + sensor to monitor an internal SoC environment (chip temperature, supply + voltage and process monitor) and on time detect critical situations, + which may cause the system instability and even damages. The IP-block + is based on the Analog Bits PVT sensor, but is equipped with a dedicated + control wrapper, which provides a MMIO registers-based access to the + sensor core functionality (APB3-bus based) and exposes an additional + functions like thresholds/data ready interrupts, its status and masks, + measurements timeout. Its internal structure is depicted on the next + diagram: + + Analog Bits core Bakal-T1 PVT control block + +--------------------+ +------------------------+ + | Temperature sensor |-+ +------| Sensors control | + |--------------------| |<---En---| |------------------------| + | Voltage sensor |-|<--Mode--| +--->| Sampled data | + |--------------------| |<--Trim--+ | |------------------------| + | Low-Vt sensor |-| | +--| Thresholds comparator | + |--------------------| |---Data----| | |------------------------| + | High-Vt sensor |-| | +->| Interrupts status | + |--------------------| |--Valid--+-+ | |------------------------| + | Standard-Vt sensor |-+ +---+--| Interrupts mask | + +--------------------+ |------------------------| + ^ | Interrupts timeout | + | +------------------------+ + | ^ ^ + Rclk-----+----------------------------------------+ | + APB3-------------------------------------------------+ + + This bindings describes the external Baikal-T1 PVT control interfaces + like MMIO registers space, interrupt request number and clocks source. + These are then used by the corresponding hwmon device driver to + implement the sysfs files-based access to the sensors functionality. + +properties: + compatible: + const: baikal,bt1-pvt + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: PVT reference clock + - description: APB3 interface clock + + clock-names: + items: + - const: ref + - const: pclk + + "#thermal-sensor-cells": + description: Baikal-T1 can be referenced as the CPU thermal-sensor + const: 0 + + baikal,pvt-temp-offset-millicelsius: + description: | + Temperature sensor trimming factor. It can be used to manually adjust the + temperature measurements within 7.130 degrees Celsius. + maxItems: 1 + items: + default: 0 + minimum: 0 + maximum: 7130 + +unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +examples: + - | + #include <dt-bindings/interrupt-controller/mips-gic.h> + + pvt@1f200000 { + compatible = "baikal,bt1-pvt"; + reg = <0x1f200000 0x1000>; + #thermal-sensor-cells = <0>; + + interrupts = <GIC_SHARED 31 IRQ_TYPE_LEVEL_HIGH>; + + baikal,pvt-temp-trim-millicelsius = <1000>; + + clocks = <&ccu_sys>, <&ccu_sys>; + clock-names = "ref", "pclk"; + }; +...
diff --git a/Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.txt b/Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.txt deleted file mode 100644 index ffb79cc..0000000 --- a/Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.txt +++ /dev/null
@@ -1,26 +0,0 @@ -Cirrus Logic Lochnagar Audio Development Board - -Lochnagar is an evaluation and development board for Cirrus Logic -Smart CODEC and Amp devices. It allows the connection of most Cirrus -Logic devices on mini-cards, as well as allowing connection of -various application processor systems to provide a full evaluation -platform. Audio system topology, clocking and power can all be -controlled through the Lochnagar, allowing the device under test -to be used in a variety of possible use cases. - -This binding document describes the binding for the hardware monitor -portion of the driver. - -This binding must be part of the Lochnagar MFD binding: - [4] ../mfd/cirrus,lochnagar.txt - -Required properties: - - - compatible : One of the following strings: - "cirrus,lochnagar2-hwmon" - -Example: - -lochnagar-hwmon { - compatible = "cirrus,lochnagar2-hwmon"; -};
diff --git a/Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.yaml new file mode 100644 index 0000000..cc00b97 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.yaml
@@ -0,0 +1,35 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/cirrus,lochnagar.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic Lochnagar Audio Development Board + +maintainers: + - patches@opensource.cirrus.com + +description: | + Lochnagar is an evaluation and development board for Cirrus Logic + Smart CODEC and Amp devices. It allows the connection of most Cirrus + Logic devices on mini-cards, as well as allowing connection of various + application processor systems to provide a full evaluation platform. + Audio system topology, clocking and power can all be controlled through + the Lochnagar, allowing the device under test to be used in a variety of + possible use cases. + + This binding document describes the binding for the hardware monitor + portion of the driver. + + This binding must be part of the Lochnagar MFD binding: + [1] ../mfd/cirrus,lochnagar.yaml + +properties: + compatible: + enum: + - cirrus,lochnagar2-hwmon + +required: + - compatible + +additionalProperties: false
diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml index 3f043e9..90b2fa3 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
@@ -45,16 +45,14 @@ The gain value for the PGA function. This is 8, 4, 2 or 1. The PGA gain affect the shunt voltage range. The range will be equal to: pga-gain * 40mV - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 2, 4, 8] default: 8 ti,bus-range-microvolt: description: | This is the operating range of the bus voltage in microvolt - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [16000000, 32000000] default: 32000000 @@ -63,14 +61,13 @@ Array of three(TMP513) or two(TMP512) n-Factor value for each remote temperature channel. See datasheet Table 11 for n-Factor range list and value interpretation. - allOf: - - $ref: /schemas/types.yaml#definitions/uint32-array - - minItems: 2 - maxItems: 3 - items: - default: 0x00 - minimum: 0x00 - maximum: 0xFF + $ref: /schemas/types.yaml#definitions/uint32-array + minItems: 2 + maxItems: 3 + items: + default: 0x00 + minimum: 0x00 + maximum: 0xFF required: - compatible
diff --git a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt index c9a6587..a8a35df 100644 --- a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
@@ -13,7 +13,7 @@ Example: -i2c@20205000 { +i2c@7e205000 { compatible = "brcm,bcm2835-i2c"; reg = <0x7e205000 0x1000>; interrupts = <2 21>;
diff --git a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml new file mode 100644 index 0000000..dc0952f --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
@@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/i2c/cdns,i2c-r1p10.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Cadence I2C controller Device Tree Bindings + +maintainers: + - Michal Simek <michal.simek@xilinx.com> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + enum: + - cdns,i2c-r1p10 # cadence i2c controller version 1.0 + - cdns,i2c-r1p14 # cadence i2c controller version 1.4 + + reg: + maxItems: 1 + + clocks: + minItems: 1 + + interrupts: + maxItems: 1 + + clock-frequency: + minimum: 1 + maximum: 400000 + description: | + Desired operating frequency, in Hz, of the bus. + + clock-name: + const: pclk + description: | + Input clock name. + +required: + - compatible + - reg + - clocks + - interrupts + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + i2c@e0004000 { + compatible = "cdns,i2c-r1p10"; + clocks = <&clkc 38>; + interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; + reg = <0xe0004000 0x1000>; + clock-frequency = <400000>; + #address-cells = <1>; + #size-cells = <0>; + };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-cadence.txt b/Documentation/devicetree/bindings/i2c/i2c-cadence.txt deleted file mode 100644 index ebaa90c..0000000 --- a/Documentation/devicetree/bindings/i2c/i2c-cadence.txt +++ /dev/null
@@ -1,28 +0,0 @@ -Binding for the Cadence I2C controller - -Required properties: - - reg: Physical base address and size of the controller's register area. - - compatible: Should contain one of: - * "cdns,i2c-r1p10" - Note: Use this when cadence i2c controller version 1.0 is used. - * "cdns,i2c-r1p14" - Note: Use this when cadence i2c controller version 1.4 is used. - - clocks: Input clock specifier. Refer to common clock bindings. - - interrupts: Interrupt specifier. Refer to interrupt bindings. - - #address-cells: Should be 1. - - #size-cells: Should be 0. - -Optional properties: - - clock-frequency: Desired operating frequency, in Hz, of the bus. - - clock-names: Input clock name, should be 'pclk'. - -Example: - i2c@e0004000 { - compatible = "cdns,i2c-r1p10"; - clocks = <&clkc 38>; - interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; - reg = <0xe0004000 0x1000>; - clock-frequency = <400000>; - #address-cells = <1>; - #size-cells = <0>; - };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-jz4780.txt b/Documentation/devicetree/bindings/i2c/i2c-jz4780.txt deleted file mode 100644 index d229eff..0000000 --- a/Documentation/devicetree/bindings/i2c/i2c-jz4780.txt +++ /dev/null
@@ -1,33 +0,0 @@ -* Ingenic JZ4780 I2C Bus controller - -Required properties: -- compatible: should be one of the following: - - "ingenic,jz4780-i2c" for the JZ4780 - - "ingenic,x1000-i2c" for the X1000 -- reg: Should contain the address & size of the I2C controller registers. -- interrupts: Should specify the interrupt provided by parent. -- clocks: Should contain a single clock specifier for the JZ4780 I2C clock. -- clock-frequency: desired I2C bus clock frequency in Hz. - -Recommended properties: -- pinctrl-names: should be "default"; -- pinctrl-0: phandle to pinctrl function - -Example - -/ { - i2c4: i2c4@10054000 { - compatible = "ingenic,jz4780-i2c"; - reg = <0x10054000 0x1000>; - - interrupt-parent = <&intc>; - interrupts = <56>; - - clocks = <&cgu JZ4780_CLK_SMB4>; - clock-frequency = <100000>; - pinctrl-names = "default"; - pinctrl-0 = <&pins_i2c4_data>; - - }; -}; -
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt index 68f6d73..88b71c1 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
@@ -8,6 +8,7 @@ "mediatek,mt2712-i2c": for MediaTek MT2712 "mediatek,mt6577-i2c": for MediaTek MT6577 "mediatek,mt6589-i2c": for MediaTek MT6589 + "mediatek,mt6797-i2c", "mediatek,mt6577-i2c": for MediaTek MT6797 "mediatek,mt7622-i2c": for MediaTek MT7622 "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623 "mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek MT7629
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml index 61eac76..790aa72 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
@@ -28,14 +28,14 @@ - const: rockchip,rk3399-i2c - items: - enum: - - rockchip,rk3036-i2c - - rockchip,rk3368-i2c + - rockchip,rk3036-i2c + - rockchip,rk3368-i2c - const: rockchip,rk3288-i2c - items: - enum: - - rockchip,px30-i2c - - rockchip,rk3308-i2c - - rockchip,rk3328-i2c + - rockchip,px30-i2c + - rockchip,rk3308-i2c + - rockchip,rk3328-i2c - const: rockchip,rk3399-i2c reg:
diff --git a/Documentation/devicetree/bindings/i2c/i2c-xiic.txt b/Documentation/devicetree/bindings/i2c/i2c-xiic.txt deleted file mode 100644 index caf42e9..0000000 --- a/Documentation/devicetree/bindings/i2c/i2c-xiic.txt +++ /dev/null
@@ -1,25 +0,0 @@ -Xilinx IIC controller: - -Required properties: -- compatible : Must be "xlnx,xps-iic-2.00.a" -- reg : IIC register location and length -- interrupts : IIC controller unterrupt -- #address-cells = <1> -- #size-cells = <0> -- clocks: Input clock specifier. Refer to common clock bindings. - -Optional properties: -- Child nodes conforming to i2c bus binding -- clock-names: Input clock name, should be 'pclk'. - -Example: - - axi_iic_0: i2c@40800000 { - compatible = "xlnx,xps-iic-2.00.a"; - clocks = <&clkc 15>; - interrupts = < 1 2 >; - reg = < 0x40800000 0x10000 >; - - #size-cells = <0>; - #address-cells = <1>; - };
diff --git a/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml b/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml new file mode 100644 index 0000000..682ed1b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml
@@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/ingenic,i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs I2C controller devicetree bindings + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + $nodename: + pattern: "^i2c@[0-9a-f]+$" + + compatible: + enum: + - ingenic,jz4780-i2c + - ingenic,x1000-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-frequency: + enum: [ 100000, 400000 ] + + dmas: + items: + - description: DMA controller phandle and request line for RX + - description: DMA controller phandle and request line for TX + + dma-names: + items: + - const: rx + - const: tx + +required: + - compatible + - reg + - interrupts + - clocks + - clock-frequency + - dmas + - dma-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/jz4780-cgu.h> + #include <dt-bindings/dma/jz4780-dma.h> + #include <dt-bindings/interrupt-controller/irq.h> + i2c@10054000 { + compatible = "ingenic,jz4780-i2c"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x10054000 0x1000>; + + interrupt-parent = <&intc>; + interrupts = <56>; + + clocks = <&cgu JZ4780_CLK_SMB4>; + pinctrl-names = "default"; + pinctrl-0 = <&pins_i2c4_data>; + + dmas = <&dma JZ4780_DMA_SMB4_RX 0xffffffff>, + <&dma JZ4780_DMA_SMB4_TX 0xffffffff>; + dma-names = "rx", "tx"; + + clock-frequency = <400000>; + + rtc@51 { + compatible = "nxp,pcf8563"; + reg = <0x51>; + + interrupt-parent = <&gpf>; + interrupts = <30 IRQ_TYPE_LEVEL_LOW>; + }; + };
diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt index f64064f..18c0de3 100644 --- a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
@@ -35,6 +35,12 @@ Due to above changes, Tegra114 I2C driver makes incompatible with previous hardware driver. Hence, tegra114 I2C controller is compatible with "nvidia,tegra114-i2c". + nvidia,tegra210-i2c-vi: Tegra210 has one I2C controller that is part of the + host1x domain and typically used for camera use-cases. This VI I2C + controller is mostly compatible with the programming model of the + regular I2C controllers with a few exceptions. The I2C registers start + at an offset of 0xc00 (instead of 0), registers are 16 bytes apart + (rather than 4) and the controller does not support slave mode. - reg: Should contain I2C controller registers physical address and length. - interrupts: Should contain I2C controller interrupts. - address-cells: Address cells for I2C device address.
diff --git a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt b/Documentation/devicetree/bindings/i2c/renesas,i2c.txt index c359965..a03f9f5 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt +++ b/Documentation/devicetree/bindings/i2c/renesas,i2c.txt
@@ -2,6 +2,7 @@ Required properties: - compatible: + "renesas,i2c-r8a7742" if the device is a part of a R8A7742 SoC. "renesas,i2c-r8a7743" if the device is a part of a R8A7743 SoC. "renesas,i2c-r8a7744" if the device is a part of a R8A7744 SoC. "renesas,i2c-r8a7745" if the device is a part of a R8A7745 SoC.
diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic.txt b/Documentation/devicetree/bindings/i2c/renesas,iic.txt index ffe085c9..89facb0 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,iic.txt +++ b/Documentation/devicetree/bindings/i2c/renesas,iic.txt
@@ -4,6 +4,7 @@ - compatible : - "renesas,iic-r8a73a4" (R-Mobile APE6) - "renesas,iic-r8a7740" (R-Mobile A1) + - "renesas,iic-r8a7742" (RZ/G1H) - "renesas,iic-r8a7743" (RZ/G1M) - "renesas,iic-r8a7744" (RZ/G1N) - "renesas,iic-r8a7745" (RZ/G1E)
diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml index 900ec1a..7b33423 100644 --- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
@@ -17,6 +17,7 @@ contains: enum: - st,stm32f7-i2c + - st,stm32mp15-i2c then: properties: i2c-scl-rising-time-ns: @@ -30,11 +31,10 @@ Fast Mode Plus speed is selected by slave. Format is phandle to syscfg / register offset within syscfg / register bitmask for FMP bit. - allOf: - - $ref: "/schemas/types.yaml#/definitions/phandle-array" - - items: - minItems: 3 - maxItems: 3 + $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + minItems: 3 + maxItems: 3 - if: properties: @@ -52,6 +52,7 @@ enum: - st,stm32f4-i2c - st,stm32f7-i2c + - st,stm32mp15-i2c reg: maxItems: 1 @@ -121,12 +122,12 @@ clocks = <&rcc 1 CLK_I2C1>; }; - //Example 3 (with st,stm32f7-i2c compatible on stm32mp) + //Example 3 (with st,stm32mp15-i2c compatible on stm32mp) #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/clock/stm32mp1-clks.h> #include <dt-bindings/reset/stm32mp1-resets.h> i2c@40013000 { - compatible = "st,stm32f7-i2c"; + compatible = "st,stm32mp15-i2c"; #address-cells = <1>; #size-cells = <0>; reg = <0x40013000 0x400>;
diff --git a/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml b/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml new file mode 100644 index 0000000..67c1c84 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
@@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/i2c/xlnx,xps-iic-2.00.a.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: ilinx IIC controller Device Tree Bindings + +maintainers: + - info@mocean-labs.com + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + const: xlnx,xps-iic-2.00.a + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + + clock-name: + const: pclk + description: | + Input clock name. + +required: + - compatible + - reg + - interrupts + - clocks + +examples: + - | + axi_iic_0: i2c@40800000 { + compatible = "xlnx,xps-iic-2.00.a"; + clocks = <&clkc 15>; + interrupts = < 1 2 >; + reg = < 0x40800000 0x10000 >; + + #size-cells = <0>; + #address-cells = <1>; + };
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt b/Documentation/devicetree/bindings/iio/accel/bma180.txt index f5323727..33da4a6 100644 --- a/Documentation/devicetree/bindings/iio/accel/bma180.txt +++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -1,15 +1,21 @@ -* Bosch BMA180 / BMA25x triaxial acceleration sensor +* Bosch BMA023 / BMA150/ BMA180 / BMA25x / SMB380 triaxial acceleration sensor +https://media.digikey.com/pdf/Data%20Sheets/Bosch/BMA150.pdf http://omapworld.com/BMA180_111_1002839.pdf http://ae-bst.resource.bosch.com/media/products/dokumente/bma250/bst-bma250-ds002-05.pdf Required properties: - compatible : should be one of: + "bosch,bma023" + "bosch,bma150" "bosch,bma180" "bosch,bma250" "bosch,bma254" + "bosch,smb380" - reg : the I2C address of the sensor + - vdd-supply : regulator phandle connected to the VDD pin + - vddio-supply : regulator phandle connected to the VDDIO pin Optional properties:
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml index f0934b2..deb34de 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
@@ -72,8 +72,8 @@ The channel number. It can have up to 8 channels on ad7124-4 and 16 channels on ad7124-8, numbered from 0 to 15. items: - minimum: 0 - maximum: 15 + minimum: 0 + maximum: 15 adi,reference-select: description: | @@ -83,9 +83,8 @@ 1: REFIN2(+)/REFIN2(−). 3: AVDD If this field is left empty, internal reference is selected. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [0, 1, 3] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 3] diff-channels: description: see Documentation/devicetree/bindings/iio/adc/adc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml new file mode 100644 index 0000000..c4f57fa --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml
@@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/adi,ad9467.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD9467 High-Speed ADC + +maintainers: + - Michael Hennerich <michael.hennerich@analog.com> + - Alexandru Ardelean <alexandru.ardelean@analog.com> + +description: | + The AD9467 is a 16-bit, monolithic, IF sampling analog-to-digital + converter (ADC). + + https://www.analog.com/media/en/technical-documentation/data-sheets/AD9467.pdf + +properties: + compatible: + enum: + - adi,ad9467 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: adc-clk + + powerdown-gpios: + description: + Pin that controls the powerdown mode of the device. + maxItems: 1 + + reset-gpios: + description: + Reset pin for the device. + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "adi,ad9467"; + reg = <0>; + clocks = <&adc_clk>; + clock-names = "adc-clk"; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml b/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml new file mode 100644 index 0000000..0924b2b --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml
@@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/adi,axi-adc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AXI ADC IP core + +maintainers: + - Michael Hennerich <michael.hennerich@analog.com> + - Alexandru Ardelean <alexandru.ardelean@analog.com> + +description: | + Analog Devices Generic AXI ADC IP core for interfacing an ADC device + with a high speed serial (JESD204B/C) or source synchronous parallel + interface (LVDS/CMOS). + Usually, some other interface type (i.e SPI) is used as a control + interface for the actual ADC, while this IP core will interface + to the data-lines of the ADC and handle the streaming of data into + memory via DMA. + + https://wiki.analog.com/resources/fpga/docs/axi_adc_ip + +properties: + compatible: + enum: + - adi,axi-adc-10.0.a + + reg: + maxItems: 1 + + dmas: + maxItems: 1 + + dma-names: + items: + - const: rx + + adi,adc-dev: + $ref: /schemas/types.yaml#/definitions/phandle + description: + A reference to a the actual ADC to which this FPGA ADC interfaces to. + +required: + - compatible + - dmas + - reg + - adi,adc-dev + +additionalProperties: false + +examples: + - | + axi-adc@44a00000 { + compatible = "adi,axi-adc-10.0.a"; + reg = <0x44a00000 0x10000>; + dmas = <&rx_dma 0>; + dma-names = "rx"; + + adi,adc-dev = <&spi_adc>; + }; +...
diff --git a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml index 118809a..6a991e9 100644 --- a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml +++ b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml
@@ -7,9 +7,9 @@ title: Linear Technology / Analog Devices LTC2496 ADC maintainers: - - Lars-Peter Clausen <lars@metafoo.de> - - Michael Hennerich <Michael.Hennerich@analog.com> - - Stefan Popa <stefan.popa@analog.com> + - Lars-Peter Clausen <lars@metafoo.de> + - Michael Hennerich <Michael.Hennerich@analog.com> + - Stefan Popa <stefan.popa@analog.com> properties: compatible: @@ -18,8 +18,7 @@ vref-supply: description: phandle to an external regulator providing the reference voltage - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle reg: description: spi chipselect number according to the usual spi bindings
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max1241.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max1241.yaml new file mode 100644 index 0000000..f562505 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/maxim,max1241.yaml
@@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2020 Alexandru Lazar +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/maxim,max1241.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX1241 12-bit, single-channel analog to digital converter + +maintainers: + - Alexandru Lazar <alazar@startmail.com> + +description: | + Bindings for the max1241 12-bit, single-channel ADC device. Datasheet + can be found at: + https://datasheets.maximintegrated.com/en/ds/MAX1240-MAX1241.pdf + +properties: + compatible: + enum: + - maxim,max1241 + + reg: + maxItems: 1 + + vdd-supply: + description: + Device tree identifier of the regulator that powers the ADC. + + vref-supply: + description: + Device tree identifier of the regulator that provides the external + reference voltage. + + shutdown-gpios: + description: + GPIO spec for the GPIO pin connected to the ADC's /SHDN pin. If + specified, the /SHDN pin will be asserted between conversions, + thus enabling power-down mode. + maxItems: 1 + +required: + - compatible + - reg + - vdd-supply + - vref-supply + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "maxim,max1241"; + reg = <0>; + vdd-supply = <&adc_vdd>; + vref-supply = <&adc_vref>; + spi-max-frequency = <1000000>; + shutdown-gpios = <&gpio 26 1>; + }; + };
diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml index 8ffeceb..95ab285 100644 --- a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml +++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
@@ -38,10 +38,9 @@ microchip,device-addr: description: Device address when multiple MCP3911 chips are present on the same SPI bus. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [0, 1, 2, 3] - - default: 0 + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 0 vref-supply: description: |
diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt deleted file mode 100644 index c2c50b5..0000000 --- a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt +++ /dev/null
@@ -1,37 +0,0 @@ -Rockchip Successive Approximation Register (SAR) A/D Converter bindings - -Required properties: -- compatible: should be "rockchip,<name>-saradc" or "rockchip,rk3066-tsadc" - - "rockchip,saradc": for rk3188, rk3288 - - "rockchip,rk3066-tsadc": for rk3036 - - "rockchip,rk3328-saradc", "rockchip,rk3399-saradc": for rk3328 - - "rockchip,rk3399-saradc": for rk3399 - - "rockchip,rv1108-saradc", "rockchip,rk3399-saradc": for rv1108 - -- reg: physical base address of the controller and length of memory mapped - region. -- interrupts: The interrupt number to the cpu. The interrupt specifier format - depends on the interrupt controller. -- clocks: Must contain an entry for each entry in clock-names. -- clock-names: Shall be "saradc" for the converter-clock, and "apb_pclk" for - the peripheral clock. -- vref-supply: The regulator supply ADC reference voltage. -- #io-channel-cells: Should be 1, see ../iio-bindings.txt - -Optional properties: -- resets: Must contain an entry for each entry in reset-names if need support - this option. See ../reset/reset.txt for details. -- reset-names: Must include the name "saradc-apb". - -Example: - saradc: saradc@2006c000 { - compatible = "rockchip,saradc"; - reg = <0x2006c000 0x100>; - interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>; - clock-names = "saradc", "apb_pclk"; - resets = <&cru SRST_SARADC>; - reset-names = "saradc-apb"; - #io-channel-cells = <1>; - vref-supply = <&vcc18>; - };
diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml new file mode 100644 index 0000000..bcff82a --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml
@@ -0,0 +1,80 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/rockchip-saradc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip Successive Approximation Register (SAR) A/D Converter + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + oneOf: + - const: rockchip,saradc + - const: rockchip,rk3066-tsadc + - const: rockchip,rk3399-saradc + - items: + - enum: + - rockchip,px30-saradc + - rockchip,rk3308-saradc + - rockchip,rk3328-saradc + - rockchip,rv1108-saradc + - const: rockchip,rk3399-saradc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: converter clock + - description: peripheral clock + + clock-names: + items: + - const: saradc + - const: apb_pclk + + resets: + maxItems: 1 + + reset-names: + const: saradc-apb + + vref-supply: + description: + The regulator supply for the ADC reference voltage. + + "#io-channel-cells": + const: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - vref-supply + - "#io-channel-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3288-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + saradc: saradc@2006c000 { + compatible = "rockchip,saradc"; + reg = <0x2006c000 0x100>; + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>; + clock-names = "saradc", "apb_pclk"; + resets = <&cru SRST_SARADC>; + reset-names = "saradc-apb"; + vref-supply = <&vcc18>; + #io-channel-cells = <1>; + };
diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml index 933ba37..28417b3 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
@@ -1,7 +1,7 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/bindings/iio/adc/st,stm32-adc.yaml#" +$id: "http://devicetree.org/schemas/iio/adc/st,stm32-adc.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: STMicroelectronics STM32 ADC bindings @@ -76,8 +76,7 @@ description: Phandle to system configuration controller. It can be used to control the analog circuitry on stm32mp1. - allOf: - - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: "/schemas/types.yaml#/definitions/phandle-array" interrupt-controller: true @@ -247,8 +246,7 @@ Resolution (bits) to use for conversions: - can be 6, 8, 10 or 12 on stm32f4 - can be 8, 10, 12, 14 or 16 on stm32h7 and stm32mp1 - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 st,adc-channels: description: | @@ -256,8 +254,7 @@ - 16 channels, numbered from 0 to 15 (for in0..in15) on stm32f4 - 20 channels, numbered from 0 to 19 (for in0..in19) on stm32h7 and stm32mp1. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array st,adc-diff-channels: description: | @@ -270,18 +267,17 @@ required. 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. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-matrix - - items: - items: - - description: | - "vinp" indicates positive input number - minimum: 0 - maximum: 19 - - description: | - "vinn" indicates negative input number - minimum: 0 - maximum: 19 + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "vinp" indicates positive input number + minimum: 0 + maximum: 19 + - description: | + "vinn" indicates negative input number + minimum: 0 + maximum: 19 st,min-sample-time-nsecs: description: @@ -291,8 +287,7 @@ array that matches "st,adc-channels" and/or "st,adc-diff-channels" list, to set sample time resp. for all channels, or independently for each channel. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array allOf: - if:
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 b162744..d61bc01 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
@@ -95,16 +95,14 @@ On stm32h7 and stm32mp1: - For st,stm32-dfsdm-adc: up to 8 channels numbered from 0 to 7. - For st,stm32-dfsdm-dmic: 1 channel numbered from 0 to 7. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - items: - minimum: 0 - maximum: 7 + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + minimum: 0 + maximum: 7 st,adc-channel-names: description: List of single-ended channel names. - allOf: - - $ref: /schemas/types.yaml#/definitions/string-array + $ref: /schemas/types.yaml#/definitions/string-array st,filter-order: description: | @@ -112,11 +110,10 @@ - 0: FastSinC - [1-5]: order 1 to 5. For audio purpose it is recommended to use order 3 to 5. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - items: - minimum: 0 - maximum: 5 + $ref: /schemas/types.yaml#/definitions/uint32 + items: + minimum: 0 + maximum: 5 "#io-channel-cells": const: 1 @@ -130,8 +127,7 @@ - "MANCH_F": manchester codec, rising edge = logic 1, falling edge = logic 0 items: enum: [ SPI_R, SPI_F, MANCH_R, MANCH_F ] - allOf: - - $ref: /schemas/types.yaml#/definitions/non-unique-string-array + $ref: /schemas/types.yaml#/definitions/non-unique-string-array st,adc-channel-clk-src: description: | @@ -142,8 +138,7 @@ - "CLKOUT_R": internal SPI clock divided by 2 (rising edge). items: enum: [ CLKIN, CLKOUT, CLKOUT_F, CLKOUT_R ] - allOf: - - $ref: /schemas/types.yaml#/definitions/non-unique-string-array + $ref: /schemas/types.yaml#/definitions/non-unique-string-array st,adc-alt-channel: description:
diff --git a/Documentation/devicetree/bindings/iio/chemical/ams,ccs811.yaml b/Documentation/devicetree/bindings/iio/chemical/ams,ccs811.yaml new file mode 100644 index 0000000..52341c8 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/chemical/ams,ccs811.yaml
@@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/chemical/ams,ccs811.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AMS CCS811 VOC Sensor + +maintainers: + - Narcisa Vasile <narcisaanamaria12@gmail.com> + +description: | + Ultra-Low Power Digital Gas Sensor for Monitoring Indoor Air Quality. + +properties: + compatible: + enum: + - ams,ccs811 + reg: + maxItems: 1 + + reset-gpios: + description: GPIO connected to the nRESET line. This is an active low + input to CCS811. + maxItems: 1 + + wakeup-gpios: + description: GPIO connected to the nWAKE line. This is an active low + input to CCS811. + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + voc@5b { + compatible = "ams,ccs811"; + reg = <0x5b>; + reset-gpios = <&gpioa 11 GPIO_ACTIVE_LOW>; + wakeup-gpios = <&gpioa 12 GPIO_ACTIVE_LOW>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/iio/chemical/atlas,sensor.yaml b/Documentation/devicetree/bindings/iio/chemical/atlas,sensor.yaml index edcd290..69e8931 100644 --- a/Documentation/devicetree/bindings/iio/chemical/atlas,sensor.yaml +++ b/Documentation/devicetree/bindings/iio/chemical/atlas,sensor.yaml
@@ -4,19 +4,21 @@ $id: http://devicetree.org/schemas/iio/chemical/atlas,sensor.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Atlas Scientific OEM sensors +title: Atlas Scientific OEM + EZO sensors maintainers: - Matt Ranostay <matt.ranostay@konsulko.com> description: | - Atlas Scientific OEM sensors connected via I2C + Atlas Scientific OEM + EZO sensors connected via I2C Datasheets: http://www.atlas-scientific.com/_files/_datasheets/_oem/DO_oem_datasheet.pdf http://www.atlas-scientific.com/_files/_datasheets/_oem/EC_oem_datasheet.pdf http://www.atlas-scientific.com/_files/_datasheets/_oem/ORP_oem_datasheet.pdf http://www.atlas-scientific.com/_files/_datasheets/_oem/pH_oem_datasheet.pdf + http://www.atlas-scientific.com/_files/_datasheets/_oem/RTD_oem_datasheet.pdf + http://www.atlas-scientific.com/_files/_datasheets/_probe/EZO_CO2_Datasheet.pdf properties: compatible: @@ -25,6 +27,8 @@ - atlas,ec-sm - atlas,orp-sm - atlas,ph-sm + - atlas,rtd-sm + - atlas,co2-ezo reg: maxItems: 1
diff --git a/Documentation/devicetree/bindings/iio/common.yaml b/Documentation/devicetree/bindings/iio/common.yaml new file mode 100644 index 0000000..97ffcb7 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/common.yaml
@@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common properties for iio sensors + +maintainers: + - Jonathan Cameron <jic23@kernel.org> + - Guido Günther <agx@sigxcpu.org> + +description: | + This document defines device tree properties common to several iio + sensors. It doesn't constitue a device tree binding specification by itself but + is meant to be referenced by device tree bindings. + + When referenced from sensor tree bindings the properties defined in this + document are defined as follows. The sensor tree bindings are responsible for + defining whether each property is required or optional. + +properties: + proximity-near-level: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + For proximity sensors whether an object can be considered near to the + device depends on parameters like sensor position, covering glass and + aperture. This value gives an indication to userspace for which + sensor readings this is the case. + + Raw proximity values equal or above this level should be + considered 'near' to the device (an object is near to the + sensor). + +...
diff --git a/Documentation/devicetree/bindings/iio/dac/ltc2632.txt b/Documentation/devicetree/bindings/iio/dac/ltc2632.txt index 338c322..1ab9570 100644 --- a/Documentation/devicetree/bindings/iio/dac/ltc2632.txt +++ b/Documentation/devicetree/bindings/iio/dac/ltc2632.txt
@@ -1,4 +1,4 @@ -Linear Technology LTC2632/2636 DAC +Linear Technology LTC2632/2634/2636 DAC Required properties: - compatible: Has to contain one of the following: @@ -8,6 +8,12 @@ lltc,ltc2632-h12 lltc,ltc2632-h10 lltc,ltc2632-h8 + lltc,ltc2634-l12 + lltc,ltc2634-l10 + lltc,ltc2634-l8 + lltc,ltc2634-h12 + lltc,ltc2634-h10 + lltc,ltc2634-h8 lltc,ltc2636-l12 lltc,ltc2636-l10 lltc,ltc2636-l8
diff --git a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.txt b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.txt deleted file mode 100644 index bf2925c..0000000 --- a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.txt +++ /dev/null
@@ -1,63 +0,0 @@ -STMicroelectronics STM32 DAC - -The STM32 DAC is a 12-bit voltage output digital-to-analog converter. The DAC -may be configured in 8 or 12-bit mode. It has two output channels, each with -its own converter. -It has built-in noise and triangle waveform generator and supports external -triggers for conversions. The DAC's output buffer allows a high drive output -current. - -Contents of a stm32 dac root node: ------------------------------------ -Required properties: -- compatible: Should be one of: - "st,stm32f4-dac-core" - "st,stm32h7-dac-core" -- reg: Offset and length of the device's register set. -- clocks: Must contain an entry for pclk (which feeds the peripheral bus - interface) -- clock-names: Must be "pclk". -- vref-supply: Phandle to the vref+ input analog reference supply. -- #address-cells = <1>; -- #size-cells = <0>; - -Optional properties: -- resets: Must contain the phandle to the reset controller. -- A pinctrl state named "default" for each DAC channel may be defined to set - DAC_OUTx pin in mode of operation for analog output on external pin. - -Contents of a stm32 dac child node: ------------------------------------ -DAC core node should contain at least one subnode, representing a -DAC instance/channel available on the machine. - -Required properties: -- compatible: Must be "st,stm32-dac". -- reg: Must be either 1 or 2, to define (single) channel in use -- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers" in - Documentation/devicetree/bindings/iio/iio-bindings.txt - -Example: - dac: dac@40007400 { - compatible = "st,stm32h7-dac-core"; - reg = <0x40007400 0x400>; - clocks = <&clk>; - clock-names = "pclk"; - vref-supply = <®_vref>; - pinctrl-names = "default"; - pinctrl-0 = <&dac_out1 &dac_out2>; - #address-cells = <1>; - #size-cells = <0>; - - dac1: dac@1 { - compatible = "st,stm32-dac"; - #io-channels-cells = <1>; - reg = <1>; - }; - - dac2: dac@2 { - compatible = "st,stm32-dac"; - #io-channels-cells = <1>; - reg = <2>; - }; - };
diff --git a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml new file mode 100644 index 0000000..393f700 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
@@ -0,0 +1,110 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/iio/dac/st,stm32-dac.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: STMicroelectronics STM32 DAC bindings + +description: | + The STM32 DAC is a 12-bit voltage output digital-to-analog converter. The DAC + may be configured in 8 or 12-bit mode. It has two output channels, each with + its own converter. + It has built-in noise and triangle waveform generator and supports external + triggers for conversions. The DAC's output buffer allows a high drive output + current. + +maintainers: + - Fabrice Gasnier <fabrice.gasnier@st.com> + +properties: + compatible: + enum: + - st,stm32f4-dac-core + - st,stm32h7-dac-core + + reg: + maxItems: 1 + + resets: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: pclk + + vref-supply: + description: Phandle to the vref input analog reference voltage. + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - vref-supply + - '#address-cells' + - '#size-cells' + +patternProperties: + "^dac@[1-2]+$": + type: object + description: + A DAC block node should contain at least one subnode, representing an + DAC instance/channel available on the machine. + + properties: + compatible: + const: st,stm32-dac + + reg: + description: Must be either 1 or 2, to define (single) channel in use + enum: [1, 2] + + '#io-channel-cells': + const: 1 + + additionalProperties: false + + required: + - compatible + - reg + - '#io-channel-cells' + +examples: + - | + // Example on stm32mp157c + #include <dt-bindings/clock/stm32mp1-clks.h> + dac: dac@40017000 { + compatible = "st,stm32h7-dac-core"; + reg = <0x40017000 0x400>; + clocks = <&rcc DAC12>; + clock-names = "pclk"; + vref-supply = <&vref>; + #address-cells = <1>; + #size-cells = <0>; + + dac@1 { + compatible = "st,stm32-dac"; + #io-channel-cells = <1>; + reg = <1>; + }; + + dac@2 { + compatible = "st,stm32-dac"; + #io-channel-cells = <1>; + reg = <2>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/bmg160.txt b/Documentation/devicetree/bindings/iio/gyroscope/bmg160.txt index 78e18a1..bb43d1a 100644 --- a/Documentation/devicetree/bindings/iio/gyroscope/bmg160.txt +++ b/Documentation/devicetree/bindings/iio/gyroscope/bmg160.txt
@@ -2,7 +2,7 @@ Required properties: - - compatible : should be "bosch,bmg160" or "bosch,bmi055_gyro" + - compatible : should be "bosch,bmg160", "bosch,bmi055_gyro" or "bosch,bmi088_gyro" - reg : the I2C address of the sensor (0x69) Optional properties:
diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16475.yaml b/Documentation/devicetree/bindings/iio/imu/adi,adis16475.yaml new file mode 100644 index 0000000..208faaf --- /dev/null +++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16475.yaml
@@ -0,0 +1,136 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/imu/adi,adis16475.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADIS16475 and similar IMUs + +maintainers: + - Nuno Sá <nuno.sa@analog.com> + +description: | + Analog Devices ADIS16475 and similar IMUs + https://www.analog.com/media/en/technical-documentation/data-sheets/ADIS16475.pdf + +properties: + compatible: + enum: + - adi,adis16475-1 + - adi,adis16475-2 + - adi,adis16475-3 + - adi,adis16477-1 + - adi,adis16477-2 + - adi,adis16477-3 + - adi,adis16470 + - adi,adis16465-1 + - adi,adis16465-2 + - adi,adis16465-3 + - adi,adis16467-1 + - adi,adis16467-2 + - adi,adis16467-3 + - adi,adis16500 + - adi,adis16505-1 + - adi,adis16505-2 + - adi,adis16505-3 + - adi,adis16507-1 + - adi,adis16507-2 + - adi,adis16507-3 + + reg: + maxItems: 1 + + spi-cpha: true + + spi-cpol: true + + spi-max-frequency: + maximum: 2000000 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + reset-gpios: + description: + Must be the device tree identifier of the RESET pin. If specified, + it will be asserted during driver probe. As the line is active low, + it should be marked GPIO_ACTIVE_LOW. + maxItems: 1 + + adi,sync-mode: + description: + Configures the device SYNC pin. The following modes are supported + 0 - output_sync + 1 - direct_sync + 2 - scaled_sync + 3 - pulse_sync + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + + adi,scaled-output-hz: + description: + This property must be present if the clock mode is scaled-sync through + clock-names property. In this mode, the input clock can have a range + of 1Hz to 128HZ which must be scaled to originate an allowable sample + rate. This property specifies that rate. + minimum: 1900 + maximum: 2100 + +required: + - compatible + - reg + - interrupts + - spi-cpha + - spi-cpol + +allOf: + - if: + properties: + compatible: + contains: + enum: + - adi,adis16500 + - adi,adis16505-1 + - adi,adis16505-2 + - adi,adis16505-3 + - adi,adis16507-1 + - adi,adis16507-2 + - adi,adis16507-3 + + then: + properties: + adi,sync-mode: + minimum: 0 + maximum: 2 + + - if: + properties: + adi,sync-mode: + enum: [1, 2, 3] + + then: + dependencies: + adi,sync-mode: [ clocks ] + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + adis16475: adis16475-3@0 { + compatible = "adi,adis16475-3"; + reg = <0>; + spi-cpha; + spi-cpol; + spi-max-frequency = <2000000>; + interrupts = <4 IRQ_TYPE_EDGE_RISING>; + interrupt-parent = <&gpio>; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/iio/imu/bmi160.txt b/Documentation/devicetree/bindings/iio/imu/bmi160.txt deleted file mode 100644 index 900c169..0000000 --- a/Documentation/devicetree/bindings/iio/imu/bmi160.txt +++ /dev/null
@@ -1,37 +0,0 @@ -Bosch BMI160 - Inertial Measurement Unit with Accelerometer, Gyroscope -and externally connectable Magnetometer - -https://www.bosch-sensortec.com/bst/products/all_products/bmi160 - -Required properties: - - compatible : should be "bosch,bmi160" - - reg : the I2C address or SPI chip select number of the sensor - - spi-max-frequency : set maximum clock frequency (only for SPI) - -Optional properties: - - interrupts : interrupt mapping for IRQ - - interrupt-names : set to "INT1" if INT1 pin should be used as interrupt - input, set to "INT2" if INT2 pin should be used instead - - drive-open-drain : set if the specified interrupt pin should be configured as - open drain. If not set, defaults to push-pull. - -Examples: - -bmi160@68 { - compatible = "bosch,bmi160"; - reg = <0x68>; - - interrupt-parent = <&gpio4>; - interrupts = <12 IRQ_TYPE_EDGE_RISING>; - interrupt-names = "INT1"; -}; - -bmi160@0 { - compatible = "bosch,bmi160"; - reg = <0>; - spi-max-frequency = <10000000>; - - interrupt-parent = <&gpio2>; - interrupts = <12 IRQ_TYPE_LEVEL_LOW>; - interrupt-names = "INT2"; -};
diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml new file mode 100644 index 0000000..0d0ef84 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
@@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/imu/bosch,bmi160.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bosch BMI160 + +maintainers: + - Jonathan Cameron <jic23@kernel.org> + +description: | + Inertial Measurement Unit with Accelerometer, Gyroscope and externally + connectable Magnetometer + https://www.bosch-sensortec.com/bst/products/all_products/bmi160 + +properties: + compatible: + const: bosch,bmi160 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-names: + enum: + - INT1 + - INT2 + description: | + set to "INT1" if INT1 pin should be used as interrupt input, set + to "INT2" if INT2 pin should be used instead + + drive-open-drain: + description: | + set if the specified interrupt pin should be configured as + open drain. If not set, defaults to push-pull. + +required: + - compatible + - reg + +examples: + - | + // Example for I2C + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bmi160@68 { + compatible = "bosch,bmi160"; + reg = <0x68>; + interrupt-parent = <&gpio4>; + interrupts = <12 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "INT1"; + }; + }; + - | + // Example for SPI + #include <dt-bindings/interrupt-controller/irq.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + bmi160@0 { + compatible = "bosch,bmi160"; + reg = <0>; + spi-max-frequency = <10000000>; + interrupt-parent = <&gpio2>; + interrupts = <12 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "INT2"; + }; + };
diff --git a/Documentation/devicetree/bindings/iio/light/amstaos,tsl2563.yaml b/Documentation/devicetree/bindings/iio/light/amstaos,tsl2563.yaml new file mode 100644 index 0000000..e201a06 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/amstaos,tsl2563.yaml
@@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/amstaos,tsl2563.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AMS TAOS TSL2563 ambient light sensor + +maintainers: + - Sebastian Reichel <sre@kernel.org> + +description: | + Ambient light sensor with an i2c interface. + +properties: + compatible: + enum: + - amstaos,tsl2560 + - amstaos,tsl2561 + - amstaos,tsl2562 + - amstaos,tsl2563 + + reg: + maxItems: 1 + + amstaos,cover-comp-gain: + description: Multiplier for gain compensation + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 16] + +required: + - compatible + - reg + +examples: + - | + i2c { + + #address-cells = <1>; + #size-cells = <0>; + + light-sensor@29 { + compatible = "amstaos,tsl2563"; + reg = <0x29>; + amstaos,cover-comp-gain = <16>; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/iio/light/tsl2563.txt b/Documentation/devicetree/bindings/iio/light/tsl2563.txt deleted file mode 100644 index f91e809..0000000 --- a/Documentation/devicetree/bindings/iio/light/tsl2563.txt +++ /dev/null
@@ -1,19 +0,0 @@ -* AMS TAOS TSL2563 ambient light sensor - -Required properties: - - - compatible : should be "amstaos,tsl2563" - - reg : the I2C address of the sensor - -Optional properties: - - - amstaos,cover-comp-gain : integer used as multiplier for gain - compensation (default = 1) - -Example: - -tsl2563@29 { - compatible = "amstaos,tsl2563"; - reg = <0x29>; - amstaos,cover-comp-gain = <16>; -};
diff --git a/Documentation/devicetree/bindings/iio/light/tsl2772.yaml b/Documentation/devicetree/bindings/iio/light/tsl2772.yaml index e8f7d1a..d812298 100644 --- a/Documentation/devicetree/bindings/iio/light/tsl2772.yaml +++ b/Documentation/devicetree/bindings/iio/light/tsl2772.yaml
@@ -33,13 +33,12 @@ amstaos,proximity-diodes: description: Proximity diodes to enable - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 1 - maxItems: 2 - items: - minimum: 0 - maximum: 1 + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 2 + items: + minimum: 0 + maximum: 1 interrupts: maxItems: 1
diff --git a/Documentation/devicetree/bindings/iio/light/vcnl4000.txt b/Documentation/devicetree/bindings/iio/light/vcnl4000.txt deleted file mode 100644 index 955af45..0000000 --- a/Documentation/devicetree/bindings/iio/light/vcnl4000.txt +++ /dev/null
@@ -1,24 +0,0 @@ -VISHAY VCNL4000 - Ambient Light and proximity sensor - -This driver supports the VCNL4000/10/20/40 and VCNL4200 chips - -Required properties: - - -compatible: must be one of : - vishay,vcnl4000 - vishay,vcnl4010 - vishay,vcnl4020 - vishay,vcnl4040 - vishay,vcnl4200 - - -reg: I2C address of the sensor, should be one from below based on the model: - 0x13 - 0x51 - 0x60 - -Example: - -light-sensor@51 { - compatible = "vishay,vcnl4200"; - reg = <0x51>; -};
diff --git a/Documentation/devicetree/bindings/iio/light/vishay,vcnl4000.yaml b/Documentation/devicetree/bindings/iio/light/vishay,vcnl4000.yaml new file mode 100644 index 0000000..da8f2e8 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/vishay,vcnl4000.yaml
@@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/vishay,vcnl4000.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: VISHAY VCNL4000 ambient light and proximity sensor + +maintainers: + - Peter Meerwald <pmeerw@pmeerw.net> + +description: | + Ambient light sensing with proximity detection over an i2c + interface. + +allOf: + - $ref: ../common.yaml# + +properties: + compatible: + enum: + - vishay,vcnl4000 + - vishay,vcnl4010 + - vishay,vcnl4020 + - vishay,vcnl4040 + - vishay,vcnl4200 + reg: + maxItems: 1 + + proximity-near-level: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: +- | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + light-sensor@51 { + compatible = "vishay,vcnl4200"; + reg = <0x51>; + proximity-near-level = <220>; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8974.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8974.txt index baecc4a..7f06eff 100644 --- a/Documentation/devicetree/bindings/iio/magnetometer/ak8974.txt +++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8974.txt
@@ -2,7 +2,9 @@ Required properties: -- compatible : should be "asahi-kasei,ak8974" +- compatible: + * "asahi-kasei,ak8974" + * "alps,hscdtd008a" - reg : the I2C address of the magnetometer Optional properties:
diff --git a/Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml b/Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml new file mode 100644 index 0000000..4190253 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml
@@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/proximity/vishay,vcnl3020.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Integrated Proximity Sensor With Infrared Emitter + +maintainers: + - Ivan Mikhaylov <i.mikhaylov@yadro.com> + +description: | + The VCNL3020 is a fully integrated proximity sensor. Fully integrated means + that the infrared emitter is included in the package. It has 16-bit + resolution. It includes a signal processing IC and features standard I2C + communication interface. It features an interrupt function. + + Specifications about the devices can be found at: + https://www.vishay.com/docs/84150/vcnl3020.pdf + +properties: + compatible: + enum: + - vishay,vcnl3020 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vdd-supply: + description: Regulator that provides power to the sensor + + vddio-supply: + description: Regulator that provides power to the bus + + vishay,led-current-microamp: + description: + The driver current for the LED used in proximity sensing. + enum: [0, 10000, 20000, 30000, 40000, 50000, 60000, 70000, 80000, 90000, + 100000, 110000, 120000, 130000, 140000, 150000, 160000, 170000, + 180000, 190000, 200000] + default: 20000 + +required: + - compatible + - reg + +examples: + - | + i2c { + + #address-cells = <1>; + #size-cells = <0>; + + proximity@13 { + compatible = "vishay,vcnl3020"; + reg = <0x13>; + vishay,led-current-microamp = <200000>; + }; + };
diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt b/Documentation/devicetree/bindings/iio/st-sensors.txt index 0ef64a4..3213599 100644 --- a/Documentation/devicetree/bindings/iio/st-sensors.txt +++ b/Documentation/devicetree/bindings/iio/st-sensors.txt
@@ -50,6 +50,7 @@ - st,lis3dhh - st,lis3de - st,lis2de12 +- st,lis2hh12 Gyroscopes: - st,l3g4200d-gyro
diff --git a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml index 8fb46de..40ccbe7 100644 --- a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml +++ b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
@@ -42,10 +42,9 @@ 0 - 50/60Hz rejection 1 - 60Hz rejection 2 - 50Hz rejection - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - maximum: 2 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 2 '#address-cells': const: 1 @@ -91,8 +90,7 @@ 7 - Type T Thermocouple 8 - Type B Thermocouple 9 - Custom Thermocouple - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 1 maximum: 9 @@ -121,8 +119,7 @@ more details look at table 69 and 70. Note should be signed, but dtc doesn't currently maintain the sign. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint64-matrix + $ref: /schemas/types.yaml#/definitions/uint64-matrix minItems: 3 maxItems: 64 items: @@ -138,8 +135,7 @@ properties: adi,sensor-type: description: Identifies the sensor as a diode. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 const: 28 adi,single-ended: @@ -196,8 +192,7 @@ 16 - RTD PT-1000 (0.00375) 17 - RTD NI-120 18 - RTD Custom - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 10 maximum: 18 @@ -210,9 +205,8 @@ description: Identifies the number of wires used by the RTD. Setting this property to 5 means 4 wires with Kelvin Rsense. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [2, 3, 4, 5] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [2, 3, 4, 5] adi,rsense-share: description: @@ -237,18 +231,16 @@ description: This property set the RTD curve used and the corresponding Callendar-VanDusen constants. Look at table 30 of the datasheet. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - maximum: 3 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 adi,custom-rtd: description: This is a table, where each entry should be a pair of resistance(ohm)-temperature(K). The entries added here are in uohm and uK. For more details values look at table 74 and 75. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint64-matrix + $ref: /schemas/types.yaml#/definitions/uint64-matrix items: minItems: 3 maxItems: 64 @@ -260,7 +252,7 @@ - adi,rsense-handle dependencies: - adi,current-rotate: [ adi,rsense-share ] + adi,current-rotate: [ "adi,rsense-share" ] "^thermistor@": type: object @@ -280,8 +272,7 @@ 25 - Thermistor Spectrum 1003k 1kohm 26 - Thermistor Custom Steinhart-Hart 27 - Custom Thermistor - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 19 maximum: 27 @@ -314,10 +305,9 @@ This property controls the magnitude of the excitation current applied to the thermistor. Value 0 set's the sensor in auto-range mode. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [0, 250, 500, 1000, 5000, 10000, 25000, 50000, 100000, - 250000, 500000, 1000000] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 250, 500, 1000, 5000, 10000, 25000, 50000, 100000, 250000, + 500000, 1000000] adi,custom-thermistor: description: @@ -325,8 +315,7 @@ resistance(ohm)-temperature(K). The entries added here are in uohm and uK only for custom thermistors. For more details look at table 78 and 79. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint64-matrix + $ref: /schemas/types.yaml#/definitions/uint64-matrix minItems: 3 maxItems: 64 items: @@ -339,8 +328,7 @@ be programmed into the device memory using this property. For Steinhart sensors the coefficients are given in the raw format. Look at table 82 for more information. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array items: minItems: 6 maxItems: 6 @@ -349,7 +337,7 @@ - adi,rsense-handle dependencies: - adi,current-rotate: [ adi,rsense-share ] + adi,current-rotate: [ "adi,rsense-share" ] "^adc@": type: object @@ -358,8 +346,7 @@ properties: adi,sensor-type: description: Identifies the sensor as a direct adc. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 const: 30 adi,single-ended: @@ -379,8 +366,7 @@ adi,sensor-type: description: Identifies the sensor as a rsense. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 const: 29 adi,rsense-val-milli-ohms:
diff --git a/Documentation/devicetree/bindings/index.rst b/Documentation/devicetree/bindings/index.rst new file mode 100644 index 0000000..3837b17 --- /dev/null +++ b/Documentation/devicetree/bindings/index.rst
@@ -0,0 +1,12 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========== +Device Tree +=========== + +.. toctree:: + :maxdepth: 1 + + ABI + submitting-patches + writing-bindings
diff --git a/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml index 5b3b71c..cffd020 100644 --- a/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml +++ b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
@@ -16,8 +16,8 @@ - const: allwinner,sun4i-a10-lradc-keys - const: allwinner,sun8i-a83t-r-lradc - items: - - const: allwinner,sun50i-a64-lradc - - const: allwinner,sun8i-a83t-r-lradc + - const: allwinner,sun50i-a64-lradc + - const: allwinner,sun8i-a83t-r-lradc reg: maxItems: 1 @@ -42,9 +42,8 @@ description: Keycode to emit channel: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [0, 1] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] description: ADC Channel this key is attached to voltage:
diff --git a/Documentation/devicetree/bindings/input/elants_i2c.txt b/Documentation/devicetree/bindings/input/elants_i2c.txt deleted file mode 100644 index 5edac8b..0000000 --- a/Documentation/devicetree/bindings/input/elants_i2c.txt +++ /dev/null
@@ -1,34 +0,0 @@ -Elantech I2C Touchscreen - -Required properties: -- compatible: must be "elan,ekth3500". -- reg: I2C address of the chip. -- interrupts: interrupt to which the chip is connected (see interrupt - binding[0]). - -Optional properties: -- wakeup-source: touchscreen 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]). -- reset-gpios: reset gpio the chip is connected to. -- vcc33-supply: a phandle for the regulator supplying 3.3V power. -- vccio-supply: a phandle for the regulator supplying IO power. - -[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt -[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt - -Example: - &i2c1 { - /* ... */ - - touchscreen@10 { - compatible = "elan,ekth3500"; - reg = <0x10>; - interrupt-parent = <&gpio4>; - interrupts = <0x0 IRQ_TYPE_EDGE_FALLING>; - wakeup-source; - }; - - /* ... */ - };
diff --git a/Documentation/devicetree/bindings/input/gpio-keys-polled.txt b/Documentation/devicetree/bindings/input/gpio-keys-polled.txt deleted file mode 100644 index 4d9a371..0000000 --- a/Documentation/devicetree/bindings/input/gpio-keys-polled.txt +++ /dev/null
@@ -1,45 +0,0 @@ -Device-Tree bindings for input/gpio_keys_polled.c keyboard driver - -Required properties: - - compatible = "gpio-keys-polled"; - - poll-interval: Poll interval time in milliseconds - -Optional properties: - - autorepeat: Boolean, Enable auto repeat feature of Linux input - subsystem. - -Each button (key) is represented as a sub-node of "gpio-keys-polled": -Subnode properties: - - - gpios: OF device-tree gpio specification. - - label: Descriptive name of the key. - - linux,code: Key / Axis code to emit. - -Optional subnode-properties: - - linux,input-type: Specify event type this button/key generates. - If not specified defaults to <1> == EV_KEY. - - linux,input-value: If linux,input-type is EV_ABS or EV_REL then this - value is sent for events this button generates when pressed. - EV_ABS/EV_REL axis will generate an event with a value of 0 when - all buttons with linux,input-type == type and linux,code == axis - are released. This value is interpreted as a signed 32 bit value, - e.g. to make a button generate a value of -1 use: - linux,input-value = <0xffffffff>; /* -1 */ - - debounce-interval: Debouncing interval time in milliseconds. - If not specified defaults to 5. - - wakeup-source: Boolean, button can wake-up the system. - (Legacy property supported: "gpio-key,wakeup") - -Example nodes: - - gpio_keys_polled { - compatible = "gpio-keys-polled"; - poll-interval = <100>; - autorepeat; - - button21 { - label = "GPIO Key UP"; - linux,code = <103>; - gpios = <&gpio1 0 1>; - }; - ...
diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt b/Documentation/devicetree/bindings/input/gpio-keys.txt deleted file mode 100644 index 7cccc49..0000000 --- a/Documentation/devicetree/bindings/input/gpio-keys.txt +++ /dev/null
@@ -1,58 +0,0 @@ -Device-Tree bindings for input/keyboard/gpio_keys.c keyboard driver - -Required properties: - - compatible = "gpio-keys"; - -Optional properties: - - autorepeat: Boolean, Enable auto repeat feature of Linux input - subsystem. - - label: String, name of the input device. - -Each button (key) is represented as a sub-node of "gpio-keys": -Subnode properties: - - - gpios: OF device-tree gpio specification. - - interrupts: the interrupt line for that input. - - label: Descriptive name of the key. - - linux,code: Keycode to emit. - -Note that either "interrupts" or "gpios" properties can be omitted, but not -both at the same time. Specifying both properties is allowed. - -Optional subnode-properties: - - linux,input-type: Specify event type this button/key generates. - If not specified defaults to <1> == EV_KEY. - - debounce-interval: Debouncing interval time in milliseconds. - If not specified defaults to 5. - - wakeup-source: Boolean, button can wake-up the system. - (Legacy property supported: "gpio-key,wakeup") - - wakeup-event-action: Specifies whether the key should wake the - system when asserted, when deasserted, or both. This property is - only valid for keys that wake up the system (e.g., when the - "wakeup-source" property is also provided). - Supported values are defined in linux-event-codes.h: - EV_ACT_ASSERTED - asserted - EV_ACT_DEASSERTED - deasserted - EV_ACT_ANY - both asserted and deasserted - - linux,can-disable: Boolean, indicates that button is connected - to dedicated (not shared) interrupt which can be disabled to - suppress events from the button. - -Example nodes: - - gpio-keys { - compatible = "gpio-keys"; - autorepeat; - - up { - label = "GPIO Key UP"; - linux,code = <103>; - gpios = <&gpio1 0 1>; - }; - - down { - label = "GPIO Key DOWN"; - linux,code = <108>; - interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>; - }; - ...
diff --git a/Documentation/devicetree/bindings/input/gpio-keys.yaml b/Documentation/devicetree/bindings/input/gpio-keys.yaml new file mode 100644 index 0000000..6966ab0 --- /dev/null +++ b/Documentation/devicetree/bindings/input/gpio-keys.yaml
@@ -0,0 +1,149 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/gpio-keys.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Device-Tree bindings for GPIO attached keys + +maintainers: + - Rob Herring <robh@kernel.org> + +properties: + compatible: + enum: + - gpio-keys + - gpio-keys-polled + +patternProperties: + ".*": + if: + type: object + then: + $ref: input.yaml# + + properties: + gpios: + maxItems: 1 + + interrupts: + maxItems: 1 + + label: + description: Descriptive name of the key. + + linux,code: + description: Key / Axis code to emit. + $ref: /schemas/types.yaml#definitions/uint32 + + linux,input-type: + description: + Specify event type this button/key generates. If not specified defaults to + <1> == EV_KEY. + $ref: /schemas/types.yaml#definitions/uint32 + + default: 1 + + linux,input-value: + description: | + If linux,input-type is EV_ABS or EV_REL then this + value is sent for events this button generates when pressed. + EV_ABS/EV_REL axis will generate an event with a value of 0 + when all buttons with linux,input-type == type and + linux,code == axis are released. This value is interpreted + as a signed 32 bit value, e.g. to make a button generate a + value of -1 use: + + linux,input-value = <0xffffffff>; /* -1 */ + + $ref: /schemas/types.yaml#definitions/uint32 + + debounce-interval: + description: + Debouncing interval time in milliseconds. If not specified defaults to 5. + $ref: /schemas/types.yaml#definitions/uint32 + + default: 5 + + wakeup-source: + description: Button can wake-up the system. + + wakeup-event-action: + description: | + Specifies whether the key should wake the system when asserted, when + deasserted, or both. This property is only valid for keys that wake up the + system (e.g., when the "wakeup-source" property is also provided). + + Supported values are defined in linux-event-codes.h: + + EV_ACT_ANY - both asserted and deasserted + EV_ACT_ASSERTED - asserted + EV_ACT_DEASSERTED - deasserted + $ref: /schemas/types.yaml#definitions/uint32 + enum: [0, 1, 2] + + linux,can-disable: + description: + Indicates that button is connected to dedicated (not shared) interrupt + which can be disabled to suppress events from the button. + type: boolean + + pinctrl-0: + maxItems: 1 + + pinctrl-names: + maxItems: 1 + + required: + - linux,code + + anyOf: + - required: + - interrupts + - required: + - gpios + + dependencies: + wakeup-event-action: [ wakeup-source ] + linux,input-value: [ gpios ] + + unevaluatedProperties: false + +if: + properties: + compatible: + const: gpio-keys-polled +then: + properties: + poll-interval: + description: + Poll interval time in milliseconds + $ref: /schemas/types.yaml#definitions/uint32 + + required: + - poll-interval + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + gpio-keys { + compatible = "gpio-keys"; + autorepeat; + + up { + label = "GPIO Key UP"; + linux,code = <103>; + gpios = <&gpio1 0 1>; + }; + + down { + label = "GPIO Key DOWN"; + linux,code = <108>; + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/input/input.yaml b/Documentation/devicetree/bindings/input/input.yaml index 6d51904..8edcb3c 100644 --- a/Documentation/devicetree/bindings/input/input.yaml +++ b/Documentation/devicetree/bindings/input/input.yaml
@@ -18,11 +18,10 @@ description: Specifies an array of numeric keycode values to be used for reporting button presses. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - items: - minimum: 0 - maximum: 0xff + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + minimum: 0 + maximum: 0xff poll-interval: description: Poll interval time in milliseconds.
diff --git a/Documentation/devicetree/bindings/input/iqs269a.yaml b/Documentation/devicetree/bindings/input/iqs269a.yaml new file mode 100644 index 0000000..9c154e5 --- /dev/null +++ b/Documentation/devicetree/bindings/input/iqs269a.yaml
@@ -0,0 +1,555 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/iqs269a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Azoteq IQS269A Capacitive Touch Controller + +maintainers: + - Jeff LaBundy <jeff@labundy.com> + +description: | + The Azoteq IQS269A is an 8-channel capacitive touch controller that features + additional Hall-effect and inductive sensing capabilities. + + Link to datasheet: https://www.azoteq.com/ + +properties: + compatible: + const: azoteq,iqs269a + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + azoteq,hall-enable: + type: boolean + description: + Enables Hall-effect sensing on channels 6 and 7. In this case, keycodes + assigned to channel 6 are ignored and keycodes assigned to channel 7 are + interpreted as switch codes. Refer to the datasheet for requirements im- + posed on channels 6 and 7 by Hall-effect sensing. + + azoteq,suspend-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 0 + description: | + Specifies the power mode during suspend as follows: + 0: Automatic (same as normal runtime, i.e. suspend/resume disabled) + 1: Low power (all sensing at a reduced reporting rate) + 2: Ultra-low power (channel 0 proximity sensing) + 3: Halt (no sensing) + + azoteq,clk-div: + type: boolean + description: Divides the device's core clock by a factor of 4. + + azoteq,ulp-update: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + default: 3 + description: Specifies the ultra-low-power mode update rate. + + azoteq,reseed-offset: + type: boolean + description: + Applies an 8-count offset to all long-term averages upon either ATI or + reseed events. + + azoteq,filt-str-lp-lta: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 0 + description: + Specifies the long-term average filter strength during low-power mode. + + azoteq,filt-str-lp-cnt: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 0 + description: + Specifies the raw count filter strength during low-power mode. + + azoteq,filt-str-np-lta: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 0 + description: + Specifies the long-term average filter strength during normal-power mode. + + azoteq,filt-str-np-cnt: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 0 + description: + Specifies the raw count filter strength during normal-power mode. + + azoteq,rate-np-ms: + minimum: 0 + maximum: 255 + default: 16 + description: Specifies the report rate (in ms) during normal-power mode. + + azoteq,rate-lp-ms: + minimum: 0 + maximum: 255 + default: 160 + description: Specifies the report rate (in ms) during low-power mode. + + azoteq,rate-ulp-ms: + multipleOf: 16 + minimum: 0 + maximum: 4080 + default: 160 + description: Specifies the report rate (in ms) during ultra-low-power mode. + + azoteq,timeout-pwr-ms: + multipleOf: 512 + minimum: 0 + maximum: 130560 + default: 2560 + description: + Specifies the length of time (in ms) to wait for an event during normal- + power mode before transitioning to low-power mode. + + azoteq,timeout-lta-ms: + multipleOf: 512 + minimum: 0 + maximum: 130560 + default: 32768 + description: + Specifies the length of time (in ms) to wait before resetting the long- + term average of all channels. Specify the maximum timeout to disable it + altogether. + + azoteq,ati-band-disable: + type: boolean + description: Disables the ATI band check. + + azoteq,ati-lp-only: + type: boolean + description: Limits automatic ATI to low-power mode. + + azoteq,ati-band-tighten: + type: boolean + description: Tightens the ATI band from 1/8 to 1/16 of the desired target. + + azoteq,filt-disable: + type: boolean + description: Disables all raw count filtering. + + azoteq,gpio3-select: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + default: 0 + description: + Selects the channel for which the GPIO3 pin represents touch state. + + azoteq,dual-direction: + type: boolean + description: + Specifies that long-term averages are to freeze in the presence of either + increasing or decreasing counts, thereby permitting events to be reported + in either direction. + + azoteq,tx-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 0 + description: | + Specifies the inductive sensing excitation frequency as follows (paren- + thesized numbers represent the frequency if 'azoteq,clk-div' is present): + 0: 16 MHz (4 MHz) + 1: 8 MHz (2 MHz) + 2: 4 MHz (1 MHz) + 3: 2 MHz (500 kHz) + + azoteq,global-cap-increase: + type: boolean + description: Increases the global capacitance adder from 0.5 pF to 1.5 pF. + + azoteq,reseed-select: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 0 + description: | + Specifies the event(s) that prompt the device to reseed (i.e. reset the + long-term average) of an associated channel as follows: + 0: None + 1: Proximity + 2: Proximity or touch + 3: Proximity, touch or deep touch + + azoteq,tracking-enable: + type: boolean + description: + Enables all associated channels to track their respective reference + channels. + + azoteq,filt-str-slider: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 1 + description: Specifies the slider coordinate filter strength. + +patternProperties: + "^channel@[0-7]$": + type: object + description: + Represents a single sensing channel. A channel is active if defined and + inactive otherwise. + + properties: + reg: + minimum: 0 + maximum: 7 + description: Index of the channel. + + azoteq,reseed-disable: + type: boolean + description: + Prevents the channel from being reseeded if the long-term average + timeout (defined in 'azoteq,timeout-lta') expires. + + azoteq,blocking-enable: + type: boolean + description: Specifies that the channel is a blocking channel. + + azoteq,slider0-select: + type: boolean + description: Specifies that the channel participates in slider 0. + + azoteq,slider1-select: + type: boolean + description: Specifies that the channel participates in slider 1. + + azoteq,rx-enable: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + items: + minimum: 0 + maximum: 7 + description: + Specifies the CRX pin(s) associated with the channel. By default, only + the CRX pin corresponding to the channel's index is enabled (e.g. CRX0 + for channel 0). + + azoteq,tx-enable: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + items: + minimum: 0 + maximum: 7 + default: [0, 1, 2, 3, 4, 5, 6, 7] + description: Specifies the TX pin(s) associated with the channel. + + azoteq,meas-cap-decrease: + type: boolean + description: + Decreases the internal measurement capacitance from 60 pF to 15 pF. + + azoteq,rx-float-inactive: + type: boolean + description: Floats any inactive CRX pins instead of grounding them. + + azoteq,local-cap-size: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + default: 0 + description: | + Specifies the capacitance to be added to the channel as follows: + 0: None + 1: Global adder (based on 'azoteq,global-cap-increase') + 2: Global adder + 0.5 pF + + azoteq,invert-enable: + type: boolean + description: + Inverts the polarity of the states reported for proximity, touch and + deep-touch events relative to their respective thresholds. + + azoteq,proj-bias: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 2 + description: | + Specifies the bias current applied during projected-capacitance + sensing as follows: + 0: 2.5 uA + 1: 5 uA + 2: 10 uA + 3: 20 uA + + azoteq,sense-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 9, 14, 15] + default: 0 + description: | + Specifies the channel's sensing mode as follows: + 0: Self capacitance + 1: Projected capacitance + 9: Self or mutual inductance + 14: Hall effect + 15: Temperature + + azoteq,sense-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 1 + description: | + Specifies the channel's sensing frequency as follows (parenthesized + numbers represent the frequency if 'azoteq,clk-div' is present): + 0: 4 MHz (1 MHz) + 1: 2 MHz (500 kHz) + 2: 1 MHz (250 kHz) + 3: 500 kHz (125 kHz) + + azoteq,static-enable: + type: boolean + description: Enables the static front-end for the channel. + + azoteq,ati-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 3 + description: | + Specifies the channel's ATI mode as follows: + 0: Disabled + 1: Semi-partial + 2: Partial + 3: Full + + azoteq,ati-base: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [75, 100, 150, 200] + default: 100 + description: Specifies the channel's ATI base. + + azoteq,ati-target: + $ref: /schemas/types.yaml#/definitions/uint32 + multipleOf: 32 + minimum: 0 + maximum: 2016 + default: 512 + description: Specifies the channel's ATI target. + + azoteq,assoc-select: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 + items: + minimum: 0 + maximum: 7 + description: + Specifies the associated channels for which the channel serves as a + reference channel. By default, no channels are selected. + + azoteq,assoc-weight: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + default: 0 + description: + Specifies the channel's impact weight if it acts as an associated + channel (0 = 0% impact, 255 = 200% impact). + + patternProperties: + "^event-prox(-alt)?$": + type: object + description: + Represents a proximity event reported by the channel in response to + a decrease in counts. Node names suffixed with '-alt' instead corre- + spond to an increase in counts. + + By default, the long-term average tracks an increase in counts such + that only events corresponding to a decrease in counts are reported + (refer to the datasheet for more information). + + Specify 'azoteq,dual-direction' to freeze the long-term average when + the counts increase or decrease such that events of either direction + can be reported. Alternatively, specify 'azoteq,invert-enable' to in- + vert the polarity of the states reported by the channel. + + Complementary events (e.g. event-touch and event-touch-alt) can both + be present and specify different key or switch codes, but not differ- + ent thresholds or hysteresis (if applicable). + + properties: + azoteq,thresh: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + default: 10 + description: Specifies the threshold for the event. + + linux,code: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Numeric key or switch code associated with the event. + + additionalProperties: false + + "^event-touch(-alt)?$": + type: object + description: Represents a touch event reported by the channel. + + properties: + azoteq,thresh: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + default: 8 + description: Specifies the threshold for the event. + + azoteq,hyst: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + default: 4 + description: Specifies the hysteresis for the event. + + linux,code: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Numeric key or switch code associated with the event. + + additionalProperties: false + + "^event-deep(-alt)?$": + type: object + description: Represents a deep-touch event reported by the channel. + + properties: + azoteq,thresh: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + default: 26 + description: Specifies the threshold for the event. + + azoteq,hyst: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + default: 0 + description: Specifies the hysteresis for the event. + + linux,code: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Numeric key or switch code associated with the event. + + additionalProperties: false + + required: + - reg + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/input/input.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + iqs269a@44 { + #address-cells = <1>; + #size-cells = <0>; + + compatible = "azoteq,iqs269a"; + reg = <0x44>; + interrupt-parent = <&gpio>; + interrupts = <17 IRQ_TYPE_LEVEL_LOW>; + + azoteq,hall-enable; + azoteq,suspend-mode = <2>; + + channel@0 { + reg = <0x0>; + + event-prox { + linux,code = <KEY_POWER>; + }; + }; + + channel@1 { + reg = <0x1>; + azoteq,slider0-select; + }; + + channel@2 { + reg = <0x2>; + azoteq,slider0-select; + }; + + channel@3 { + reg = <0x3>; + azoteq,slider0-select; + }; + + channel@4 { + reg = <0x4>; + azoteq,slider0-select; + }; + + channel@5 { + reg = <0x5>; + azoteq,slider0-select; + }; + + channel@6 { + reg = <0x6>; + azoteq,invert-enable; + azoteq,static-enable; + azoteq,reseed-disable; + azoteq,rx-enable = <0>; + azoteq,sense-freq = <0x0>; + azoteq,sense-mode = <0xE>; + azoteq,ati-mode = <0x0>; + azoteq,ati-base = <200>; + azoteq,ati-target = <320>; + }; + + channel@7 { + reg = <0x7>; + azoteq,invert-enable; + azoteq,static-enable; + azoteq,reseed-disable; + azoteq,rx-enable = <0>, <6>; + azoteq,sense-freq = <0x0>; + azoteq,sense-mode = <0xE>; + azoteq,ati-mode = <0x3>; + azoteq,ati-base = <200>; + azoteq,ati-target = <320>; + + event-touch { + linux,code = <SW_LID>; + }; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/input/iqs62x-keys.yaml b/Documentation/devicetree/bindings/input/iqs62x-keys.yaml index 5625c22..77fe3b5 100644 --- a/Documentation/devicetree/bindings/input/iqs62x-keys.yaml +++ b/Documentation/devicetree/bindings/input/iqs62x-keys.yaml
@@ -30,10 +30,9 @@ - azoteq,iqs625-keys linux,keycodes: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 1 - maxItems: 16 + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 16 description: | Specifies the numeric keycodes associated with each available touch or proximity event according to the following table. An 'x' indicates the
diff --git a/Documentation/devicetree/bindings/input/msm-vibrator.txt b/Documentation/devicetree/bindings/input/msm-vibrator.txt deleted file mode 100644 index 8dcf014e..0000000 --- a/Documentation/devicetree/bindings/input/msm-vibrator.txt +++ /dev/null
@@ -1,36 +0,0 @@ -* Device tree bindings for the Qualcomm MSM vibrator - -Required properties: - - - compatible: Should be one of - "qcom,msm8226-vibrator" - "qcom,msm8974-vibrator" - - reg: the base address and length of the IO memory for the registers. - - pinctrl-names: set to default. - - pinctrl-0: phandles pointing to pin configuration nodes. See - Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt - - clock-names: set to pwm - - clocks: phandle of the clock. See - Documentation/devicetree/bindings/clock/clock-bindings.txt - - enable-gpios: GPIO that enables the vibrator. - -Optional properties: - - - vcc-supply: phandle to the regulator that provides power to the sensor. - -Example from a LG Nexus 5 (hammerhead) phone: - -vibrator@fd8c3450 { - reg = <0xfd8c3450 0x400>; - compatible = "qcom,msm8974-vibrator"; - - vcc-supply = <&pm8941_l19>; - - clocks = <&mmcc CAMSS_GP1_CLK>; - clock-names = "pwm"; - - enable-gpios = <&msmgpio 60 GPIO_ACTIVE_HIGH>; - - pinctrl-names = "default"; - pinctrl-0 = <&vibrator_pin>; -};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma140.yaml b/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma140.yaml new file mode 100644 index 0000000..8c73e52 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma140.yaml
@@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/cypress,cy8ctma140.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cypress CY8CTMA140 series touchscreen controller bindings + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: touchscreen.yaml# + +properties: + compatible: + const: cypress,cy8ctma140 + + reg: + const: 0x20 + + clock-frequency: + description: I2C client clock frequency, defined for host + minimum: 100000 + maximum: 400000 + + interrupts: + maxItems: 1 + + vcpin-supply: + description: Analog power supply regulator on VCPIN pin + + vdd-supply: + description: Digital power supply regulator on VDD pin + + touchscreen-inverted-x: true + touchscreen-inverted-y: true + touchscreen-size-x: true + touchscreen-size-y: true + touchscreen-swapped-x-y: true + touchscreen-max-pressure: true + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - touchscreen-size-x + - touchscreen-size-y + - touchscreen-max-pressure + +examples: +- | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + touchscreen@20 { + compatible = "cypress,cy8ctma140"; + reg = <0x20>; + touchscreen-size-x = <480>; + touchscreen-size-y = <800>; + touchscreen-max-pressure = <255>; + interrupt-parent = <&gpio6>; + interrupts = <26 IRQ_TYPE_EDGE_FALLING>; + vdd-supply = <&ab8500_ldo_aux2_reg>; + vcpin-supply = <&ab8500_ldo_aux2_reg>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml index 383d64a..024b262 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
@@ -42,7 +42,7 @@ - focaltech,ft6236 reg: - const: 0x38 + maxItems: 1 interrupts: maxItems: 1 @@ -61,33 +61,29 @@ gain: description: Allows setting the sensitivity in the range from 0 to 31. Note that lower values indicate higher sensitivity. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - - maximum: 31 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 offset: description: Allows setting the edge compensation in the range from 0 to 31. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - - maximum: 31 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 offset-x: description: Same as offset, but applies only to the horizontal position. Range from 0 to 80, only supported by evervision,ev-ft5726 devices. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - - maximum: 80 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 80 offset-y: description: Same as offset, but applies only to the vertical position. Range from 0 to 80, only supported by evervision,ev-ft5726 devices. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - - maximum: 80 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 80 touchscreen-size-x: true touchscreen-size-y: true
diff --git a/Documentation/devicetree/bindings/input/touchscreen/elan,elants_i2c.yaml b/Documentation/devicetree/bindings/input/touchscreen/elan,elants_i2c.yaml new file mode 100644 index 0000000..a792d63 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/elan,elants_i2c.yaml
@@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/input/touchscreen/elan,elants_i2c.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Elantech I2C Touchscreen + +maintainers: + - David Heidelberg <david@ixit.cz> + +allOf: + - $ref: touchscreen.yaml# + +properties: + compatible: + enum: + - elan,ektf3624 + - elan,ekth3500 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + wakeup-source: + type: boolean + description: touchscreen can be used as a wakeup source. + + reset-gpios: + description: reset gpio the chip is connected to. + + vcc33-supply: + description: a phandle for the regulator supplying 3.3V power. + + vccio-supply: + description: a phandle for the regulator supplying IO power. + + touchscreen-inverted-x: true + touchscreen-inverted-y: true + touchscreen-size-x: true + touchscreen-size-y: true + touchscreen-swapped-x-y: true + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touchscreen@10 { + compatible = "elan,ekth3500"; + reg = <0x10>; + + interrupt-parent = <&gpio4>; + interrupts = <0x0 IRQ_TYPE_EDGE_FALLING>; + wakeup-source; + }; + };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml index c8ea943..e81cfa56 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
@@ -63,7 +63,7 @@ - interrupts examples: -- | + - | i2c { #address-cells = <1>; #size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/input/touchscreen/mms114.txt b/Documentation/devicetree/bindings/input/touchscreen/mms114.txt index 2cd9540..707234c 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/mms114.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
@@ -1,9 +1,10 @@ -* MELFAS MMS114/MMS152 touchscreen controller +* MELFAS MMS114/MMS152/MMS345L touchscreen controller Required properties: - compatible: should be one of: - "melfas,mms114" - "melfas,mms152" + - "melfas,mms345l" - reg: I2C address of the chip - interrupts: interrupt to which the chip is connected - touchscreen-size-x: See [1]
diff --git a/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml b/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml new file mode 100644 index 0000000..ff09550 --- /dev/null +++ b/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml
@@ -0,0 +1,101 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interconnect/fsl,imx8m-noc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic i.MX bus frequency device + +maintainers: + - Leonard Crestez <leonard.crestez@nxp.com> + +description: | + The i.MX SoC family has multiple buses for which clock frequency (and + sometimes voltage) can be adjusted. + + Some of those buses expose register areas mentioned in the memory maps as GPV + ("Global Programmers View") but not all. Access to this area might be denied + for normal (non-secure) world. + + The buses are based on externally licensed IPs such as ARM NIC-301 and + Arteris FlexNOC but DT bindings are specific to the integration of these bus + interconnect IPs into imx SOCs. + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,imx8mn-nic + - fsl,imx8mm-nic + - fsl,imx8mq-nic + - const: fsl,imx8m-nic + - items: + - enum: + - fsl,imx8mn-noc + - fsl,imx8mm-noc + - fsl,imx8mq-noc + - const: fsl,imx8m-noc + - const: fsl,imx8m-nic + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + operating-points-v2: true + opp-table: true + + fsl,ddrc: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: + Phandle to DDR Controller. + + '#interconnect-cells': + description: + If specified then also act as an interconnect provider. Should only be + set once per soc on the main noc. + const: 1 + +required: + - compatible + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mm-clock.h> + #include <dt-bindings/interconnect/imx8mm.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + noc: interconnect@32700000 { + compatible = "fsl,imx8mm-noc", "fsl,imx8m-noc"; + reg = <0x32700000 0x100000>; + clocks = <&clk IMX8MM_CLK_NOC>; + #interconnect-cells = <1>; + fsl,ddrc = <&ddrc>; + + operating-points-v2 = <&noc_opp_table>; + noc_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-133M { + opp-hz = /bits/ 64 <133333333>; + }; + opp-800M { + opp-hz = /bits/ 64 <800000000>; + }; + }; + }; + + ddrc: memory-controller@3d400000 { + compatible = "fsl,imx8mm-ddrc", "fsl,imx8m-ddrc"; + reg = <0x3d400000 0x400000>; + clock-names = "core", "pll", "alt", "apb"; + clocks = <&clk IMX8MM_CLK_DRAM_CORE>, + <&clk IMX8MM_DRAM_PLL>, + <&clk IMX8MM_CLK_DRAM_ALT>, + <&clk IMX8MM_CLK_DRAM_APB>; + };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8916.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8916.yaml index 4107e60c..e1009ae 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,msm8916.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8916.yaml
@@ -10,8 +10,8 @@ - Georgi Djakov <georgi.djakov@linaro.org> description: | - The Qualcomm MSM8916 interconnect providers support adjusting the - bandwidth requirements between the various NoC fabrics. + The Qualcomm MSM8916 interconnect providers support adjusting the + bandwidth requirements between the various NoC fabrics. properties: compatible:
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml index 9af3c6e..8004c4b 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml
@@ -10,8 +10,8 @@ - Brian Masney <masneyb@onstation.org> description: | - The Qualcomm MSM8974 interconnect providers support setting system - bandwidth requirements between various network-on-chip fabrics. + The Qualcomm MSM8974 interconnect providers support setting system + bandwidth requirements between various network-on-chip fabrics. properties: reg:
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcs404.yaml b/Documentation/devicetree/bindings/interconnect/qcom,qcs404.yaml index 8d65c5f..3fbb878 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,qcs404.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,qcs404.yaml
@@ -10,8 +10,8 @@ - Georgi Djakov <georgi.djakov@linaro.org> description: | - The Qualcomm QCS404 interconnect providers support adjusting the - bandwidth requirements between the various NoC fabrics. + The Qualcomm QCS404 interconnect providers support adjusting the + bandwidth requirements between the various NoC fabrics. properties: reg:
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sc7180.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sc7180.yaml index 50f78f8..d01bac8 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,sc7180.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,sc7180.yaml
@@ -65,21 +65,21 @@ config_noc: interconnect@1500000 { compatible = "qcom,sc7180-config-noc"; - reg = <0 0x01500000 0 0x28000>; + reg = <0x01500000 0x28000>; #interconnect-cells = <1>; qcom,bcm-voters = <&apps_bcm_voter>; }; system_noc: interconnect@1620000 { compatible = "qcom,sc7180-system-noc"; - reg = <0 0x01620000 0 0x17080>; + reg = <0x01620000 0x17080>; #interconnect-cells = <1>; qcom,bcm-voters = <&apps_bcm_voter>; }; mmss_noc: interconnect@1740000 { compatible = "qcom,sc7180-mmss-noc"; - reg = <0 0x01740000 0 0x1c100>; + reg = <0x01740000 0x1c100>; #interconnect-cells = <1>; qcom,bcm-voters = <&apps_bcm_voter>; };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml index 8b087e0..74536747 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml
@@ -60,14 +60,14 @@ mem_noc: interconnect@1380000 { compatible = "qcom,sdm845-mem-noc"; - reg = <0 0x01380000 0 0x27200>; + reg = <0x01380000 0x27200>; #interconnect-cells = <1>; qcom,bcm-voters = <&apps_bcm_voter>; }; mmss_noc: interconnect@1740000 { compatible = "qcom,sdm845-mmss-noc"; - reg = <0 0x01740000 0 0x1c1000>; + reg = <0x01740000 0x1c1000>; #interconnect-cells = <1>; qcom,bcm-voter-names = "apps", "disp"; qcom,bcm-voters = <&apps_bcm_voter>, <&disp_bcm_voter>;
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml index cf09055..7cd6b8b 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
@@ -27,15 +27,15 @@ deprecated: true - const: allwinner,sun7i-a20-sc-nmi - items: - - const: allwinner,sun8i-a83t-r-intc - - const: allwinner,sun6i-a31-r-intc + - const: allwinner,sun8i-a83t-r-intc + - const: allwinner,sun6i-a31-r-intc - const: allwinner,sun9i-a80-sc-nmi - items: - - const: allwinner,sun50i-a64-r-intc - - const: allwinner,sun6i-a31-r-intc + - const: allwinner,sun50i-a64-r-intc + - const: allwinner,sun6i-a31-r-intc - items: - - const: allwinner,sun50i-h6-r-intc - - const: allwinner,sun6i-a31-r-intc + - const: allwinner,sun50i-h6-r-intc + - const: allwinner,sun6i-a31-r-intc reg: maxItems: 1
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml index 66aacd1..1ecd183 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
@@ -91,18 +91,16 @@ description: If using padding pages, specifies the stride of consecutive redistributors. Must be a multiple of 64kB. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint64 - - multipleOf: 0x10000 - exclusiveMinimum: 0 + $ref: /schemas/types.yaml#/definitions/uint64 + multipleOf: 0x10000 + exclusiveMinimum: 0 "#redistributor-regions": description: The number of independent contiguous regions occupied by the redistributors. Required if more than one such region is present. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - maximum: 4096 # Should be enough? + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 4096 msi-controller: description: @@ -114,22 +112,20 @@ A list of pairs <intid span>, where "intid" is the first SPI of a range that can be used an MBI, and "span" the size of that range. Multiple ranges can be provided. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-matrix - - items: - minItems: 2 - maxItems: 2 + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + minItems: 2 + maxItems: 2 mbi-alias: description: Address property. Base address of an alias of the GICD region containing only the {SET,CLR}SPI registers to be used if isolation is required, and if supported by the HW. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - items: - minItems: 1 - maxItems: 2 + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + minItems: 1 + maxItems: 2 ppi-partitions: type: object @@ -188,11 +184,10 @@ description: (u32, u32) tuple describing the untranslated address and size of the pre-ITS window. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - items: - minItems: 2 - maxItems: 2 + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + minItems: 2 + maxItems: 2 required: - compatible
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml index 9a47820..96f8803 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
@@ -40,6 +40,12 @@ - qcom,msm-qgic2 - items: + - const: arm,gic-400 + - enum: + - arm,cortex-a15-gic + - arm,cortex-a7-gic + + - items: - const: arm,arm1176jzf-devchip-gic - const: arm,arm11mp-gic @@ -125,6 +131,9 @@ power-domains: maxItems: 1 + resets: + maxItems: 1 + required: - compatible - reg
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt deleted file mode 100644 index 582991c..0000000 --- a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt +++ /dev/null
@@ -1,35 +0,0 @@ -Freescale IRQSTEER Interrupt multiplexer - -Required properties: - -- compatible: should be: - - "fsl,imx8m-irqsteer" - - "fsl,imx-irqsteer" -- reg: Physical base address and size of registers. -- interrupts: Should contain the up to 8 parent interrupt lines used to - multiplex the input interrupts. They should be specified sequentially - from output 0 to 7. -- clocks: Should contain one clock for entry in clock-names - see Documentation/devicetree/bindings/clock/clock-bindings.txt -- clock-names: - - "ipg": main logic clock -- interrupt-controller: Identifies the node as an interrupt controller. -- #interrupt-cells: Specifies the number of cells needed to encode an - interrupt source. The value must be 1. -- fsl,channel: The output channel that all input IRQs should be steered into. -- fsl,num-irqs: Number of input interrupts of this channel. - Should be multiple of 32 input interrupts and up to 512 interrupts. - -Example: - - interrupt-controller@32e2d000 { - compatible = "fsl,imx8m-irqsteer", "fsl,imx-irqsteer"; - reg = <0x32e2d000 0x1000>; - interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clk IMX8MQ_CLK_DISP_APB_ROOT>; - clock-names = "ipg"; - fsl,channel = <0>; - fsl,num-irqs = <64>; - interrupt-controller; - #interrupt-cells = <1>; - };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml new file mode 100644 index 0000000..360a575 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
@@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/fsl,irqsteer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale IRQSTEER Interrupt Multiplexer + +maintainers: + - Lucas Stach <l.stach@pengutronix.de> + +properties: + compatible: + enum: + - fsl,imx8m-irqsteer + - fsl,imx-irqsteer + + reg: + maxItems: 1 + + interrupts: + description: | + should contain the up to 8 parent interrupt lines used to multiplex + the input interrupts. They should be specified sequentially from + output 0 to 7. + items: + - description: output interrupt 0 + - description: output interrupt 1 + - description: output interrupt 2 + - description: output interrupt 3 + - description: output interrupt 4 + - description: output interrupt 5 + - description: output interrupt 6 + - description: output interrupt 7 + minItems: 1 + maxItems: 8 + + clocks: + maxItems: 1 + + clock-names: + const: ipg + + interrupt-controller: true + + "#interrupt-cells": + const: 1 + + fsl,channel: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: | + u32 value representing the output channel that all input IRQs should be + steered into. + + fsl,num-irqs: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: | + u32 value representing the number of input interrupts of this channel, + should be multiple of 32 input interrupts and up to 512 interrupts. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - interrupt-controller + - "#interrupt-cells" + - fsl,channel + - fsl,num-irqs + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mq-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + interrupt-controller@32e2d000 { + compatible = "fsl,imx-irqsteer"; + reg = <0x32e2d000 0x1000>; + interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_DISP_APB_ROOT>; + clock-names = "ipg"; + fsl,channel = <0>; + fsl,num-irqs = <64>; + interrupt-controller; + #interrupt-cells = <1>; + };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.txt b/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.txt deleted file mode 100644 index d4373d0..0000000 --- a/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.txt +++ /dev/null
@@ -1,28 +0,0 @@ -Ingenic SoC Interrupt Controller - -Required properties: - -- compatible : should be "ingenic,<socname>-intc". Valid strings are: - ingenic,jz4740-intc - ingenic,jz4725b-intc - ingenic,jz4770-intc - ingenic,jz4775-intc - ingenic,jz4780-intc -- reg : Specifies base physical address and size of the registers. -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. The value shall be 1. -- interrupts : Specifies the CPU interrupt the controller is connected to. - -Example: - -intc: interrupt-controller@10001000 { - compatible = "ingenic,jz4740-intc"; - reg = <0x10001000 0x14>; - - interrupt-controller; - #interrupt-cells = <1>; - - interrupt-parent = <&cpuintc>; - interrupts = <2>; -};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml new file mode 100644 index 0000000..28b27e1 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml
@@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/ingenic,intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs interrupt controller devicetree bindings + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +properties: + $nodename: + pattern: "^interrupt-controller@[0-9a-f]+$" + + compatible: + oneOf: + - enum: + - ingenic,jz4740-intc + - ingenic,jz4760-intc + - ingenic,jz4780-intc + - items: + - enum: + - ingenic,jz4775-intc + - ingenic,jz4770-intc + - const: ingenic,jz4760-intc + - items: + - const: ingenic,x1000-intc + - const: ingenic,jz4780-intc + - items: + - const: ingenic,jz4725b-intc + - const: ingenic,jz4740-intc + + "#interrupt-cells": + const: 1 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + +required: + - compatible + - reg + - interrupts + - "#interrupt-cells" + - interrupt-controller + +examples: + - | + intc: interrupt-controller@10001000 { + compatible = "ingenic,jz4770-intc", "ingenic,jz4760-intc"; + reg = <0x10001000 0x40>; + + interrupt-controller; + #interrupt-cells = <1>; + + interrupt-parent = <&cpuintc>; + interrupts = <2>; + };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml b/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml index ccc507f..14dced1 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml
@@ -25,10 +25,10 @@ compatible: items: - enum: - - intel,ixp42x-interrupt - - intel,ixp43x-interrupt - - intel,ixp45x-interrupt - - intel,ixp46x-interrupt + - intel,ixp42x-interrupt + - intel,ixp43x-interrupt + - intel,ixp45x-interrupt + - intel,ixp46x-interrupt reg: maxItems: 1
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml new file mode 100644 index 0000000..e865cd8 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml
@@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/interrupt-controller/loongson,htvec.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Loongson-3 HyperTransport Interrupt Vector Controller + +maintainers: + - Jiaxun Yang <jiaxun.yang@flygoat.com> + +description: + This interrupt controller is found in the Loongson-3 family of chips for + receiving vectorized interrupts from PCH's interrupt controller. + +properties: + compatible: + const: loongson,htvec-1.0 + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 4 + description: Four parent interrupts that receive chained interrupts. + + interrupt-controller: true + + '#interrupt-cells': + const: 1 + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - '#interrupt-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + htvec: interrupt-controller@fb000080 { + compatible = "loongson,htvec-1.0"; + reg = <0xfb000080 0x40>; + interrupt-controller; + #interrupt-cells = <1>; + + interrupt-parent = <&liointc>; + interrupts = <24 IRQ_TYPE_LEVEL_HIGH>, + <25 IRQ_TYPE_LEVEL_HIGH>, + <26 IRQ_TYPE_LEVEL_HIGH>, + <27 IRQ_TYPE_LEVEL_HIGH>; + }; +...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml index 26f1fcf..b1db21e 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml
@@ -54,11 +54,9 @@ and each bit in the cell refers to a children interrupt fron 0 to 31. If a CPU interrupt line didn't connected with liointc, then keep it's cell with zero. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 4 - maxItems: 4 - + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 4 + maxItems: 4 required: - compatible
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml new file mode 100644 index 0000000..1b256d9 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml
@@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/interrupt-controller/loongson,pch-msi.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Loongson PCH MSI Controller + +maintainers: + - Jiaxun Yang <jiaxun.yang@flygoat.com> + +description: + This interrupt controller is found in the Loongson LS7A family of PCH for + transforming interrupts from PCIe MSI into HyperTransport vectorized + interrupts. + +properties: + compatible: + const: loongson,pch-msi-1.0 + + reg: + maxItems: 1 + + loongson,msi-base-vec: + description: + u32 value of the base of parent HyperTransport vector allocated + to PCH MSI. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 255 + + loongson,msi-num-vecs: + description: + u32 value of the number of parent HyperTransport vectors allocated + to PCH MSI. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 1 + maximum: 256 + + msi-controller: true + +required: + - compatible + - reg + - msi-controller + - loongson,msi-base-vec + - loongson,msi-num-vecs + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + msi: msi-controller@2ff00000 { + compatible = "loongson,pch-msi-1.0"; + reg = <0x2ff00000 0x4>; + msi-controller; + loongson,msi-base-vec = <64>; + loongson,msi-num-vecs = <64>; + interrupt-parent = <&htvec>; + }; +...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml new file mode 100644 index 0000000..a6dcbb2 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml
@@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/interrupt-controller/loongson,pch-pic.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Loongson PCH PIC Controller + +maintainers: + - Jiaxun Yang <jiaxun.yang@flygoat.com> + +description: + This interrupt controller is found in the Loongson LS7A family of PCH for + transforming interrupts from on-chip devices into HyperTransport vectorized + interrupts. + +properties: + compatible: + const: loongson,pch-pic-1.0 + + reg: + maxItems: 1 + + loongson,pic-base-vec: + description: + u32 value of the base of parent HyperTransport vector allocated + to PCH PIC. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 192 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + +required: + - compatible + - reg + - loongson,pic-base-vec + - interrupt-controller + - '#interrupt-cells' + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + pic: interrupt-controller@10000000 { + compatible = "loongson,pch-pic-1.0"; + reg = <0x10000000 0x400>; + interrupt-controller; + #interrupt-cells = <2>; + loongson,pic-base-vec = <64>; + interrupt-parent = <&htvec>; + }; +...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt deleted file mode 100644 index 772c550..0000000 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt +++ /dev/null
@@ -1,62 +0,0 @@ -DT bindings for the R-/SH-Mobile irqpin controller - -Required properties: - -- compatible: has to be "renesas,intc-irqpin-<soctype>", "renesas,intc-irqpin" - as fallback. - Examples with soctypes are: - - "renesas,intc-irqpin-r8a7740" (R-Mobile A1) - - "renesas,intc-irqpin-r8a7778" (R-Car M1A) - - "renesas,intc-irqpin-r8a7779" (R-Car H1) - - "renesas,intc-irqpin-sh73a0" (SH-Mobile AG5) - -- reg: Base address and length of each register bank used by the external - IRQ pins driven by the interrupt controller hardware module. The base - addresses, length and number of required register banks varies with soctype. -- interrupt-controller: Identifies the node as an interrupt controller. -- #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in - interrupts.txt in this directory. -- interrupts: Must contain a list of interrupt specifiers. For each interrupt - provided by this irqpin controller instance, there must be one entry, - referring to the corresponding parent interrupt. - -Optional properties: - -- any properties, listed in interrupts.txt, and any standard resource allocation - properties -- sense-bitfield-width: width of a single sense bitfield in the SENSE register, - if different from the default 4 bits -- control-parent: disable and enable interrupts on the parent interrupt - controller, needed for some broken implementations -- clocks: Must contain a reference to the functional clock. This property is - mandatory if the hardware implements a controllable functional clock for - the irqpin controller instance. -- power-domains: Must contain a reference to the power domain. This property is - mandatory if the irqpin controller instance is part of a controllable power - domain. - - -Example -------- - - irqpin1: interrupt-controller@e6900004 { - compatible = "renesas,intc-irqpin-r8a7740", - "renesas,intc-irqpin"; - #interrupt-cells = <2>; - interrupt-controller; - reg = <0xe6900004 4>, - <0xe6900014 4>, - <0xe6900024 1>, - <0xe6900044 1>, - <0xe6900064 1>; - interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH - 0 149 IRQ_TYPE_LEVEL_HIGH - 0 149 IRQ_TYPE_LEVEL_HIGH - 0 149 IRQ_TYPE_LEVEL_HIGH - 0 149 IRQ_TYPE_LEVEL_HIGH - 0 149 IRQ_TYPE_LEVEL_HIGH - 0 149 IRQ_TYPE_LEVEL_HIGH - 0 149 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp2_clks R8A7740_CLK_INTCA>; - power-domains = <&pd_a4s>; - };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.yaml new file mode 100644 index 0000000..f4aae56 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.yaml
@@ -0,0 +1,107 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/renesas,intc-irqpin.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas Interrupt Controller (INTC) for external pins + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + +properties: + compatible: + items: + - enum: + - renesas,intc-irqpin-r8a7740 # R-Mobile A1 + - renesas,intc-irqpin-r8a7778 # R-Car M1A + - renesas,intc-irqpin-r8a7779 # R-Car H1 + - renesas,intc-irqpin-sh73a0 # SH-Mobile AG5 + - const: renesas,intc-irqpin + + reg: + minItems: 5 + items: + - description: Interrupt control register + - description: Interrupt priority register + - description: Interrupt source register + - description: Interrupt mask register + - description: Interrupt mask clear register + - description: Interrupt control register for ICR0 with IRLM0 bit + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + interrupts: + minItems: 1 + maxItems: 8 + + sense-bitfield-width: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [2, 4] + default: 4 + description: + Width of a single sense bitfield in the SENSE register, if different from the + default. + + control-parent: + type: boolean + description: + Disable and enable interrupts on the parent interrupt controller, needed for some + broken implementations. + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupt-controller + - '#interrupt-cells' + - interrupts + +if: + properties: + compatible: + contains: + enum: + - renesas,intc-irqpin-r8a7740 + - renesas,intc-irqpin-sh73a0 +then: + required: + - clocks + - power-domains + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7740-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + irqpin1: interrupt-controller@e6900004 { + compatible = "renesas,intc-irqpin-r8a7740", "renesas,intc-irqpin"; + reg = <0xe6900004 4>, + <0xe6900014 4>, + <0xe6900024 1>, + <0xe6900044 1>, + <0xe6900064 1>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp2_clks R8A7740_CLK_INTCA>; + power-domains = <&pd_a4s>; + };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml index ee5273b..b67b8cb 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml
@@ -14,6 +14,7 @@ items: - enum: - renesas,irqc-r8a73a4 # R-Mobile APE6 + - renesas,irqc-r8a7742 # RZ/G1H - renesas,irqc-r8a7743 # RZ/G1M - renesas,irqc-r8a7744 # RZ/G1N - renesas,irqc-r8a7745 # RZ/G1E @@ -78,7 +79,7 @@ compatible = "renesas,irqc-r8a7790", "renesas,irqc"; #interrupt-cells = <2>; interrupt-controller; - reg = <0 0xe61c0000 0 0x200>; + reg = <0xe61c0000 0x200>; interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml index 9e5c660..2a5b295 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml
@@ -14,13 +14,13 @@ compatible: oneOf: - items: - - enum: - - st,stm32-exti - - st,stm32h7-exti + - enum: + - st,stm32-exti + - st,stm32h7-exti - items: - - enum: - - st,stm32mp1-exti - - const: syscon + - enum: + - st,stm32mp1-exti + - const: syscon "#interrupt-cells": const: 2
diff --git a/Documentation/devicetree/bindings/iommu/allwinner,sun50i-h6-iommu.yaml b/Documentation/devicetree/bindings/iommu/allwinner,sun50i-h6-iommu.yaml new file mode 100644 index 0000000..5e125cf --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/allwinner,sun50i-h6-iommu.yaml
@@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iommu/allwinner,sun50i-h6-iommu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner H6 IOMMU Device Tree Bindings + +maintainers: + - Chen-Yu Tsai <wens@csie.org> + - Maxime Ripard <mripard@kernel.org> + +properties: + "#iommu-cells": + const: 1 + description: + The content of the cell is the master ID. + + compatible: + const: allwinner,sun50i-h6-iommu + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - "#iommu-cells" + - compatible + - reg + - interrupts + - clocks + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + #include <dt-bindings/clock/sun50i-h6-ccu.h> + #include <dt-bindings/reset/sun50i-h6-ccu.h> + + iommu: iommu@30f0000 { + compatible = "allwinner,sun50i-h6-iommu"; + reg = <0x030f0000 0x10000>; + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&ccu CLK_BUS_IOMMU>; + resets = <&ccu RST_BUS_IOMMU>; + #iommu-cells = <1>; + }; + +...
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 6515dbe..d7ceb4c 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -28,6 +28,7 @@ - enum: - qcom,msm8996-smmu-v2 - qcom,msm8998-smmu-v2 + - qcom,sc7180-smmu-v2 - qcom,sdm845-smmu-v2 - const: qcom,smmu-v2 @@ -41,7 +42,9 @@ - const: arm,mmu-500 - const: arm,smmu-v2 - items: - - const: arm,mmu-401 + - enum: + - arm,mmu-400 + - arm,mmu-401 - const: arm,smmu-v1 - enum: - arm,smmu-v1 @@ -56,8 +59,7 @@ '#global-interrupts': description: The number of global interrupts exposed by the device. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 260 # 2 secure, 2 non-secure, and up to 256 perf counters
diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt deleted file mode 100644 index 020d6f2..0000000 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt +++ /dev/null
@@ -1,73 +0,0 @@ -* Renesas VMSA-Compatible IOMMU - -The IPMMU is an IOMMU implementation compatible with the ARM VMSA page tables. -It provides address translation for bus masters outside of the CPU, each -connected to the IPMMU through a port called micro-TLB. - - -Required Properties: - - - compatible: Must contain SoC-specific and generic entry below in case - the device is compatible with the R-Car Gen2 VMSA-compatible IPMMU. - - - "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU. - - "renesas,ipmmu-r8a7743" for the R8A7743 (RZ/G1M) IPMMU. - - "renesas,ipmmu-r8a7744" for the R8A7744 (RZ/G1N) IPMMU. - - "renesas,ipmmu-r8a7745" for the R8A7745 (RZ/G1E) IPMMU. - - "renesas,ipmmu-r8a774a1" for the R8A774A1 (RZ/G2M) IPMMU. - - "renesas,ipmmu-r8a774b1" for the R8A774B1 (RZ/G2N) IPMMU. - - "renesas,ipmmu-r8a774c0" for the R8A774C0 (RZ/G2E) IPMMU. - - "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU. - - "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU. - - "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU. - - "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU. - - "renesas,ipmmu-r8a7795" for the R8A7795 (R-Car H3) IPMMU. - - "renesas,ipmmu-r8a7796" for the R8A7796 (R-Car M3-W) IPMMU. - - "renesas,ipmmu-r8a77965" for the R8A77965 (R-Car M3-N) IPMMU. - - "renesas,ipmmu-r8a77970" for the R8A77970 (R-Car V3M) IPMMU. - - "renesas,ipmmu-r8a77980" for the R8A77980 (R-Car V3H) IPMMU. - - "renesas,ipmmu-r8a77990" for the R8A77990 (R-Car E3) IPMMU. - - "renesas,ipmmu-r8a77995" for the R8A77995 (R-Car D3) IPMMU. - - "renesas,ipmmu-vmsa" for generic R-Car Gen2 or RZ/G1 VMSA-compatible - IPMMU. - - - reg: Base address and size of the IPMMU registers. - - interrupts: Specifiers for the MMU fault interrupts. For instances that - support secure mode two interrupts must be specified, for non-secure and - secure mode, in that order. For instances that don't support secure mode a - single interrupt must be specified. Not required for cache IPMMUs. - - - #iommu-cells: Must be 1. - -Optional properties: - - - renesas,ipmmu-main: reference to the main IPMMU instance in two cells. - The first cell is a phandle to the main IPMMU and the second cell is - the interrupt bit number associated with the particular cache IPMMU device. - The interrupt bit number needs to match the main IPMMU IMSSTR register. - Only used by cache IPMMU instances. - - -Each bus master connected to an IPMMU must reference the IPMMU in its device -node with the following property: - - - iommus: A reference to the IPMMU in two cells. The first cell is a phandle - to the IPMMU and the second cell the number of the micro-TLB that the - device is connected to. - - -Example: R8A7791 IPMMU-MX and VSP1-D0 bus master - - ipmmu_mx: mmu@fe951000 { - compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa"; - reg = <0 0xfe951000 0 0x1000>; - interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>, - <0 221 IRQ_TYPE_LEVEL_HIGH>; - #iommu-cells = <1>; - }; - - vsp@fe928000 { - ... - iommus = <&ipmmu_mx 13>; - ... - };
diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml new file mode 100644 index 0000000..39675cf --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iommu/renesas,ipmmu-vmsa.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas VMSA-Compatible IOMMU + +maintainers: + - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> + +description: + The IPMMU is an IOMMU implementation compatible with the ARM VMSA page tables. + It provides address translation for bus masters outside of the CPU, each + connected to the IPMMU through a port called micro-TLB. + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,ipmmu-r8a73a4 # R-Mobile APE6 + - renesas,ipmmu-r8a7743 # RZ/G1M + - renesas,ipmmu-r8a7744 # RZ/G1N + - renesas,ipmmu-r8a7745 # RZ/G1E + - renesas,ipmmu-r8a7790 # R-Car H2 + - renesas,ipmmu-r8a7791 # R-Car M2-W + - renesas,ipmmu-r8a7793 # R-Car M2-N + - renesas,ipmmu-r8a7794 # R-Car E2 + - const: renesas,ipmmu-vmsa # R-Mobile APE6 or R-Car Gen2 or RZ/G1 + - items: + - enum: + - renesas,ipmmu-r8a774a1 # RZ/G2M + - renesas,ipmmu-r8a774b1 # RZ/G2N + - renesas,ipmmu-r8a774c0 # RZ/G2E + - renesas,ipmmu-r8a7795 # R-Car H3 + - renesas,ipmmu-r8a7796 # R-Car M3-W + - renesas,ipmmu-r8a77965 # R-Car M3-N + - renesas,ipmmu-r8a77970 # R-Car V3M + - renesas,ipmmu-r8a77980 # R-Car V3H + - renesas,ipmmu-r8a77990 # R-Car E3 + - renesas,ipmmu-r8a77995 # R-Car D3 + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + description: + Specifiers for the MMU fault interrupts. Not required for cache IPMMUs. + items: + - description: non-secure mode + - description: secure mode if supported + + '#iommu-cells': + const: 1 + description: + The number of the micro-TLB that the device is connected to. + + power-domains: + maxItems: 1 + + renesas,ipmmu-main: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Reference to the main IPMMU phandle plus 1 cell. The cell is + the interrupt bit number associated with the particular cache IPMMU + device. The interrupt bit number needs to match the main IPMMU IMSSTR + register. Only used by cache IPMMU instances. + +required: + - compatible + - reg + - '#iommu-cells' + - power-domains + +oneOf: + - required: + - interrupts + - required: + - renesas,ipmmu-main + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7791-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7791-sysc.h> + + ipmmu_mx: iommu@fe951000 { + compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa"; + reg = <0xfe951000 0x1000>; + interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>; + #iommu-cells = <1>; + };
diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml index 0e33cd9..af51b91 100644 --- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml +++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml
@@ -54,13 +54,13 @@ clock-names: oneOf: - items: - - const: sysmmu + - const: sysmmu - items: - - const: sysmmu - - const: master + - const: sysmmu + - const: master - items: - - const: aclk - - const: pclk + - const: aclk + - const: pclk "#iommu-cells": const: 0
diff --git a/Documentation/devicetree/bindings/ipmi/ipmi-smic.txt b/Documentation/devicetree/bindings/ipmi/ipmi-smic.txt deleted file mode 100644 index d5f1a87..0000000 --- a/Documentation/devicetree/bindings/ipmi/ipmi-smic.txt +++ /dev/null
@@ -1,25 +0,0 @@ -IPMI device - -Required properties: -- compatible: should be one of ipmi-kcs, ipmi-smic, or ipmi-bt -- device_type: should be ipmi -- reg: Address and length of the register set for the device - -Optional properties: -- interrupts: The interrupt for the device. Without this the interface - is polled. -- reg-size - The size of the register. Defaults to 1 -- reg-spacing - The number of bytes between register starts. Defaults to 1 -- reg-shift - The amount to shift the registers to the right to get the data - into bit zero. - -Example: - -smic@fff3a000 { - compatible = "ipmi-smic"; - device_type = "ipmi"; - reg = <0xfff3a000 0x1000>; - interrupts = <0 24 4>; - reg-size = <4>; - reg-spacing = <4>; -};
diff --git a/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml b/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml new file mode 100644 index 0000000..58fa76e --- /dev/null +++ b/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml
@@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ipmi/ipmi-smic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: IPMI device bindings + +description: IPMI device bindings + +maintainers: + - Corey Minyard <cminyard@mvista.com> + +properties: + compatible: + enum: + - ipmi-kcs + - ipmi-smic + - ipmi-bt + + device_type: + items: + - const: "ipmi" + + reg: + maxItems: 1 + + interrupts: + description: Interface is polled if this property is omitted. + maxItems: 1 + + reg-size: + description: The access width of the register in bytes. Defaults to 1. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8] + + reg-spacing: + $ref: /schemas/types.yaml#/definitions/uint32 + description: The number of bytes between register starts. Defaults to 1. + + reg-shift: + description: | + The amount of bits to shift the register content to the right to get + the data into bit zero. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 56 + +required: + - compatible + - reg + +examples: + - | + smic@fff3a000 { + compatible = "ipmi-smic"; + device_type = "ipmi"; + reg = <0xfff3a000 0x1000>; + interrupts = <0 24 4>; + reg-size = <4>; + reg-spacing = <4>; + };
diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt deleted file mode 100644 index c06863b..0000000 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt +++ /dev/null
@@ -1,154 +0,0 @@ -Binding for Qualcomm Technologies, Inc. WLED driver - -WLED (White Light Emitting Diode) driver is used for controlling display -backlight that is part of PMIC on Qualcomm Technologies, Inc. reference -platforms. The PMIC is connected to the host processor via SPMI bus. - -- compatible - Usage: required - Value type: <string> - Definition: should be one of: - "qcom,pm8941-wled" - "qcom,pmi8998-wled" - "qcom,pm660l-wled" - -- reg - Usage: required - Value type: <prop encoded array> - Definition: Base address of the WLED modules. - -- default-brightness - Usage: optional - Value type: <u32> - Definition: brightness value on boot, value from: 0-4095. - Default: 2048 - -- label - Usage: required - Value type: <string> - Definition: The name of the backlight device - -- qcom,cs-out - Usage: optional - Value type: <bool> - Definition: enable current sink output. - This property is supported only for PM8941. - -- qcom,cabc - Usage: optional - Value type: <bool> - Definition: enable content adaptive backlight control. - -- qcom,ext-gen - Usage: optional - Value type: <bool> - Definition: use externally generated modulator signal to dim. - This property is supported only for PM8941. - -- qcom,current-limit - Usage: optional - Value type: <u32> - Definition: mA; per-string current limit; value from 0 to 25 with - 1 mA step. Default 20 mA. - This property is supported only for pm8941. - -- qcom,current-limit-microamp - Usage: optional - Value type: <u32> - Definition: uA; per-string current limit; value from 0 to 30000 with - 2500 uA step. Default 25 mA. - -- qcom,current-boost-limit - Usage: optional - Value type: <u32> - Definition: mA; boost current limit. - For pm8941: one of: 105, 385, 525, 805, 980, 1260, 1400, - 1680. Default: 805 mA. - For pmi8998: one of: 105, 280, 450, 620, 970, 1150, 1300, - 1500. Default: 970 mA. - -- qcom,switching-freq - Usage: optional - Value type: <u32> - Definition: kHz; switching frequency; one of: 600, 640, 685, 738, - 800, 872, 960, 1066, 1200, 1371, 1600, 1920, 2400, 3200, - 4800, 9600. - Default: for pm8941: 1600 kHz - for pmi8998: 800 kHz - -- qcom,ovp - Usage: optional - Value type: <u32> - Definition: V; Over-voltage protection limit; one of: - 27, 29, 32, 35. Default: 29V - This property is supported only for PM8941. - -- qcom,ovp-millivolt - Usage: optional - Value type: <u32> - Definition: mV; Over-voltage protection limit; - For pmi8998: one of 18100, 19600, 29600, 31100. - Default 29600 mV. - If this property is not specified for PM8941, it - falls back to "qcom,ovp" property. - -- qcom,num-strings - Usage: optional - Value type: <u32> - Definition: #; number of led strings attached; - value: For PM8941 from 1 to 3. Default: 2 - For PMI8998 from 1 to 4. - -- interrupts - Usage: optional - Value type: <prop encoded array> - Definition: Interrupts associated with WLED. This should be - "short" and "ovp" interrupts. Interrupts can be - specified as per the encoding listed under - Documentation/devicetree/bindings/spmi/ - qcom,spmi-pmic-arb.txt. - -- interrupt-names - Usage: optional - Value type: <string> - Definition: Interrupt names associated with the interrupts. - Must be "short" and "ovp". The short circuit detection - is not supported for PM8941. - -- qcom,enabled-strings - Usage: optional - Value tyoe: <u32 array> - Definition: Array of the WLED strings numbered from 0 to 3. Each - string of leds are operated individually. Specify the - list of strings used by the device. Any combination of - led strings can be used. - -- qcom,external-pfet - Usage: optional - Value type: <bool> - Definition: Specify if external PFET control for short circuit - protection is used. This property is supported only - for PMI8998. - -- qcom,auto-string-detection - Usage: optional - Value type: <bool> - Definition: Enables auto-detection of the WLED string configuration. - This feature is not supported for PM8941. - - -Example: - -pm8941-wled@d800 { - compatible = "qcom,pm8941-wled"; - reg = <0xd800>; - label = "backlight"; - - qcom,cs-out; - qcom,current-limit = <20>; - qcom,current-boost-limit = <805>; - qcom,switching-freq = <1600>; - qcom,ovp = <29>; - qcom,num-strings = <2>; - qcom,enabled-strings = <0 1>; -};
diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml new file mode 100644 index 0000000..32e0896c --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
@@ -0,0 +1,252 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/qcom-wled.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for Qualcomm Technologies, Inc. WLED driver + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + - Kiran Gunda <kgunda@codeaurora.org> + +description: | + WLED (White Light Emitting Diode) driver is used for controlling display + backlight that is part of PMIC on Qualcomm Technologies, Inc. reference + platforms. The PMIC is connected to the host processor via SPMI bus. + +properties: + compatible: + enum: + - qcom,pm8941-wled + - qcom,pmi8998-wled + - qcom,pm660l-wled + - qcom,pm8150l-wled + + reg: + maxItems: 1 + + default-brightness: + description: | + brightness value on boot. + + label: true + + max-brightness: + description: | + Maximum brightness level. + + qcom,cs-out: + description: | + enable current sink output. + This property is supported only for WLED3. + type: boolean + + qcom,cabc: + description: | + enable content adaptive backlight control. + type: boolean + + qcom,ext-gen: + description: | + use externally generated modulator signal to dim. + This property is supported only for WLED3. + type: boolean + + qcom,current-limit: + description: | + mA; per-string current limit. + This property is supported only for WLED3. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 20 + minimum: 0 + maximum: 25 + + qcom,current-limit-microamp: + description: | + uA; per-string current limit. + default: 25 + minimum: 0 + maximum: 30000 + multipleOf: 25 + + qcom,current-boost-limit: + description: | + mA; boost current limit. + $ref: /schemas/types.yaml#/definitions/uint32 + + qcom,switching-freq: + description: | + kHz; switching frequency. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371, 1600, 1920, 2400, 3200, 4800, 9600 ] + + qcom,ovp: + description: | + V; Over-voltage protection limit. + This property is supported only for WLED3. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 27, 29, 32, 35 ] + default: 29 + + qcom,ovp-millivolt: + description: | + Over-voltage protection limit. This property is for WLED4 only. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 18100, 19600, 29600, 31100 ] + default: 29600 + + qcom,num-strings: + description: | + number of led strings attached. + $ref: /schemas/types.yaml#/definitions/uint32 + + qcom,enabled-strings: + description: | + Array of the WLED strings numbered from 0 to 3. Each + string of leds are operated individually. Specify the + list of strings used by the device. Any combination of + led strings can be used. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 4 + + qcom,external-pfet: + description: | + Specify if external PFET control for short circuit + protection is used. This property is supported only + for WLED4. + type: boolean + + qcom,auto-string-detection: + description: | + Enables auto-detection of the WLED string configuration. + This feature is not supported for WLED3. + type: boolean + + interrupts: + minItems: 1 + items: + - description: over voltage protection interrupt. + - description: short circuit interrupt. + + interrupt-names: + minItems: 1 + items: + - const: ovp + - const: short + + qcom,modulator-sel: + description: | + Selects the modulator used for brightness modulation. + Allowed values are, + 0 - Modulator A + 1 - Modulator B + This property is applicable only to WLED5 peripheral. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1 ] + default: 0 + + qcom,cabc-sel: + description: | + Selects the CABC pin signal used for brightness modulation. + Allowed values are, + 0 - CABC disabled + 1 - CABC 1 + 2 - CABC 2 + 3 - External signal (e.g. LPG) is used for dimming + This property is applicable only to WLED5 peripheral. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2, 3 ] + +allOf: + - if: + properties: + compatible: + contains: + const: qcom,pm8941-wled + + then: + properties: + qcom,current-boost-limit: + enum: [ 105, 385, 525, 805, 980, 1260, 1400, 1680 ] + default: 805 + + qcom,switching-freq: + default: 1600 + + qcom,num-strings: + enum: [ 1, 2, 3 ] + + interrupts: + maxItems: 1 + + interrupt-names: + maxItems: 1 + + else: + properties: + qcom,current-boost-limit: + enum: [ 105, 280, 450, 620, 970, 1150, 1300, 1500 ] + default: 970 + + qcom,switching-freq: + default: 800 + + qcom,num-strings: + enum: [ 1, 2, 3, 4 ] + + interrupts: + minItems: 2 + + interrupt-names: + minItems: 2 + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8150l-wled + + then: + properties: + default-brightness: + minimum: 0 + maximum: 32767 + + max-brightness: + minimum: 0 + maximum: 32767 + + else: + properties: + default-brightness: + minimum: 0 + maximum: 4095 + + max-brightness: + minimum: 0 + maximum: 4095 + +required: + - compatible + - reg + - label + +additionalProperties: false + +examples: + - | + backlight@d800 { + compatible = "qcom,pm8941-wled"; + reg = <0xd800 0x100>; + label = "backlight"; + + qcom,cs-out; + qcom,current-limit = <20>; + qcom,current-boost-limit = <805>; + qcom,switching-freq = <1600>; + qcom,ovp = <29>; + qcom,num-strings = <2>; + qcom,enabled-strings = <0 1>; + };
diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index 4c270fd..a2a541b 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -41,8 +41,7 @@ Color of the LED. Use one of the LED_COLOR_ID_* prefixed definitions from the header include/dt-bindings/leds/common.h. If there is no matching LED_COLOR_ID available, add a new one. - allOf: - - $ref: /schemas/types.yaml#definitions/uint32 + $ref: /schemas/types.yaml#definitions/uint32 minimum: 0 maximum: 8 @@ -67,8 +66,7 @@ produced where the LED momentarily turns off (or on). The "keep" setting will keep the LED at whatever its current state is, without producing a glitch. - allOf: - - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#definitions/string enum: - on - off @@ -79,8 +77,8 @@ description: This parameter, if present, is a string defining the trigger assigned to the LED. - allOf: - - $ref: /schemas/types.yaml#definitions/string + $ref: /schemas/types.yaml#definitions/string + enum: # LED will act as a back-light, controlled by the framebuffer system - backlight @@ -111,8 +109,7 @@ brightness and duration (in ms). The exact format is described in: Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt - allOf: - - $ref: /schemas/types.yaml#definitions/uint32-matrix + $ref: /schemas/types.yaml#definitions/uint32-matrix items: minItems: 2 maxItems: 2
diff --git a/Documentation/devicetree/bindings/leds/leds-aw2013.yaml b/Documentation/devicetree/bindings/leds/leds-aw2013.yaml new file mode 100644 index 0000000..e24b0d1 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-aw2013.yaml
@@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-aw2013.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AWINIC AW2013 3-channel LED Driver + +maintainers: + - Nikita Travkin <nikitos.tr@gmail.com> + +description: | + The AW2013 is a 3-channel LED driver with I2C interface. It can control + LED brightness with PWM output. + +properties: + compatible: + const: awinic,aw2013 + + reg: + maxItems: 1 + + vcc-supply: + description: Regulator providing power to the "VCC" pin. + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^led@[0-2]$": + type: object + $ref: common.yaml# + + properties: + reg: + description: Index of the LED. + minimum: 0 + maximum: 2 + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/leds/common.h> + + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@45 { + compatible = "awinic,aw2013"; + reg = <0x45>; + #address-cells = <1>; + #size-cells = <0>; + + vcc-supply = <&pm8916_l17>; + + led@0 { + reg = <0>; + led-max-microamp = <5000>; + function = LED_FUNCTION_INDICATOR; + color = <LED_COLOR_ID_RED>; + }; + + led@1 { + reg = <1>; + led-max-microamp = <5000>; + function = LED_FUNCTION_INDICATOR; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <2>; + led-max-microamp = <5000>; + function = LED_FUNCTION_INDICATOR; + color = <LED_COLOR_ID_BLUE>; + }; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.yaml b/Documentation/devicetree/bindings/leds/leds-gpio.yaml index 0e75b18..7ad2bae 100644 --- a/Documentation/devicetree/bindings/leds/leds-gpio.yaml +++ b/Documentation/devicetree/bindings/leds/leds-gpio.yaml
@@ -24,8 +24,7 @@ "(^led-[0-9a-f]$|led)": type: object - allOf: - - $ref: common.yaml# + $ref: common.yaml# properties: gpios:
diff --git a/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml b/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml new file mode 100644 index 0000000..f682596 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml
@@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-sgm3140.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SGMICRO SGM3140 500mA Buck/Boost Charge Pump LED Driver + +maintainers: + - Luca Weiss <luca@z3ntu.xyz> + +description: | + The SGM3140 is a current-regulated charge pump which can regulate two current + levels for Flash and Torch modes. + + The data sheet can be found at: + http://www.sg-micro.com/uploads/soft/20190626/1561535688.pdf + +properties: + compatible: + const: sgmicro,sgm3140 + + enable-gpios: + maxItems: 1 + description: A connection to the 'EN' pin. + + flash-gpios: + maxItems: 1 + description: A connection to the 'FLASH' pin. + + vin-supply: + description: Regulator providing power to the 'VIN' pin. + + led: + type: object + $ref: common.yaml# + +required: + - compatible + - flash-gpios + - enable-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/leds/common.h> + + led-controller { + compatible = "sgmicro,sgm3140"; + flash-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */ + enable-gpios = <&pio 2 3 GPIO_ACTIVE_HIGH>; /* PC3 */ + vin-supply = <®_dcdc1>; + + sgm3140_flash: led { + function = LED_FUNCTION_FLASH; + color = <LED_COLOR_ID_WHITE>; + flash-max-timeout-us = <250000>; + }; + };
diff --git a/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml b/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml index 90edf9d..86a37c9 100644 --- a/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml +++ b/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
@@ -34,11 +34,10 @@ #- $ref: "common.yaml#" rohm,led-compatible: description: LED identification string - allOf: - - $ref: "/schemas/types.yaml#/definitions/string" - - enum: - - bd71828-ambled - - bd71828-grnled + $ref: "/schemas/types.yaml#/definitions/string" + enum: + - bd71828-ambled + - bd71828-grnled function: description: Purpose of LED as defined in dt-bindings/leds/common.h
diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt deleted file mode 100644 index 31486c9..0000000 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt +++ /dev/null
@@ -1,58 +0,0 @@ -NXP i.MX Messaging Unit (MU) --------------------------------------------------------------------- - -The Messaging Unit module enables two processors within the SoC to -communicate and coordinate by passing messages (e.g. data, status -and control) through the MU interface. The MU also provides the ability -for one processor to signal the other processor using interrupts. - -Because the MU manages the messaging between processors, the MU uses -different clocks (from each side of the different peripheral buses). -Therefore, the MU must synchronize the accesses from one side to the -other. The MU accomplishes synchronization using two sets of matching -registers (Processor A-facing, Processor B-facing). - -Messaging Unit Device Node: -============================= - -Required properties: -------------------- -- compatible : should be "fsl,<chip>-mu", the supported chips include - imx6sx, imx7s, imx8qxp, imx8qm. - The "fsl,imx6sx-mu" compatible is seen as generic and should - be included together with SoC specific compatible. - There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu" - compatible to support it. - To communicate with i.MX8 SCU, "fsl,imx8-mu-scu" could be - used for fast IPC -- reg : Should contain the registers location and length -- interrupts : Interrupt number. The interrupt specifier format depends - on the interrupt controller parent. -- #mbox-cells: Must be 2. - <&phandle type channel> - phandle : Label name of controller - type : Channel type - channel : Channel number - - This MU support 4 type of unidirectional channels, each type - has 4 channels. A total of 16 channels. Following types are - supported: - 0 - TX channel with 32bit transmit register and IRQ transmit - acknowledgment support. - 1 - RX channel with 32bit receive register and IRQ support - 2 - TX doorbell channel. Without own register and no ACK support. - 3 - RX doorbell channel. - -Optional properties: -------------------- -- clocks : phandle to the input clock. -- fsl,mu-side-b : Should be set for side B MU. - -Examples: --------- -lsio_mu0: mailbox@5d1b0000 { - compatible = "fsl,imx8qxp-mu"; - reg = <0x0 0x5d1b0000 0x0 0x10000>; - interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>; - #mbox-cells = <2>; -};
diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml new file mode 100644 index 0000000..3b35eb5 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml
@@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/fsl,mu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX Messaging Unit (MU) + +maintainers: + - Dong Aisheng <aisheng.dong@nxp.com> + +description: | + The Messaging Unit module enables two processors within the SoC to + communicate and coordinate by passing messages (e.g. data, status + and control) through the MU interface. The MU also provides the ability + for one processor to signal the other processor using interrupts. + + Because the MU manages the messaging between processors, the MU uses + different clocks (from each side of the different peripheral buses). + Therefore, the MU must synchronize the accesses from one side to the + other. The MU accomplishes synchronization using two sets of matching + registers (Processor A-facing, Processor B-facing). + +properties: + compatible: + oneOf: + - const: fsl,imx6sx-mu + - const: fsl,imx7ulp-mu + - const: fsl,imx8-mu-scu + - items: + - enum: + - fsl,imx7s-mu + - fsl,imx8mq-mu + - fsl,imx8mm-mu + - fsl,imx8mn-mu + - fsl,imx8mp-mu + - fsl,imx8qxp-mu + - const: fsl,imx6sx-mu + - description: To communicate with i.MX8 SCU with fast IPC + items: + - const: fsl,imx8qxp-mu + - const: fsl,imx8-mu-scu + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#mbox-cells": + description: | + <&phandle type channel> + phandle : Label name of controller + type : Channel type + channel : Channel number + + This MU support 4 type of unidirectional channels, each type + has 4 channels. A total of 16 channels. Following types are + supported: + 0 - TX channel with 32bit transmit register and IRQ transmit + acknowledgment support. + 1 - RX channel with 32bit receive register and IRQ support + 2 - TX doorbell channel. Without own register and no ACK support. + 3 - RX doorbell channel. + const: 2 + + clocks: + maxItems: 1 + + fsl,mu-side-b: + description: boolean, if present, means it is for side B MU. + type: boolean + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + mailbox@5d1b0000 { + compatible = "fsl,imx8qxp-mu", "fsl,imx6sx-mu"; + reg = <0x5d1b0000 0x10000>; + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>; + #mbox-cells = <2>; + };
diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt deleted file mode 100644 index beec612..0000000 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt +++ /dev/null
@@ -1,88 +0,0 @@ -Binding for the Qualcomm APCS global block -========================================== - -This binding describes the APCS "global" block found in various Qualcomm -platforms. - -- compatible: - Usage: required - Value type: <string> - Definition: must be one of: - "qcom,msm8916-apcs-kpss-global", - "qcom,msm8996-apcs-hmss-global" - "qcom,msm8998-apcs-hmss-global" - "qcom,qcs404-apcs-apps-global" - "qcom,sc7180-apss-shared" - "qcom,sdm845-apss-shared" - "qcom,sm8150-apss-shared" - "qcom,ipq8074-apcs-apps-global" - -- reg: - Usage: required - Value type: <prop-encoded-array> - Definition: must specify the base address and size of the global block - -- clocks: - Usage: required if #clock-names property is present - Value type: <phandle array> - Definition: phandles to the two parent clocks of the clock driver. - -- #mbox-cells: - Usage: required - Value type: <u32> - Definition: as described in mailbox.txt, must be 1 - -- #clock-cells: - Usage: optional - Value type: <u32> - Definition: as described in clock.txt, must be 0 - -- clock-names: - Usage: required if the platform data based clock driver needs to - retrieve the parent clock names from device tree. - This will requires two mandatory clocks to be defined. - Value type: <string-array> - Definition: must be "pll" and "aux" - -= EXAMPLE -The following example describes the APCS HMSS found in MSM8996 and part of the -GLINK RPM referencing the "rpm_hlos" doorbell therein. - - apcs_glb: mailbox@9820000 { - compatible = "qcom,msm8996-apcs-hmss-global"; - reg = <0x9820000 0x1000>; - - #mbox-cells = <1>; - }; - - rpm-glink { - compatible = "qcom,glink-rpm"; - - interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>; - - qcom,rpm-msg-ram = <&rpm_msg_ram>; - - mboxes = <&apcs_glb 0>; - mbox-names = "rpm_hlos"; - }; - -Below is another example of the APCS binding on MSM8916 platforms: - - apcs: mailbox@b011000 { - compatible = "qcom,msm8916-apcs-kpss-global"; - reg = <0xb011000 0x1000>; - #mbox-cells = <1>; - clocks = <&a53pll>; - #clock-cells = <0>; - }; - -Below is another example of the APCS binding on QCS404 platforms: - - apcs_glb: mailbox@b011000 { - compatible = "qcom,qcs404-apcs-apps-global", "syscon"; - reg = <0x0b011000 0x1000>; - #mbox-cells = <1>; - clocks = <&apcs_hfpll>, <&gcc GCC_GPLL0_AO_OUT_MAIN>; - clock-names = "pll", "aux"; - #clock-cells = <0>; - };
diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml new file mode 100644 index 0000000..12eff94 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
@@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mailbox/qcom,apcs-kpss-global.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm APCS global block bindings + +description: + This binding describes the APCS "global" block found in various Qualcomm + platforms. + +maintainers: + - Sivaprakash Murugesan <sivaprak@codeaurora.org> + +properties: + compatible: + enum: + - qcom,ipq8074-apcs-apps-global + - qcom,msm8916-apcs-kpss-global + - qcom,msm8996-apcs-hmss-global + - qcom,msm8998-apcs-hmss-global + - qcom,qcs404-apcs-apps-global + - qcom,sc7180-apss-shared + - qcom,sdm845-apss-shared + - qcom,sm8150-apss-shared + + reg: + maxItems: 1 + + clocks: + description: phandles to the parent clocks of the clock driver + items: + - description: primary pll parent of the clock driver + - description: auxiliary parent + + '#mbox-cells': + const: 1 + + '#clock-cells': + const: 0 + + clock-names: + items: + - const: pll + - const: aux + +required: + - compatible + - reg + - '#mbox-cells' + +additionalProperties: false + +examples: + + # Example apcs with msm8996 + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + apcs_glb: mailbox@9820000 { + compatible = "qcom,msm8996-apcs-hmss-global"; + reg = <0x9820000 0x1000>; + + #mbox-cells = <1>; + }; + + rpm-glink { + compatible = "qcom,glink-rpm"; + interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>; + qcom,rpm-msg-ram = <&rpm_msg_ram>; + mboxes = <&apcs_glb 0>; + mbox-names = "rpm_hlos"; + }; + + # Example apcs with qcs404 + - | + #define GCC_APSS_AHB_CLK_SRC 1 + #define GCC_GPLL0_AO_OUT_MAIN 123 + apcs: mailbox@b011000 { + compatible = "qcom,qcs404-apcs-apps-global"; + reg = <0x0b011000 0x1000>; + #mbox-cells = <1>; + clocks = <&apcs_hfpll>, <&gcc GCC_GPLL0_AO_OUT_MAIN>; + clock-names = "pll", "aux"; + #clock-cells = <0>; + };
diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml new file mode 100644 index 0000000..4ac2123 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
@@ -0,0 +1,80 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/qcom-ipcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. Inter-Processor Communication Controller + +maintainers: + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> + +description: + The Inter-Processor Communication Controller (IPCC) is a centralized hardware + to route interrupts across various subsystems. It involves a three-level + addressing scheme called protocol, client and signal. For example, consider an + entity on the Application Processor Subsystem (APSS) that wants to listen to + Modem's interrupts via Shared Memory Point to Point (SMP2P) interface. In such + a case, the client would be Modem (client-id is 2) and the signal would be + SMP2P (signal-id is 2). The SMP2P itself falls under the Multiprocessor (MPROC) + protocol (protocol-id is 0). Refer include/dt-bindings/mailbox/qcom-ipcc.h + for the list of such IDs. + +properties: + compatible: + items: + - enum: + - qcom,sm8250-ipcc + - const: qcom,ipcc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 3 + description: + The first cell is the client-id, the second cell is the signal-id and the + third cell is the interrupt type. + + "#mbox-cells": + const: 2 + description: + The first cell is the client-id, and the second cell is the signal-id. + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - "#interrupt-cells" + - "#mbox-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/mailbox/qcom-ipcc.h> + + mailbox@408000 { + compatible = "qcom,sm8250-ipcc", "qcom,ipcc"; + reg = <0x408000 0x1000>; + interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <3>; + #mbox-cells = <2>; + }; + + smp2p-modem { + compatible = "qcom,smp2p"; + interrupts-extended = <&ipcc_mproc IPCC_CLIENT_MPSS + IPCC_MPROC_SIGNAL_SMP2P IRQ_TYPE_EDGE_RISING>; + mboxes = <&ipcc_mproc IPCC_CLIENT_MPSS IPCC_MPROC_SIGNAL_SMP2P>; + + /* Other SMP2P fields */ + };
diff --git a/Documentation/devicetree/bindings/mailbox/sprd-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/sprd-mailbox.yaml new file mode 100644 index 0000000..26a5cca --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/sprd-mailbox.yaml
@@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mailbox/sprd-mailbox.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Spreadtrum mailbox controller bindings + +maintainers: + - Orson Zhai <orsonzhai@gmail.com> + - Baolin Wang <baolin.wang7@gmail.com> + - Chunyan Zhang <zhang.lyra@gmail.com> + +properties: + compatible: + enum: + - sprd,sc9860-mailbox + + reg: + items: + - description: inbox registers' base address + - description: outbox registers' base address + + interrupts: + items: + - description: inbox interrupt + - description: outbox interrupt + + clocks: + maxItems: 1 + + clock-names: + items: + - const: enable + + "#mbox-cells": + const: 1 + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + mailbox: mailbox@400a0000 { + compatible = "sprd,sc9860-mailbox"; + reg = <0x400a0000 0x8000>, <0x400a8000 0x8000>; + #mbox-cells = <1>; + clock-names = "enable"; + clocks = <&aon_gate 53>; + interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>; + }; +...
diff --git a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml index 5b13d66..3b7ab61 100644 --- a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml
@@ -24,7 +24,7 @@ maxItems: 1 clocks: - maxItems: 1 + maxItems: 1 interrupts: items: @@ -49,9 +49,8 @@ st,proc-id: description: Processor id using the mailbox (0 or 1) - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 0, 1 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] required: - compatible
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml index 8453ee3..0931883 100644 --- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
@@ -20,11 +20,11 @@ - const: allwinner,sun4i-a10-csi1 - const: allwinner,sun7i-a20-csi0 - items: - - const: allwinner,sun7i-a20-csi1 - - const: allwinner,sun4i-a10-csi1 + - const: allwinner,sun7i-a20-csi1 + - const: allwinner,sun4i-a10-csi1 - items: - - const: allwinner,sun8i-r40-csi0 - - const: allwinner,sun7i-a20-csi0 + - const: allwinner,sun8i-r40-csi0 + - const: allwinner,sun7i-a20-csi0 reg: maxItems: 1 @@ -35,24 +35,24 @@ clocks: oneOf: - items: - - description: The CSI interface clock - - description: The CSI DRAM clock + - description: The CSI interface clock + - description: The CSI DRAM clock - items: - - description: The CSI interface clock - - description: The CSI ISP clock - - description: The CSI DRAM clock + - description: The CSI interface clock + - description: The CSI ISP clock + - description: The CSI DRAM clock clock-names: oneOf: - items: - - const: bus - - const: ram + - const: bus + - const: ram - items: - - const: bus - - const: isp - - const: ram + - const: bus + - const: isp + - const: ram resets: maxItems: 1
diff --git a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml index 37d77e0..b902495 100644 --- a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml +++ b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml
@@ -29,14 +29,14 @@ compatible: oneOf: - items: - - enum: - - amlogic,gxbb-vdec # GXBB (S905) - - amlogic,gxl-vdec # GXL (S905X, S905D) - - amlogic,gxm-vdec # GXM (S912) - - const: amlogic,gx-vdec + - enum: + - amlogic,gxbb-vdec # GXBB (S905) + - amlogic,gxl-vdec # GXL (S905X, S905D) + - amlogic,gxm-vdec # GXM (S912) + - const: amlogic,gx-vdec - enum: - - amlogic,g12a-vdec # G12A (S905X2, S905D2) - - amlogic,sm1-vdec # SM1 (S905X3, S905D3) + - amlogic,g12a-vdec # G12A (S905X2, S905D2) + - amlogic,sm1-vdec # SM1 (S905X3, S905D3) interrupts: minItems: 2 @@ -77,13 +77,11 @@ amlogic,ao-sysctrl: description: should point to the AOBUS sysctrl node - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle amlogic,canvas: description: should point to a canvas provider node - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle allOf: - if:
diff --git a/Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml b/Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml index 95ffa8b..d93aea6 100644 --- a/Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml +++ b/Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml
@@ -35,8 +35,7 @@ hdmi-phandle: description: phandle to the HDMI controller - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle allOf: - if: @@ -88,7 +87,7 @@ - | cec_AO: cec@100 { compatible = "amlogic,meson-gx-ao-cec"; - reg = <0x0 0x00100 0x0 0x14>; + reg = <0x00100 0x14>; interrupts = <199>; clocks = <&clkc_cec>; clock-names = "core";
diff --git a/Documentation/devicetree/bindings/media/i2c/imx219.yaml b/Documentation/devicetree/bindings/media/i2c/imx219.yaml index 32d6b69..dfc4d29 100644 --- a/Documentation/devicetree/bindings/media/i2c/imx219.yaml +++ b/Documentation/devicetree/bindings/media/i2c/imx219.yaml
@@ -67,8 +67,7 @@ otherwise it's continuous. link-frequencies: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint64-array + $ref: /schemas/types.yaml#/definitions/uint64-array description: Allowed data bus frequencies.
diff --git a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml index d6af685..1956b2a 100644 --- a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml
@@ -79,8 +79,7 @@ - const: 4 link-frequencies: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint64-array + $ref: /schemas/types.yaml#/definitions/uint64-array description: Allowed data bus frequencies. 360000000, 180000000 Hz or both are supported by the driver.
diff --git a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.txt b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.txt deleted file mode 100644 index 7ec2c8c..0000000 --- a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.txt +++ /dev/null
@@ -1,50 +0,0 @@ -Marvell MMP2 camera host interface - -Required properties: - - compatible: Should be "marvell,mmp2-ccic". - - reg: Register base and size. - - interrupts: The interrupt number. - - #clock-cells: Must be 0. - -Optional properties: - - clocks: Reference to the input clock as specified by - Documentation/devicetree/bindings/clock/clock-bindings.txt. - - clock-names: Names of the clocks used; "axi" for the AXI bus interface, - "func" for the peripheral clock and "phy" for the parallel - video bus interface. - - clock-output-names: Optional clock source for sensors. Shall be "mclk". - -Required subnodes: - - port: The parallel bus interface port with a single endpoint linked to - the sensor's endpoint as described in - Documentation/devicetree/bindings/media/video-interfaces.txt. - -Required endpoint properties: - - bus-type: data bus type, <5> or <6> for Parallel or Bt.656 respectively - - pclk-sample: pixel clock polarity - - hsync-active: horizontal synchronization polarity (only required for - parallel bus) - - vsync-active: vertical synchronization polarity (only required for - parallel bus) - -Example: - - camera0: camera@d420a000 { - compatible = "marvell,mmp2-ccic"; - reg = <0xd420a000 0x800>; - interrupts = <42>; - clocks = <&soc_clocks MMP2_CLK_CCIC0>; - clock-names = "axi"; - #clock-cells = <0>; - clock-output-names = "mclk"; - - port { - camera0_0: endpoint { - remote-endpoint = <&ov7670_0>; - bus-type = <5>; /* Parallel */ - hsync-active = <1>; /* Active high */ - vsync-active = <1>; /* Active high */ - pclk-sample = <0>; /* Falling */ - }; - }; - };
diff --git a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml new file mode 100644 index 0000000..49bff73 --- /dev/null +++ b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
@@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2019,2020 Lubomir Rintel <lkundrak@v3.sk> +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/marvell,mmp2-ccic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell MMP2 camera host interface bindings + +maintainers: + - Lubomir Rintel <lkundrak@v3.sk> + +properties: + $nodename: + pattern: '^camera@[a-f0-9]+$' + + compatible: + const: marvell,mmp2-ccic + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + port: + type: object + additionalProperties: false + + properties: + endpoint: + type: object + additionalProperties: false + + # Properties described in + # Documentation/devicetree/bindings/media/video-interfaces.txt + properties: + remote-endpoint: true + hsync-active: true + vsync-active: true + pclk-sample: true + bus-type: true + + required: + - remote-endpoint + + required: + - endpoint + + clocks: + minItems: 1 + maxItems: 3 + items: + - description: AXI bus interface clock + - description: Peripheral clock + - description: Parallel video bus interface clock + + clock-names: + const: axi + + '#clock-cells': + const: 0 + + clock-output-names: + const: mclk + +required: + - compatible + - reg + - interrupts + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/marvell,mmp2.h> + + camera@d420a000 { + compatible = "marvell,mmp2-ccic"; + reg = <0xd420a000 0x800>; + interrupts = <42>; + clocks = <&soc_clocks MMP2_CLK_CCIC0>; + clock-names = "axi"; + #clock-cells = <0>; + clock-output-names = "mclk"; + + port { + camera0_0: endpoint { + remote-endpoint = <&ov7670_0>; + bus-type = <5>; /* Parallel */ + hsync-active = <1>; /* Active high */ + vsync-active = <1>; /* Active high */ + pclk-sample = <0>; /* Falling */ + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml index 764affa..55f2d67 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
@@ -115,7 +115,7 @@ venus: video-codec@aa00000 { compatible = "qcom,sc7180-venus"; - reg = <0 0x0aa00000 0 0xff000>; + reg = <0x0aa00000 0xff000>; interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; power-domains = <&videocc VENUS_GDSC>, <&videocc VCODEC0_GDSC>;
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml index 8552f4a..157dff8 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
@@ -110,7 +110,7 @@ video-codec@aa00000 { compatible = "qcom,sdm845-venus-v2"; - reg = <0 0x0aa00000 0 0xff000>; + reg = <0x0aa00000 0xff000>; interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, <&videocc VIDEO_CC_VENUS_AHB_CLK>,
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml index 05cabe4..084e45e 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
@@ -127,7 +127,7 @@ video-codec@aa00000 { compatible = "qcom,sdm845-venus"; - reg = <0 0x0aa00000 0 0xff000>; + reg = <0x0aa00000 0xff000>; interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, <&videocc VIDEO_CC_VENUS_AHB_CLK>,
diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml index b27c938..ded2ac4 100644 --- a/Documentation/devicetree/bindings/media/rc.yaml +++ b/Documentation/devicetree/bindings/media/rc.yaml
@@ -18,136 +18,135 @@ description: Specifies the scancode/key mapping table defined in-kernel for the remote controller. - allOf: - - $ref: '/schemas/types.yaml#/definitions/string' - - enum: - - rc-adstech-dvb-t-pci - - rc-alink-dtu-m - - rc-anysee - - rc-apac-viewcomp - - rc-astrometa-t2hybrid - - rc-asus-pc39 - - rc-asus-ps3-100 - - rc-ati-tv-wonder-hd-600 - - rc-ati-x10 - - rc-avermedia - - rc-avermedia-a16d - - rc-avermedia-cardbus - - rc-avermedia-dvbt - - rc-avermedia-m135a - - rc-avermedia-m733a-rm-k6 - - rc-avermedia-rm-ks - - rc-avertv-303 - - rc-azurewave-ad-tu700 - - rc-beelink-gs1 - - rc-behold - - rc-behold-columbus - - rc-budget-ci-old - - rc-cec - - rc-cinergy - - rc-cinergy-1400 - - rc-d680-dmb - - rc-delock-61959 - - rc-dib0700-nec - - rc-dib0700-rc5 - - rc-digitalnow-tinytwin - - rc-digittrade - - rc-dm1105-nec - - rc-dntv-live-dvb-t - - rc-dntv-live-dvbt-pro - - rc-dtt200u - - rc-dvbsky - - rc-dvico-mce - - rc-dvico-portable - - rc-em-terratec - - rc-empty - - rc-encore-enltv - - rc-encore-enltv-fm53 - - rc-encore-enltv2 - - rc-evga-indtube - - rc-eztv - - rc-flydvb - - rc-flyvideo - - rc-fusionhdtv-mce - - rc-gadmei-rm008z - - rc-geekbox - - rc-genius-tvgo-a11mce - - rc-gotview7135 - - rc-hauppauge - - rc-hisi-poplar - - rc-hisi-tv-demo - - rc-imon-mce - - rc-imon-pad - - rc-imon-rsc - - rc-iodata-bctv7e - - rc-it913x-v1 - - rc-it913x-v2 - - rc-kaiomy - - rc-khadas - - rc-kworld-315u - - rc-kworld-pc150u - - rc-kworld-plus-tv-analog - - rc-leadtek-y04g0051 - - rc-lme2510 - - rc-manli - - rc-medion-x10 - - rc-medion-x10-digitainer - - rc-medion-x10-or2x - - rc-msi-digivox-ii - - rc-msi-digivox-iii - - rc-msi-tvanywhere - - rc-msi-tvanywhere-plus - - rc-nebula - - rc-nec-terratec-cinergy-xs - - rc-norwood - - rc-npgtech - - rc-odroid - - rc-pctv-sedna - - rc-pinnacle-color - - rc-pinnacle-grey - - rc-pinnacle-pctv-hd - - rc-pixelview - - rc-pixelview-002t - - rc-pixelview-mk12 - - rc-pixelview-new - - rc-powercolor-real-angel - - rc-proteus-2309 - - rc-purpletv - - rc-pv951 - - rc-rc5-tv - - rc-rc6-mce - - rc-real-audio-220-32-keys - - rc-reddo - - rc-snapstream-firefly - - rc-streamzap - - rc-su3000 - - rc-tango - - rc-tanix-tx3mini - - rc-tanix-tx5max - - rc-tbs-nec - - rc-technisat-ts35 - - rc-technisat-usb2 - - rc-terratec-cinergy-c-pci - - rc-terratec-cinergy-s2-hd - - rc-terratec-cinergy-xs - - rc-terratec-slim - - rc-terratec-slim-2 - - rc-tevii-nec - - rc-tivo - - rc-total-media-in-hand - - rc-total-media-in-hand-02 - - rc-trekstor - - rc-tt-1500 - - rc-twinhan-dtv-cab-ci - - rc-twinhan1027 - - rc-videomate-k100 - - rc-videomate-s350 - - rc-videomate-tv-pvr - - rc-videostrong-kii-pro - - rc-wetek-hub - - rc-wetek-play2 - - rc-winfast - - rc-winfast-usbii-deluxe - - rc-x96max - - rc-xbox-dvd - - rc-zx-irdec + $ref: '/schemas/types.yaml#/definitions/string' + enum: + - rc-adstech-dvb-t-pci + - rc-alink-dtu-m + - rc-anysee + - rc-apac-viewcomp + - rc-astrometa-t2hybrid + - rc-asus-pc39 + - rc-asus-ps3-100 + - rc-ati-tv-wonder-hd-600 + - rc-ati-x10 + - rc-avermedia + - rc-avermedia-a16d + - rc-avermedia-cardbus + - rc-avermedia-dvbt + - rc-avermedia-m135a + - rc-avermedia-m733a-rm-k6 + - rc-avermedia-rm-ks + - rc-avertv-303 + - rc-azurewave-ad-tu700 + - rc-beelink-gs1 + - rc-behold + - rc-behold-columbus + - rc-budget-ci-old + - rc-cec + - rc-cinergy + - rc-cinergy-1400 + - rc-d680-dmb + - rc-delock-61959 + - rc-dib0700-nec + - rc-dib0700-rc5 + - rc-digitalnow-tinytwin + - rc-digittrade + - rc-dm1105-nec + - rc-dntv-live-dvb-t + - rc-dntv-live-dvbt-pro + - rc-dtt200u + - rc-dvbsky + - rc-dvico-mce + - rc-dvico-portable + - rc-em-terratec + - rc-empty + - rc-encore-enltv + - rc-encore-enltv-fm53 + - rc-encore-enltv2 + - rc-evga-indtube + - rc-eztv + - rc-flydvb + - rc-flyvideo + - rc-fusionhdtv-mce + - rc-gadmei-rm008z + - rc-geekbox + - rc-genius-tvgo-a11mce + - rc-gotview7135 + - rc-hauppauge + - rc-hisi-poplar + - rc-hisi-tv-demo + - rc-imon-mce + - rc-imon-pad + - rc-imon-rsc + - rc-iodata-bctv7e + - rc-it913x-v1 + - rc-it913x-v2 + - rc-kaiomy + - rc-khadas + - rc-kworld-315u + - rc-kworld-pc150u + - rc-kworld-plus-tv-analog + - rc-leadtek-y04g0051 + - rc-lme2510 + - rc-manli + - rc-medion-x10 + - rc-medion-x10-digitainer + - rc-medion-x10-or2x + - rc-msi-digivox-ii + - rc-msi-digivox-iii + - rc-msi-tvanywhere + - rc-msi-tvanywhere-plus + - rc-nebula + - rc-nec-terratec-cinergy-xs + - rc-norwood + - rc-npgtech + - rc-odroid + - rc-pctv-sedna + - rc-pinnacle-color + - rc-pinnacle-grey + - rc-pinnacle-pctv-hd + - rc-pixelview + - rc-pixelview-002t + - rc-pixelview-mk12 + - rc-pixelview-new + - rc-powercolor-real-angel + - rc-proteus-2309 + - rc-purpletv + - rc-pv951 + - rc-rc5-tv + - rc-rc6-mce + - rc-real-audio-220-32-keys + - rc-reddo + - rc-snapstream-firefly + - rc-streamzap + - rc-su3000 + - rc-tango + - rc-tanix-tx3mini + - rc-tanix-tx5max + - rc-tbs-nec + - rc-technisat-ts35 + - rc-technisat-usb2 + - rc-terratec-cinergy-c-pci + - rc-terratec-cinergy-s2-hd + - rc-terratec-cinergy-xs + - rc-terratec-slim + - rc-terratec-slim-2 + - rc-tevii-nec + - rc-tivo + - rc-total-media-in-hand + - rc-total-media-in-hand-02 + - rc-trekstor + - rc-tt-1500 + - rc-twinhan-dtv-cab-ci + - rc-twinhan1027 + - rc-videomate-k100 + - rc-videomate-s350 + - rc-videomate-tv-pvr + - rc-videostrong-kii-pro + - rc-wetek-hub + - rc-wetek-play2 + - rc-winfast + - rc-winfast-usbii-deluxe + - rc-x96max + - rc-xbox-dvd + - rc-zx-irdec
diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.yaml b/Documentation/devicetree/bindings/media/renesas,ceu.yaml index fcb5f13..c7e1e4f 100644 --- a/Documentation/devicetree/bindings/media/renesas,ceu.yaml +++ b/Documentation/devicetree/bindings/media/renesas,ceu.yaml
@@ -27,28 +27,34 @@ interrupts: maxItems: 1 + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + port: type: object additionalProperties: false properties: - endpoint: - type: object - additionalProperties: false + endpoint: + type: object + additionalProperties: false # Properties described in # Documentation/devicetree/bindings/media/video-interfaces.txt - properties: - remote-endpoint: true - hsync-active: true - vsync-active: true - field-even-active: false - bus-width: - enum: [8, 16] - default: 8 + properties: + remote-endpoint: true + hsync-active: true + vsync-active: true + field-even-active: false + bus-width: + enum: [8, 16] + default: 8 - required: - - remote-endpoint + required: + - remote-endpoint required: - endpoint @@ -57,6 +63,8 @@ - compatible - reg - interrupts + - clocks + - power-domains - port additionalProperties: false @@ -64,11 +72,14 @@ examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/r7s72100-clock.h> ceu: ceu@e8210000 { reg = <0xe8210000 0x209c>; compatible = "renesas,r7s72100-ceu"; interrupts = <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp6_clks R7S72100_CLK_CEU>; + power-domains = <&cpg_clocks>; port { ceu_in: endpoint {
diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.yaml b/Documentation/devicetree/bindings/media/renesas,csi2.yaml index 408442a..c9e0682 100644 --- a/Documentation/devicetree/bindings/media/renesas,csi2.yaml +++ b/Documentation/devicetree/bindings/media/renesas,csi2.yaml
@@ -135,7 +135,7 @@ csi20: csi2@fea80000 { compatible = "renesas,r8a7796-csi2"; - reg = <0 0xfea80000 0 0x10000>; + reg = <0xfea80000 0x10000>; interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 714>; power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml index 1ec947b..53c0a72 100644 --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml
@@ -116,10 +116,9 @@ #The per-board settings for Gen3 and RZ/G2 platforms: renesas,id: description: VIN channel number - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - - maximum: 15 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 ports: type: object @@ -261,13 +260,13 @@ anyOf: - required: - - endpoint@0 + - endpoint@0 - required: - - endpoint@1 + - endpoint@1 - required: - - endpoint@2 + - endpoint@2 - required: - - endpoint@3 + - endpoint@3 additionalProperties: false @@ -307,7 +306,7 @@ vin1: vin@e6ef1000 { compatible = "renesas,vin-r8a7790", "renesas,rcar-gen2-vin"; - reg = <0 0xe6ef1000 0 0x1000>; + reg = <0xe6ef1000 0x1000>; interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 810>; power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; @@ -329,7 +328,7 @@ vin0: video@e6ef0000 { compatible = "renesas,vin-r8a7795"; - reg = <0 0xe6ef0000 0 0x1000>; + reg = <0xe6ef0000 0x1000>; interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 811>; power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; @@ -366,7 +365,7 @@ vin2: video@e6ef2000 { compatible = "renesas,vin-r8a77970"; - reg = <0 0xe6ef2000 0 0x1000>; + reg = <0xe6ef2000 0x1000>; interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 809>; power-domains = <&sysc R8A77970_PD_ALWAYS_ON>;
diff --git a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml index 0c68cda..8d35c32 100644 --- a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml +++ b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml
@@ -61,7 +61,7 @@ vdec: video-codec@ff660000 { compatible = "rockchip,rk3399-vdec"; - reg = <0x0 0xff660000 0x0 0x400>; + reg = <0xff660000 0x400>; interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH 0>; clocks = <&cru ACLK_VDU>, <&cru HCLK_VDU>, <&cru SCLK_VDU_CA>, <&cru SCLK_VDU_CORE>;
diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml index 27df18a..2b62945 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
@@ -66,7 +66,7 @@ vpu: video-codec@ff9a0000 { compatible = "rockchip,rk3288-vpu"; - reg = <0x0 0xff9a0000 0x0 0x800>; + reg = <0xff9a0000 0x800>; interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "vepu", "vdpu";
diff --git a/Documentation/devicetree/bindings/media/ti,vpe.yaml b/Documentation/devicetree/bindings/media/ti,vpe.yaml index f3a8a35..ef473f2 100644 --- a/Documentation/devicetree/bindings/media/ti,vpe.yaml +++ b/Documentation/devicetree/bindings/media/ti,vpe.yaml
@@ -17,7 +17,7 @@ properties: compatible: - const: ti,dra7-vpe + const: ti,dra7-vpe reg: items:
diff --git a/Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml b/Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml new file mode 100644 index 0000000..1fca282 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml
@@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/baikal,bt1-l2-ctl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Baikal-T1 L2-cache Control Block + +maintainers: + - Serge Semin <fancer.lancer@gmail.com> + +description: | + By means of the System Controller Baikal-T1 SoC exposes a few settings to + tune the MIPS P5600 CM2 L2 cache performance up. In particular it's possible + to change the Tag, Data and Way-select RAM access latencies. Baikal-T1 + L2-cache controller block is responsible for the tuning. Its DT node is + supposed to be a child of the system controller. + +properties: + compatible: + const: baikal,bt1-l2-ctl + + reg: + maxItems: 1 + + baikal,l2-ws-latency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Cycles of latency for Way-select RAM accesses + default: 0 + minimum: 0 + maximum: 3 + + baikal,l2-tag-latency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Cycles of latency for Tag RAM accesses + default: 0 + minimum: 0 + maximum: 3 + + baikal,l2-data-latency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Cycles of latency for Data RAM accesses + default: 1 + minimum: 0 + maximum: 3 + +additionalProperties: false + +required: + - compatible + +examples: + - | + l2@1f04d028 { + compatible = "baikal,bt1-l2-ctl"; + reg = <0x1f04d028 0x004>; + + baikal,l2-ws-latency = <1>; + baikal,l2-tag-latency = <1>; + baikal,l2-data-latency = <2>; + }; +...
diff --git a/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.txt b/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.txt deleted file mode 100644 index 0496759..0000000 --- a/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.txt +++ /dev/null
@@ -1,16 +0,0 @@ -Calxeda DDR memory controller - -Properties: -- compatible : Should be: - - "calxeda,hb-ddr-ctrl" for ECX-1000 - - "calxeda,ecx-2000-ddr-ctrl" for ECX-2000 -- reg : Address and size for DDR controller registers. -- interrupts : Interrupt for DDR controller. - -Example: - - memory-controller@fff00000 { - compatible = "calxeda,hb-ddr-ctrl"; - reg = <0xfff00000 0x1000>; - interrupts = <0 91 4>; - };
diff --git a/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.yaml b/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.yaml new file mode 100644 index 0000000..96d563f --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.yaml
@@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/calxeda-ddr-ctrlr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Calxeda DDR memory controller binding + +description: | + The Calxeda DDR memory controller is initialised and programmed by the + firmware, but an OS might want to read its registers for error reporting + purposes and to learn about the DRAM topology. + +maintainers: + - Andre Przywara <andre.przywara@arm.com> + +properties: + compatible: + enum: + - calxeda,hb-ddr-ctrl + - calxeda,ecx-2000-ddr-ctrl + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + memory-controller@fff00000 { + compatible = "calxeda,hb-ddr-ctrl"; + reg = <0xfff00000 0x1000>; + interrupts = <0 91 4>; + };
diff --git a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml index cdfe3f7..637e24f 100644 --- a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml
@@ -51,9 +51,7 @@ maxItems: 1 reg-io-width: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [1, 2] + enum: [1, 2] description: Data width in bytes (1 or 2). If omitted, default of 1 is used. @@ -64,11 +62,10 @@ type: boolean samsung,srom-timing: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - items: - minItems: 6 - maxItems: 6 + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + minItems: 6 + maxItems: 6 description: | Array of 6 integers, specifying bank timings in the following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/imx8m-ddrc.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/imx8m-ddrc.yaml index c9e6c22..445e46f 100644 --- a/Documentation/devicetree/bindings/memory-controllers/fsl/imx8m-ddrc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/imx8m-ddrc.yaml
@@ -25,9 +25,9 @@ compatible: items: - enum: - - fsl,imx8mn-ddrc - - fsl,imx8mm-ddrc - - fsl,imx8mq-ddrc + - fsl,imx8mn-ddrc + - fsl,imx8mm-ddrc + - fsl,imx8mq-ddrc - const: fsl,imx8m-ddrc reg:
diff --git a/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt b/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt deleted file mode 100644 index 59b8dcc..0000000 --- a/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt +++ /dev/null
@@ -1,76 +0,0 @@ -* Ingenic JZ4780 NAND/external memory controller (NEMC) - -This file documents the device tree bindings for the NEMC external memory -controller in Ingenic JZ4780 - -Required properties: -- compatible: Should be set to one of: - "ingenic,jz4740-nemc" (JZ4740) - "ingenic,jz4780-nemc" (JZ4780) -- reg: Should specify the NEMC controller registers location and length. -- clocks: Clock for the NEMC controller. -- #address-cells: Must be set to 2. -- #size-cells: Must be set to 1. -- ranges: A set of ranges for each bank describing the physical memory layout. - Each should specify the following 4 integer values: - - <cs number> 0 <physical address of mapping> <size of mapping> - -Each child of the NEMC node describes a device connected to the NEMC. - -Required child node properties: -- reg: Should contain at least one register specifier, given in the following - format: - - <cs number> <offset> <size> - - Multiple registers can be specified across multiple banks. This is needed, - for example, for packaged NAND devices with multiple dies. Such devices - should be grouped into a single node. - -Optional child node properties: -- ingenic,nemc-bus-width: Specifies the bus width in bits. Defaults to 8 bits. -- ingenic,nemc-tAS: Address setup time in nanoseconds. -- ingenic,nemc-tAH: Address hold time in nanoseconds. -- ingenic,nemc-tBP: Burst pitch time in nanoseconds. -- ingenic,nemc-tAW: Access wait time in nanoseconds. -- ingenic,nemc-tSTRV: Static memory recovery time in nanoseconds. - -If a child node references multiple banks in its "reg" property, the same value -for all optional parameters will be configured for all banks. If any optional -parameters are omitted, they will be left unchanged from whatever they are -configured to when the NEMC device is probed (which may be the reset value as -given in the hardware reference manual, or a value configured by the boot -loader). - -Example (NEMC node with a NAND child device attached at CS1): - -nemc: nemc@13410000 { - compatible = "ingenic,jz4780-nemc"; - reg = <0x13410000 0x10000>; - - #address-cells = <2>; - #size-cells = <1>; - - ranges = <1 0 0x1b000000 0x1000000 - 2 0 0x1a000000 0x1000000 - 3 0 0x19000000 0x1000000 - 4 0 0x18000000 0x1000000 - 5 0 0x17000000 0x1000000 - 6 0 0x16000000 0x1000000>; - - clocks = <&cgu JZ4780_CLK_NEMC>; - - nand: nand@1 { - compatible = "ingenic,jz4780-nand"; - reg = <1 0 0x1000000>; - - ingenic,nemc-tAS = <10>; - ingenic,nemc-tAH = <5>; - ingenic,nemc-tBP = <10>; - ingenic,nemc-tAW = <15>; - ingenic,nemc-tSTRV = <100>; - - ... - }; -};
diff --git a/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml new file mode 100644 index 0000000..17ba45a --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml
@@ -0,0 +1,125 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ingenic,nemc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs NAND / External Memory Controller (NEMC) devicetree bindings + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +properties: + $nodename: + pattern: "^memory-controller@[0-9a-f]+$" + + compatible: + oneOf: + - enum: + - ingenic,jz4740-nemc + - ingenic,jz4780-nemc + - items: + - const: ingenic,jz4725b-nemc + - const: ingenic,jz4740-nemc + + "#address-cells": + const: 2 + + "#size-cells": + const: 1 + + ranges: true + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +patternProperties: + ".*@[0-9]+$": + type: object + properties: + reg: + minItems: 1 + maxItems: 255 + + ingenic,nemc-bus-width: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16] + description: Specifies the bus width in bits. + + ingenic,nemc-tAS: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Address setup time in nanoseconds. + + ingenic,nemc-tAH: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Address hold time in nanoseconds. + + ingenic,nemc-tBP: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Burst pitch time in nanoseconds. + + ingenic,nemc-tAW: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Address wait time in nanoseconds. + + ingenic,nemc-tSTRV: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Static memory recovery time in nanoseconds. + + required: + - reg + +required: + - compatible + - "#address-cells" + - "#size-cells" + - ranges + - reg + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/jz4780-cgu.h> + #include <dt-bindings/gpio/gpio.h> + nemc: memory-controller@13410000 { + compatible = "ingenic,jz4780-nemc"; + reg = <0x13410000 0x10000>; + #address-cells = <2>; + #size-cells = <1>; + ranges = <1 0 0x1b000000 0x1000000>, + <2 0 0x1a000000 0x1000000>, + <3 0 0x19000000 0x1000000>, + <4 0 0x18000000 0x1000000>, + <5 0 0x17000000 0x1000000>, + <6 0 0x16000000 0x1000000>; + + clocks = <&cgu JZ4780_CLK_NEMC>; + + ethernet@6 { + compatible = "davicom,dm9000"; + davicom,no-eeprom; + + pinctrl-names = "default"; + pinctrl-0 = <&pins_nemc_cs6>; + + reg = <6 0 1>, /* addr */ + <6 2 1>; /* data */ + + ingenic,nemc-tAS = <15>; + ingenic,nemc-tAH = <10>; + ingenic,nemc-tBP = <20>; + ingenic,nemc-tAW = <50>; + ingenic,nemc-tSTRV = <100>; + + reset-gpios = <&gpf 12 GPIO_ACTIVE_HIGH>; + vcc-supply = <ð0_power>; + + interrupt-parent = <&gpe>; + interrupts = <19 4>; + }; + };
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml index 3e0a8a9..278549f 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
@@ -73,10 +73,9 @@ timings nvidia,emc-auto-cal-interval: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 description: pad calibration interval in microseconds + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 2097151 @@ -136,11 +135,10 @@ value of the EMC_XM2DQSPADCTRL2 register for this set of timings nvidia,emc-zcal-cnt-long: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 description: number of EMC clocks to wait before issuing any commands after clock change + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1023 @@ -150,12 +148,11 @@ value of the EMC_ZCAL_INTERVAL register for this set of timings nvidia,emc-configuration: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array description: EMC timing characterization data. These are the registers (see section "15.6.2 EMC Registers" in the TRM) whose values need to be specified, according to the board documentation. + $ref: /schemas/types.yaml#/definitions/uint32-array items: - description: EMC_RC - description: EMC_RFC @@ -340,7 +337,7 @@ mc: memory-controller@70019000 { compatible = "nvidia,tegra124-mc"; - reg = <0x0 0x70019000 0x0 0x1000>; + reg = <0x70019000 0x1000>; clocks = <&tegra_car TEGRA124_CLK_MC>; clock-names = "mc"; @@ -352,7 +349,7 @@ external-memory-controller@7001b000 { compatible = "nvidia,tegra124-emc"; - reg = <0x0 0x7001b000 0x0 0x1000>; + reg = <0x7001b000 0x1000>; clocks = <&car TEGRA124_CLK_EMC>; clock-names = "emc";
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml index 22a94b6..84d0339 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
@@ -60,8 +60,7 @@ maximum: 1066000000 nvidia,emem-configuration: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array description: | Values to be written to the EMEM register block. See section "15.6.1 MC Registers" in the TRM. @@ -112,7 +111,7 @@ - | memory-controller@70019000 { compatible = "nvidia,tegra124-mc"; - reg = <0x0 0x70019000 0x0 0x1000>; + reg = <0x70019000 0x1000>; clocks = <&tegra_car 32>; clock-names = "mc";
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml new file mode 100644 index 0000000..49ab092 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
@@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/nvidia,tegra210-emc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra210 SoC External Memory Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: | + The EMC interfaces with the off-chip SDRAM to service the request stream + sent from the memory controller. + +properties: + compatible: + const: nvidia,tegra210-emc + + reg: + maxItems: 3 + + clocks: + items: + - description: external memory clock + + clock-names: + items: + - const: emc + + interrupts: + items: + - description: EMC general interrupt + + memory-region: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to a reserved memory region describing the table of EMC + frequencies trained by the firmware + + nvidia,memory-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle of the memory controller node + +required: + - compatible + - reg + - clocks + - clock-names + - nvidia,memory-controller + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra210-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + emc_table: emc-table@83400000 { + compatible = "nvidia,tegra210-emc-table"; + reg = <0x83400000 0x10000>; + }; + }; + + external-memory-controller@7001b000 { + compatible = "nvidia,tegra210-emc"; + reg = <0x7001b000 0x1000>, + <0x7001e000 0x1000>, + <0x7001f000 0x1000>; + clocks = <&tegra_car TEGRA210_CLK_EMC>; + clock-names = "emc"; + interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>; + memory-region = <&emc_table>; + nvidia,memory-controller = <&mc>; + };
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml index e4135ba..112bae2 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
@@ -56,10 +56,9 @@ maximum: 900000000 nvidia,emc-auto-cal-interval: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 description: Pad calibration interval in microseconds. + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 2097151 @@ -79,11 +78,10 @@ Mode Register 0. nvidia,emc-zcal-cnt-long: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 description: Number of EMC clocks to wait before issuing any commands after sending ZCAL_MRW_CMD. + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1023 @@ -98,12 +96,11 @@ FBIO "read" FIFO periodic resetting enabled. nvidia,emc-configuration: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array description: EMC timing characterization data. These are the registers (see section "18.13.2 EMC Registers" in the TRM) whose values need to be specified, according to the board documentation. + $ref: /schemas/types.yaml#/definitions/uint32-array items: - description: EMC_RC - description: EMC_RFC
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml index 4b9196c..84fd57b 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml
@@ -77,8 +77,7 @@ maximum: 900000000 nvidia,emem-configuration: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array description: | Values to be written to the EMEM register block. See section "18.13.1 MC Registers" in the TRM.
diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.txt b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.txt deleted file mode 100644 index 9f78e6c..0000000 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.txt +++ /dev/null
@@ -1,44 +0,0 @@ -DT bindings for Renesas R-Mobile and SH-Mobile memory controllers -================================================================= - -Renesas R-Mobile and SH-Mobile SoCs contain one or more memory controllers. -These memory controllers differ from one SoC variant to another, and are called -by different names ("DDR Bus Controller (DBSC)", "DDR3 Bus State Controller -(DBSC3)", "SDRAM Bus State Controller (SBSC)"). - -Currently memory controller device nodes are used only to reference PM -domains, and prevent these PM domains from being powered down, which would -crash the system. - -As there exist no actual drivers for these controllers yet, these bindings -should be considered EXPERIMENTAL for now. - -Required properties: - - compatible: Must be one of the following SoC-specific values: - - "renesas,dbsc-r8a73a4" (R-Mobile APE6) - - "renesas,dbsc3-r8a7740" (R-Mobile A1) - - "renesas,sbsc-sh73a0" (SH-Mobile AG5) - - reg: Must contain the base address and length of the memory controller's - registers. - -Optional properties: - - interrupts: Must contain a list of interrupt specifiers for memory - controller interrupts, if available. - - interrupt-names: Must contain a list of interrupt names corresponding to - the interrupts in the interrupts property, if available. - Valid interrupt names are: - - "sec" (secure interrupt) - - "temp" (normal (temperature) interrupt) - - power-domains: Must contain a reference to the PM domain that the memory - controller belongs to, if available. - -Example: - - sbsc1: memory-controller@fe400000 { - compatible = "renesas,sbsc-sh73a0"; - reg = <0xfe400000 0x400>; - interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>, - <0 36 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "sec", "temp"; - power-domains = <&pd_a4bc0>; - };
diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml new file mode 100644 index 0000000..7056ccb --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
@@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/memory-controllers/renesas,dbsc.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Renesas DDR Bus Controllers + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: | + Renesas SoCs contain one or more memory controllers. These memory + controllers differ from one SoC variant to another, and are called by + different names, e.g. "DDR Bus Controller (DBSC)", "DDR3 Bus State Controller + (DBSC3)", or "SDRAM Bus State Controller (SBSC)"). + +properties: + compatible: + enum: + - renesas,dbsc-r8a73a4 # R-Mobile APE6 + - renesas,dbsc3-r8a7740 # R-Mobile A1 + - renesas,sbsc-sh73a0 # SH-Mobile AG5 + + reg: + maxItems: 1 + + interrupts: + maxItems: 2 + + interrupt-names: + items: + - const: sec # secure interrupt + - const: temp # normal (temperature) interrupt + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - power-domains + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + sbsc1: memory-controller@fe400000 { + compatible = "renesas,sbsc-sh73a0"; + reg = <0xfe400000 0x400>; + interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "sec", "temp"; + power-domains = <&pd_a4bc0>; + };
diff --git a/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml b/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml index 39afacc..f591332 100644 --- a/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml +++ b/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml
@@ -31,19 +31,19 @@ description: A touchscreen is attached to the controller allwinner,tp-sensitive-adjust: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - maximum: 15 - default: 15 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + default: 15 + description: Sensitivity of pen down detection allwinner,filter-type: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - maximum: 3 - default: 1 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + default: 1 + description: | Select median and averaging filter. Sample used for median / averaging filter:
diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt deleted file mode 100644 index 148ef62..0000000 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ /dev/null
@@ -1,101 +0,0 @@ -Cirrus Logic/Wolfson Microelectronics Arizona class audio SoCs - -These devices are audio SoCs with extensive digital capabilities and a range -of analogue I/O. - -Required properties: - - - compatible : One of the following chip-specific strings: - "cirrus,cs47l24" - "wlf,wm5102" - "wlf,wm5110" - "wlf,wm8280" - "wlf,wm8997" - "wlf,wm8998" - "wlf,wm1814" - "wlf,wm1831" - - - reg : I2C slave address when connected using I2C, chip select number when - using SPI. - - - interrupts : The interrupt line the /IRQ signal for the device is - connected to. - - interrupt-controller : Arizona class devices contain interrupt controllers - and may provide interrupt services to other devices. - - #interrupt-cells: the number of cells to describe an IRQ, this should be 2. - The first cell is the IRQ number. - The second cell is the flags, encoded as the trigger masks from - Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - - - gpio-controller : Indicates this device is a GPIO controller. - - #gpio-cells : Must be 2. The first cell is the pin number and the - second cell is used to specify optional parameters, see ../gpio/gpio.txt - for details. - - - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the device, - as covered in Documentation/devicetree/bindings/regulator/regulator.txt - - - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102, - wm5110, wm8280, wm8998, wm1814) - - - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102, - wm5110, wm8280, wm8998, wm1814) - - - SPKVDD-supply : Speaker driver power supply (wm8997) - - - DCVDD-supply : Main power supply (cs47l24, wm1831) - - - MICVDD-supply : Microphone power supply (cs47l24, wm1831) - -Optional properties: - - - reset-gpios : GPIO specifier for the GPIO controlling /RESET - - - clocks: Should reference the clocks supplied on MCLK1 and MCLK2 - - clock-names: Should contains two strings: - "mclk1" for the clock supplied on MCLK1, recommended to be a high - quality audio reference clock - "mclk2" for the clock supplied on MCLK2, recommended to be an always on - 32k clock - - - wlf,gpio-defaults : A list of GPIO configuration register values. Defines - for the appropriate values can found in <dt-bindings/mfd/arizona.txt>. If - absent, no configuration of these registers is performed. If any entry has - a value that is out of range for a 16 bit register then the chip default - will be used. If present exactly five values must be specified. - - - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if - they are being externally supplied. As covered in - Documentation/devicetree/bindings/regulator/regulator.txt - (wm5102, wm5110, wm8280, wm8997, wm8998, wm1814) - -Deprecated properties: - - - wlf,reset : GPIO specifier for the GPIO controlling /RESET - -Also see child specific device properties: - Regulator - ../regulator/arizona-regulator.txt - Extcon - ../extcon/extcon-arizona.txt - Sound - ../sound/wlf,arizona.txt - -Example: - -codec: wm5102@1a { - compatible = "wlf,wm5102"; - reg = <0x1a>; - interrupts = <347>; - interrupt-controller; - #interrupt-cells = <2>; - interrupt-parent = <&gic>; - - gpio-controller; - #gpio-cells = <2>; - - wlf,gpio-defaults = < - ARIZONA_GP_FN_TXLRCLK - ARIZONA_GP_DEFAULT - ARIZONA_GP_DEFAULT - ARIZONA_GP_DEFAULT - ARIZONA_GP_DEFAULT - >; -};
diff --git a/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.txt b/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.txt deleted file mode 100644 index 3bf92ad3..0000000 --- a/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.txt +++ /dev/null
@@ -1,85 +0,0 @@ -Cirrus Logic Lochnagar Audio Development Board - -Lochnagar is an evaluation and development board for Cirrus Logic -Smart CODEC and Amp devices. It allows the connection of most Cirrus -Logic devices on mini-cards, as well as allowing connection of -various application processor systems to provide a full evaluation -platform. Audio system topology, clocking and power can all be -controlled through the Lochnagar, allowing the device under test -to be used in a variety of possible use cases. - -Also see these documents for generic binding information: - [1] GPIO : ../gpio/gpio.txt - -And these for relevant defines: - [2] include/dt-bindings/pinctrl/lochnagar.h - [3] include/dt-bindings/clock/lochnagar.h - -And these documents for the required sub-node binding details: - [4] Clock: ../clock/cirrus,lochnagar.txt - [5] Pinctrl: ../pinctrl/cirrus,lochnagar.txt - [6] Regulator: ../regulator/cirrus,lochnagar.txt - [7] Sound: ../sound/cirrus,lochnagar.txt - [8] Hardware Monitor: ../hwmon/cirrus,lochnagar.txt - -Required properties: - - - compatible : One of the following strings: - "cirrus,lochnagar1" - "cirrus,lochnagar2" - - - reg : I2C slave address - - - reset-gpios : Reset line to the Lochnagar, see [1]. - -Required sub-nodes: - - - lochnagar-clk : Binding for the clocking components, see [4]. - - - lochnagar-pinctrl : Binding for the pin control components, see [5]. - -Optional sub-nodes: - - - Bindings for the regulator components, see [6]. Only available on - Lochnagar 2. - - - lochnagar-sc : Binding for the sound card components, see [7]. - Only available on Lochnagar 2. - - lochnagar-hwmon : Binding for the hardware monitor components, see [8]. - Only available on Lochnagar 2. - -Optional properties: - - - present-gpios : Host present line, indicating the presence of a - host system, see [1]. This can be omitted if the present line is - tied in hardware. - -Example: - -lochnagar: lochnagar@22 { - compatible = "cirrus,lochnagar2"; - reg = <0x22>; - - reset-gpios = <&gpio0 55 0>; - present-gpios = <&gpio0 60 0>; - - lochnagar-clk { - compatible = "cirrus,lochnagar2-clk"; - ... - }; - - lochnagar-pinctrl { - compatible = "cirrus,lochnagar-pinctrl"; - ... - }; - - lochnagar-sc { - compatible = "cirrus,lochnagar2-soundcard"; - ... - }; - - lochnagar-hwmon { - compatible = "cirrus,lochnagar2-hwmon"; - ... - }; -};
diff --git a/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml new file mode 100644 index 0000000..7a61657 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml
@@ -0,0 +1,352 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/cirrus,lochnagar.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic Lochnagar Audio Development Board + +maintainers: + - patches@opensource.cirrus.com + +description: | + Lochnagar is an evaluation and development board for Cirrus Logic + Smart CODEC and Amp devices. It allows the connection of most Cirrus + Logic devices on mini-cards, as well as allowing connection of + various application processor systems to provide a full evaluation + platform. Audio system topology, clocking and power can all be + controlled through the Lochnagar, allowing the device under test + to be used in a variety of possible use cases. + + Also see these documents for generic binding information: + [1] GPIO : ../gpio/gpio.txt + + And these for relevant defines: + [2] include/dt-bindings/pinctrl/lochnagar.h + [3] include/dt-bindings/clock/lochnagar.h + + And these documents for the required sub-node binding details: + [4] Clock: ../clock/cirrus,lochnagar.yaml + [5] Pinctrl: ../pinctrl/cirrus,lochnagar.yaml + [6] Sound: ../sound/cirrus,lochnagar.yaml + [7] Hardware Monitor: ../hwmon/cirrus,lochnagar.yaml + +allOf: + - if: + properties: + compatible: + enum: + - cirrus,lochnagar2 + then: + properties: + lochnagar-hwmon: + type: object + $ref: /schemas/hwmon/cirrus,lochnagar.yaml# + + lochnagar-sc: + type: object + $ref: /schemas/sound/cirrus,lochnagar.yaml# + +properties: + compatible: + enum: + - cirrus,lochnagar1 + - cirrus,lochnagar2 + + reg: + const: 0x22 + + reset-gpios: + maxItems: 1 + + present-gpios: + description: | + Host present line, indicating the presence of a + host system, see [1]. This can be omitted if the present line is + tied in hardware. + maxItems: 1 + + lochnagar-clk: + type: object + $ref: /schemas/clock/cirrus,lochnagar.yaml# + + lochnagar-pmic32k: + type: object + $ref: /schemas/clock/fixed-clock.yaml# + properties: + clock-frequency: + const: 32768 + + lochnagar-clk12m: + type: object + $ref: /schemas/clock/fixed-clock.yaml# + properties: + clock-frequency: + const: 12288000 + + lochnagar-clk11m: + type: object + $ref: /schemas/clock/fixed-clock.yaml# + properties: + clock-frequency: + const: 11298600 + + lochnagar-clk24m: + type: object + $ref: /schemas/clock/fixed-clock.yaml# + properties: + clock-frequency: + const: 24576000 + + lochnagar-clk22m: + type: object + $ref: /schemas/clock/fixed-clock.yaml# + properties: + clock-frequency: + const: 22579200 + + lochnagar-clk8m: + type: object + $ref: /schemas/clock/fixed-clock.yaml# + properties: + clock-frequency: + const: 8192000 + + lochnagar-usb24m: + type: object + $ref: /schemas/clock/fixed-clock.yaml# + properties: + clock-frequency: + const: 24576000 + + lochnagar-usb12m: + type: object + $ref: /schemas/clock/fixed-clock.yaml# + properties: + clock-frequency: + const: 12288000 + + lochnagar-pinctrl: + type: object + $ref: /schemas/pinctrl/cirrus,lochnagar.yaml# + + VDDCORE: + description: + Initialisation data for the VDDCORE regulator, which supplies the + CODECs digital core if not being provided by an internal regulator. + type: object + $ref: /schemas/regulator/regulator.yaml# + properties: + compatible: + enum: + - cirrus,lochnagar2-vddcore + + SYSVDD-supply: + description: + Primary power supply for the Lochnagar. + required: + - compatible + + MICVDD: + description: + Initialisation data for the MICVDD regulator, which supplies the + CODECs MICVDD. + type: object + $ref: /schemas/regulator/regulator.yaml# + properties: + compatible: + enum: + - cirrus,lochnagar2-micvdd + + SYSVDD-supply: + description: + Primary power supply for the Lochnagar. + required: + - compatible + + MIC1VDD: + description: + Initialisation data for the MIC1VDD supplies. + type: object + $ref: /schemas/regulator/regulator.yaml# + properties: + compatible: + enum: + - cirrus,lochnagar2-mic1vdd + + cirrus,micbias-input: + description: + A property selecting which of the CODEC minicard micbias outputs + should be used. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 4 + + MICBIAS1-supply: + description: + Regulator supplies for the MIC1VDD outputs, supplying the digital + microphones, normally supplied from the attached CODEC. + required: + - compatible + + MIC2VDD: + description: + Initialisation data for the MIC2VDD supplies. + type: object + $ref: /schemas/regulator/regulator.yaml# + properties: + compatible: + enum: + - cirrus,lochnagar2-mic2vdd + + cirrus,micbias-input: + description: + A property selecting which of the CODEC minicard micbias outputs + should be used. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 4 + + MICBIAS2-supply: + description: + Regulator supplies for the MIC2VDD outputs, supplying the digital + microphones, normally supplied from the attached CODEC. + required: + - compatible + + VDD1V8: + description: + Recommended fixed regulator for the VDD1V8 regulator, which supplies + the CODECs analog and 1.8V digital supplies. + type: object + $ref: /schemas/regulator/regulator.yaml# + properties: + compatible: + enum: + - regulator-fixed + + regulator-min-microvolt: + const: 1800000 + + regulator-max-microvolt: + const: 1800000 + + vin-supply: + description: + Should be set to same supply as SYSVDD + required: + - compatible + - regulator-min-microvolt + - regulator-max-microvolt + - regulator-boot-on + - regulator-always-on + - vin-supply + +required: + - compatible + - reg + - reset-gpios + - lochnagar-clk + - lochnagar-pinctrl + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clk/lochnagar.h> + #include <dt-bindings/pinctrl/lochnagar.h> + i2c@e0004000 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0xe0004000 0x1000>; + + lochnagar: lochnagar@22 { + compatible = "cirrus,lochnagar2"; + reg = <0x22>; + + reset-gpios = <&gpio0 55 0>; + present-gpios = <&gpio0 60 0>; + + lochnagarclk: lochnagar-clk { + compatible = "cirrus,lochnagar2-clk"; + + #clock-cells = <1>; + clocks = <&clkaudio>, <&clkpmic>; + clock-names = "ln-gf-mclk2", "ln-pmic-32k"; + + assigned-clocks = <&lochnagarclk LOCHNAGAR_CDC_MCLK1>, + <&lochnagarclk LOCHNAGAR_CDC_MCLK2>; + assigned-clock-parents = <&clkaudio>, <&clkpmic>; + }; + + clkpmic: lochnagar-pmic32k { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + }; + + lochnagar-pinctrl { + compatible = "cirrus,lochnagar-pinctrl"; + + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&lochnagar 0 0 LOCHNAGAR2_PIN_NUM_GPIOS>; + + pinctrl-names = "default"; + pinctrl-0 = <&pinsettings>; + + pinsettings: pin-settings { + ap2aif-pins { + input-enable; + groups = "gf-aif1"; + function = "codec-aif3"; + }; + codec2aif-pins { + output-enable; + groups = "codec-aif3"; + function = "gf-aif1"; + }; + }; + }; + + lochnagar-sc { + compatible = "cirrus,lochnagar2-soundcard"; + + #sound-dai-cells = <1>; + + clocks = <&lochnagarclk LOCHNAGAR_SOUNDCARD_MCLK>; + clock-names = "mclk"; + }; + + lochnagar-hwmon { + compatible = "cirrus,lochnagar2-hwmon"; + }; + + MIC1VDD { + compatible = "cirrus,lochnagar2-mic1vdd"; + + cirrus,micbias-input = <3>; + }; + + MICVDD { + compatible = "cirrus,lochnagar2-micvdd"; + + SYSVDD-supply = <&wallvdd>; + + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + + VDD1V8 { + compatible = "regulator-fixed"; + + regulator-name = "VDD1V8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-boot-on; + regulator-always-on; + + vin-supply = <&wallvdd>; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/mfd/cirrus,madera.yaml b/Documentation/devicetree/bindings/mfd/cirrus,madera.yaml new file mode 100644 index 0000000..a5531f6 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/cirrus,madera.yaml
@@ -0,0 +1,299 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/cirrus,madera.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic Madera class audio CODECs Multi-Functional Device + +maintainers: + - patches@opensource.cirrus.com + +description: | + These devices are audio SoCs with extensive digital capabilities and a range + of analogue I/O. + + See also the child driver bindings in: + + bindings/pinctrl/cirrus,madera.yaml + bindings/regulator/wlf,arizona.yaml + bindings/sound/cirrus,madera.yaml + +allOf: + - $ref: /schemas/pinctrl/cirrus,madera.yaml# + - $ref: /schemas/regulator/wlf,arizona.yaml# + - $ref: /schemas/sound/cirrus,madera.yaml# + - if: + properties: + compatible: + contains: + enum: + - cirrus,cs47l85 + - wlf,wm1840 + then: + properties: + SPKVDDL-supply: + description: + Left speaker driver power supply. + + SPKVDDR-supply: + description: + Right speaker driver power supply. + + required: + - SPKVDDL-supply + - SPKVDDR-supply + else: + required: + - DCVDD-supply + - if: + properties: + compatible: + contains: + enum: + - cirrus,cs47l15 + - cirrus,cs47l35 + then: + properties: + SPKVDD-supply: + description: + Mono speaker driver power supply. + + required: + - SPKVDD-supply + - if: + properties: + compatible: + contains: + enum: + - cirrus,cs47l35 + - cirrus,cs47l85 + - cirrus,cs47l90 + - cirrus,cs47l91 + - wlf,wm1840 + then: + properties: + DBVDD2-supply: + description: + Databus power supply. + + required: + - DBVDD2-supply + - if: + properties: + compatible: + contains: + enum: + - cirrus,cs47l85 + - cirrus,cs47l90 + - cirrus,cs47l91 + - wlf,wm1840 + then: + properties: + DBVDD3-supply: + description: + Databus power supply. + + DBVDD4-supply: + description: + Databus power supply. + - if: + properties: + compatible: + contains: + enum: + - cirrus,cs47l15 + then: + required: + - MICVDD-supply + else: + properties: + CPVDD2-supply: + description: + Secondary charge pump power supply. + + required: + - CPVDD2-supply + +properties: + compatible: + enum: + - cirrus,cs47l15 + - cirrus,cs47l35 + - cirrus,cs47l85 + - cirrus,cs47l90 + - cirrus,cs47l91 + - cirrus,cs42l92 + - cirrus,cs47l92 + - cirrus,cs47l93 + - cirrus,wm1840 + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + description: + The first cell is the pin number. The second cell is reserved for + future use and must be zero + const: 2 + + interrupt-controller: true + + '#interrupt-cells': + description: + The first cell is the IRQ number. + The second cell is the flags, encoded as the trigger masks from + bindings/interrupt-controller/interrupts.txt + const: 2 + + interrupts: + maxItems: 1 + + reset-gpios: + description: + One entry specifying the GPIO controlling /RESET. As defined in + bindings/gpio.txt. Although optional, it is strongly recommended + to use a hardware reset. + maxItems: 1 + + clocks: + description: + Should reference the clocks supplied on MCLK1, MCLK2 and MCLK3. + minItems: 1 + maxItems: 3 + + clock-names: + description: | + May contain up to three strings: + "mclk1" For the clock supplied on MCLK1, recommended to be a + high quality audio reference clock. + "mclk2" For the clock supplied on MCLK2, required to be an + always on 32k clock. + "mclk3" For the clock supplied on MCLK3. + oneOf: + - items: + - const: mclk1 + - items: + - const: mclk2 + - items: + - const: mclk3 + - items: + - const: mclk1 + - const: mclk2 + - items: + - const: mclk1 + - const: mclk3 + - items: + - const: mclk2 + - const: mclk3 + - items: + - const: mclk1 + - const: mclk2 + - const: mclk3 + + AVDD-supply: + description: + Analogue power supply. + + DBVDD1-supply: + description: + Databus power supply. + + CPVDD1-supply: + description: + Charge pump power supply. + + DCVDD-supply: + description: + Digital power supply, optional on CS47L85, WM1840 where it can + be supplied internally. + + MICVDD-supply: + description: + Microphone power supply, normally supplied internally except on + cs47l24, wm1831 where it is mandatory. + +required: + - compatible + - gpio-controller + - '#gpio-cells' + - interrupt-controller + - '#interrupt-cells' + - interrupt-parent + - interrupts + - AVDD-supply + - DBVDD1-supply + - CPVDD1-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/sound/madera.h> + i2c@e0004000 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0xe0004000 0x1000>; + + cs47l85: codec@1a { + compatible = "cirrus,cs47l85"; + reg = <0x1a>; + + reset-gpios = <&gpio 0>; + wlf,ldoena = <&gpio 1>; + + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <&host_irq1>; + interrupt-parent = <&gic>; + + gpio-controller; + #gpio-cells = <2>; + + AVDD-supply = <&vdd1v8>; + DBVDD1-supply = <&vdd1v8>; + DBVDD2-supply = <&vdd1v8>; + DBVDD3-supply = <&vdd1v8>; + DBVDD4-supply = <&vdd1v8>; + CPVDD1-supply = <&vdd1v8>; + CPVDD2-supply = <&vdd1v2>; + SPKVDDL-supply = <&vdd5v>; + SPKVDDR-supply = <&vdd5v>; + + clocks = <&clks 0>, <&clks 1>, <&clks 2>; + clock-names = "mclk1", "mclk2", "mclk3"; + + cirrus,dmic-ref = <0 0 MADERA_DMIC_REF_MICBIAS1>; + cirrus,inmode = < + MADERA_INMODE_SE MADERA_INMODE_SE + MADERA_INMODE_SE MADERA_INMODE_SE + MADERA_INMODE_DIFF MADERA_INMODE_DIFF + >; + cirrus,max-channels-clocked = <2 0 0>; + + pinctrl-names = "default"; + pinctrl-0 = <&pinsettings>; + + pinsettings: pin-settings { + aif1-pins { + groups = "aif1"; + function = "aif1"; + bias-bus-hold; + }; + + aif2-pins { + groups = "aif2"; + function = "aif2"; + bias-bus-hold; + }; + + aif3-pins { + groups = "aif3"; + function = "aif3"; + bias-bus-hold; + }; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml new file mode 100644 index 0000000..487a844 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
@@ -0,0 +1,196 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/gateworks-gsc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Gateworks System Controller + +description: | + The Gateworks System Controller (GSC) is a device present across various + Gateworks product families that provides a set of system related features + such as the following (refer to the board hardware user manuals to see what + features are present) + - Watchdog Timer + - GPIO + - Pushbutton controller + - Hardware monitor with ADC's for temperature and voltage rails and + fan controller + +maintainers: + - Tim Harvey <tharvey@gateworks.com> + - Robert Jones <rjones@gateworks.com> + +properties: + $nodename: + pattern: "gsc@[0-9a-f]{1,2}" + compatible: + const: gw,gsc + + reg: + description: I2C device address + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + adc: + type: object + description: Optional hardware monitoring module + + properties: + compatible: + const: gw,gsc-adc + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + "^channel@[0-9]+$": + type: object + description: | + Properties for a single ADC which can report cooked values + (i.e. temperature sensor based on thermister), raw values + (i.e. voltage rail with a pre-scaling resistor divider). + + properties: + reg: + description: Register of the ADC + maxItems: 1 + + label: + description: Name of the ADC input + + gw,mode: + description: | + conversion mode: + 0 - temperature, in C*10 + 1 - pre-scaled voltage value + 2 - scaled voltage based on an optional resistor divider + and optional offset + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + + gw,voltage-divider-ohms: + description: Values of resistors for divider on raw ADC input + maxItems: 2 + items: + minimum: 1000 + maximum: 1000000 + + gw,voltage-offset-microvolt: + description: | + A positive voltage offset to apply to a raw ADC + (i.e. to compensate for a diode drop). + minimum: 0 + maximum: 1000000 + + required: + - gw,mode + - reg + - label + + required: + - compatible + - "#address-cells" + - "#size-cells" + +patternProperties: + "^fan-controller@[0-9a-f]+$": + type: object + description: Optional fan controller + + properties: + compatible: + const: gw,gsc-fan + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + reg: + description: The fan controller base address + maxItems: 1 + + required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - "#interrupt-cells" + - "#address-cells" + - "#size-cells" + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + gsc@20 { + compatible = "gw,gsc"; + reg = <0x20>; + interrupt-parent = <&gpio1>; + interrupts = <4 GPIO_ACTIVE_LOW>; + interrupt-controller; + #interrupt-cells = <1>; + #address-cells = <1>; + #size-cells = <0>; + + adc { + compatible = "gw,gsc-adc"; + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { /* A0: Board Temperature */ + reg = <0x00>; + label = "temp"; + gw,mode = <0>; + }; + + channel@2 { /* A1: Input Voltage (raw ADC) */ + reg = <0x02>; + label = "vdd_vin"; + gw,mode = <1>; + gw,voltage-divider-ohms = <22100 1000>; + gw,voltage-offset-microvolt = <800000>; + }; + + channel@b { /* A2: Battery voltage */ + reg = <0x0b>; + label = "vdd_bat"; + gw,mode = <1>; + }; + }; + + fan-controller@2c { + #address-cells = <1>; + #size-cells = <0>; + compatible = "gw,gsc-fan"; + reg = <0x2c>; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/mfd/madera.txt b/Documentation/devicetree/bindings/mfd/madera.txt deleted file mode 100644 index 47e2b8b..0000000 --- a/Documentation/devicetree/bindings/mfd/madera.txt +++ /dev/null
@@ -1,114 +0,0 @@ -Cirrus Logic Madera class audio codecs Multi-Functional Device - -These devices are audio SoCs with extensive digital capabilities and a range -of analogue I/O. - -See also the child driver bindings in: -bindings/pinctrl/cirrus,madera-pinctrl.txt -bindings/regulator/arizona-regulator.txt -bindings/sound/madera.txt - -Required properties: - - - compatible : One of the following chip-specific strings: - "cirrus,cs47l15" - "cirrus,cs47l35" - "cirrus,cs47l85" - "cirrus,cs47l90" - "cirrus,cs47l91" - "cirrus,cs42l92" - "cirrus,cs47l92" - "cirrus,cs47l93" - "cirrus,wm1840" - - - reg : I2C slave address when connected using I2C, chip select number when - using SPI. - - - DCVDD-supply : Power supply for the device as defined in - bindings/regulator/regulator.txt - Mandatory on CS47L15, CS47L35, CS47L90, CS47L91, CS42L92, CS47L92, CS47L93 - Optional on CS47L85, WM1840 - - - AVDD-supply, DBVDD1-supply, DBVDD2-supply, CPVDD1-supply, CPVDD2-supply : - Power supplies for the device - - - DBVDD3-supply, DBVDD4-supply : Power supplies for the device - (CS47L85, CS47L90, CS47L91, WM1840) - - - SPKVDDL-supply, SPKVDDR-supply : Power supplies for the device - (CS47L85, WM1840) - - - SPKVDD-supply : Power supply for the device - (CS47L15, CS47L35) - - - interrupt-controller : Indicates that this device is an interrupt controller - - - #interrupt-cells: the number of cells to describe an IRQ, must be 2. - The first cell is the IRQ number. - The second cell is the flags, encoded as the trigger masks from - bindings/interrupt-controller/interrupts.txt - - - gpio-controller : Indicates this device is a GPIO controller. - - - #gpio-cells : Must be 2. The first cell is the pin number. The second cell - is reserved for future use and must be zero - - - interrupt-parent : The parent interrupt controller. - - - interrupts : The interrupt line the /IRQ signal for the device is - connected to. - -Optional properties: - - - MICVDD-supply : Power supply, only need to be specified if - powered externally - - - reset-gpios : One entry specifying the GPIO controlling /RESET. - As defined in bindings/gpio.txt. - Although optional, it is strongly recommended to use a hardware reset - - - clocks: Should reference the clocks supplied on MCLK1, MCLK2 and MCLK3 - - clock-names: May contain up to three strings: - "mclk1" for the clock supplied on MCLK1, recommended to be a high - quality audio reference clock - "mclk2" for the clock supplied on MCLK2, required to be an always on - 32k clock - "mclk3" for the clock supplied on MCLK3 - - - MICBIASx : Initial data for the MICBIAS regulators, as covered in - Documentation/devicetree/bindings/regulator/regulator.txt. - One for each MICBIAS generator (MICBIAS1, MICBIAS2, ...) - (all codecs) - - One for each output pin (MICBIAS1A, MIBCIAS1B, MICBIAS2A, ...) - (all except CS47L85, WM1840) - - The following following additional property is supported for the generator - nodes: - - cirrus,ext-cap : Set to 1 if the MICBIAS has external decoupling - capacitors attached. - -Optional child nodes: - micvdd : Node containing initialization data for the micvdd regulator - See bindings/regulator/arizona-regulator.txt - - ldo1 : Node containing initialization data for the LDO1 regulator - See bindings/regulator/arizona-regulator.txt - (cs47l85, wm1840) - -Example: - -cs47l85@0 { - compatible = "cirrus,cs47l85"; - reg = <0>; - - reset-gpios = <&gpio 0>; - - interrupt-controller; - #interrupt-cells = <2>; - interrupts = <&host_irq1>; - interrupt-parent = <&gic>; - - gpio-controller; - #gpio-cells = <2>; -};
diff --git a/Documentation/devicetree/bindings/mfd/max8998.txt b/Documentation/devicetree/bindings/mfd/max8998.txt index 5f2f07c..4ed5218 100644 --- a/Documentation/devicetree/bindings/mfd/max8998.txt +++ b/Documentation/devicetree/bindings/mfd/max8998.txt
@@ -73,6 +73,8 @@ - ESAFEOUT1: (ldo19) - ESAFEOUT2: (ld020) + - CHARGER: main battery charger current control + Standard regulator bindings are used inside regulator subnodes. Check Documentation/devicetree/bindings/regulator/regulator.txt for more details. @@ -113,5 +115,11 @@ regulator-always-on; regulator-boot-on; }; + + charger_reg: CHARGER { + regulator-name = "CHARGER"; + regulator-min-microamp = <90000>; + regulator-max-microamp = <800000>; + }; }; };
diff --git a/Documentation/devicetree/bindings/mfd/mps,mp2629.yaml b/Documentation/devicetree/bindings/mfd/mps,mp2629.yaml new file mode 100644 index 0000000..f91acc4 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/mps,mp2629.yaml
@@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/mps,mp2629.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MP2629 Battery Charger PMIC from Monolithic Power System. + +maintainers: + - Saravanan Sekar <sravanhome@gmail.com> + +description: | + MP2629 is a PMIC providing battery charging and power supply for smartphones, + wireless camera and portable devices. Chip is controlled over I2C. + + The battery charge management device handles battery charger controller and + ADC IIO device for battery, system voltage + +properties: + compatible: + const: mps,mp2629 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + description: + The first cell is the IRQ number, the second cell is the trigger type. + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - "#interrupt-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/input/linux-event-codes.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@4b { + compatible = "mps,mp2629"; + reg = <0x4b>; + + interrupt-controller; + interrupt-parent = <&gpio2>; + #interrupt-cells = <2>; + interrupts = <3 IRQ_TYPE_LEVEL_HIGH>; + }; + };
diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt index a9b105a..2661775 100644 --- a/Documentation/devicetree/bindings/mfd/mt6397.txt +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
@@ -18,24 +18,30 @@ This document describes the binding for MFD device and its sub module. Required properties: -compatible: "mediatek,mt6397" or "mediatek,mt6323" +compatible: + "mediatek,mt6323" for PMIC MT6323 + "mediatek,mt6358" for PMIC MT6358 + "mediatek,mt6397" for PMIC MT6397 Optional subnodes: - rtc Required properties: Should be one of follows - compatible: "mediatek,mt6323-rtc" + - compatible: "mediatek,mt6358-rtc" - compatible: "mediatek,mt6397-rtc" For details, see ../rtc/rtc-mt6397.txt - regulators Required properties: - - compatible: "mediatek,mt6397-regulator" - see ../regulator/mt6397-regulator.txt - compatible: "mediatek,mt6323-regulator" see ../regulator/mt6323-regulator.txt + - compatible: "mediatek,mt6358-regulator" + see ../regulator/mt6358-regulator.txt + - compatible: "mediatek,mt6397-regulator" + see ../regulator/mt6397-regulator.txt - codec Required properties: - - compatible: "mediatek,mt6397-codec" + - compatible: "mediatek,mt6397-codec" or "mediatek,mt6358-sound" - clk Required properties: - compatible: "mediatek,mt6397-clk" @@ -54,6 +60,11 @@ - compatible: "mediatek,mt6323-pwrc" For details, see ../power/reset/mt6323-poweroff.txt +- pin-controller + Required properties: + - compatible: "mediatek,mt6397-pinctrl" + For details, see ../pinctrl/pinctrl-mt65xx.txt + Example: pwrap: pwrap@1000f000 { compatible = "mediatek,mt8135-pwrap";
diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml index ddf190c..e675611f 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml
@@ -66,8 +66,8 @@ reg: description: Identify trigger hardware block. items: - minimum: 0 - maximum: 2 + minimum: 0 + maximum: 2 required: - compatible
diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml index 590849e..f212fc6 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
@@ -67,23 +67,22 @@ description: One or two <index level filter> to describe break input configurations. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-matrix - - items: - items: - - description: | - "index" indicates on which break input (0 or 1) the - configuration should be applied. - enum: [ 0 , 1] - - description: | - "level" gives the active level (0=low or 1=high) of the - input signal for this configuration - enum: [ 0, 1 ] - - description: | - "filter" gives the filtering value (up to 15) to be applied. - maximum: 15 - minItems: 1 - maxItems: 2 + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "index" indicates on which break input (0 or 1) the + configuration should be applied. + enum: [0, 1] + - description: | + "level" gives the active level (0=low or 1=high) of the + input signal for this configuration + enum: [0, 1] + - description: | + "filter" gives the filtering value (up to 15) to be applied. + maximum: 15 + minItems: 1 + maxItems: 2 required: - "#pwm-cells" @@ -102,8 +101,8 @@ reg: description: Identify trigger hardware block. items: - minimum: 0 - maximum: 16 + minimum: 0 + maximum: 16 required: - compatible
diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml index f88d13d..dd995d7 100644 --- a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
@@ -29,8 +29,7 @@ onkey: type: object - allOf: - - $ref: ../input/input.yaml + $ref: ../input/input.yaml properties: compatible: @@ -68,8 +67,7 @@ watchdog: type: object - allOf: - - $ref: ../watchdog/watchdog.yaml + $ref: ../watchdog/watchdog.yaml properties: compatible: @@ -190,8 +188,7 @@ description: STPMIC1 voltage regulators supplies "^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])$": - allOf: - - $ref: ../regulator/regulator.yaml + $ref: ../regulator/regulator.yaml "^ldo[1-2,5-6]$": type: object @@ -259,8 +256,6 @@ additionalProperties: false - additionalProperties: false - additionalProperties: false required:
diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index 39375e4..19bdaf7 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -33,13 +33,13 @@ compatible: anyOf: - items: - - enum: - - allwinner,sun8i-a83t-system-controller - - allwinner,sun8i-h3-system-controller - - allwinner,sun8i-v3s-system-controller - - allwinner,sun50i-a64-system-controller + - enum: + - allwinner,sun8i-a83t-system-controller + - allwinner,sun8i-h3-system-controller + - allwinner,sun8i-v3s-system-controller + - allwinner,sun50i-a64-system-controller - - const: syscon + - const: syscon - contains: const: syscon @@ -52,9 +52,8 @@ description: | The size (in bytes) of the IO accesses that should be performed on the device. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 1, 2, 4, 8 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8] hwlocks: maxItems: 1
diff --git a/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml b/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml new file mode 100644 index 0000000..4c0106c --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml
@@ -0,0 +1,280 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/wlf,arizona.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic/Wolfson Microelectronics Arizona class audio SoCs + +maintainers: + - patches@opensource.cirrus.com + +description: | + These devices are audio SoCs with extensive digital capabilities and a + range of analogue I/O. + +allOf: + - $ref: /schemas/sound/wlf,arizona.yaml# + - $ref: /schemas/regulator/wlf,arizona.yaml# + - $ref: /schemas/extcon/wlf,arizona.yaml# + - if: + properties: + compatible: + contains: + enum: + - cirrus,cs47l24 + - wlf,wm1831 + then: + required: + - DCVDD-supply + - MICVDD-supply + else: + properties: + LDOVDD-supply: + description: + Digital power supply, used internally to generate DCVDD when + internally supplied. + + - if: + properties: + compatible: + contains: + enum: + - wlf,wm1814 + - wlf,wm5102 + - wlf,wm5110 + - wlf,wm8280 + - wlf,wm8997 + - wlf,wm8998 + then: + properties: + DBVDD2-supply: + description: + Databus power supply. + + required: + - DBVDD2-supply + - if: + properties: + compatible: + contains: + enum: + - wlf,wm1814 + - wlf,wm5102 + - wlf,wm5110 + - wlf,wm8280 + - wlf,wm8998 + then: + properties: + DBVDD3-supply: + description: + Databus power supply. + + required: + - DBVDD3-supply + - if: + properties: + compatible: + contains: + enum: + - cirrus,cs47l24 + - wlf,wm1831 + - wlf,wm8997 + then: + properties: + SPKVDD-supply: + description: + Mono speaker driver power supply. + + required: + - SPKVDD-supply + else: + properties: + SPKVDDL-supply: + description: + Left speaker driver power supply. + + SPKVDDR-supply: + description: + Right speaker driver power supply. + + required: + - SPKVDDL-supply + - SPKVDDR-supply + +properties: + compatible: + enum: + - cirrus,cs47l24 + - wlf,wm1814 + - wlf,wm1831 + - wlf,wm5102 + - wlf,wm5110 + - wlf,wm8280 + - wlf,wm8997 + - wlf,wm8998 + + reg: + maxItems: 1 + + AVDD-supply: + description: + Analogue power supply. + + CPVDD-supply: + description: + Charge pump power supply. + + DBVDD1-supply: + description: + Databus power supply. + + DCVDD-supply: + description: + Digital power supply, normally supplied internally except on cs47l24, + wm1831 where it is mandatory. + + MICVDD-supply: + description: + Microphone power supply, normally supplied internally except on + cs47l24, wm1831 where it is mandatory. + + gpio-controller: true + + '#gpio-cells': + description: + The first cell is the pin number and the second cell is used to + specify optional parameters. + const: 2 + + wlf,gpio-defaults: + description: + A list of GPIO configuration register values. Defines for the + appropriate values can found in dt-bindings/mfd/arizona.h. If + absent, no configuration of these registers is performed. If any + entry has a value that is out of range for a 16 bit register then the + chip default will be used. If present exactly five values must be + specified. + $ref: "/schemas/types.yaml#/definitions/uint32-array" + minItems: 1 + maxItems: 5 + + interrupt-controller: true + + '#interrupt-cells': + description: + The first cell is the IRQ number. The second cell is the flags, + encoded as trigger masks. + const: 2 + + interrupts: + maxItems: 1 + + clocks: + description: + Should reference the clocks supplied on MCLK1 and MCLK2. + minItems: 1 + maxItems: 2 + + clock-names: + description: + Should contains two strings mclk1 for the clock supplied on MCLK1, + recommended to be a high quality audio reference clock mclk2 for the + clock supplied on MCLK2, recommended to be an always on 32k clock. + oneOf: + - items: + - const: mclk1 + - items: + - const: mclk2 + - items: + - const: mclk1 + - const: mclk2 + + reset-gpios: + maxItems: 1 + + wlf,reset: + description: + GPIO specifier for the GPIO controlling RESET + deprecated: true + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - AVDD-supply + - CPVDD-supply + - DBVDD1-supply + - gpio-controller + - '#gpio-cells' + - interrupt-controller + - '#interrupt-cells' + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/mfd/arizona.h> + i2c@e0004000 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0xe0004000 0x1000>; + + wm5102: codec@1a { + compatible = "wlf,wm5102"; + reg = <0x1a>; + + reset-gpios = <&gpio 0>; + wlf,ldoena = <&gpio 1>; + + AVDD-supply = <&vdd1v8>; + DBVDD1-supply = <&vdd1v8>; + DBVDD2-supply = <&vdd1v8>; + DBVDD3-supply = <&vdd1v8>; + CPVDD-supply = <&vdd1v8>; + LDOVDD-supply = <&vdd1v8>; + SPKVDDL-supply = <&vdd5v>; + SPKVDDR-supply = <&vdd5v>; + + interrupts = <347>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&gic>; + + gpio-controller; + #gpio-cells = <2>; + + #sound-dai-cells = <1>; + + wlf,gpio-defaults = < + ARIZONA_GP_FN_TXLRCLK + ARIZONA_GP_DEFAULT + ARIZONA_GP_DEFAULT + ARIZONA_GP_DEFAULT + ARIZONA_GP_DEFAULT + >; + + clocks = <&clks 0>, <&clks 1>; + clock-names = "mclk1", "mclk2"; + + wlf,inmode = <ARIZONA_INMODE_DIFF ARIZONA_INMODE_DMIC>; + wlf,dmic-ref = <ARIZONA_DMIC_MICBIAS1 ARIZONA_DMIC_MICBIAS3>; + + wlf,use-jd2; + wlf,use-jd2-nopull; + wlf,jd-invert; + + wlf,micd-software-compare; + wlf,micd-detect-debounce = <0>; + wlf,micd-pol-gpio = <&codec 2 0>; + wlf,micd-rate = <ARIZONA_MICD_TIME_8MS>; + wlf,micd-dbtime = <4>; + wlf,micd-timeout-ms = <100>; + wlf,micd-force-micbias; + wlf,micd-configs = <0 ARIZONA_DMIC_MICBIAS1 0>, + <0x2000 ARIZONA_DMIC_MICBIAS2 1>; + + wlf,gpsw = <ARIZONA_GPSW_OPEN>; + }; + };
diff --git a/Documentation/devicetree/bindings/mips/ingenic/devices.yaml b/Documentation/devicetree/bindings/mips/ingenic/devices.yaml index 78dcf6e..d117503 100644 --- a/Documentation/devicetree/bindings/mips/ingenic/devices.yaml +++ b/Documentation/devicetree/bindings/mips/ingenic/devices.yaml
@@ -20,16 +20,20 @@ - description: Qi Hardware Ben NanoNote items: - const: qi,lb60 + - const: ingenic,jz4740 - description: Game Consoles Worldwide GCW Zero items: - const: gcw,zero + - const: ingenic,jz4770 - description: MIPS Creator CI20 items: - const: img,ci20 + - const: ingenic,jz4780 - description: YSH & ATIL General Board CU Neo items: - const: yna,cu1000-neo + - const: ingenic,x1000 ...
diff --git a/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml b/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml new file mode 100644 index 0000000..d317897e --- /dev/null +++ b/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml
@@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mips/loongson/rs780e-acpi.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Loongson RS780E PCH ACPI Controller + +maintainers: + - Jiaxun Yang <jiaxun.yang@flygoat.com> + +description: | + This controller can be found in Loongson-3 systems with RS780E PCH. + +properties: + compatible: + const: loongson,rs780e-acpi + + reg: + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + isa@0 { + compatible = "isa"; + #address-cells = <2>; + #size-cells = <1>; + ranges = <1 0 0 0x1000>; + + acpi@800 { + compatible = "loongson,rs780e-acpi"; + reg = <1 0x800 0x100>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml new file mode 100644 index 0000000..7a386a5 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml
@@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/amlogic,meson-mx-sdhc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson SDHC controller Device Tree Bindings + +allOf: + - $ref: "mmc-controller.yaml" + +maintainers: + - Martin Blumenstingl <martin.blumenstingl@googlemail.com> + +description: | + The SDHC MMC host controller on Amlogic SoCs provides an eMMC and MMC + card interface with 1/4/8-bit bus width. + It supports eMMC spec 4.4x/4.5x including HS200 (up to 100MHz clock). + +properties: + compatible: + items: + - enum: + - amlogic,meson8-sdhc + - amlogic,meson8b-sdhc + - amlogic,meson8m2-sdhc + - const: amlogic,meson-mx-sdhc + + reg: + minItems: 1 + + interrupts: + minItems: 1 + + clocks: + minItems: 5 + + clock-names: + items: + - const: clkin0 + - const: clkin1 + - const: clkin2 + - const: clkin3 + - const: pclk + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + sdhc: mmc@8e00 { + compatible = "amlogic,meson8-sdhc", "amlogic,meson-mx-sdhc"; + reg = <0x8e00 0x42>; + interrupts = <GIC_SPI 78 IRQ_TYPE_EDGE_RISING>; + clocks = <&xtal>, + <&fclk_div4>, + <&fclk_div3>, + <&fclk_div5>, + <&sdhc_pclk>; + clock-names = "clkin0", "clkin1", "clkin2", "clkin3", "pclk"; + };
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt index 428685e..f29bf7d 100644 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -18,12 +18,21 @@ - "xlnx,zynqmp-8.9a": ZynqMP SDHCI 8.9a PHY For this device it is strongly suggested to include clock-output-names and #clock-cells. + - "xlnx,versal-8.9a": Versal SDHCI 8.9a PHY + For this device it is strongly suggested to include clock-output-names and + #clock-cells. - "ti,am654-sdhci-5.1", "arasan,sdhci-5.1": TI AM654 MMC PHY Note: This binding has been deprecated and moved to [5]. - "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1": Intel LGM eMMC PHY For this device it is strongly suggested to include arasan,soc-ctl-syscon. - "intel,lgm-sdhci-5.1-sdxc", "arasan,sdhci-5.1": Intel LGM SDXC PHY For this device it is strongly suggested to include arasan,soc-ctl-syscon. + - "intel,keembay-sdhci-5.1-emmc", "arasan,sdhci-5.1": Intel Keem Bay eMMC + For this device it is strongly suggested to include arasan,soc-ctl-syscon. + - "intel,keembay-sdhci-5.1-sd": Intel Keem Bay SD controller + For this device it is strongly suggested to include arasan,soc-ctl-syscon. + - "intel,keembay-sdhci-5.1-sdio": Intel Keem Bay SDIO controller + For this device it is strongly suggested to include arasan,soc-ctl-syscon. [5] Documentation/devicetree/bindings/mmc/sdhci-am654.txt @@ -104,6 +113,18 @@ clk-phase-sd-hs = <63>, <72>; }; + sdhci: mmc@f1040000 { + compatible = "xlnx,versal-8.9a", "arasan,sdhci-8.9a"; + interrupt-parent = <&gic>; + interrupts = <0 126 4>; + reg = <0x0 0xf1040000 0x0 0x10000>; + clocks = <&clk200>, <&clk200>; + clock-names = "clk_xin", "clk_ahb"; + clock-output-names = "clk_out_sd0", "clk_in_sd0"; + #clock-cells = <1>; + clk-phase-sd-hs = <132>, <60>; + }; + emmc: sdhci@ec700000 { compatible = "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1"; reg = <0xec700000 0x300>; @@ -133,3 +154,39 @@ phy-names = "phy_arasan"; arasan,soc-ctl-syscon = <&sysconf>; }; + + mmc: mmc@33000000 { + compatible = "intel,keembay-sdhci-5.1-emmc", "arasan,sdhci-5.1"; + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x0 0x33000000 0x0 0x300>; + clock-names = "clk_xin", "clk_ahb"; + clocks = <&scmi_clk KEEM_BAY_PSS_AUX_EMMC>, + <&scmi_clk KEEM_BAY_PSS_EMMC>; + phys = <&emmc_phy>; + phy-names = "phy_arasan"; + assigned-clocks = <&scmi_clk KEEM_BAY_PSS_AUX_EMMC>; + assigned-clock-rates = <200000000>; + clock-output-names = "emmc_cardclock"; + #clock-cells = <0>; + arasan,soc-ctl-syscon = <&mmc_phy_syscon>; + }; + + sd0: mmc@31000000 { + compatible = "intel,keembay-sdhci-5.1-sd"; + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x0 0x31000000 0x0 0x300>; + clock-names = "clk_xin", "clk_ahb"; + clocks = <&scmi_clk KEEM_BAY_PSS_AUX_SD0>, + <&scmi_clk KEEM_BAY_PSS_SD0>; + arasan,soc-ctl-syscon = <&sd0_phy_syscon>; + }; + + sd1: mmc@32000000 { + compatible = "intel,keembay-sdhci-5.1-sdio"; + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x0 0x32000000 0x0 0x300>; + clock-names = "clk_xin", "clk_ahb"; + clocks = <&scmi_clk KEEM_BAY_PSS_AUX_SD1>, + <&scmi_clk KEEM_BAY_PSS_SD1>; + arasan,soc-ctl-syscon = <&sd1_phy_syscon>; + };
diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml index 200de93..987b287f 100644 --- a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
@@ -41,8 +41,8 @@ patternProperties: "^sdhci@[0-9a-f]+$": type: object - allOf: - - $ref: mmc-controller.yaml + $ref: mmc-controller.yaml + properties: compatible: enum:
diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml index 2f45dd0..d93f779 100644 --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
@@ -17,7 +17,7 @@ compatible: items: - enum: - - socionext,uniphier-sd4hc + - socionext,uniphier-sd4hc - const: cdns,sd4hc reg: @@ -36,91 +36,80 @@ cdns,phy-input-delay-sd-highspeed: description: Value of the delay in the input path for SD high-speed timing - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - - maximum: 0x1f + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 0x1f cdns,phy-input-delay-legacy: description: Value of the delay in the input path for legacy timing - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - - maximum: 0x1f + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 0x1f cdns,phy-input-delay-sd-uhs-sdr12: description: Value of the delay in the input path for SD UHS SDR12 timing - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - - maximum: 0x1f + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 0x1f cdns,phy-input-delay-sd-uhs-sdr25: description: Value of the delay in the input path for SD UHS SDR25 timing - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - - maximum: 0x1f + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 0x1f cdns,phy-input-delay-sd-uhs-sdr50: description: Value of the delay in the input path for SD UHS SDR50 timing - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - - maximum: 0x1f + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 0x1f cdns,phy-input-delay-sd-uhs-ddr50: description: Value of the delay in the input path for SD UHS DDR50 timing - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - - maximum: 0x1f + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 0x1f cdns,phy-input-delay-mmc-highspeed: description: Value of the delay in the input path for MMC high-speed timing - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - - maximum: 0x1f + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 0x1f cdns,phy-input-delay-mmc-ddr: description: Value of the delay in the input path for eMMC high-speed DDR timing - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - - maximum: 0x1f # PHY DLL clock delays: # Each delay property represents the fraction of the clock period. # The approximate delay value will be # (<delay property value>/128)*sdmclk_clock_period. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 0x1f cdns,phy-dll-delay-sdclk: description: | Value of the delay introduced on the sdclk output for all modes except HS200, HS400 and HS400_ES. - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - - maximum: 0x7f + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 0x7f cdns,phy-dll-delay-sdclk-hsmmc: description: | Value of the delay introduced on the sdclk output for HS200, HS400 and HS400_ES speed modes. - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - - maximum: 0x7f + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 0x7f cdns,phy-dll-delay-strobe: description: | Value of the delay introduced on the dat_strobe input used in HS400 / HS400_ES speed modes. - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - - maximum: 0x7f + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 0x7f required: - compatible
diff --git a/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml b/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml new file mode 100644 index 0000000..e60bfe9 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml
@@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/ingenic,mmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs MMC Controller DT bindings + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +allOf: + - $ref: mmc-controller.yaml# + +properties: + compatible: + oneOf: + - enum: + - ingenic,jz4740-mmc + - ingenic,jz4725b-mmc + - ingenic,jz4760-mmc + - ingenic,jz4780-mmc + - ingenic,x1000-mmc + - items: + - const: ingenic,jz4770-mmc + - const: ingenic,jz4760-mmc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: mmc + + dmas: + items: + - description: DMA controller phandle and request line for RX + - description: DMA controller phandle and request line for TX + + dma-names: + items: + - const: rx + - const: tx + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + +examples: + - | + #include <dt-bindings/clock/jz4780-cgu.h> + #include <dt-bindings/dma/jz4780-dma.h> + mmc0: mmc@13450000 { + compatible = "ingenic,jz4780-mmc"; + reg = <0x13450000 0x1000>; + + interrupt-parent = <&intc>; + interrupts = <37>; + + clocks = <&cgu JZ4780_CLK_MSC0>; + clock-names = "mmc"; + + cap-sd-highspeed; + cap-mmc-highspeed; + cap-sdio-irq; + dmas = <&dma JZ4780_DMA_MSC0_RX 0xffffffff>, + <&dma JZ4780_DMA_MSC0_TX 0xffffffff>; + dma-names = "rx", "tx"; + };
diff --git a/Documentation/devicetree/bindings/mmc/jz4740.txt b/Documentation/devicetree/bindings/mmc/jz4740.txt deleted file mode 100644 index 453d3b9..0000000 --- a/Documentation/devicetree/bindings/mmc/jz4740.txt +++ /dev/null
@@ -1,41 +0,0 @@ -* Ingenic XBurst MMC controllers - -This file documents the device tree properties used for the MMC controller in -Ingenic JZ4740/JZ4760/JZ4780/X1000 SoCs. These are in addition to the core MMC -properties described in mmc.txt. - -Required properties: -- compatible: Should be one of the following: - - "ingenic,jz4740-mmc" for the JZ4740 - - "ingenic,jz4725b-mmc" for the JZ4725B - - "ingenic,jz4760-mmc" for the JZ4760 - - "ingenic,jz4780-mmc" for the JZ4780 - - "ingenic,x1000-mmc" for the X1000 -- reg: Should contain the MMC controller registers location and length. -- interrupts: Should contain the interrupt specifier of the MMC controller. -- clocks: Clock for the MMC controller. - -Optional properties: -- dmas: List of DMA specifiers with the controller specific format - as described in the generic DMA client binding. A tx and rx - specifier is required. -- dma-names: RX and TX DMA request names. - Should be "rx" and "tx", in that order. - -For additional details on DMA client bindings see ../dma/dma.txt. - -Example: - -mmc0: mmc@13450000 { - compatible = "ingenic,jz4780-mmc"; - reg = <0x13450000 0x1000>; - - interrupt-parent = <&intc>; - interrupts = <37>; - - clocks = <&cgu JZ4780_CLK_MSC0>; - clock-names = "mmc"; - - dmas = <&dma JZ4780_DMA_MSC0_RX 0xffffffff>, <&dma JZ4780_DMA_MSC0_TX 0xffffffff>; - dma-names = "rx", "tx"; -};
diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml index acc9f10..4931fab 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
@@ -76,20 +76,18 @@ # Other properties bus-width: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [1, 4, 8] - default: 1 description: Number of data lines. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 4, 8] + default: 1 max-frequency: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 400000 - - maximum: 200000000 description: Maximum operating frequency of the bus. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 400000 + maximum: 200000000 disable-wp: $ref: /schemas/types.yaml#/definitions/flag @@ -212,13 +210,12 @@ eMMC HS400 enhanced strobe mode is supported dsr: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - - maximum: 0xffff description: Value the card Driver Stage Register (DSR) should be programmed with. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 0xffff no-sdio: $ref: /schemas/types.yaml#/definitions/flag @@ -238,25 +235,23 @@ initialization. fixed-emmc-driver-type: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - - maximum: 4 description: For non-removable eMMC, enforce this driver type. The value is the driver type as specified in the eMMC specification (table 206 in spec version 5.1) + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 4 post-power-on-delay-ms: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - default: 10 description: It was invented for MMC pwrseq-simple which could be referred to mmc-pwrseq-simple.txt. But now it\'s reused as a tunable delay waiting for I/O signalling and card power supply to be stable, regardless of whether pwrseq-simple is used. Default to 10ms if no available. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 10 supports-cqe: $ref: /schemas/types.yaml#/definitions/flag @@ -333,8 +328,8 @@ - reg "^clk-phase-(legacy|sd-hs|mmc-(hs|hs[24]00|ddr52)|uhs-(sdr(12|25|50|104)|ddr50))$": - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 maxItems: 2 items:
diff --git a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml index 12b4021..1380501 100644 --- a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
@@ -47,7 +47,7 @@ - | mmc0: mmc@e0330000 { compatible = "actions,owl-mmc"; - reg = <0x0 0xe0330000 0x0 0x4000>; + reg = <0xe0330000 0x4000>; interrupts = <0 42 4>; clocks = <&cmu 56>; resets = <&cmu 23>;
diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt index c064af5..291532a 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt +++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
@@ -11,6 +11,7 @@ - "renesas,mmcif-r7s72100" for the MMCIF found in r7s72100 SoCs - "renesas,mmcif-r8a73a4" for the MMCIF found in r8a73a4 SoCs - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs + - "renesas,mmcif-r8a7742" for the MMCIF found in r8a7742 SoCs - "renesas,mmcif-r8a7743" for the MMCIF found in r8a7743 SoCs - "renesas,mmcif-r8a7744" for the MMCIF found in r8a7744 SoCs - "renesas,mmcif-r8a7745" for the MMCIF found in r8a7745 SoCs @@ -24,8 +25,8 @@ - interrupts: Some SoCs have only 1 shared interrupt, while others have either 2 or 3 individual interrupts (error, int, card detect). Below is the number of interrupts for each SoC: - 1: r8a73a4, r8a7743, r8a7744, r8a7745, r8a7778, r8a7790, r8a7791, r8a7793, - r8a7794 + 1: r8a73a4, r8a7742, r8a7743, r8a7744, r8a7745, r8a7778, r8a7790, r8a7791, + r8a7793, r8a7794 2: r8a7740, sh73a0 3: r7s72100
diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt b/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt index e6cc478..0ca9a62 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt
@@ -7,6 +7,7 @@ "renesas,sdhi-r7s9210" - SDHI IP on R7S9210 SoC "renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC + "renesas,sdhi-r8a7742" - SDHI IP on R8A7742 SoC "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC "renesas,sdhi-r8a7744" - SDHI IP on R8A7744 SoC "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml index 89c3edd6..0131618 100644 --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
@@ -30,21 +30,21 @@ - items: - enum: # for Rockchip PX30 - - rockchip,px30-dw-mshc + - rockchip,px30-dw-mshc # for Rockchip RK3036 - - rockchip,rk3036-dw-mshc + - rockchip,rk3036-dw-mshc # for Rockchip RK322x - - rockchip,rk3228-dw-mshc + - rockchip,rk3228-dw-mshc # for Rockchip RK3308 - - rockchip,rk3308-dw-mshc + - rockchip,rk3308-dw-mshc # for Rockchip RK3328 - - rockchip,rk3328-dw-mshc + - rockchip,rk3328-dw-mshc # for Rockchip RK3368 - - rockchip,rk3368-dw-mshc + - rockchip,rk3368-dw-mshc # for Rockchip RK3399 - - rockchip,rk3399-dw-mshc + - rockchip,rk3399-dw-mshc # for Rockchip RV1108 - - rockchip,rv1108-dw-mshc + - rockchip,rv1108-dw-mshc - const: rockchip,rk3288-dw-mshc reg: @@ -76,8 +76,7 @@ high speed modes. rockchip,default-sample-phase: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 360 default: 0 @@ -87,8 +86,7 @@ If not specified 0 deg will be used. rockchip,desired-num-phases: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 360 default: 360 @@ -111,7 +109,7 @@ #include <dt-bindings/interrupt-controller/irq.h> sdmmc: mmc@ff0c0000 { compatible = "rockchip,rk3288-dw-mshc"; - reg = <0x0 0xff0c0000 0x0 0x4000>; + reg = <0xff0c0000 0x4000>; interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>, <&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt index 5445931..b8e1d2b 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -17,6 +17,7 @@ "qcom,msm8916-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8992-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8996-sdhci", "qcom,sdhci-msm-v4" + "qcom,sm8250-sdhci", "qcom,sdhci-msm-v5" "qcom,sdm845-sdhci", "qcom,sdhci-msm-v5" "qcom,qcs404-sdhci", "qcom,sdhci-msm-v5" "qcom,sc7180-sdhci", "qcom,sdhci-msm-v5"; @@ -46,6 +47,13 @@ "cal" - reference clock for RCLK delay calibration (optional) "sleep" - sleep clock for RCLK delay calibration (optional) +- qcom,ddr-config: Certain chipsets and platforms require particular settings + for the DDR_CONFIG register. Use this field to specify the register + value as per the Hardware Programming Guide. + +- qcom,dll-config: Chipset and Platform specific value. Use this field to + specify the DLL_CONFIG register value as per Hardware Programming Guide. + Example: sdhc_1: sdhci@f9824900 { @@ -63,6 +71,9 @@ clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>; clock-names = "core", "iface"; + + qcom,dll-config = <0x000f642c>; + qcom,ddr-config = <0x80040868>; }; sdhc_2: sdhci@f98a4900 { @@ -80,4 +91,7 @@ clocks = <&gcc GCC_SDCC2_APPS_CLK>, <&gcc GCC_SDCC2_AHB_CLK>; clock-names = "core", "iface"; + + qcom,dll-config = <0x0007642c>; + qcom,ddr-config = <0x80040868>; };
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt deleted file mode 100644 index 3d1b449..0000000 --- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt +++ /dev/null
@@ -1,50 +0,0 @@ -* Marvell sdhci-pxa v2/v3 controller - -This file documents differences between the core properties in mmc.txt -and the properties used by the sdhci-pxav2 and sdhci-pxav3 drivers. - -Required properties: -- compatible: Should be "mrvl,pxav2-mmc", "mrvl,pxav3-mmc" or - "marvell,armada-380-sdhci". -- reg: - * for "mrvl,pxav2-mmc" and "mrvl,pxav3-mmc", one register area for - the SDHCI registers. - - * for "marvell,armada-380-sdhci", three register areas. The first - one for the SDHCI registers themselves, the second one for the - AXI/Mbus bridge registers of the SDHCI unit, the third one for the - SDIO3 Configuration register -- reg names: should be "sdhci", "mbus", "conf-sdio3". only mandatory - for "marvell,armada-380-sdhci" -- clocks: Array of clocks required for SDHCI; requires at least one for - I/O clock. -- clock-names: Array of names corresponding to clocks property; shall be - "io" for I/O clock and "core" for optional core clock. - -Optional properties: -- mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning. - -Example: - -sdhci@d4280800 { - compatible = "mrvl,pxav3-mmc"; - reg = <0xd4280800 0x800>; - bus-width = <8>; - interrupts = <27>; - clocks = <&chip CLKID_SDIO1XIN>, <&chip CLKID_SDIO1>; - clock-names = "io", "core"; - non-removable; - mrvl,clk-delay-cycles = <31>; -}; - -sdhci@d8000 { - compatible = "marvell,armada-380-sdhci"; - reg-names = "sdhci", "mbus", "conf-sdio3"; - reg = <0xd8000 0x1000>, - <0xdc000 0x100>; - <0x18454 0x4>; - interrupts = <0 25 0x4>; - clocks = <&gateclk 17>; - clock-names = "io"; - mrvl,clk-delay-cycles = <0x1F>; -};
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml b/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml new file mode 100644 index 0000000..a58715c --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml
@@ -0,0 +1,102 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/sdhci-pxa.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell PXA SDHCI v2/v3 bindings + +maintainers: + - Ulf Hansson <ulf.hansson@linaro.org> + +allOf: + - $ref: mmc-controller.yaml# + - if: + properties: + compatible: + contains: + const: marvell,armada-380-sdhci + then: + properties: + regs: + minItems: 3 + reg-names: + minItems: 3 + required: + - reg-names + else: + properties: + regs: + maxItems: 1 + reg-names: + maxItems: 1 + +properties: + compatible: + enum: + - mrvl,pxav2-mmc + - mrvl,pxav3-mmc + - marvell,armada-380-sdhci + + reg: + minItems: 1 + maxItems: 3 + + reg-names: + items: + - const: sdhci + - const: mbus + - const: conf-sdio3 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + items: + - const: io + - const: core + + mrvl,clk-delay-cycles: + description: Specify a number of cycles to delay for tuning. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +examples: + - | + #include <dt-bindings/clock/berlin2.h> + mmc@d4280800 { + compatible = "mrvl,pxav3-mmc"; + reg = <0xd4280800 0x800>; + bus-width = <8>; + interrupts = <27>; + clocks = <&chip CLKID_SDIO1XIN>, <&chip CLKID_SDIO1>; + clock-names = "io", "core"; + non-removable; + mrvl,clk-delay-cycles = <31>; + }; + - | + mmc@d8000 { + compatible = "marvell,armada-380-sdhci"; + reg-names = "sdhci", "mbus", "conf-sdio3"; + reg = <0xd8000 0x1000>, + <0xdc000 0x100>, + <0x18454 0x4>; + interrupts = <0 25 0x4>; + clocks = <&gateclk 17>; + clock-names = "io"; + mrvl,clk-delay-cycles = <0x1F>; + }; + +...
diff --git a/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml b/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml index cdfac9b..8d6413f 100644 --- a/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml
@@ -35,15 +35,15 @@ oneOf: - const: host - items: - - const: host - - const: bridge + - const: host + - const: bridge - items: - - const: host - - const: hw + - const: host + - const: hw - items: - - const: host - - const: bridge - - const: hw + - const: host + - const: bridge + - const: hw resets: minItems: 1
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml index 890d47a..85bd528 100644 --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
@@ -27,39 +27,35 @@ clock to this at probe time. fifo-depth: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 description: The maximum size of the tx/rx fifo's. If this property is not specified, the default value of the fifo size is determined from the controller registers. + $ref: /schemas/types.yaml#/definitions/uint32 card-detect-delay: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - default: 0 description: Delay in milli-seconds before detecting card after card insert event. The default value is 0. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 data-addr: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 description: Override fifo address with value provided by DT. The default FIFO reg offset is assumed as 0x100 (version < 0x240A) and 0x200(version >= 0x240A) by driver. If the controller does not follow this rule, please use this property to set fifo address in device tree. + $ref: /schemas/types.yaml#/definitions/uint32 fifo-watermark-aligned: - allOf: - - $ref: /schemas/types.yaml#/definitions/flag description: Data done irq is expected if data length is less than watermark in PIO mode. But fifo watermark is requested to be aligned with data length in some SoC so that TX/RX irq can be generated with data done irq. Add this watermark quirk to mark this requirement and force fifo watermark setting accordingly. + $ref: /schemas/types.yaml#/definitions/flag dmas: maxItems: 1
diff --git a/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml b/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml index 5d3fa41..c033ac3 100644 --- a/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml
@@ -75,13 +75,12 @@ allwinner,rb: description: Contains the native Ready/Busy IDs. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 1 - maxItems: 2 - items: - minimum: 0 - maximum: 1 + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 2 + items: + minimum: 0 + maximum: 1 additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml new file mode 100644 index 0000000..cb9794e --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml
@@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/arasan,nand-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arasan NAND Flash Controller with ONFI 3.1 support device tree bindings + +allOf: + - $ref: "nand-controller.yaml" + +maintainers: + - Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - xlnx,zynqmp-nand-controller + - enum: + - arasan,nfc-v3p10 + + reg: + maxItems: 1 + + clocks: + items: + - description: Controller clock + - description: NAND bus clock + + clock-names: + items: + - const: controller + - const: bus + + interrupts: + maxItems: 1 + + "#address-cells": true + "#size-cells": true + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + +additionalProperties: true + +examples: + - | + nfc: nand-controller@ff100000 { + compatible = "xlnx,zynqmp-nand-controller", "arasan,nfc-v3p10"; + reg = <0xff100000 0x1000>; + clock-names = "controller", "bus"; + clocks = <&clk200>, <&clk100>; + interrupt-parent = <&gic>; + interrupts = <0 14 4>; + #address-cells = <1>; + #size-cells = <0>; + };
diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt index 05651a6..44335a4 100644 --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
@@ -20,6 +20,8 @@ "brcm,brcmnand" and an appropriate version compatibility string, like "brcm,brcmnand-v7.0" Possible values: + brcm,brcmnand-v2.1 + brcm,brcmnand-v2.2 brcm,brcmnand-v4.0 brcm,brcmnand-v5.0 brcm,brcmnand-v6.0
diff --git a/Documentation/devicetree/bindings/mtd/denali,nand.yaml b/Documentation/devicetree/bindings/mtd/denali,nand.yaml index 46e6b672..c07b915 100644 --- a/Documentation/devicetree/bindings/mtd/denali,nand.yaml +++ b/Documentation/devicetree/bindings/mtd/denali,nand.yaml
@@ -54,8 +54,8 @@ reg: register reset oneOf: - items: - - const: nand - - const: reg + - const: nand + - const: reg - const: nand - const: reg
diff --git a/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt deleted file mode 100644 index c022593..0000000 --- a/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt +++ /dev/null
@@ -1,92 +0,0 @@ -* Ingenic JZ4780 NAND/ECC - -This file documents the device tree bindings for NAND flash devices on the -JZ4780. NAND devices are connected to the NEMC controller (described in -memory-controllers/ingenic,jz4780-nemc.txt), and thus NAND device nodes must -be children of the NEMC node. - -Required NAND controller device properties: -- compatible: Should be one of: - * ingenic,jz4740-nand - * ingenic,jz4725b-nand - * ingenic,jz4780-nand -- reg: For each bank with a NAND chip attached, should specify a bank number, - an offset of 0 and a size of 0x1000000 (i.e. the whole NEMC bank). - -Optional NAND controller device properties: -- ecc-engine: To make use of the hardware ECC controller, this - property must contain a phandle for the ECC controller node. The required - properties for this node are described below. If this is not specified, - software ECC will be used instead. - -Optional children nodes: -- Individual NAND chips are children of the NAND controller node. - -Required children node properties: -- reg: An integer ranging from 1 to 6 representing the CS line to use. - -Optional children node properties: -- nand-ecc-step-size: ECC block size in bytes. -- nand-ecc-strength: ECC strength (max number of correctable bits). -- nand-ecc-mode: String, operation mode of the NAND ecc mode. "hw" by default -- nand-on-flash-bbt: boolean to enable on flash bbt option, if not present false -- rb-gpios: GPIO specifier for the busy pin. -- wp-gpios: GPIO specifier for the write protect pin. - -Optional child node of NAND chip nodes: -- partitions: see Documentation/devicetree/bindings/mtd/partition.txt - -Example: - -nemc: nemc@13410000 { - ... - - nandc: nand-controller@1 { - compatible = "ingenic,jz4780-nand"; - reg = <1 0 0x1000000>; /* Bank 1 */ - - #address-cells = <1>; - #size-cells = <0>; - - ecc-engine = <&bch>; - - nand@1 { - reg = <1>; - - nand-ecc-step-size = <1024>; - nand-ecc-strength = <24>; - nand-ecc-mode = "hw"; - nand-on-flash-bbt; - - rb-gpios = <&gpa 20 GPIO_ACTIVE_LOW>; - wp-gpios = <&gpf 22 GPIO_ACTIVE_LOW>; - - partitions { - #address-cells = <2>; - #size-cells = <2>; - ... - } - }; - }; -}; - -The ECC controller is a separate SoC component used for error correction on -NAND devices. The following is a description of the device properties for a -ECC controller. - -Required ECC properties: -- compatible: Should be one of: - * ingenic,jz4740-ecc - * ingenic,jz4725b-bch - * ingenic,jz4780-bch -- reg: Should specify the ECC controller registers location and length. -- clocks: Clock for the ECC controller. - -Example: - -bch: bch@134d0000 { - compatible = "ingenic,jz4780-bch"; - reg = <0x134d0000 0x10000>; - - clocks = <&cgu JZ4780_CLK_BCH>; -};
diff --git a/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml b/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml new file mode 100644 index 0000000..8abb6d4 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
@@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/ingenic,nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs NAND controller devicetree bindings + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +allOf: + - $ref: nand-controller.yaml# + +properties: + compatible: + enum: + - ingenic,jz4740-nand + - ingenic,jz4725b-nand + - ingenic,jz4780-nand + + reg: + items: + - description: Bank number, offset and size of first attached NAND chip + - description: Bank number, offset and size of second attached NAND chip + - description: Bank number, offset and size of third attached NAND chip + - description: Bank number, offset and size of fourth attached NAND chip + minItems: 1 + + ecc-engine: true + + partitions: + type: object + description: + Node containing description of fixed partitions. + See Documentation/devicetree/bindings/mtd/partition.txt + +patternProperties: + "^nand@[a-f0-9]$": + type: object + properties: + rb-gpios: + description: GPIO specifier for the busy pin. + maxItems: 1 + + wp-gpios: + description: GPIO specifier for the write-protect pin. + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/clock/jz4780-cgu.h> + memory-controller@13410000 { + compatible = "ingenic,jz4780-nemc"; + reg = <0x13410000 0x10000>; + #address-cells = <2>; + #size-cells = <1>; + ranges = <1 0 0x1b000000 0x1000000>, + <2 0 0x1a000000 0x1000000>, + <3 0 0x19000000 0x1000000>, + <4 0 0x18000000 0x1000000>, + <5 0 0x17000000 0x1000000>, + <6 0 0x16000000 0x1000000>; + + clocks = <&cgu JZ4780_CLK_NEMC>; + + nand-controller@1 { + compatible = "ingenic,jz4780-nand"; + reg = <1 0 0x1000000>; + + #address-cells = <1>; + #size-cells = <0>; + + ecc-engine = <&bch>; + + ingenic,nemc-tAS = <10>; + ingenic,nemc-tAH = <5>; + ingenic,nemc-tBP = <10>; + ingenic,nemc-tAW = <15>; + ingenic,nemc-tSTRV = <100>; + + pinctrl-names = "default"; + pinctrl-0 = <&pins_nemc>; + + nand@1 { + reg = <1>; + + nand-ecc-step-size = <1024>; + nand-ecc-strength = <24>; + nand-ecc-mode = "hw"; + nand-on-flash-bbt; + + pinctrl-names = "default"; + pinctrl-0 = <&pins_nemc_cs1>; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <2>; + #size-cells = <2>; + + partition@0 { + label = "u-boot-spl"; + reg = <0x0 0x0 0x0 0x800000>; + }; + + partition@800000 { + label = "u-boot"; + reg = <0x0 0x800000 0x0 0x200000>; + }; + + partition@a00000 { + label = "u-boot-env"; + reg = <0x0 0xa00000 0x0 0x200000>; + }; + + partition@c00000 { + label = "boot"; + reg = <0x0 0xc00000 0x0 0x4000000>; + }; + + partition@4c00000 { + label = "system"; + reg = <0x0 0x4c00000 0x1 0xfb400000>; + }; + }; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index d261b70..cde7c4d 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -47,29 +47,26 @@ Contains the native Ready/Busy IDs. nand-ecc-mode: - allOf: - - $ref: /schemas/types.yaml#/definitions/string - - enum: [ none, soft, hw, hw_syndrome, hw_oob_first, on-die ] description: Desired ECC engine, either hardware (most of the time embedded in the NAND controller) or software correction (Linux will handle the calculations). soft_bch is deprecated and should be replaced by soft and nand-ecc-algo. + $ref: /schemas/types.yaml#/definitions/string + enum: [none, soft, hw, hw_syndrome, hw_oob_first, on-die] nand-ecc-algo: - allOf: - - $ref: /schemas/types.yaml#/definitions/string - - enum: [ hamming, bch, rs ] description: Desired ECC algorithm. + $ref: /schemas/types.yaml#/definitions/string + enum: [hamming, bch, rs] nand-bus-width: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 8, 16 ] - - default: 8 description: Bus width to the NAND chip + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16] + default: 8 nand-on-flash-bbt: $ref: /schemas/types.yaml#/definitions/flag @@ -83,18 +80,16 @@ build a volatile BBT in RAM. nand-ecc-strength: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 1 description: Maximum number of bits that can be corrected per ECC step. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 nand-ecc-step-size: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 1 description: Number of data bytes covered by a single ECC step. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 nand-ecc-maximize: $ref: /schemas/types.yaml#/definitions/flag
diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt index afbbd87..4a39698 100644 --- a/Documentation/devicetree/bindings/mtd/partition.txt +++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -61,6 +61,9 @@ clobbered. - lock : Do not unlock the partition at initialization time (not supported on all devices) +- slc-mode: This parameter, if present, allows one to emulate SLC mode on a + partition attached to an MLC NAND thus making this partition immune to + paired-pages corruptions Examples:
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml index db36b4d..c7c9ad4 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -19,8 +19,8 @@ - const: allwinner,sun8i-v3s-emac - const: allwinner,sun50i-a64-emac - items: - - const: allwinner,sun50i-h6-emac - - const: allwinner,sun50i-a64-emac + - const: allwinner,sun50i-h6-emac + - const: allwinner,sun50i-a64-emac reg: maxItems: 1
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index ae91aa9..64c20c9 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -40,18 +40,22 @@ then: properties: clocks: + minItems: 3 + maxItems: 4 items: - description: GMAC main clock - description: First parent clock of the internal mux - description: Second parent clock of the internal mux + - description: The clock which drives the timing adjustment logic clock-names: minItems: 3 - maxItems: 3 + maxItems: 4 items: - const: stmmaceth - const: clkin0 - const: clkin1 + - const: timing-adjustment amlogic,tx-delay-ns: $ref: /schemas/types.yaml#definitions/uint32 @@ -67,6 +71,19 @@ PHY and MAC are adding a delay). Any configuration is ignored when the phy-mode is set to "rmii". + amlogic,rx-delay-ns: + enum: + - 0 + - 2 + default: 0 + description: + The internal RGMII RX clock delay (provided by this IP block) in + nanoseconds. When phy-mode is set to "rgmii" then the RX delay + should be explicitly configured. When the phy-mode is set to + either "rgmii-id" or "rgmii-rxid" the RX clock delay is already + provided by the PHY. Any configuration is ignored when the + phy-mode is set to "rmii". + properties: compatible: additionalItems: true @@ -107,7 +124,7 @@ reg = <0xc9410000 0x10000>, <0xc8834540 0x8>; interrupts = <8>; interrupt-names = "macirq"; - clocks = <&clk_eth>, <&clkc_fclk_div2>, <&clk_mpll2>; - clock-names = "stmmaceth", "clkin0", "clkin1"; + clocks = <&clk_eth>, <&clk_fclk_div2>, <&clk_mpll2>, <&clk_fclk_div2>; + clock-names = "stmmaceth", "clkin0", "clkin1", "timing-adjustment"; phy-mode = "rgmii"; };
diff --git a/Documentation/devicetree/bindings/net/calxeda-xgmac.txt b/Documentation/devicetree/bindings/net/calxeda-xgmac.txt deleted file mode 100644 index c8ae996..0000000 --- a/Documentation/devicetree/bindings/net/calxeda-xgmac.txt +++ /dev/null
@@ -1,18 +0,0 @@ -* Calxeda Highbank 10Gb XGMAC Ethernet - -Required properties: -- compatible : Should be "calxeda,hb-xgmac" -- reg : Address and length of the register set for the device -- interrupts : Should contain 3 xgmac interrupts. The 1st is main interrupt. - The 2nd is pwr mgt interrupt. The 3rd is low power state interrupt. - -Optional properties: -- dma-coherent : Present if dma operations are coherent - -Example: - -ethernet@fff50000 { - compatible = "calxeda,hb-xgmac"; - reg = <0xfff50000 0x1000>; - interrupts = <0 77 4 0 78 4 0 79 4>; -};
diff --git a/Documentation/devicetree/bindings/net/calxeda-xgmac.yaml b/Documentation/devicetree/bindings/net/calxeda-xgmac.yaml new file mode 100644 index 0000000..c3ca266 --- /dev/null +++ b/Documentation/devicetree/bindings/net/calxeda-xgmac.yaml
@@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/calxeda-xgmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Calxeda Highbank 10Gb XGMAC Ethernet controller + +description: | + The Calxeda XGMAC Ethernet controllers are directly connected to the + internal machine "network fabric", which is set up, initialised and + managed by the firmware. So there are no PHY properties in this + binding. Switches in the fabric take care of routing and mapping the + traffic to external network ports. + +maintainers: + - Andre Przywara <andre.przywara@arm.com> + +properties: + compatible: + const: calxeda,hb-xgmac + + reg: + maxItems: 1 + + interrupts: + description: | + Can point to at most 3 xgmac interrupts. The 1st one is the main + interrupt, the 2nd one is used for power management. The optional + 3rd one is the low power state interrupt. + minItems: 2 + maxItems: 3 + + dma-coherent: true + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + ethernet@fff50000 { + compatible = "calxeda,hb-xgmac"; + reg = <0xfff50000 0x1000>; + interrupts = <0 77 4>, <0 78 4>, <0 79 4>; + };
diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index cccf820..798fa5f 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
@@ -9,7 +9,7 @@ description: Bosch MCAN controller for CAN bus maintainers: - - Sriram Dash <sriram.dash@samsung.com> + - Sriram Dash <sriram.dash@samsung.com> properties: compatible: @@ -51,61 +51,60 @@ bosch,mram-cfg: description: | - Message RAM configuration data. - Multiple M_CAN instances can share the same Message RAM - and each element(e.g Rx FIFO or Tx Buffer and etc) number - in Message RAM is also configurable, so this property is - telling driver how the shared or private Message RAM are - used by this M_CAN controller. + Message RAM configuration data. + Multiple M_CAN instances can share the same Message RAM + and each element(e.g Rx FIFO or Tx Buffer and etc) number + in Message RAM is also configurable, so this property is + telling driver how the shared or private Message RAM are + used by this M_CAN controller. - The format should be as follows: - <offset sidf_elems xidf_elems rxf0_elems rxf1_elems rxb_elems txe_elems txb_elems> - The 'offset' is an address offset of the Message RAM where - the following elements start from. This is usually set to - 0x0 if you're using a private Message RAM. The remain cells - are used to specify how many elements are used for each FIFO/Buffer. + The format should be as follows: + <offset sidf_elems xidf_elems rxf0_elems rxf1_elems rxb_elems txe_elems txb_elems> + The 'offset' is an address offset of the Message RAM where + the following elements start from. This is usually set to + 0x0 if you're using a private Message RAM. The remain cells + are used to specify how many elements are used for each FIFO/Buffer. - M_CAN includes the following elements according to user manual: - 11-bit Filter 0-128 elements / 0-128 words - 29-bit Filter 0-64 elements / 0-128 words - Rx FIFO 0 0-64 elements / 0-1152 words - Rx FIFO 1 0-64 elements / 0-1152 words - Rx Buffers 0-64 elements / 0-1152 words - Tx Event FIFO 0-32 elements / 0-64 words - Tx Buffers 0-32 elements / 0-576 words + M_CAN includes the following elements according to user manual: + 11-bit Filter 0-128 elements / 0-128 words + 29-bit Filter 0-64 elements / 0-128 words + Rx FIFO 0 0-64 elements / 0-1152 words + Rx FIFO 1 0-64 elements / 0-1152 words + Rx Buffers 0-64 elements / 0-1152 words + Tx Event FIFO 0-32 elements / 0-64 words + Tx Buffers 0-32 elements / 0-576 words - Please refer to 2.4.1 Message RAM Configuration in Bosch - M_CAN user manual for details. - allOf: - - $ref: /schemas/types.yaml#/definitions/int32-array - - items: - items: - - description: The 'offset' is an address offset of the Message RAM - where the following elements start from. This is usually - set to 0x0 if you're using a private Message RAM. - default: 0 - - description: 11-bit Filter 0-128 elements / 0-128 words - minimum: 0 - maximum: 128 - - description: 29-bit Filter 0-64 elements / 0-128 words - minimum: 0 - maximum: 64 - - description: Rx FIFO 0 0-64 elements / 0-1152 words - minimum: 0 - maximum: 64 - - description: Rx FIFO 1 0-64 elements / 0-1152 words - minimum: 0 - maximum: 64 - - description: Rx Buffers 0-64 elements / 0-1152 words - minimum: 0 - maximum: 64 - - description: Tx Event FIFO 0-32 elements / 0-64 words - minimum: 0 - maximum: 32 - - description: Tx Buffers 0-32 elements / 0-576 words - minimum: 0 - maximum: 32 - maxItems: 1 + Please refer to 2.4.1 Message RAM Configuration in Bosch + M_CAN user manual for details. + $ref: /schemas/types.yaml#/definitions/int32-array + items: + items: + - description: The 'offset' is an address offset of the Message RAM where + the following elements start from. This is usually set to 0x0 if + you're using a private Message RAM. + default: 0 + - description: 11-bit Filter 0-128 elements / 0-128 words + minimum: 0 + maximum: 128 + - description: 29-bit Filter 0-64 elements / 0-128 words + minimum: 0 + maximum: 64 + - description: Rx FIFO 0 0-64 elements / 0-1152 words + minimum: 0 + maximum: 64 + - description: Rx FIFO 1 0-64 elements / 0-1152 words + minimum: 0 + maximum: 64 + - description: Rx Buffers 0-64 elements / 0-1152 words + minimum: 0 + maximum: 64 + - description: Tx Event FIFO 0-32 elements / 0-64 words + minimum: 0 + maximum: 32 + - description: Tx Buffers 0-32 elements / 0-576 words + minimum: 0 + maximum: 32 + maxItems: 1 can-transceiver: $ref: can-transceiver.yaml#
diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt index 5201bc15..cfd1afd 100644 --- a/Documentation/devicetree/bindings/net/dsa/b53.txt +++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
@@ -110,6 +110,9 @@ #size-cells = <0>; ports { + #address-cells = <1>; + #size-cells = <0>; + port0@0 { reg = <0>; label = "lan1";
diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index ac471b6..1c447403 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
@@ -14,25 +14,23 @@ pattern: "^ethernet(@.*)?$" local-mac-address: - allOf: - - $ref: /schemas/types.yaml#definitions/uint8-array - - items: - - minItems: 6 - maxItems: 6 description: Specifies the MAC address that was assigned to the network device. + $ref: /schemas/types.yaml#definitions/uint8-array + items: + - minItems: 6 + maxItems: 6 mac-address: - allOf: - - $ref: /schemas/types.yaml#definitions/uint8-array - - items: - - minItems: 6 - maxItems: 6 description: Specifies the MAC address that was last used by the boot program; should be used in cases where the MAC address assigned to the device by the boot program is different from the local-mac-address property. + $ref: /schemas/types.yaml#definitions/uint8-array + items: + - minItems: 6 + maxItems: 6 max-frame-size: $ref: /schemas/types.yaml#definitions/uint32 @@ -133,15 +131,14 @@ is used for components that can have configurable fifo sizes. managed: - allOf: - - $ref: /schemas/types.yaml#definitions/string - - default: auto - enum: - - auto - - in-band-status description: Specifies the PHY management type. If auto is set and fixed-link is not specified, it uses MDIO for management. + $ref: /schemas/types.yaml#definitions/string + default: auto + enum: + - auto + - in-band-status fixed-link: allOf: @@ -183,11 +180,10 @@ then: properties: speed: - allOf: - - $ref: /schemas/types.yaml#definitions/uint32 - - enum: [10, 100, 1000] description: Link speed. + $ref: /schemas/types.yaml#definitions/uint32 + enum: [10, 100, 1000] full-duplex: $ref: /schemas/types.yaml#definitions/flag
diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index 5aa141c..9b1f114 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -81,7 +81,8 @@ $ref: /schemas/types.yaml#definitions/flag description: If set, indicates the PHY device does not correctly release - the turn around line low at the end of a MDIO transaction. + the turn around line low at end of the control phase of the + MDIO transaction. enet-phy-lane-swap: $ref: /schemas/types.yaml#definitions/flag
diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt index ff8b0f2..9b54378 100644 --- a/Documentation/devicetree/bindings/net/fsl-fec.txt +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
@@ -22,8 +22,11 @@ - fsl,err006687-workaround-present: If present indicates that the system has the hardware workaround for ERR006687 applied and does not need a software workaround. -- gpr: phandle of SoC general purpose register mode. Required for wake on LAN - on some SoCs +- fsl,stop-mode: register bits of stop mode control, the format is + <&gpr req_gpr req_bit>. + gpr is the phandle to general purpose register node. + req_gpr is the gpr register offset for ENET stop request. + req_bit is the gpr bit offset for ENET stop request. -interrupt-names: names of the interrupts listed in interrupts property in the same order. The defaults if not specified are __Number of interrupts__ __Default__ @@ -82,6 +85,7 @@ phy-supply = <®_fec_supply>; phy-handle = <ðphy>; mdio { + clock-frequency = <5000000>; ethphy: ethernet-phy@6 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <6>;
diff --git a/Documentation/devicetree/bindings/net/imx-dwmac.txt b/Documentation/devicetree/bindings/net/imx-dwmac.txt new file mode 100644 index 0000000..921d522 --- /dev/null +++ b/Documentation/devicetree/bindings/net/imx-dwmac.txt
@@ -0,0 +1,56 @@ +IMX8 glue layer controller, NXP imx8 families support Synopsys MAC 5.10a IP. + +This file documents platform glue layer for IMX. +Please see stmmac.txt for the other unchanged properties. + +The device node has following properties. + +Required properties: +- compatible: Should be "nxp,imx8mp-dwmac-eqos" to select glue layer + and "snps,dwmac-5.10a" to select IP version. +- clocks: Must contain a phandle for each entry in clock-names. +- clock-names: Should be "stmmaceth" for the host clock. + Should be "pclk" for the MAC apb clock. + Should be "ptp_ref" for the MAC timer clock. + Should be "tx" for the MAC RGMII TX clock: + Should be "mem" for EQOS MEM clock. + - "mem" clock is required for imx8dxl platform. + - "mem" clock is not required for imx8mp platform. +- interrupt-names: Should contain a list of interrupt names corresponding to + the interrupts in the interrupts property, if available. + Should be "macirq" for the main MAC IRQ + Should be "eth_wake_irq" for the IT which wake up system +- intf_mode: Should be phandle/offset pair. The phandle to the syscon node which + encompases the GPR register, and the offset of the GPR register. + - required for imx8mp platform. + - is optional for imx8dxl platform. + +Optional properties: +- intf_mode: is optional for imx8dxl platform. +- snps,rmii_refclk_ext: to select RMII reference clock from external. + +Example: + eqos: ethernet@30bf0000 { + compatible = "nxp,imx8mp-dwmac-eqos", "snps,dwmac-5.10a"; + reg = <0x30bf0000 0x10000>; + interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "eth_wake_irq", "macirq"; + clocks = <&clk IMX8MP_CLK_ENET_QOS_ROOT>, + <&clk IMX8MP_CLK_QOS_ENET_ROOT>, + <&clk IMX8MP_CLK_ENET_QOS_TIMER>, + <&clk IMX8MP_CLK_ENET_QOS>; + clock-names = "stmmaceth", "pclk", "ptp_ref", "tx"; + assigned-clocks = <&clk IMX8MP_CLK_ENET_AXI>, + <&clk IMX8MP_CLK_ENET_QOS_TIMER>, + <&clk IMX8MP_CLK_ENET_QOS>; + assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_266M>, + <&clk IMX8MP_SYS_PLL2_100M>, + <&clk IMX8MP_SYS_PLL2_125M>; + assigned-clock-rates = <0>, <100000000>, <125000000>; + nvmem-cells = <ð_mac0>; + nvmem-cell-names = "mac-address"; + nvmem_macaddr_swap; + intf_mode = <&gpr 0x4>; + status = "disabled"; + };
diff --git a/Documentation/devicetree/bindings/net/mdio.yaml b/Documentation/devicetree/bindings/net/mdio.yaml index 50c3397..d6a3bf8 100644 --- a/Documentation/devicetree/bindings/net/mdio.yaml +++ b/Documentation/devicetree/bindings/net/mdio.yaml
@@ -31,13 +31,25 @@ maxItems: 1 description: The phandle and specifier for the GPIO that controls the RESET - lines of all PHYs on that MDIO bus. + lines of all devices on that MDIO bus. reset-delay-us: description: - RESET pulse width in microseconds. It applies to all PHY devices - and must therefore be appropriately determined based on all PHY - requirements (maximum value of all per-PHY RESET pulse widths). + RESET pulse width in microseconds. It applies to all MDIO devices + and must therefore be appropriately determined based on all devices + requirements (maximum value of all per-device RESET pulse widths). + + clock-frequency: + description: + Desired MDIO bus clock frequency in Hz. Values greater than IEEE 802.3 + defined 2.5MHz should only be used when all devices on the bus support + the given clock speed. + + suppress-preamble: + description: + The 32 bit preamble should be suppressed. In order for this to + work, all devices on the bus must support suppressed preamble. + type: boolean patternProperties: "^ethernet-phy@[0-9a-f]+$": @@ -48,7 +60,35 @@ minimum: 0 maximum: 31 description: - The ID number for the PHY. + The ID number for the device. + + broken-turn-around: + $ref: /schemas/types.yaml#definitions/flag + description: + If set, indicates the MDIO device does not correctly release + the turn around line low at end of the control phase of the + MDIO transaction. + + resets: + maxItems: 1 + + reset-names: + const: phy + + reset-gpios: + maxItems: 1 + description: + The GPIO phandle and specifier for the MDIO reset signal. + + reset-assert-us: + description: + Delay after the reset was asserted in microseconds. If this + property is missing the delay will be skipped. + + reset-deassert-us: + description: + Delay after the reset was deasserted in microseconds. If + this property is missing the delay will be skipped. required: - reg
diff --git a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml new file mode 100644 index 0000000..aea88e6 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml
@@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mediatek,star-emac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek STAR Ethernet MAC Controller + +maintainers: + - Bartosz Golaszewski <bgolaszewski@baylibre.com> + +description: + This Ethernet MAC is used on the MT8* family of SoCs from MediaTek. + It's compliant with 802.3 standards and supports half- and full-duplex + modes with flow-control as well as CRC offloading and VLAN tags. + +allOf: + - $ref: "ethernet-controller.yaml#" + +properties: + compatible: + enum: + - mediatek,mt8516-eth + - mediatek,mt8518-eth + - mediatek,mt8175-eth + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 3 + maxItems: 3 + + clock-names: + additionalItems: false + items: + - const: core + - const: reg + - const: trans + + mediatek,pericfg: + $ref: /schemas/types.yaml#definitions/phandle + description: + Phandle to the device containing the PERICFG register range. This is used + to control the MII mode. + + mdio: + type: object + description: + Creates and registers an MDIO bus. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - mediatek,pericfg + - phy-handle + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8516-clk.h> + + ethernet: ethernet@11180000 { + compatible = "mediatek,mt8516-eth"; + reg = <0x11180000 0x1000>; + mediatek,pericfg = <&pericfg>; + interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_LOW>; + clocks = <&topckgen CLK_TOP_RG_ETH>, + <&topckgen CLK_TOP_66M_ETH>, + <&topckgen CLK_TOP_133M_ETH>; + clock-names = "core", "reg", "trans"; + phy-handle = <ð_phy>; + phy-mode = "rmii"; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + eth_phy: ethernet-phy@0 { + reg = <0>; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml new file mode 100644 index 0000000..42be0255 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
@@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0+ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nxp,tja11xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP TJA11xx PHY + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + - Florian Fainelli <f.fainelli@gmail.com> + - Heiner Kallweit <hkallweit1@gmail.com> + +description: + Bindings for NXP TJA11xx automotive PHYs + +allOf: + - $ref: ethernet-phy.yaml# + +patternProperties: + "^ethernet-phy@[0-9a-f]+$": + type: object + description: | + Some packages have multiple PHYs. Secondary PHY should be defines as + subnode of the first (parent) PHY. + + properties: + reg: + minimum: 0 + maximum: 31 + description: + The ID number for the child PHY. Should be +1 of parent PHY. + + required: + - reg + +examples: + - | + mdio { + #address-cells = <1>; + #size-cells = <0>; + + tja1101_phy0: ethernet-phy@4 { + reg = <0x4>; + }; + }; + - | + mdio { + #address-cells = <1>; + #size-cells = <0>; + + tja1102_phy0: ethernet-phy@4 { + reg = <0x4>; + #address-cells = <1>; + #size-cells = <0>; + + tja1102_phy1: ethernet-phy@5 { + reg = <0x5>; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/net/qca,ar71xx.txt b/Documentation/devicetree/bindings/net/qca,ar71xx.txt deleted file mode 100644 index 2a33e71..0000000 --- a/Documentation/devicetree/bindings/net/qca,ar71xx.txt +++ /dev/null
@@ -1,45 +0,0 @@ -Required properties: -- compatible: Should be "qca,<soc>-eth". Currently support compatibles are: - qca,ar7100-eth - Atheros AR7100 - qca,ar7240-eth - Atheros AR7240 - qca,ar7241-eth - Atheros AR7241 - qca,ar7242-eth - Atheros AR7242 - qca,ar9130-eth - Atheros AR9130 - qca,ar9330-eth - Atheros AR9330 - qca,ar9340-eth - Atheros AR9340 - qca,qca9530-eth - Qualcomm Atheros QCA9530 - qca,qca9550-eth - Qualcomm Atheros QCA9550 - qca,qca9560-eth - Qualcomm Atheros QCA9560 - -- reg : Address and length of the register set for the device -- interrupts : Should contain eth interrupt -- phy-mode : See ethernet.txt file in the same directory -- clocks: the clock used by the core -- clock-names: the names of the clock listed in the clocks property. These are - "eth" and "mdio". -- resets: Should contain phandles to the reset signals -- reset-names: Should contain the names of reset signal listed in the resets - property. These are "mac" and "mdio" - -Optional properties: -- phy-handle : phandle to the PHY device connected to this device. -- fixed-link : Assume a fixed link. See fixed-link.txt in the same directory. - Use instead of phy-handle. - -Optional subnodes: -- mdio : specifies the mdio bus, used as a container for phy nodes - according to phy.txt in the same directory - -Example: - -ethernet@1a000000 { - compatible = "qca,ar9330-eth"; - reg = <0x1a000000 0x200>; - interrupts = <5>; - resets = <&rst 13>, <&rst 23>; - reset-names = "mac", "mdio"; - clocks = <&pll ATH79_CLK_AHB>, <&pll ATH79_CLK_MDIO>; - clock-names = "eth", "mdio"; - - phy-mode = "gmii"; -};
diff --git a/Documentation/devicetree/bindings/net/qca,ar71xx.yaml b/Documentation/devicetree/bindings/net/qca,ar71xx.yaml new file mode 100644 index 0000000..f99a5aa --- /dev/null +++ b/Documentation/devicetree/bindings/net/qca,ar71xx.yaml
@@ -0,0 +1,216 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/qca,ar71xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: QCA AR71XX MAC + +allOf: + - $ref: ethernet-controller.yaml# + +maintainers: + - Oleksij Rempel <o.rempel@pengutronix.de> + +properties: + compatible: + oneOf: + - items: + - enum: + - qca,ar7100-eth # Atheros AR7100 + - qca,ar7240-eth # Atheros AR7240 + - qca,ar7241-eth # Atheros AR7241 + - qca,ar7242-eth # Atheros AR7242 + - qca,ar9130-eth # Atheros AR9130 + - qca,ar9330-eth # Atheros AR9330 + - qca,ar9340-eth # Atheros AR9340 + - qca,qca9530-eth # Qualcomm Atheros QCA9530 + - qca,qca9550-eth # Qualcomm Atheros QCA9550 + - qca,qca9560-eth # Qualcomm Atheros QCA9560 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#address-cells': + description: number of address cells for the MDIO bus + const: 1 + + '#size-cells': + description: number of size cells on the MDIO bus + const: 0 + + clocks: + items: + - description: MAC main clock + - description: MDIO clock + + clock-names: + items: + - const: eth + - const: mdio + + resets: + items: + - description: MAC reset + - description: MDIO reset + + reset-names: + items: + - const: mac + - const: mdio + +required: + - compatible + - reg + - interrupts + - phy-mode + - clocks + - clock-names + - resets + - reset-names + +examples: + # Lager board + - | + eth0: ethernet@19000000 { + compatible = "qca,ar9330-eth"; + reg = <0x19000000 0x200>; + interrupts = <4>; + resets = <&rst 9>, <&rst 22>; + reset-names = "mac", "mdio"; + clocks = <&pll 1>, <&pll 2>; + clock-names = "eth", "mdio"; + qca,ethcfg = <ðcfg>; + phy-mode = "mii"; + phy-handle = <&phy_port4>; + }; + + eth1: ethernet@1a000000 { + compatible = "qca,ar9330-eth"; + reg = <0x1a000000 0x200>; + interrupts = <5>; + resets = <&rst 13>, <&rst 23>; + reset-names = "mac", "mdio"; + clocks = <&pll 1>, <&pll 2>; + clock-names = "eth", "mdio"; + + phy-mode = "gmii"; + + status = "disabled"; + + fixed-link { + speed = <1000>; + full-duplex; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + switch10: switch@10 { + #address-cells = <1>; + #size-cells = <0>; + + compatible = "qca,ar9331-switch"; + reg = <0x10>; + resets = <&rst 8>; + reset-names = "switch"; + + interrupt-parent = <&miscintc>; + interrupts = <12>; + + interrupt-controller; + #interrupt-cells = <1>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + switch_port0: port@0 { + reg = <0x0>; + label = "cpu"; + ethernet = <ð1>; + + phy-mode = "gmii"; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + + switch_port1: port@1 { + reg = <0x1>; + phy-handle = <&phy_port0>; + phy-mode = "internal"; + + status = "disabled"; + }; + + switch_port2: port@2 { + reg = <0x2>; + phy-handle = <&phy_port1>; + phy-mode = "internal"; + + status = "disabled"; + }; + + switch_port3: port@3 { + reg = <0x3>; + phy-handle = <&phy_port2>; + phy-mode = "internal"; + + status = "disabled"; + }; + + switch_port4: port@4 { + reg = <0x4>; + phy-handle = <&phy_port3>; + phy-mode = "internal"; + + status = "disabled"; + }; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + interrupt-parent = <&switch10>; + + phy_port0: phy@0 { + reg = <0x0>; + interrupts = <0>; + status = "disabled"; + }; + + phy_port1: phy@1 { + reg = <0x1>; + interrupts = <0>; + status = "disabled"; + }; + + phy_port2: phy@2 { + reg = <0x2>; + interrupts = <0>; + status = "disabled"; + }; + + phy_port3: phy@3 { + reg = <0x3>; + interrupts = <0>; + status = "disabled"; + }; + + phy_port4: phy@4 { + reg = <0x4>; + interrupts = <0>; + status = "disabled"; + }; + }; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/net/qca,ar803x.yaml b/Documentation/devicetree/bindings/net/qca,ar803x.yaml index 5a6c9d2..1788884 100644 --- a/Documentation/devicetree/bindings/net/qca,ar803x.yaml +++ b/Documentation/devicetree/bindings/net/qca,ar803x.yaml
@@ -20,15 +20,13 @@ properties: qca,clk-out-frequency: description: Clock output frequency in Hertz. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 25000000, 50000000, 62500000, 125000000 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [25000000, 50000000, 62500000, 125000000] qca,clk-out-strength: description: Clock output driver strength. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 0, 1, 2 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] qca,keep-pll-enabled: description: | @@ -52,17 +50,14 @@ type: object description: Initial data for the VDDIO regulator. Set this to 1.5V or 1.8V. - allOf: - - $ref: /schemas/regulator/regulator.yaml + $ref: /schemas/regulator/regulator.yaml vddh-regulator: type: object description: Dummy subnode to model the external connection of the PHY VDDH regulator to VDDIO. - allOf: - - $ref: /schemas/regulator/regulator.yaml - + $ref: /schemas/regulator/regulator.yaml examples: - |
diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index 140f152..a356127 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
@@ -20,7 +20,10 @@ The GSI is an integral part of the IPA, but it is logically isolated and has a distinct interrupt and a separately-defined address space. - See also soc/qcom/qcom,smp2p.txt and interconnect/interconnect.txt. + See also soc/qcom/qcom,smp2p.txt and interconnect/interconnect.txt. See + iommu/iommu.txt and iommu/arm,smmu.yaml for more information about SMMU + bindings. + - | -------- --------- @@ -54,6 +57,9 @@ - const: ipa-shared - const: gsi + iommus: + maxItems: 1 + clocks: maxItems: 1 @@ -87,16 +93,14 @@ - const: config qcom,smem-states: - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle-array description: State bits used in by the AP to signal the modem. items: - description: Whether the "ipa-clock-enabled" state bit is valid - description: Whether the IPA clock is enabled (if valid) qcom,smem-state-names: - allOf: - - $ref: /schemas/types.yaml#/definitions/string-array + $ref: /schemas/types.yaml#/definitions/string-array description: The names of the state bits used for SMP2P output items: - const: ipa-clock-enabled-valid @@ -126,6 +130,7 @@ required: - compatible + - iommus - reg - clocks - interrupts @@ -164,9 +169,10 @@ modem-init; modem-remoteproc = <&mss_pil>; - reg = <0 0x1e40000 0 0x7000>, - <0 0x1e47000 0 0x2000>, - <0 0x1e04000 0 0x2c000>; + iommus = <&apps_smmu 0x720 0x3>; + reg = <0x1e40000 0x7000>, + <0x1e47000 0x2000>, + <0x1e04000 0x2c000>; reg-names = "ipa-reg", "ipa-shared", "gsi";
diff --git a/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml new file mode 100644 index 0000000..13555a8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.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/qcom,ipq4019-mdio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm IPQ40xx MDIO Controller Device Tree Bindings + +maintainers: + - Robert Marko <robert.marko@sartura.hr> + +allOf: + - $ref: "mdio.yaml#" + +properties: + compatible: + const: qcom,ipq4019-mdio + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +examples: + - | + mdio@90000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "qcom,ipq4019-mdio"; + reg = <0x90000 0x64>; + + ethphy0: ethernet-phy@0 { + reg = <0>; + }; + + ethphy1: ethernet-phy@1 { + reg = <1>; + }; + + ethphy2: ethernet-phy@2 { + reg = <2>; + }; + + ethphy3: ethernet-phy@3 { + reg = <3>; + }; + + ethphy4: ethernet-phy@4 { + reg = <4>; + }; + };
diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt index d220279..709ca6d5 100644 --- a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt +++ b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
@@ -10,9 +10,11 @@ Required properties: - compatible: should contain one of the following: * "qcom,qca6174-bt" + * "qcom,qca9377-bt" * "qcom,wcn3990-bt" * "qcom,wcn3991-bt" * "qcom,wcn3998-bt" + * "qcom,qca6390-bt" Optional properties for compatible string qcom,qca6174-bt: @@ -20,6 +22,10 @@ - clocks: clock provided to the controller (SUSCLK_32KHZ) - firmware-name: specify the name of nvm firmware to load +Optional properties for compatible string qcom,qca9377-bt: + + - max-speed: see Documentation/devicetree/bindings/serial/serial.yaml + Required properties for compatible string qcom,wcn399x-bt: - vddio-supply: VDD_IO supply regulator handle.
diff --git a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml new file mode 100644 index 0000000..f15a5e5 --- /dev/null +++ b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml
@@ -0,0 +1,54 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/realtek-bluetooth.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RTL8723BS/RTL8723CS/RTL8822CS Bluetooth Device Tree Bindings + +maintainers: + - Vasily Khoruzhick <anarsoul@gmail.com> + - Alistair Francis <alistair@alistair23.me> + +description: + RTL8723CS/RTL8723CS/RTL8822CS is WiFi + BT chip. WiFi part is connected over + SDIO, while BT is connected over serial. It speaks H5 protocol with few + extra commands to upload firmware and change module speed. + +properties: + compatible: + oneOf: + - const: "realtek,rtl8723bs-bt" + - const: "realtek,rtl8723cs-bt" + - const: "realtek,rtl8822cs-bt" + + device-wake-gpios: + maxItems: 1 + description: GPIO specifier, used to wakeup the BT module + + enable-gpios: + maxItems: 1 + description: GPIO specifier, used to enable the BT module + + host-wake-gpios: + maxItems: 1 + description: GPIO specifier, used to wakeup the host processor + +required: + - compatible + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + uart1 { + pinctrl-names = "default"; + pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>; + uart-has-rtscts = <1>; + + bluetooth { + compatible = "realtek,rtl8723bs-bt"; + device-wake-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* PL5 */ + host-wakeup-gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */ + }; + };
diff --git a/Documentation/devicetree/bindings/net/renesas,ether.yaml b/Documentation/devicetree/bindings/net/renesas,ether.yaml index 7f84df9..08678af 100644 --- a/Documentation/devicetree/bindings/net/renesas,ether.yaml +++ b/Documentation/devicetree/bindings/net/renesas,ether.yaml
@@ -29,8 +29,9 @@ - renesas,rcar-gen1-ether # a generic R-Car Gen1 device - items: - enum: - - renesas,ether-r8a7745 # device is a part of R8A7745 SoC + - renesas,ether-r8a7742 # device is a part of R8A7742 SoC - renesas,ether-r8a7743 # device is a part of R8A7743 SoC + - renesas,ether-r8a7745 # device is a part of R8A7745 SoC - renesas,ether-r8a7790 # device is a part of R8A7790 SoC - renesas,ether-r8a7791 # device is a part of R8A7791 SoC - renesas,ether-r8a7793 # device is a part of R8A7793 SoC @@ -40,8 +41,8 @@ reg: items: - - description: E-DMAC/feLic registers - - description: TSU registers + - description: E-DMAC/feLic registers + - description: TSU registers minItems: 1 interrupts: @@ -92,7 +93,7 @@ ethernet@ee700000 { compatible = "renesas,ether-r8a7790", "renesas,rcar-gen2-ether"; - reg = <0 0xee700000 0 0x400>; + reg = <0xee700000 0x400>; interrupt-parent = <&gic>; interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>; clocks = <&mstp8_clks R8A7790_CLK_ETHER>;
diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt index 87dad2d..032b76f 100644 --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -5,6 +5,7 @@ Required properties: - compatible: Must contain one or more of the following: + - "renesas,etheravb-r8a7742" for the R8A7742 SoC. - "renesas,etheravb-r8a7743" for the R8A7743 SoC. - "renesas,etheravb-r8a7744" for the R8A7744 SoC. - "renesas,etheravb-r8a7745" for the R8A7745 SoC.
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index e08cd4c..30a1efd 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -27,6 +27,7 @@ - snps,dwmac-3.710 - snps,dwmac-4.00 - snps,dwmac-4.10a + - snps,dwmac-4.20a - snps,dwxgmac - snps,dwxgmac-2.10 @@ -62,6 +63,7 @@ - snps,dwmac-3.710 - snps,dwmac-4.00 - snps,dwmac-4.10a + - snps,dwmac-4.20a - snps,dwxgmac - snps,dwxgmac-2.10 @@ -87,7 +89,8 @@ clocks: minItems: 1 - maxItems: 3 + maxItems: 5 + additionalItems: true items: - description: GMAC main clock - description: Peripheral registers interface clock @@ -97,6 +100,8 @@ clock will be used and this is fine on some platforms. clock-names: + minItems: 1 + maxItems: 5 additionalItems: true contains: enum: @@ -199,14 +204,13 @@ snps,reset-delays-us: deprecated: true - allOf: - - $ref: /schemas/types.yaml#definitions/uint32-array - - minItems: 3 - maxItems: 3 description: Triplet of delays. The 1st cell is reset pre-delay in micro seconds. The 2nd cell is reset pulse in micro seconds. The 3rd cell is reset post-delay in micro seconds. + $ref: /schemas/types.yaml#definitions/uint32-array + minItems: 3 + maxItems: 3 snps,aal: $ref: /schemas/types.yaml#definitions/flag @@ -301,27 +305,24 @@ then: properties: snps,pbl: - allOf: - - $ref: /schemas/types.yaml#definitions/uint32 - - enum: [2, 4, 8] description: Programmable Burst Length (tx and rx) + $ref: /schemas/types.yaml#definitions/uint32 + enum: [2, 4, 8] snps,txpbl: - allOf: - - $ref: /schemas/types.yaml#definitions/uint32 - - enum: [2, 4, 8] description: Tx Programmable Burst Length. If set, DMA tx will use this value rather than snps,pbl. + $ref: /schemas/types.yaml#definitions/uint32 + enum: [2, 4, 8] snps,rxpbl: - allOf: - - $ref: /schemas/types.yaml#definitions/uint32 - - enum: [2, 4, 8] description: Rx Programmable Burst Length. If set, DMA rx will use this value rather than snps,pbl. + $ref: /schemas/types.yaml#definitions/uint32 + enum: [2, 4, 8] snps,no-pbl-x8: $ref: /schemas/types.yaml#definitions/flag @@ -342,6 +343,7 @@ - allwinner,sun50i-a64-emac - snps,dwmac-4.00 - snps,dwmac-4.10a + - snps,dwmac-4.20a - snps,dwxgmac - snps,dwxgmac-2.10 - st,spear600-gmac
diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt deleted file mode 100644 index 4e85fc4..0000000 --- a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt +++ /dev/null
@@ -1,64 +0,0 @@ -* Socionext AVE ethernet controller - -This describes the devicetree bindings for AVE ethernet controller -implemented on Socionext UniPhier SoCs. - -Required properties: - - compatible: Should be - - "socionext,uniphier-pro4-ave4" : for Pro4 SoC - - "socionext,uniphier-pxs2-ave4" : for PXs2 SoC - - "socionext,uniphier-ld11-ave4" : for LD11 SoC - - "socionext,uniphier-ld20-ave4" : for LD20 SoC - - "socionext,uniphier-pxs3-ave4" : for PXs3 SoC - - reg: Address where registers are mapped and size of region. - - interrupts: Should contain the MAC interrupt. - - phy-mode: See ethernet.txt in the same directory. Allow to choose - "rgmii", "rmii", "mii", or "internal" according to the PHY. - The acceptable mode is SoC-dependent. - - phy-handle: Should point to the external phy device. - See ethernet.txt file in the same directory. - - clocks: A phandle to the clock for the MAC. - For Pro4 SoC, that is "socionext,uniphier-pro4-ave4", - another MAC clock, GIO bus clock and PHY clock are also required. - - clock-names: Should contain - - "ether", "ether-gb", "gio", "ether-phy" for Pro4 SoC - - "ether" for others - - resets: A phandle to the reset control for the MAC. For Pro4 SoC, - GIO bus reset is also required. - - reset-names: Should contain - - "ether", "gio" for Pro4 SoC - - "ether" for others - - socionext,syscon-phy-mode: A phandle to syscon with one argument - that configures phy mode. The argument is the ID of MAC instance. - -The MAC address will be determined using the optional properties -defined in ethernet.txt. - -Required subnode: - - mdio: A container for child nodes representing phy nodes. - See phy.txt in the same directory. - -Example: - - ether: ethernet@65000000 { - compatible = "socionext,uniphier-ld20-ave4"; - reg = <0x65000000 0x8500>; - interrupts = <0 66 4>; - phy-mode = "rgmii"; - phy-handle = <ðphy>; - clock-names = "ether"; - clocks = <&sys_clk 6>; - reset-names = "ether"; - resets = <&sys_rst 6>; - socionext,syscon-phy-mode = <&soc_glue 0>; - local-mac-address = [00 00 00 00 00 00]; - - mdio { - #address-cells = <1>; - #size-cells = <0>; - - ethphy: ethphy@1 { - reg = <1>; - }; - }; - };
diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml new file mode 100644 index 0000000..7d84a86 --- /dev/null +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml
@@ -0,0 +1,111 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/socionext,uniphier-ave4.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext AVE ethernet controller + +maintainers: + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> + +description: | + This describes the devicetree bindings for AVE ethernet controller + implemented on Socionext UniPhier SoCs. + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + enum: + - socionext,uniphier-pro4-ave4 + - socionext,uniphier-pxs2-ave4 + - socionext,uniphier-ld11-ave4 + - socionext,uniphier-ld20-ave4 + - socionext,uniphier-pxs3-ave4 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + phy-mode: true + + phy-handle: true + + mac-address: true + + local-mac-address: true + + clocks: + minItems: 1 + maxItems: 4 + + clock-names: + oneOf: + - items: # for Pro4 + - const: gio + - const: ether + - const: ether-gb + - const: ether-phy + - const: ether # for others + + resets: + minItems: 1 + maxItems: 2 + + reset-names: + oneOf: + - items: # for Pro4 + - const: gio + - const: ether + - const: ether # for others + + socionext,syscon-phy-mode: + $ref: /schemas/types.yaml#definitions/phandle-array + description: + A phandle to syscon with one argument that configures phy mode. + The argument is the ID of MAC instance. + + mdio: + $ref: mdio.yaml# + +required: + - compatible + - reg + - interrupts + - phy-mode + - phy-handle + - clocks + - clock-names + - resets + - reset-names + - mdio + +additionalProperties: false + +examples: + - | + ether: ethernet@65000000 { + compatible = "socionext,uniphier-ld20-ave4"; + reg = <0x65000000 0x8500>; + interrupts = <0 66 4>; + phy-mode = "rgmii"; + phy-handle = <ðphy>; + clock-names = "ether"; + clocks = <&sys_clk 6>; + reset-names = "ether"; + resets = <&sys_rst 6>; + socionext,syscon-phy-mode = <&soc_glue 0>; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + ethphy: ethernet-phy@1 { + reg = <1>; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt deleted file mode 100644 index a90eef1..0000000 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.txt +++ /dev/null
@@ -1,44 +0,0 @@ -STMicroelectronics STM32 / MCU DWMAC glue layer controller - -This file documents platform glue layer for stmmac. -Please see stmmac.txt for the other unchanged properties. - -The device node has following properties. - -Required properties: -- compatible: For MCU family should be "st,stm32-dwmac" to select glue, and - "snps,dwmac-3.50a" to select IP version. - For MPU family should be "st,stm32mp1-dwmac" to select - glue, and "snps,dwmac-4.20a" to select IP version. -- clocks: Must contain a phandle for each entry in clock-names. -- clock-names: Should be "stmmaceth" for the host clock. - Should be "mac-clk-tx" for the MAC TX clock. - Should be "mac-clk-rx" for the MAC RX clock. - For MPU family need to add also "ethstp" for power mode clock -- interrupt-names: Should contain a list of interrupt names corresponding to - the interrupts in the interrupts property, if available. - Should be "macirq" for the main MAC IRQ - Should be "eth_wake_irq" for the IT which wake up system -- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which - encompases the glue register, and the offset of the control register. - -Optional properties: -- clock-names: For MPU family "eth-ck" for PHY without quartz -- st,eth-clk-sel (boolean) : set this property in RGMII PHY when you want to select RCC clock instead of ETH_CLK125. -- st,eth-ref-clk-sel (boolean) : set this property in RMII mode when you have PHY without crystal 50MHz and want to select RCC clock instead of ETH_REF_CLK. - -Example: - - ethernet@40028000 { - compatible = "st,stm32-dwmac", "snps,dwmac-3.50a"; - reg = <0x40028000 0x8000>; - reg-names = "stmmaceth"; - interrupts = <0 61 0>, <0 62 0>; - interrupt-names = "macirq", "eth_wake_irq"; - clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx"; - clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>; - st,syscon = <&syscfg 0x4>; - snps,pbl = <8>; - snps,mixed-burst; - dma-ranges; - };
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml new file mode 100644 index 0000000..fafa34c --- /dev/null +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
@@ -0,0 +1,148 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 BayLibre, SAS +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/net/stm32-dwmac.yaml#" +$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> + +description: + This file documents platform glue layer for stmmac. + +# We need a select here so we don't match all nodes with 'snps,dwmac' +select: + properties: + compatible: + contains: + enum: + - st,stm32-dwmac + - st,stm32mp1-dwmac + required: + - compatible + +allOf: + - $ref: "snps,dwmac.yaml#" + +properties: + compatible: + oneOf: + - items: + - enum: + - st,stm32mp1-dwmac + - const: snps,dwmac-4.20a + - items: + - enum: + - st,stm32-dwmac + - const: snps,dwmac-4.10a + - items: + - enum: + - st,stm32-dwmac + - const: snps,dwmac-3.50a + + clocks: + minItems: 3 + maxItems: 5 + items: + - description: GMAC main clock + - description: MAC TX clock + - description: MAC RX clock + - description: For MPU family, used for power mode + - description: For MPU family, used for PHY without quartz + + clock-names: + minItems: 3 + maxItems: 5 + contains: + enum: + - stmmaceth + - mac-clk-tx + - mac-clk-rx + - ethstp + - eth-ck + + st,syscon: + $ref: "/schemas/types.yaml#/definitions/phandle-array" + description: + Should be phandle/offset pair. The phandle to the syscon node which + encompases the glue register, and the offset of the control register + + st,eth-clk-sel: + description: + set this property in RGMII PHY when you want to select RCC clock instead of ETH_CLK125. + type: boolean + + st,eth-ref-clk-sel: + description: + set this property in RMII mode when you have PHY without crystal 50MHz and want to + select RCC clock instead of ETH_REF_CLK. + type: boolean + +required: + - compatible + - clocks + - clock-names + - st,syscon + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/stm32mp1-clks.h> + #include <dt-bindings/reset/stm32mp1-resets.h> + #include <dt-bindings/mfd/stm32h7-rcc.h> + //Example 1 + ethernet0: ethernet@5800a000 { + compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a"; + reg = <0x5800a000 0x2000>; + reg-names = "stmmaceth"; + interrupts = <&intc GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq"; + clock-names = "stmmaceth", + "mac-clk-tx", + "mac-clk-rx", + "ethstp", + "eth-ck"; + clocks = <&rcc ETHMAC>, + <&rcc ETHTX>, + <&rcc ETHRX>, + <&rcc ETHSTP>, + <&rcc ETHCK_K>; + st,syscon = <&syscfg 0x4>; + snps,pbl = <2>; + snps,axi-config = <&stmmac_axi_config_0>; + snps,tso; + phy-mode = "rgmii"; + }; + + //Example 2 (MCU example) + ethernet1: ethernet@40028000 { + compatible = "st,stm32-dwmac", "snps,dwmac-3.50a"; + reg = <0x40028000 0x8000>; + reg-names = "stmmaceth"; + interrupts = <0 61 0>, <0 62 0>; + interrupt-names = "macirq", "eth_wake_irq"; + clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx"; + clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>; + st,syscon = <&syscfg 0x4>; + snps,pbl = <8>; + snps,mixed-burst; + phy-mode = "mii"; + }; + + //Example 3 + ethernet2: ethernet@40027000 { + compatible = "st,stm32-dwmac", "snps,dwmac-4.10a"; + reg = <0x40028000 0x8000>; + reg-names = "stmmaceth"; + interrupts = <61>; + interrupt-names = "macirq"; + clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx"; + clocks = <&rcc 62>, <&rcc 61>, <&rcc 60>; + st,syscon = <&syscfg 0x4>; + snps,pbl = <8>; + phy-mode = "mii"; + };
diff --git a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml index 976f139..3ea0e12 100644 --- a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml +++ b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml
@@ -23,14 +23,14 @@ oneOf: - const: ti,cpsw-switch - items: - - const: ti,am335x-cpsw-switch - - const: ti,cpsw-switch + - const: ti,am335x-cpsw-switch + - const: ti,cpsw-switch - items: - - const: ti,am4372-cpsw-switch - - const: ti,cpsw-switch + - const: ti,am4372-cpsw-switch + - const: ti,cpsw-switch - items: - - const: ti,dra7-cpsw-switch - - const: ti,cpsw-switch + - const: ti,dra7-cpsw-switch + - const: ti,cpsw-switch reg: maxItems: 1 @@ -105,8 +105,7 @@ description: label associated with this port ti,dual-emac-pvid: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 1 maximum: 1024 description: @@ -150,10 +149,9 @@ patternProperties: "^mdio@": type: object - allOf: - - $ref: "ti,davinci-mdio.yaml#" description: CPSW MDIO bus. + $ref: "ti,davinci-mdio.yaml#" required:
diff --git a/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml b/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml index 242ac49..d454c1f 100644 --- a/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml +++ b/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml
@@ -18,33 +18,31 @@ properties: compatible: oneOf: - - const: ti,davinci_mdio - - items: - - const: ti,keystone_mdio - - const: ti,davinci_mdio - - items: - - const: ti,cpsw-mdio - - const: ti,davinci_mdio - - items: - - const: ti,am4372-mdio - - const: ti,cpsw-mdio - - const: ti,davinci_mdio + - const: ti,davinci_mdio + - items: + - const: ti,keystone_mdio + - const: ti,davinci_mdio + - items: + - const: ti,cpsw-mdio + - const: ti,davinci_mdio + - items: + - const: ti,am4372-mdio + - const: ti,cpsw-mdio + - const: ti,davinci_mdio reg: maxItems: 1 bus_freq: - maximum: 2500000 - description: - MDIO Bus frequency + maximum: 2500000 + description: MDIO Bus frequency ti,hwmods: description: TI hwmod name deprecated: true - allOf: - - $ref: /schemas/types.yaml#/definitions/string-array - - items: - const: davinci_mdio + $ref: /schemas/types.yaml#/definitions/string-array + items: + const: davinci_mdio if: properties:
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt deleted file mode 100644 index 44e2a4f..0000000 --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt +++ /dev/null
@@ -1,68 +0,0 @@ -* Texas Instruments - dp83867 Giga bit ethernet phy - -Required properties: - - reg - The ID number for the phy, usually a small integer - - ti,rx-internal-delay - RGMII Receive Clock Delay - see dt-bindings/net/ti-dp83867.h - for applicable values. Required only if interface type is - PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_RXID - - ti,tx-internal-delay - RGMII Transmit Clock Delay - see dt-bindings/net/ti-dp83867.h - for applicable values. Required only if interface type is - PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID - -Note: If the interface type is PHY_INTERFACE_MODE_RGMII the TX/RX clock delays - will be left at their default values, as set by the PHY's pin strapping. - The default strapping will use a delay of 2.00 ns. Thus - PHY_INTERFACE_MODE_RGMII, by default, does not behave as RGMII with no - internal delay, but as PHY_INTERFACE_MODE_RGMII_ID. The device tree - should use "rgmii-id" if internal delays are desired as this may be - changed in future to cause "rgmii" mode to disable delays. - -Optional property: - - ti,min-output-impedance - MAC Interface Impedance control to set - the programmable output impedance to - minimum value (35 ohms). - - ti,max-output-impedance - MAC Interface Impedance control to set - the programmable output impedance to - maximum value (70 ohms). - - ti,dp83867-rxctrl-strap-quirk - This denotes the fact that the - board has RX_DV/RX_CTRL pin strapped in - mode 1 or 2. To ensure PHY operation, - there are specific actions that - software needs to take when this pin is - strapped in these modes. See data manual - for details. - - ti,clk-output-sel - Muxing option for CLK_OUT pin. See dt-bindings/net/ti-dp83867.h - for applicable values. The CLK_OUT pin can also - be disabled by this property. When omitted, the - PHY's default will be left as is. - - ti,sgmii-ref-clock-output-enable - This denotes which - SGMII configuration is used (4 or 6-wire modes). - Some MACs work with differential SGMII clock. - See data manual for details. - - - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h - for applicable values (deprecated) - - -tx-fifo-depth - As defined in the ethernet-controller.yaml. Values for - the depth can be found in dt-bindings/net/ti-dp83867.h - -rx-fifo-depth - As defined in the ethernet-controller.yaml. Values for - the depth can be found in dt-bindings/net/ti-dp83867.h - -Note: ti,min-output-impedance and ti,max-output-impedance are mutually - exclusive. When both properties are present ti,max-output-impedance - takes precedence. - -Default child nodes are standard Ethernet PHY device -nodes as described in Documentation/devicetree/bindings/net/phy.txt - -Example: - - ethernet-phy@0 { - reg = <0>; - ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>; - ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_75_NS>; - tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>; - }; - -Datasheet can be found: -http://www.ti.com/product/DP83867IR/datasheet
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml new file mode 100644 index 0000000..554dcd7 --- /dev/null +++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
@@ -0,0 +1,127 @@ +# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause) +# Copyright (C) 2019 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/net/ti,dp83867.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: TI DP83867 ethernet PHY + +allOf: + - $ref: "ethernet-controller.yaml#" + +maintainers: + - Dan Murphy <dmurphy@ti.com> + +description: | + The DP83867 device is a robust, low power, fully featured Physical Layer + transceiver with integrated PMD sublayers to support 10BASE-Te, 100BASE-TX + and 1000BASE-T Ethernet protocols. + + The DP83867 is designed for easy implementation of 10/100/1000 Mbps Ethernet + LANs. It interfaces directly to twisted pair media via an external + transformer. This device interfaces directly to the MAC layer through the + IEEE 802.3 Standard Media Independent Interface (MII), the IEEE 802.3 Gigabit + Media Independent Interface (GMII) or Reduced GMII (RGMII). + + Specifications about the charger can be found at: + https://www.ti.com/lit/gpn/dp83867ir + +properties: + reg: + maxItems: 1 + + ti,min-output-impedance: + type: boolean + description: | + MAC Interface Impedance control to set the programmable output impedance + to a minimum value (35 ohms). + + ti,max-output-impedance: + type: boolean + description: | + MAC Interface Impedance control to set the programmable output impedance + to a maximum value (70 ohms). + Note: ti,min-output-impedance and ti,max-output-impedance are mutually + exclusive. When both properties are present ti,max-output-impedance + takes precedence. + + tx-fifo-depth: + $ref: /schemas/types.yaml#definitions/uint32 + description: | + Transmitt FIFO depth see dt-bindings/net/ti-dp83867.h for values + + rx-fifo-depth: + $ref: /schemas/types.yaml#definitions/uint32 + description: | + Receive FIFO depth see dt-bindings/net/ti-dp83867.h for values + + ti,clk-output-sel: + $ref: /schemas/types.yaml#definitions/uint32 + description: | + Muxing option for CLK_OUT pin. See dt-bindings/net/ti-dp83867.h + for applicable values. The CLK_OUT pin can also be disabled by this + property. When omitted, the PHY's default will be left as is. + + ti,rx-internal-delay: + $ref: /schemas/types.yaml#definitions/uint32 + description: | + RGMII Receive Clock Delay - see dt-bindings/net/ti-dp83867.h + for applicable values. Required only if interface type is + PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_RXID. + + ti,tx-internal-delay: + $ref: /schemas/types.yaml#definitions/uint32 + description: | + RGMII Transmit Clock Delay - see dt-bindings/net/ti-dp83867.h + for applicable values. Required only if interface type is + PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID. + + Note: If the interface type is PHY_INTERFACE_MODE_RGMII the TX/RX clock + delays will be left at their default values, as set by the PHY's pin + strapping. The default strapping will use a delay of 2.00 ns. Thus + PHY_INTERFACE_MODE_RGMII, by default, does not behave as RGMII with no + internal delay, but as PHY_INTERFACE_MODE_RGMII_ID. The device tree + should use "rgmii-id" if internal delays are desired as this may be + changed in future to cause "rgmii" mode to disable delays. + + ti,dp83867-rxctrl-strap-quirk: + type: boolean + description: | + This denotes the fact that the board has RX_DV/RX_CTRL pin strapped in + mode 1 or 2. To ensure PHY operation, there are specific actions that + software needs to take when this pin is strapped in these modes. + See data manual for details. + + ti,sgmii-ref-clock-output-enable: + type: boolean + description: | + This denotes which SGMII configuration is used (4 or 6-wire modes). + Some MACs work with differential SGMII clock. See data manual for details. + + ti,fifo-depth: + deprecated: true + $ref: /schemas/types.yaml#definitions/uint32 + description: | + Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h for applicable + values. + +required: + - reg + +examples: + - | + #include <dt-bindings/net/ti-dp83867.h> + mdio0 { + #address-cells = <1>; + #size-cells = <0>; + ethphy0: ethernet-phy@0 { + reg = <0>; + tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>; + rx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>; + ti,max-output-impedance; + ti,clk-output-sel = <DP83867_CLK_O_SEL_CHN_A_RCLK>; + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>; + ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_75_NS>; + }; + };
diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml index 6fe3e45..5b69ef0 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
@@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0 +# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause) # Copyright (C) 2019 Texas Instruments Incorporated %YAML 1.2 ---
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml index 78bf511..1745793 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
@@ -103,8 +103,7 @@ type: object description: CPSW2G NUSS external ports - allOf: - - $ref: ethernet-controller.yaml# + $ref: ethernet-controller.yaml# properties: reg: @@ -139,11 +138,17 @@ patternProperties: "^mdio@[0-9a-f]+$": type: object - allOf: - - $ref: "ti,davinci-mdio.yaml#" + $ref: "ti,davinci-mdio.yaml#" + description: CPSW MDIO bus. + "^cpts@[0-9a-f]+": + type: object + $ref: "ti,k3-am654-cpts.yaml#" + description: + CPSW Common Platform Time Sync (CPTS) module. + required: - compatible - reg @@ -164,38 +169,44 @@ #include <dt-bindings/pinctrl/k3.h> #include <dt-bindings/soc/ti,sci_pm_domain.h> #include <dt-bindings/net/ti-dp83867.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> - mcu_cpsw: ethernet@46000000 { - compatible = "ti,am654-cpsw-nuss"; + bus { #address-cells = <2>; #size-cells = <2>; - reg = <0x0 0x46000000 0x0 0x200000>; - reg-names = "cpsw_nuss"; - ranges = <0x0 0x0 0x46000000 0x0 0x200000>; - dma-coherent; - clocks = <&k3_clks 5 10>; - clock-names = "fck"; - power-domains = <&k3_pds 5 TI_SCI_PD_EXCLUSIVE>; - pinctrl-names = "default"; - pinctrl-0 = <&mcu_cpsw_pins_default &mcu_mdio_pins_default>; - dmas = <&mcu_udmap 0xf000>, - <&mcu_udmap 0xf001>, - <&mcu_udmap 0xf002>, - <&mcu_udmap 0xf003>, - <&mcu_udmap 0xf004>, - <&mcu_udmap 0xf005>, - <&mcu_udmap 0xf006>, - <&mcu_udmap 0xf007>, - <&mcu_udmap 0x7000>; - dma-names = "tx0", "tx1", "tx2", "tx3", "tx4", "tx5", "tx6", "tx7", - "rx"; + mcu_cpsw: ethernet@46000000 { + compatible = "ti,am654-cpsw-nuss"; + #address-cells = <2>; + #size-cells = <2>; + reg = <0x0 0x46000000 0x0 0x200000>; + reg-names = "cpsw_nuss"; + ranges = <0x0 0x0 0x0 0x46000000 0x0 0x200000>; + dma-coherent; + clocks = <&k3_clks 5 10>; + clock-names = "fck"; + power-domains = <&k3_pds 5 TI_SCI_PD_EXCLUSIVE>; + pinctrl-names = "default"; + pinctrl-0 = <&mcu_cpsw_pins_default &mcu_mdio_pins_default>; - ethernet-ports { - #address-cells = <1>; - #size-cells = <0>; + dmas = <&mcu_udmap 0xf000>, + <&mcu_udmap 0xf001>, + <&mcu_udmap 0xf002>, + <&mcu_udmap 0xf003>, + <&mcu_udmap 0xf004>, + <&mcu_udmap 0xf005>, + <&mcu_udmap 0xf006>, + <&mcu_udmap 0xf007>, + <&mcu_udmap 0x7000>; + dma-names = "tx0", "tx1", "tx2", "tx3", "tx4", "tx5", "tx6", "tx7", + "rx"; - cpsw_port1: port@1 { + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + cpsw_port1: port@1 { reg = <1>; ti,mac-only; label = "port1"; @@ -204,22 +215,34 @@ phy-mode = "rgmii-rxid"; phy-handle = <&phy0>; - }; - }; + }; + }; - davinci_mdio: mdio@f00 { - compatible = "ti,cpsw-mdio","ti,davinci_mdio"; - reg = <0x0 0xf00 0x0 0x100>; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&k3_clks 5 10>; - clock-names = "fck"; - bus_freq = <1000000>; + davinci_mdio: mdio@f00 { + compatible = "ti,cpsw-mdio","ti,davinci_mdio"; + reg = <0x0 0xf00 0x0 0x100>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&k3_clks 5 10>; + clock-names = "fck"; + bus_freq = <1000000>; - phy0: ethernet-phy@0 { + phy0: ethernet-phy@0 { reg = <0>; ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>; ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>; - }; + }; + }; + }; + + cpts@3d000 { + compatible = "ti,am65-cpts"; + reg = <0x0 0x3d000 0x0 0x400>; + clocks = <&k3_clks 18 2>; + clock-names = "cpts"; + interrupts-extended = <&gic500 GIC_SPI 858 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "cpts"; + ti,cpts-ext-ts-inputs = <4>; + ti,cpts-periodic-outputs = <2>; }; };
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml new file mode 100644 index 0000000..9b71179 --- /dev/null +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml
@@ -0,0 +1,143 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/ti,k3-am654-cpts.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: The TI AM654x/J721E Common Platform Time Sync (CPTS) module Device Tree Bindings + +maintainers: + - Grygorii Strashko <grygorii.strashko@ti.com> + - Sekhar Nori <nsekhar@ti.com> + +description: |+ + The TI AM654x/J721E CPTS module is used to facilitate host control of time + sync operations. + Main features of CPTS module are + - selection of multiple external clock sources + - Software control of time sync events via interrupt or polling + - 64-bit timestamp mode in ns with PPM and nudge adjustment. + - hardware timestamp push inputs (HWx_TS_PUSH) + - timestamp counter compare output (TS_COMP) + - timestamp counter bit output (TS_SYNC) + - periodic Generator function outputs (TS_GENFx) + - Ethernet Enhanced Scheduled Traffic Operations (CPTS_ESTFn) (TSN) + - external hardware timestamp push inputs (HWx_TS_PUSH) timestamping + + Depending on integration it enables compliance with the IEEE 1588-2008 + standard for a precision clock synchronization protocol, Ethernet Enhanced + Scheduled Traffic Operations (CPTS_ESTFn) and PCIe Subsystem Precision Time + Measurement (PTM). + + TI AM654x/J721E SoCs has several similar CPTS modules integrated into the + different parts of the system which could be synchronized with each other + - Main CPTS + - MCU CPSW CPTS with IEEE 1588-2008 support + - PCIe subsystem CPTS for PTM support + + Depending on CPTS module integration and when CPTS is integral part of + another module (MCU CPSW for example) "compatible" and "reg" can + be omitted - parent module is fully responsible for CPTS enabling and + configuration. + +properties: + $nodename: + pattern: "^cpts@[0-9a-f]+$" + + compatible: + oneOf: + - const: ti,am65-cpts + - const: ti,j721e-cpts + + reg: + maxItems: 1 + description: + The physical base address and size of CPTS IO range + + reg-names: + items: + - const: cpts + + clocks: + description: CPTS reference clock + + clock-names: + items: + - const: cpts + + interrupts: + items: + - description: CPTS events interrupt + + interrupt-names: + items: + - const: cpts + + ti,cpts-ext-ts-inputs: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 8 + description: + Number of hardware timestamp push inputs (HWx_TS_PUSH) + + ti,cpts-periodic-outputs: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 8 + description: + Number of timestamp Generator function outputs (TS_GENFx) + + refclk-mux: + type: object + description: CPTS reference clock multiplexer clock + properties: + '#clock-cells': + const: 0 + + clocks: + maxItems: 8 + + assigned-clocks: + maxItems: 1 + + assigned-clocks-parents: + maxItems: 1 + + required: + - clocks + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - interrupt-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + cpts@310d0000 { + compatible = "ti,am65-cpts"; + reg = <0x310d0000 0x400>; + reg-names = "cpts"; + clocks = <&main_cpts_mux>; + clock-names = "cpts"; + interrupts-extended = <&k3_irq 163 0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "cpts"; + ti,cpts-periodic-outputs = <6>; + ti,cpts-ext-ts-inputs = <8>; + + main_cpts_mux: refclk-mux { + #clock-cells = <0>; + clocks = <&k3_clks 118 5>, <&k3_clks 118 11>, + <&k3_clks 157 91>, <&k3_clks 157 77>, + <&k3_clks 157 102>, <&k3_clks 157 80>, + <&k3_clks 120 3>, <&k3_clks 121 3>; + assigned-clocks = <&main_cpts_mux>; + assigned-clock-parents = <&k3_clks 118 11>; + }; + }; +
diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt index 3a76d8f..ab7e7a0 100644 --- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
@@ -25,6 +25,9 @@ - mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data - big-endian: if the radio eeprom partition is written in big-endian, specify this property +- mediatek,eeprom-merge-otp: Merge EEPROM data with OTP data. Can be used on + boards where the flash calibration data is generic and specific calibration + data should be pulled from the OTP ROM The MAC address can as well be set with corresponding optional properties defined in net/ethernet.txt.
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt index 71bf91f..65ee68e 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -96,6 +96,17 @@ - qcom,coexist-gpio-pin : gpio pin number information to support coex which will be used by wifi firmware. +* Subnodes +The ath10k wifi node can contain one optional firmware subnode. +Firmware subnode is needed when the platform does not have TustZone. +The firmware subnode must have: + +- iommus: + Usage: required + Value type: <prop-encoded-array> + Definition: A list of phandle and IOMMU specifier pairs. + + Example (to supply PCI based wifi block details): In this example, the node is defined as child node of the PCI controller. @@ -196,4 +207,7 @@ memory-region = <&wifi_msa_mem>; iommus = <&apps_smmu 0x0040 0x1>; qcom,msa-fixed-perm; + wifi-firmware { + iommus = <&apps_iommu 0xc22 0x1>; + }; };
diff --git a/Documentation/devicetree/bindings/nvmem/imx-iim.txt b/Documentation/devicetree/bindings/nvmem/imx-iim.txt deleted file mode 100644 index 1978c5b..0000000 --- a/Documentation/devicetree/bindings/nvmem/imx-iim.txt +++ /dev/null
@@ -1,22 +0,0 @@ -Freescale i.MX IC Identification Module (IIM) device tree bindings - -This binding represents the IC Identification Module (IIM) found on -i.MX25, i.MX27, i.MX31, i.MX35, i.MX51 and i.MX53 SoCs. - -Required properties: -- compatible: should be one of - "fsl,imx25-iim", "fsl,imx27-iim", - "fsl,imx31-iim", "fsl,imx35-iim", - "fsl,imx51-iim", "fsl,imx53-iim", -- reg: Should contain the register base and length. -- interrupts: Should contain the interrupt for the IIM -- clocks: Should contain a phandle pointing to the gated peripheral clock. - -Example: - - iim: iim@63f98000 { - compatible = "fsl,imx53-iim", "fsl,imx27-iim"; - reg = <0x63f98000 0x4000>; - interrupts = <69>; - clocks = <&clks IMX5_CLK_IIM_GATE>; - };
diff --git a/Documentation/devicetree/bindings/nvmem/imx-iim.yaml b/Documentation/devicetree/bindings/nvmem/imx-iim.yaml new file mode 100644 index 0000000..9cc43e7 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/imx-iim.yaml
@@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/imx-iim.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX IC Identification Module (IIM) device tree bindings + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +description: | + This binding represents the IC Identification Module (IIM) found on + i.MX25, i.MX27, i.MX31, i.MX35, i.MX51 and i.MX53 SoCs. + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + enum: + - fsl,imx25-iim + - fsl,imx27-iim + - fsl,imx31-iim + - fsl,imx35-iim + - fsl,imx51-iim + - fsl,imx53-iim + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx5-clock.h> + + iim: efuse@63f98000 { + compatible = "fsl,imx53-iim"; + reg = <0x63f98000 0x4000>; + interrupts = <69>; + clocks = <&clks IMX5_CLK_IIM_GATE>; + }; + +...
diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt deleted file mode 100644 index 6e346d5..0000000 --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt +++ /dev/null
@@ -1,50 +0,0 @@ -Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings - -This binding represents the on-chip eFuse OTP controller found on -i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX, i.MX6UL, i.MX6ULL/ULZ, i.MX6SLL, -i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM, i.MX8MN and i.MX8MP SoCs. - -Required properties: -- compatible: should be one of - "fsl,imx6q-ocotp" (i.MX6Q/D/DL/S), - "fsl,imx6sl-ocotp" (i.MX6SL), or - "fsl,imx6sx-ocotp" (i.MX6SX), - "fsl,imx6ul-ocotp" (i.MX6UL), - "fsl,imx6ull-ocotp" (i.MX6ULL/ULZ), - "fsl,imx7d-ocotp" (i.MX7D/S), - "fsl,imx6sll-ocotp" (i.MX6SLL), - "fsl,imx7ulp-ocotp" (i.MX7ULP), - "fsl,imx8mq-ocotp" (i.MX8MQ), - "fsl,imx8mm-ocotp" (i.MX8MM), - "fsl,imx8mn-ocotp" (i.MX8MN), - "fsl,imx8mp-ocotp" (i.MX8MP), - followed by "syscon". -- #address-cells : Should be 1 -- #size-cells : Should be 1 -- reg: Should contain the register base and length. -- clocks: Should contain a phandle pointing to the gated peripheral clock. - -Optional properties: -- read-only: disable write access - -Optional Child nodes: - -- Data cells of ocotp: - Detailed bindings are described in bindings/nvmem/nvmem.txt - -Example: - ocotp: ocotp@21bc000 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,imx6sx-ocotp", "syscon"; - reg = <0x021bc000 0x4000>; - clocks = <&clks IMX6SX_CLK_OCOTP>; - - tempmon_calib: calib@38 { - reg = <0x38 4>; - }; - - tempmon_temp_grade: temp-grade@20 { - reg = <0x20 4>; - }; - };
diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml new file mode 100644 index 0000000..fe9c7df --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
@@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/imx-ocotp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +description: | + This binding represents the on-chip eFuse OTP controller found on + i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX, i.MX6UL, i.MX6ULL/ULZ, i.MX6SLL, + i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM, i.MX8MN and i.MX8MP SoCs. + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + items: + - enum: + - fsl,imx6q-ocotp + - fsl,imx6sl-ocotp + - fsl,imx6sx-ocotp + - fsl,imx6ul-ocotp + - fsl,imx6ull-ocotp + - fsl,imx7d-ocotp + - fsl,imx6sll-ocotp + - fsl,imx7ulp-ocotp + - fsl,imx8mq-ocotp + - fsl,imx8mm-ocotp + - fsl,imx8mn-ocotp + - fsl,imx8mp-ocotp + - const: syscon + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + clocks: + maxItems: 1 + +required: + - "#address-cells" + - "#size-cells" + - compatible + - reg + +patternProperties: + "^.*@[0-9a-f]+$": + type: object + + properties: + reg: + maxItems: 1 + description: + Offset and size in bytes within the storage device. + + required: + - reg + + additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx6sx-clock.h> + + ocotp: efuse@21bc000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,imx6sx-ocotp", "syscon"; + reg = <0x021bc000 0x4000>; + clocks = <&clks IMX6SX_CLK_OCOTP>; + + cpu_speed_grade: speed-grade@10 { + reg = <0x10 4>; + }; + + tempmon_calib: calib@38 { + reg = <0x38 4>; + }; + + tempmon_temp_grade: temp-grade@20 { + reg = <0x20 4>; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt deleted file mode 100644 index 372c72f..0000000 --- a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt +++ /dev/null
@@ -1,24 +0,0 @@ -On-Chip OTP Memory for Freescale i.MX23/i.MX28 - -Required properties : -- compatible : - - "fsl,imx23-ocotp" for i.MX23 - - "fsl,imx28-ocotp" for i.MX28 -- #address-cells : Should be 1 -- #size-cells : Should be 1 -- reg : Address and length of OTP controller registers -- clocks : Should contain a reference to the hbus clock - -= Data cells = -Are child nodes of mxs-ocotp, bindings of which as described in -bindings/nvmem/nvmem.txt - -Example for i.MX28: - - ocotp: ocotp@8002c000 { - compatible = "fsl,imx28-ocotp", "fsl,ocotp"; - #address-cells = <1>; - #size-cells = <1>; - reg = <0x8002c000 0x2000>; - clocks = <&clks 25>; - };
diff --git a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml new file mode 100644 index 0000000..ff317fd7 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
@@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/mxs-ocotp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: On-Chip OTP Memory for Freescale i.MX23/i.MX28 + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + enum: + - fsl,imx23-ocotp + - fsl,imx28-ocotp + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + ocotp: efuse@8002c000 { + compatible = "fsl,imx28-ocotp"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x8002c000 0x2000>; + clocks = <&clks 25>; + }; + +...
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml index 6598022..b459f9d 100644 --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
@@ -67,8 +67,6 @@ required: - reg - additionalProperties: false - examples: - | #include <dt-bindings/gpio/gpio.h>
diff --git a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt deleted file mode 100644 index 265bdb7..0000000 --- a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt +++ /dev/null
@@ -1,54 +0,0 @@ -= Rockchip eFuse device tree bindings = - -Required properties: -- compatible: Should be one of the following. - - "rockchip,rk3066a-efuse" - for RK3066a SoCs. - - "rockchip,rk3188-efuse" - for RK3188 SoCs. - - "rockchip,rk3228-efuse" - for RK3228 SoCs. - - "rockchip,rk3288-efuse" - for RK3288 SoCs. - - "rockchip,rk3328-efuse" - for RK3328 SoCs. - - "rockchip,rk3368-efuse" - for RK3368 SoCs. - - "rockchip,rk3399-efuse" - for RK3399 SoCs. -- reg: Should contain the registers location and exact eFuse size -- clocks: Should be the clock id of eFuse -- clock-names: Should be "pclk_efuse" - -Optional properties: -- rockchip,efuse-size: Should be exact eFuse size in byte, the eFuse - size in property <reg> will be invalid if define this property. - -Deprecated properties: -- compatible: "rockchip,rockchip-efuse" - Old efuse compatible value compatible to rk3066a, rk3188 and rk3288 - efuses - -= Data cells = -Are child nodes of eFuse, bindings of which as described in -bindings/nvmem/nvmem.txt - -Example: - - efuse: efuse@ffb40000 { - compatible = "rockchip,rk3288-efuse"; - reg = <0xffb40000 0x20>; - #address-cells = <1>; - #size-cells = <1>; - clocks = <&cru PCLK_EFUSE256>; - clock-names = "pclk_efuse"; - - /* Data cells */ - cpu_leakage: cpu_leakage { - reg = <0x17 0x1>; - }; - }; - -= Data consumers = -Are device nodes which consume nvmem data cells. - -Example: - - cpu_leakage { - ... - nvmem-cells = <&cpu_leakage>; - nvmem-cell-names = "cpu_leakage"; - };
diff --git a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml new file mode 100644 index 0000000..3ae00b0 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml
@@ -0,0 +1,70 @@ +# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/rockchip-efuse.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip eFuse device tree bindings + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + enum: + - rockchip,rk3066a-efuse + - rockchip,rk3188-efuse + - rockchip,rk3228-efuse + - rockchip,rk3288-efuse + - rockchip,rk3328-efuse + - rockchip,rk3368-efuse + - rockchip,rk3399-efuse + + # Deprecated: old compatible value for rk3066a, rk3188 and rk3288 + - rockchip,rockchip-efuse + + reg: + description: + Registers location and eFuse size. + maxItems: 1 + + clocks: + description: + eFuse clock id. + maxItems: 1 + + clock-names: + const: pclk_efuse + + rockchip,efuse-size: + description: + eFuse size in bytes. The eFuse size in property <reg> will be invalid if + this property is defined. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - reg + - clocks + - clock-names + +examples: + - | + #include <dt-bindings/clock/rk3288-cru.h> + efuse: efuse@ffb40000 { + compatible = "rockchip,rk3288-efuse"; + reg = <0xffb40000 0x20>; + #address-cells = <1>; + #size-cells = <1>; + clocks = <&cru PCLK_EFUSE256>; + clock-names = "pclk_efuse"; + + /* Data cells */ + cpu_leakage: cpu_leakage@17 { + reg = <0x17 0x1>; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml index d84deb4..c11c99f 100644 --- a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml +++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml
@@ -24,6 +24,18 @@ - st,stm32f4-otp - st,stm32mp15-bsec +patternProperties: + "^.*@[0-9a-f]+$": + type: object + + properties: + st,non-secure-otp: + description: | + This property explicits a factory programmed area that both secure + and non-secure worlds can access. It is needed when, by default, the + related area can only be reached by the secure world. + type: boolean + required: - "#address-cells" - "#size-cells" @@ -41,6 +53,11 @@ calib@22c { reg = <0x22c 0x2>; }; + + mac_addr@e4 { + reg = <0xe4 0x8>; + st,non-secure-otp; + }; }; ...
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt index 6859227..9d16d41 100644 --- a/Documentation/devicetree/bindings/opp/opp.txt +++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -83,9 +83,14 @@ Required properties: - opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. This is a - required property for all device nodes but devices like power domains. The - power domain nodes must have another (implementation dependent) property which - uniquely identifies the OPP nodes. + required property for all device nodes, unless another "required" property to + uniquely identify the OPP nodes exists. Devices like power domains must have + another (implementation dependent) property. + +- opp-peak-kBps: Peak bandwidth in kilobytes per second, expressed as an array + of 32-bit big-endian integers. Each element of the array represents the + peak bandwidth value of each interconnect path. The number of elements should + match the number of interconnect paths. Optional properties: - opp-microvolt: voltage in micro Volts. @@ -132,6 +137,12 @@ - opp-level: A value representing the performance level of the device, expressed as a 32-bit integer. +- opp-avg-kBps: Average bandwidth in kilobytes per second, expressed as an array + of 32-bit big-endian integers. Each element of the array represents the + average bandwidth value of each interconnect path. The number of elements + should match the number of interconnect paths. This property is only + meaningful in OPP tables where opp-peak-kBps is present. + - clock-latency-ns: Specifies the maximum possible transition latency (in nanoseconds) for switching to this OPP from any other OPP.
diff --git a/Documentation/devicetree/bindings/pci/aardvark-pci.txt b/Documentation/devicetree/bindings/pci/aardvark-pci.txt index 310ef71..2b8ca92 100644 --- a/Documentation/devicetree/bindings/pci/aardvark-pci.txt +++ b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
@@ -19,6 +19,9 @@ - interrupt-map-mask and interrupt-map: standard PCI properties to define the mapping of the PCIe interface to interrupt numbers. - bus-range: PCI bus numbers covered + - phys: the PCIe PHY handle + - max-link-speed: see pci.txt + - reset-gpios: see pci.txt In addition, the Device Tree describing an Aardvark PCIe controller must include a sub-node that describes the legacy interrupt controller @@ -48,6 +51,7 @@ <0 0 0 2 &pcie_intc 1>, <0 0 0 3 &pcie_intc 2>, <0 0 0 4 &pcie_intc 3>; + phys = <&comphy1 0>; pcie_intc: interrupt-controller { interrupt-controller; #interrupt-cells = <1>;
diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml index 77d3e81..8680a0f 100644 --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -56,6 +56,8 @@ description: Indicates usage of spread-spectrum clocking. type: boolean + aspm-no-l0s: true + required: - reg - dma-ranges
diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml index 2996f8d..50ce5d7 100644 --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml
@@ -10,7 +10,7 @@ - Tom Joseph <tjoseph@cadence.com> allOf: - - $ref: "cdns-pcie.yaml#" + - $ref: "cdns-pcie-ep.yaml#" - $ref: "pci-ep.yaml#" properties:
diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml index cabbe46..84a8f09 100644 --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml
@@ -45,8 +45,6 @@ #size-cells = <2>; bus-range = <0x0 0xff>; linux,pci-domain = <0>; - cdns,max-outbound-regions = <16>; - cdns,no-bar-match-nbits = <32>; vendor-id = <0x17cd>; device-id = <0x0200>; @@ -57,6 +55,7 @@ ranges = <0x02000000 0x0 0x42000000 0x0 0x42000000 0x0 0x1000000>, <0x01000000 0x0 0x43000000 0x0 0x43000000 0x0 0x0010000>; + dma-ranges = <0x02000000 0x0 0x0 0x0 0x0 0x1 0x00000000>; #interrupt-cells = <0x1>;
diff --git a/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml new file mode 100644 index 0000000..016a5f6 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml
@@ -0,0 +1,24 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/pci/cdns-pcie-ep.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Cadence PCIe Device + +maintainers: + - Tom Joseph <tjoseph@cadence.com> + +allOf: + - $ref: "cdns-pcie.yaml#" + +properties: + cdns,max-outbound-regions: + description: maximum number of outbound regions + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 32 + default: 32 + +required: + - cdns,max-outbound-regions
diff --git a/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml b/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml index ab6e43b..303078a 100644 --- a/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml
@@ -14,14 +14,22 @@ - $ref: "cdns-pcie.yaml#" properties: + cdns,max-outbound-regions: + description: maximum number of outbound regions + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 32 + default: 32 + deprecated: true + cdns,no-bar-match-nbits: description: Set into the no BAR match register to configure the number of least significant bits kept during inbound (PCIe -> AXI) address translations - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 64 default: 32 + deprecated: true msi-parent: true
diff --git a/Documentation/devicetree/bindings/pci/cdns-pcie.yaml b/Documentation/devicetree/bindings/pci/cdns-pcie.yaml index 6887ccc..02553d5e 100644 --- a/Documentation/devicetree/bindings/pci/cdns-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/cdns-pcie.yaml
@@ -10,14 +10,6 @@ - Tom Joseph <tjoseph@cadence.com> properties: - cdns,max-outbound-regions: - description: maximum number of outbound regions - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 1 - maximum: 32 - default: 32 - phys: description: One per lane if more than one in the list. If only one PHY listed it must
diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml index 48a98da..64b2c64 100644 --- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
@@ -71,10 +71,9 @@ max-link-speed: description: Specify PCI Gen for link capability. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 1, 2, 3, 4 ] - - default: 1 + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 3, 4] + default: 1 bus-range: description: Range of bus numbers associated with this controller.
diff --git a/Documentation/devicetree/bindings/pci/loongson.yaml b/Documentation/devicetree/bindings/pci/loongson.yaml new file mode 100644 index 0000000..30e7cf1 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/loongson.yaml
@@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/loongson.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson PCI Host Controller + +maintainers: + - Jiaxun Yang <jiaxun.yang@flygoat.com> + +description: |+ + PCI host controller found on Loongson PCHs and SoCs. + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + +properties: + compatible: + oneOf: + - const: loongson,ls2k-pci + - const: loongson,ls7a-pci + - const: loongson,rs780e-pci + + reg: + minItems: 1 + maxItems: 2 + items: + - description: CFG0 standard config space register + - description: CFG1 extended config space register + + ranges: + minItems: 1 + maxItems: 3 + + +required: + - compatible + - reg + - ranges + +examples: + - | + + bus { + #address-cells = <2>; + #size-cells = <2>; + pcie@1a000000 { + compatible = "loongson,rs780e-pci"; + device_type = "pci"; + #address-cells = <3>; + #size-cells = <2>; + + // CPU_PHYSICAL(2) SIZE(2) + reg = <0x0 0x1a000000 0x0 0x2000000>; + + // BUS_ADDRESS(3) CPU_PHYSICAL(2) SIZE(2) + ranges = <0x01000000 0x0 0x00004000 0x0 0x00004000 0x0 0x00004000>, + <0x02000000 0x0 0x40000000 0x0 0x40000000 0x0 0x40000000>; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/pci/pci-ep.yaml b/Documentation/devicetree/bindings/pci/pci-ep.yaml index b3df100..0f8e575 100644 --- a/Documentation/devicetree/bindings/pci/pci-ep.yaml +++ b/Documentation/devicetree/bindings/pci/pci-ep.yaml
@@ -18,21 +18,18 @@ max-functions: description: Maximum number of functions that can be configured - allOf: - - $ref: /schemas/types.yaml#/definitions/uint8 + $ref: /schemas/types.yaml#/definitions/uint8 minimum: 1 default: 1 maximum: 255 max-link-speed: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 enum: [ 1, 2, 3, 4 ] num-lanes: description: maximum number of lanes - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 1 default: 1 maximum: 16
diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt index b94078f58..aeba38f 100644 --- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
@@ -6,7 +6,8 @@ OHCI and EHCI controllers. Required properties: -- compatible: "renesas,pci-r8a7743" for the R8A7743 SoC; +- compatible: "renesas,pci-r8a7742" for the R8A7742 SoC; + "renesas,pci-r8a7743" for the R8A7743 SoC; "renesas,pci-r8a7744" for the R8A7744 SoC; "renesas,pci-r8a7745" for the R8A7745 SoC; "renesas,pci-r8a7790" for the R8A7790 SoC;
diff --git a/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml b/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml new file mode 100644 index 0000000..aa483c7 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml
@@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Renesas Electronics Europe GmbH - https://www.renesas.com/eu/en/ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/rcar-pci-ep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car PCIe Endpoint + +maintainers: + - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> + - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> + +properties: + compatible: + items: + - const: renesas,r8a774c0-pcie-ep + - const: renesas,rcar-gen3-pcie-ep + + reg: + maxItems: 5 + + reg-names: + items: + - const: apb-base + - const: memory0 + - const: memory1 + - const: memory2 + - const: memory3 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: pcie + + max-functions: + minimum: 1 + maximum: 1 + +required: + - compatible + - reg + - reg-names + - resets + - power-domains + - clocks + - clock-names + - max-functions + +examples: + - | + #include <dt-bindings/clock/r8a774c0-cpg-mssr.h> + #include <dt-bindings/power/r8a774c0-sysc.h> + + pcie0_ep: pcie-ep@fe000000 { + compatible = "renesas,r8a774c0-pcie-ep", + "renesas,rcar-gen3-pcie-ep"; + reg = <0xfe000000 0x80000>, + <0xfe100000 0x100000>, + <0xfe200000 0x200000>, + <0x30000000 0x8000000>, + <0x38000000 0x8000000>; + reg-names = "apb-base", "memory0", "memory1", "memory2", "memory3"; + resets = <&cpg 319>; + power-domains = <&sysc R8A774C0_PD_ALWAYS_ON>; + clocks = <&cpg CPG_MOD 319>; + clock-names = "pcie"; + max-functions = /bits/ 8 <1>; + };
diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt index 12702c8..1041c44a 100644 --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -11,7 +11,8 @@ "renesas,pcie-r8a7791" for the R8A7791 SoC; "renesas,pcie-r8a7793" for the R8A7793 SoC; "renesas,pcie-r8a7795" for the R8A7795 SoC; - "renesas,pcie-r8a7796" for the R8A7796 SoC; + "renesas,pcie-r8a7796" for the R8A77960 SoC; + "renesas,pcie-r8a77961" for the R8A77961 SoC; "renesas,pcie-r8a77980" for the R8A77980 SoC; "renesas,pcie-r8a77990" for the R8A77990 SoC; "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 or
diff --git a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml new file mode 100644 index 0000000..f0558b9 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml
@@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/socionext,uniphier-pcie-ep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier PCIe endpoint controller + +description: | + UniPhier PCIe endpoint controller is based on the Synopsys DesignWare + PCI core. It shares common features with the PCIe DesignWare core and + inherits common properties defined in + Documentation/devicetree/bindings/pci/designware-pcie.txt. + +maintainers: + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> + +allOf: + - $ref: "pci-ep.yaml#" + +properties: + compatible: + const: socionext,uniphier-pro5-pcie-ep + + reg: + maxItems: 4 + + reg-names: + items: + - const: dbi + - const: dbi2 + - const: link + - const: addr_space + + clocks: + maxItems: 2 + + clock-names: + items: + - const: gio + - const: link + + resets: + maxItems: 2 + + reset-names: + items: + - const: gio + - const: link + + num-ib-windows: + const: 16 + + num-ob-windows: + const: 16 + + num-lanes: true + + phys: + maxItems: 1 + + phy-names: + const: pcie-phy + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - resets + - reset-names + +additionalProperties: false + +examples: + - | + pcie_ep: pcie-ep@66000000 { + compatible = "socionext,uniphier-pro5-pcie-ep"; + reg-names = "dbi", "dbi2", "link", "addr_space"; + reg = <0x66000000 0x1000>, <0x66001000 0x1000>, + <0x66010000 0x10000>, <0x67000000 0x400000>; + clock-names = "gio", "link"; + clocks = <&sys_clk 12>, <&sys_clk 24>; + reset-names = "gio", "link"; + resets = <&sys_rst 12>, <&sys_rst 24>; + num-ib-windows = <16>; + num-ob-windows = <16>; + num-lanes = <4>; + phy-names = "pcie-phy"; + phys = <&pcie_phy>; + };
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml index 88683db..18c1ec5 100644 --- a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml +++ b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml
@@ -30,6 +30,6 @@ - | mpphy: phy@0 { compatible = "amlogic,axg-mipi-pcie-analog-phy"; - reg = <0x0 0x0 0x0 0xc>; + reg = <0x0 0xc>; #phy-cells = <1>; };
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-pcie.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-pcie.yaml index 086478a..45f3d72 100644 --- a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-pcie.yaml +++ b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-pcie.yaml
@@ -44,7 +44,7 @@ #include <dt-bindings/phy/phy.h> pcie_phy: pcie-phy@ff644000 { compatible = "amlogic,axg-pcie-phy"; - reg = <0x0 0xff644000 0x0 0x1c>; + reg = <0xff644000 0x1c>; resets = <&reset RESET_PCIE_PHY>; phys = <&mipi_analog_phy PHY_TYPE_PCIE>; phy-names = "analog";
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson8b-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson8b-usb2-phy.yaml new file mode 100644 index 0000000..03c4809 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/amlogic,meson8b-usb2-phy.yaml
@@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/amlogic,meson8b-usb2-phy.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson8, Meson8b, Meson8m2 and GXBB USB2 PHY + +maintainers: + - Martin Blumenstingl <martin.blumenstingl@googlemail.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - amlogic,meson8-usb2-phy + - amlogic,meson8b-usb2-phy + - amlogic,meson8m2-usb2-phy + - const: amlogic,meson-mx-usb2-phy + - const: amlogic,meson-gxbb-usb2-phy + + reg: + maxItems: 1 + + clocks: + minItems: 2 + + clock-names: + items: + - const: usb_general + - const: usb + + resets: + minItems: 1 + + "#phy-cells": + const: 0 + + phy-supply: + description: + Phandle to a regulator that provides power to the PHY. This + regulator will be managed during the PHY power on/off sequence. + +required: + - compatible + - reg + - clocks + - clock-names + - "#phy-cells" + +additionalProperties: false + +examples: + - | + usb-phy@c0000000 { + compatible = "amlogic,meson-gxbb-usb2-phy"; + reg = <0xc0000000 0x20>; + resets = <&reset_usb_phy>; + clocks = <&clk_usb_general>, <&reset_usb>; + clock-names = "usb_general", "usb"; + phy-supply = <&usb_vbus>; + #phy-cells = <0>; + };
diff --git a/Documentation/devicetree/bindings/phy/calxeda-combophy.txt b/Documentation/devicetree/bindings/phy/calxeda-combophy.txt deleted file mode 100644 index 6622bdb..0000000 --- a/Documentation/devicetree/bindings/phy/calxeda-combophy.txt +++ /dev/null
@@ -1,17 +0,0 @@ -Calxeda Highbank Combination Phys for SATA - -Properties: -- compatible : Should be "calxeda,hb-combophy" -- #phy-cells: Should be 1. -- reg : Address and size for Combination Phy registers. -- phydev: device ID for programming the combophy. - -Example: - - combophy5: combo-phy@fff5d000 { - compatible = "calxeda,hb-combophy"; - #phy-cells = <1>; - reg = <0xfff5d000 0x1000>; - phydev = <31>; - }; -
diff --git a/Documentation/devicetree/bindings/phy/calxeda-combophy.yaml b/Documentation/devicetree/bindings/phy/calxeda-combophy.yaml new file mode 100644 index 0000000..41ee16e --- /dev/null +++ b/Documentation/devicetree/bindings/phy/calxeda-combophy.yaml
@@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/calxeda-combophy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Calxeda Highbank Combination PHYs binding for SATA + +description: | + The Calxeda Combination PHYs connect the SoC to the internal fabric + and to SATA connectors. The PHYs support multiple protocols (SATA, + SGMII, PCIe) and can be assigned to different devices (SATA or XGMAC + controller). + Programming the PHYs is typically handled by those device drivers, + not by a dedicated PHY driver. + +maintainers: + - Andre Przywara <andre.przywara@arm.com> + +properties: + compatible: + const: calxeda,hb-combophy + + '#phy-cells': + const: 1 + + reg: + maxItems: 1 + + phydev: + description: device ID for programming the ComboPHY. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 31 + +required: + - compatible + - reg + - phydev + - '#phy-cells' + +additionalProperties: false + +examples: + - | + combophy5: combo-phy@fff5d000 { + compatible = "calxeda,hb-combophy"; + #phy-cells = <1>; + reg = <0xfff5d000 0x1000>; + phydev = <31>; + };
diff --git a/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml b/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml new file mode 100644 index 0000000..3a07285 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml
@@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright (c) 2020 NXP +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/cdns,salvo-phy.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Cadence SALVO PHY + +maintainers: + - Peter Chen <peter.chen@nxp.com> + +properties: + compatible: + enum: + - nxp,salvo-phy + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: salvo_phy_clk + + power-domains: + maxItems: 1 + + "#phy-cells": + const: 0 + +required: + - compatible + - reg + - "#phy-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/firmware/imx/rsrc.h> + + usb3phy: usb3-phy@5b160000 { + compatible = "nxp,salvo-phy"; + reg = <0x5b160000 0x40000>; + clocks = <&usb3_lpcg 4>; + clock-names = "salvo_phy_clk"; + power-domains = <&pd IMX_SC_R_USB_2_PHY>; + #phy-cells = <0>; + };
diff --git a/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml new file mode 100644 index 0000000..347d0cd --- /dev/null +++ b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml
@@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/intel,combo-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel ComboPhy Subsystem + +maintainers: + - Dilip Kota <eswara.kota@linux.intel.com> + +description: | + Intel Combophy subsystem supports PHYs for PCIe, EMAC and SATA + controllers. A single Combophy provides two PHY instances. + +properties: + $nodename: + pattern: "combophy(@.*|-[0-9a-f])*$" + + compatible: + items: + - const: intel,combophy-lgm + - const: intel,combo-phy + + clocks: + maxItems: 1 + + reg: + items: + - description: ComboPhy core registers + - description: PCIe app core control registers + + reg-names: + items: + - const: core + - const: app + + resets: + maxItems: 4 + + reset-names: + items: + - const: phy + - const: core + - const: iphy0 + - const: iphy1 + + intel,syscfg: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: Chip configuration registers handle and ComboPhy instance id + + intel,hsio: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: HSIO registers handle and ComboPhy instance id on NOC + + intel,aggregation: + type: boolean + description: | + Specify the flag to configure ComboPHY in dual lane mode. + + intel,phy-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Mode of the two phys in ComboPhy. + See dt-bindings/phy/phy.h for values. + + "#phy-cells": + const: 1 + +required: + - compatible + - clocks + - reg + - reg-names + - intel,syscfg + - intel,hsio + - intel,phy-mode + - "#phy-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/phy/phy.h> + combophy@d0a00000 { + compatible = "intel,combophy-lgm", "intel,combo-phy"; + clocks = <&cgu0 1>; + #phy-cells = <1>; + reg = <0xd0a00000 0x40000>, + <0xd0a40000 0x1000>; + reg-names = "core", "app"; + resets = <&rcu0 0x50 6>, + <&rcu0 0x50 17>, + <&rcu0 0x50 23>, + <&rcu0 0x50 24>; + reset-names = "phy", "core", "iphy0", "iphy1"; + intel,syscfg = <&sysconf 0>; + intel,hsio = <&hsiol 0>; + intel,phy-mode = <PHY_TYPE_PCIE>; + intel,aggregation; + };
diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml index 9a346d6..77bb530 100644 --- a/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml +++ b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
@@ -23,7 +23,7 @@ properties: compatible: - const: intel,lgm-emmc-phy + const: intel,lgm-emmc-phy "#phy-cells": const: 0
diff --git a/Documentation/devicetree/bindings/phy/meson-gxl-usb3-phy.txt b/Documentation/devicetree/bindings/phy/meson-gxl-usb3-phy.txt deleted file mode 100644 index 114947e..0000000 --- a/Documentation/devicetree/bindings/phy/meson-gxl-usb3-phy.txt +++ /dev/null
@@ -1,31 +0,0 @@ -* Amlogic Meson GXL and GXM USB3 PHY and OTG detection binding - -Required properties: -- compatible: Should be "amlogic,meson-gxl-usb3-phy" -- #phys-cells: must be 0 (see phy-bindings.txt in this directory) -- reg: The base address and length of the registers -- interrupts: the interrupt specifier for the OTG detection -- clocks: phandles to the clocks for - - the USB3 PHY - - and peripheral mode/OTG detection -- clock-names: must contain "phy" and "peripheral" -- resets: phandle to the reset lines for: - - the USB3 PHY and - - peripheral mode/OTG detection -- reset-names: must contain "phy" and "peripheral" - -Optional properties: -- phy-supply: see phy-bindings.txt in this directory - - -Example: - usb3_phy0: phy@78080 { - compatible = "amlogic,meson-gxl-usb3-phy"; - #phy-cells = <0>; - reg = <0x0 0x78080 0x0 0x20>; - interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clkc CLKID_USB_OTG>, <&clkc_AO CLKID_AO_CEC_32K>; - clock-names = "phy", "peripheral"; - resets = <&reset RESET_USB_OTG>, <&reset RESET_USB_OTG>; - reset-names = "phy", "peripheral"; - };
diff --git a/Documentation/devicetree/bindings/phy/meson8b-usb2-phy.txt b/Documentation/devicetree/bindings/phy/meson8b-usb2-phy.txt deleted file mode 100644 index d81d73a..0000000 --- a/Documentation/devicetree/bindings/phy/meson8b-usb2-phy.txt +++ /dev/null
@@ -1,28 +0,0 @@ -* Amlogic Meson8, Meson8b and GXBB USB2 PHY - -Required properties: -- compatible: Depending on the platform this should be one of: - "amlogic,meson8-usb2-phy" - "amlogic,meson8b-usb2-phy" - "amlogic,meson-gxbb-usb2-phy" -- reg: The base address and length of the registers -- #phys-cells: should be 0 (see phy-bindings.txt in this directory) -- clocks: phandle and clock identifier for the phy clocks -- clock-names: "usb_general" and "usb" - -Optional properties: -- resets: reference to the reset controller -- phy-supply: see phy-bindings.txt in this directory - - -Example: - -usb0_phy: usb-phy@c0000000 { - compatible = "amlogic,meson-gxbb-usb2-phy"; - #phy-cells = <0>; - reg = <0x0 0xc0000000 0x0 0x20>; - resets = <&reset RESET_USB_OTG>; - clocks = <&clkc CLKID_USB>, <&clkc CLKID_USB0>; - clock-names = "usb_general", "usb"; - phy-supply = <&usb_vbus>; -};
diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml index c779a3c..4071438 100644 --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
@@ -77,24 +77,21 @@ description: Specifies the type of PHY for which the group of PHY lanes is used. Refer include/dt-bindings/phy/phy.h. Constants from the header should be used. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [1, 2, 3, 4, 5, 6] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 3, 4, 5, 6] cdns,num-lanes: description: Number of DisplayPort lanes. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [1, 2, 4] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4] default: 4 cdns,max-bit-rate: description: Maximum DisplayPort link bit rate to use, in Mbps - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [2160, 2430, 2700, 3240, 4320, 5400, 8100] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [2160, 2430, 2700, 3240, 4320, 5400, 8100] default: 8100 required: @@ -120,24 +117,30 @@ examples: - | #include <dt-bindings/phy/phy.h> - torrent_phy: torrent-phy@f0fb500000 { - compatible = "cdns,torrent-phy"; - reg = <0xf0 0xfb500000 0x0 0x00100000>, - <0xf0 0xfb030a00 0x0 0x00000040>; - reg-names = "torrent_phy", "dptx_phy"; - resets = <&phyrst 0>; - clocks = <&ref_clk>; - clock-names = "refclk"; - #address-cells = <1>; - #size-cells = <0>; - torrent_phy_dp: phy@0 { - reg = <0>; - resets = <&phyrst 1>, <&phyrst 2>, - <&phyrst 3>, <&phyrst 4>; - #phy-cells = <0>; - cdns,phy-type = <PHY_TYPE_DP>; - cdns,num-lanes = <4>; - cdns,max-bit-rate = <8100>; - }; + + bus { + #address-cells = <2>; + #size-cells = <2>; + + torrent-phy@f0fb500000 { + compatible = "cdns,torrent-phy"; + reg = <0xf0 0xfb500000 0x0 0x00100000>, + <0xf0 0xfb030a00 0x0 0x00000040>; + reg-names = "torrent_phy", "dptx_phy"; + resets = <&phyrst 0>; + clocks = <&ref_clk>; + clock-names = "refclk"; + #address-cells = <1>; + #size-cells = <0>; + phy@0 { + reg = <0>; + resets = <&phyrst 1>, <&phyrst 2>, + <&phyrst 3>, <&phyrst 4>; + #phy-cells = <0>; + cdns,phy-type = <PHY_TYPE_DP>; + cdns,num-lanes = <4>; + cdns,max-bit-rate = <8100>; + }; + }; }; ...
diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml new file mode 100644 index 0000000..f80f889 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
@@ -0,0 +1,317 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/qcom,qmp-phy.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm QMP PHY controller + +maintainers: + - Manu Gautam <mgautam@codeaurora.org> + +description: + QMP phy controller supports physical layer functionality for a number of + controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB. + +properties: + compatible: + enum: + - qcom,ipq8074-qmp-pcie-phy + - qcom,msm8996-qmp-pcie-phy + - qcom,msm8996-qmp-ufs-phy + - qcom,msm8996-qmp-usb3-phy + - qcom,msm8998-qmp-pcie-phy + - qcom,msm8998-qmp-ufs-phy + - qcom,msm8998-qmp-usb3-phy + - qcom,sdm845-qhp-pcie-phy + - qcom,sdm845-qmp-pcie-phy + - qcom,sdm845-qmp-ufs-phy + - qcom,sdm845-qmp-usb3-uni-phy + - qcom,sm8150-qmp-ufs-phy + - qcom,sm8250-qmp-ufs-phy + + reg: + items: + - description: Address and length of PHY's common serdes block. + + "#clock-cells": + enum: [ 1, 2 ] + + "#address-cells": + enum: [ 1, 2 ] + + "#size-cells": + enum: [ 1, 2 ] + + ranges: true + + clocks: + minItems: 1 + maxItems: 4 + + clock-names: + minItems: 1 + maxItems: 4 + + resets: + minItems: 1 + maxItems: 3 + + reset-names: + minItems: 1 + maxItems: 3 + + vdda-phy-supply: + description: + Phandle to a regulator supply to PHY core block. + + vdda-pll-supply: + description: + Phandle to 1.8V regulator supply to PHY refclk pll block. + + vddp-ref-clk-supply: + description: + Phandle to a regulator supply to any specific refclk + pll block. + +#Required nodes: +patternProperties: + "^phy@[0-9a-f]+$": + type: object + description: + Each device node of QMP phy is required to have as many child nodes as + the number of lanes the PHY has. + +required: + - compatible + - reg + - "#clock-cells" + - "#address-cells" + - "#size-cells" + - ranges + - clocks + - clock-names + - resets + - reset-names + - vdda-phy-supply + - vdda-pll-supply + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,sdm845-qmp-usb3-uni-phy + then: + properties: + clocks: + items: + - description: Phy aux clock. + - description: Phy config clock. + - description: 19.2 MHz ref clk. + - description: Phy common block aux clock. + clock-names: + items: + - const: aux + - const: cfg_ahb + - const: ref + - const: com_aux + resets: + items: + - description: reset of phy block. + - description: phy common block reset. + reset-names: + items: + - const: phy + - const: common + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8996-qmp-pcie-phy + then: + properties: + clocks: + items: + - description: Phy aux clock. + - description: Phy config clock. + - description: 19.2 MHz ref clk. + clock-names: + items: + - const: aux + - const: cfg_ahb + - const: ref + resets: + items: + - description: reset of phy block. + - description: phy common block reset. + - description: phy's ahb cfg block reset. + reset-names: + items: + - const: phy + - const: common + - const: cfg + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8996-qmp-usb3-phy + - qcom,msm8998-qmp-pcie-phy + - qcom,msm8998-qmp-usb3-phy + then: + properties: + clocks: + items: + - description: Phy aux clock. + - description: Phy config clock. + - description: 19.2 MHz ref clk. + clock-names: + items: + - const: aux + - const: cfg_ahb + - const: ref + resets: + items: + - description: reset of phy block. + - description: phy common block reset. + reset-names: + items: + - const: phy + - const: common + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8996-qmp-ufs-phy + then: + properties: + clocks: + items: + - description: 19.2 MHz ref clk. + clock-names: + items: + - const: ref + resets: + items: + - description: PHY reset in the UFS controller. + reset-names: + items: + - const: ufsphy + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8998-qmp-ufs-phy + - qcom,sdm845-qmp-ufs-phy + - qcom,sm8150-qmp-ufs-phy + - qcom,sm8250-qmp-ufs-phy + then: + properties: + clocks: + items: + - description: 19.2 MHz ref clk. + - description: Phy reference aux clock. + clock-names: + items: + - const: ref + - const: ref_aux + resets: + items: + - description: PHY reset in the UFS controller. + 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 + - if: + properties: + compatible: + contains: + enum: + - qcom,sdm845-qhp-pcie-phy + - qcom,sdm845-qmp-pcie-phy + then: + properties: + clocks: + items: + - description: Phy aux clock. + - description: Phy config clock. + - description: 19.2 MHz ref clk. + - description: Phy refgen clk. + clock-names: + items: + - const: aux + - const: cfg_ahb + - const: ref + - const: refgen + resets: + items: + - description: reset of phy block. + reset-names: + items: + - const: phy + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + usb_2_qmpphy: phy-wrapper@88eb000 { + compatible = "qcom,sdm845-qmp-usb3-uni-phy"; + reg = <0x088eb000 0x18c>; + #clock-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x088eb000 0x2000>; + + clocks = <&gcc GCC_USB3_SEC_PHY_AUX_CLK >, + <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>, + <&gcc GCC_USB3_SEC_CLKREF_CLK>, + <&gcc GCC_USB3_SEC_PHY_COM_AUX_CLK>; + clock-names = "aux", "cfg_ahb", "ref", "com_aux"; + + resets = <&gcc GCC_USB3PHY_PHY_SEC_BCR>, + <&gcc GCC_USB3_PHY_SEC_BCR>; + reset-names = "phy", "common"; + + vdda-phy-supply = <&vdda_usb2_ss_1p2>; + vdda-pll-supply = <&vdda_usb2_ss_core>; + + usb_2_ssphy: phy@200 { + reg = <0x200 0x128>, + <0x400 0x1fc>, + <0x800 0x218>, + <0x600 0x70>; + #clock-cells = <0>; + #phy-cells = <0>; + clocks = <&gcc GCC_USB3_SEC_PHY_PIPE_CLK>; + clock-names = "pipe0"; + clock-output-names = "usb3_uni_phy_pipe_clk_src"; + }; + };
diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml new file mode 100644 index 0000000..6e24875 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
@@ -0,0 +1,140 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/qcom,qmp-usb3-dp-phy.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm QMP USB3 DP PHY controller + +maintainers: + - Manu Gautam <mgautam@codeaurora.org> + +properties: + compatible: + enum: + - qcom,sc7180-qmp-usb3-phy + - qcom,sdm845-qmp-usb3-phy + reg: + items: + - description: Address and length of PHY's common serdes block. + - description: Address and length of the DP_COM control block. + + reg-names: + items: + - const: reg-base + - const: dp_com + + "#clock-cells": + enum: [ 1, 2 ] + + "#address-cells": + enum: [ 1, 2 ] + + "#size-cells": + enum: [ 1, 2 ] + + ranges: true + + clocks: + items: + - description: Phy aux clock. + - description: Phy config clock. + - description: 19.2 MHz ref clk. + - description: Phy common block aux clock. + + clock-names: + items: + - const: aux + - const: cfg_ahb + - const: ref + - const: com_aux + + resets: + items: + - description: reset of phy block. + - description: phy common block reset. + + reset-names: + items: + - const: phy + - const: common + + vdda-phy-supply: + description: + Phandle to a regulator supply to PHY core block. + + vdda-pll-supply: + description: + Phandle to 1.8V regulator supply to PHY refclk pll block. + + vddp-ref-clk-supply: + description: + Phandle to a regulator supply to any specific refclk + pll block. + +#Required nodes: +patternProperties: + "^phy@[0-9a-f]+$": + type: object + description: + Each device node of QMP phy is required to have as many child nodes as + the number of lanes the PHY has. + +required: + - compatible + - reg + - reg-names + - "#clock-cells" + - "#address-cells" + - "#size-cells" + - ranges + - clocks + - clock-names + - resets + - reset-names + - vdda-phy-supply + - vdda-pll-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + usb_1_qmpphy: phy-wrapper@88e9000 { + compatible = "qcom,sdm845-qmp-usb3-phy"; + reg = <0x088e9000 0x18c>, + <0x088e8000 0x10>; + reg-names = "reg-base", "dp_com"; + #clock-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x088e9000 0x1000>; + + clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>, + <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>, + <&gcc GCC_USB3_PRIM_CLKREF_CLK>, + <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>; + clock-names = "aux", "cfg_ahb", "ref", "com_aux"; + + resets = <&gcc GCC_USB3_PHY_PRIM_BCR>, + <&gcc GCC_USB3_DP_PHY_PRIM_BCR>; + reset-names = "phy", "common"; + + vdda-phy-supply = <&vdda_usb2_ss_1p2>; + vdda-pll-supply = <&vdda_usb2_ss_core>; + + phy@200 { + reg = <0x200 0x128>, + <0x400 0x200>, + <0xc00 0x218>, + <0x600 0x128>, + <0x800 0x200>, + <0xa00 0x100>; + #clock-cells = <0>; + #phy-cells = <0>; + clocks = <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>; + clock-names = "pipe0"; + clock-output-names = "usb3_phy_pipe_clk_src"; + }; + };
diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index 144ae29..b5a6195 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -83,31 +83,28 @@ It is a 6 bit value that specifies offset to be added to PHY refgen RESCODE via IMP_CTRL1 register. It is a PHY tuning parameter that may vary for different boards of same SOC. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - maximum: 63 - default: 0 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 63 + default: 0 qcom,bias-ctrl-value: description: It is a 6 bit value that specifies bias-ctrl-value. It is a PHY tuning parameter that may vary for different boards of same SOC. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - maximum: 63 - default: 0 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 63 + default: 32 qcom,charge-ctrl-value: - description: + description: It is a 2 bit value that specifies charge-ctrl-value. It is a PHY tuning parameter that may vary for different boards of same SOC. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - maximum: 3 - default: 0 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + default: 0 qcom,hstx-trim-value: description: @@ -115,22 +112,20 @@ output current. Possible range is - 15mA to 24mA (stepsize of 600 uA). See dt-bindings/phy/phy-qcom-qusb2.h for applicable values. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - maximum: 15 - default: 3 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + default: 3 qcom,preemphasis-level: description: It is a 2 bit value that specifies pre-emphasis level. Possible range is 0 to 15% (stepsize of 5%). See dt-bindings/phy/phy-qcom-qusb2.h for applicable values. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - maximum: 3 - default: 2 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + default: 2 qcom,preemphasis-width: description: @@ -138,21 +133,19 @@ pre-emphasis (specified using qcom,preemphasis-level) must be in effect. Duration could be half-bit of full-bit. See dt-bindings/phy/phy-qcom-qusb2.h for applicable values. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - maximum: 1 - default: 0 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 1 + default: 0 qcom,hsdisc-trim-value: description: It is a 2 bit value tuning parameter that control disconnect threshold and may vary for different boards of same SOC. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 0 - maximum: 3 - default: 0 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3 + default: 0 required: - compatible
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml new file mode 100644 index 0000000..4949a28 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
@@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/qcom,usb-snps-femto-v2.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Synopsys Femto High-Speed USB PHY V2 + +maintainers: + - Wesley Cheng <wcheng@codeaurora.org> + +description: | + Qualcomm High-Speed USB PHY + +properties: + compatible: + enum: + - qcom,usb-snps-hs-7nm-phy + - qcom,sm8150-usb-hs-phy + - qcom,usb-snps-femto-v2-phy + + reg: + maxItems: 1 + + "#phy-cells": + const: 0 + + clocks: + items: + - description: rpmhcc ref clock + + clock-names: + items: + - const: ref + + resets: + items: + - description: PHY core reset + + vdda-pll-supply: + description: phandle to the regulator VDD supply node. + + vdda18-supply: + description: phandle to the regulator 1.8V supply node. + + vdda33-supply: + description: phandle to the regulator 3.3V supply node. + +required: + - compatible + - reg + - "#phy-cells" + - clocks + - clock-names + - resets + - vdda-pll-supply + - vdda18-supply + - vdda33-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/clock/qcom,gcc-sm8150.h> + phy@88e2000 { + compatible = "qcom,sm8150-usb-hs-phy"; + reg = <0x088e2000 0x400>; + #phy-cells = <0>; + + clocks = <&rpmhcc RPMH_CXO_CLK>; + clock-names = "ref"; + + resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>; + + vdda-pll-supply = <&vdd_usb_hs_core>; + vdda33-supply = <&vdda_usb_hs_3p1>; + vdda18-supply = <&vdda_usb_hs_1p8>; + }; +...
diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt deleted file mode 100644 index 54d6f8d..0000000 --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt +++ /dev/null
@@ -1,242 +0,0 @@ -Qualcomm QMP PHY controller -=========================== - -QMP phy controller supports physical layer functionality for a number of -controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB. - -Required properties: - - compatible: compatible list, contains: - "qcom,ipq8074-qmp-pcie-phy" for PCIe phy on IPQ8074 - "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996, - "qcom,msm8996-qmp-ufs-phy" for 14nm UFS phy on msm8996, - "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996, - "qcom,msm8998-qmp-usb3-phy" for USB3 QMP V3 phy on msm8998, - "qcom,msm8998-qmp-ufs-phy" for UFS QMP phy on msm8998, - "qcom,msm8998-qmp-pcie-phy" for PCIe QMP phy on msm8998, - "qcom,sdm845-qhp-pcie-phy" for QHP PCIe phy on sdm845, - "qcom,sdm845-qmp-pcie-phy" for QMP PCIe phy on sdm845, - "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845, - "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845, - "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845, - "qcom,sm8150-qmp-ufs-phy" for UFS QMP phy on sm8150. - -- reg: - - index 0: address and length of register set for PHY's common - serdes block. - - index 1: address and length of the DP_COM control block (for - "qcom,sdm845-qmp-usb3-phy" only). - -- reg-names: - - For "qcom,sdm845-qmp-usb3-phy": - - Should be: "reg-base", "dp_com" - - For all others: - - The reg-names property shouldn't be defined. - - - #address-cells: must be 1 - - #size-cells: must be 1 - - ranges: must be present - - - clocks: a list of phandles and clock-specifier pairs, - one for each entry in clock-names. - - clock-names: "cfg_ahb" for phy config clock, - "aux" for phy aux clock, - "ref" for 19.2 MHz ref clk, - "com_aux" for phy common block aux clock, - "ref_aux" for phy reference aux clock, - - For "qcom,ipq8074-qmp-pcie-phy": no clocks are listed. - For "qcom,msm8996-qmp-pcie-phy" must contain: - "aux", "cfg_ahb", "ref". - For "qcom,msm8996-qmp-ufs-phy" must contain: - "ref". - For "qcom,msm8996-qmp-usb3-phy" must contain: - "aux", "cfg_ahb", "ref". - For "qcom,msm8998-qmp-usb3-phy" must contain: - "aux", "cfg_ahb", "ref". - For "qcom,msm8998-qmp-ufs-phy" must contain: - "ref", "ref_aux". - For "qcom,msm8998-qmp-pcie-phy" must contain: - "aux", "cfg_ahb", "ref". - For "qcom,sdm845-qhp-pcie-phy" must contain: - "aux", "cfg_ahb", "ref", "refgen". - For "qcom,sdm845-qmp-pcie-phy" must contain: - "aux", "cfg_ahb", "ref", "refgen". - For "qcom,sdm845-qmp-usb3-phy" must contain: - "aux", "cfg_ahb", "ref", "com_aux". - For "qcom,sdm845-qmp-usb3-uni-phy" must contain: - "aux", "cfg_ahb", "ref", "com_aux". - For "qcom,sdm845-qmp-ufs-phy" must contain: - "ref", "ref_aux". - For "qcom,sm8150-qmp-ufs-phy" must contain: - "ref", "ref_aux". - - - resets: a list of phandles and reset controller specifier pairs, - one for each entry in reset-names. - - reset-names: "phy" for reset of phy block, - "common" for phy common block reset, - "cfg" for phy's ahb cfg block reset, - "ufsphy" for the PHY reset in the UFS controller. - - For "qcom,ipq8074-qmp-pcie-phy" must contain: - "phy", "common". - For "qcom,msm8996-qmp-pcie-phy" must contain: - "phy", "common", "cfg". - For "qcom,msm8996-qmp-ufs-phy": must contain: - "ufsphy". - For "qcom,msm8996-qmp-usb3-phy" must contain - "phy", "common". - For "qcom,msm8998-qmp-usb3-phy" must contain - "phy", "common". - For "qcom,msm8998-qmp-ufs-phy": must contain: - "ufsphy". - For "qcom,msm8998-qmp-pcie-phy" must contain: - "phy", "common". - For "qcom,sdm845-qhp-pcie-phy" must contain: - "phy". - For "qcom,sdm845-qmp-pcie-phy" must contain: - "phy". - For "qcom,sdm845-qmp-usb3-phy" must contain: - "phy", "common". - For "qcom,sdm845-qmp-usb3-uni-phy" must contain: - "phy", "common". - For "qcom,sdm845-qmp-ufs-phy": must contain: - "ufsphy". - For "qcom,sm8150-qmp-ufs-phy": must contain: - "ufsphy". - - - vdda-phy-supply: Phandle to a regulator supply to PHY core block. - - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block. - -Optional properties: - - vddp-ref-clk-supply: Phandle to a regulator supply to any specific refclk - pll block. - -Required nodes: - - Each device node of QMP phy is required to have as many child nodes as - the number of lanes the PHY has. - -Required properties for child nodes of PCIe PHYs (one child per lane): - - reg: list of offset and length pairs of register sets for PHY blocks - - tx, rx, pcs, and pcs_misc (optional). - - #phy-cells: must be 0 - -Required properties for a single "lanes" child node of non-PCIe PHYs: - - reg: list of offset and length pairs of register sets for PHY blocks - For 1-lane devices: - tx, rx, pcs, and (optionally) pcs_misc - For 2-lane devices: - tx0, rx0, pcs, tx1, rx1, and (optionally) pcs_misc - - #phy-cells: must be 0 - -Required properties for child node of PCIe and USB3 qmp phys: - - clocks: a list of phandles and clock-specifier pairs, - one for each entry in clock-names. - - clock-names: Must contain following: - "pipe<lane-number>" for pipe clock specific to each lane. - - clock-output-names: Name of the PHY clock that will be the parent for - the above pipe clock. - For "qcom,ipq8074-qmp-pcie-phy": - - "pcie20_phy0_pipe_clk" Pipe Clock parent - (or) - "pcie20_phy1_pipe_clk" - - #clock-cells: must be 0 - - Phy pll outputs pipe clocks for pipe based PHYs. These clocks are then - gate-controlled by the gcc. - -Required properties for child node of PHYs with lane reset, AKA: - "qcom,msm8996-qmp-pcie-phy" - - resets: a list of phandles and reset controller specifier pairs, - one for each entry in reset-names. - - reset-names: Must contain following: - "lane<lane-number>" for reset specific to each lane. - -Example: - phy@34000 { - compatible = "qcom,msm8996-qmp-pcie-phy"; - reg = <0x34000 0x488>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - clocks = <&gcc GCC_PCIE_PHY_AUX_CLK>, - <&gcc GCC_PCIE_PHY_CFG_AHB_CLK>, - <&gcc GCC_PCIE_CLKREF_CLK>; - clock-names = "aux", "cfg_ahb", "ref"; - - vdda-phy-supply = <&pm8994_l28>; - vdda-pll-supply = <&pm8994_l12>; - - resets = <&gcc GCC_PCIE_PHY_BCR>, - <&gcc GCC_PCIE_PHY_COM_BCR>, - <&gcc GCC_PCIE_PHY_COM_NOCSR_BCR>; - reset-names = "phy", "common", "cfg"; - - pciephy_0: lane@35000 { - reg = <0x35000 0x130>, - <0x35200 0x200>, - <0x35400 0x1dc>; - #clock-cells = <0>; - #phy-cells = <0>; - - clocks = <&gcc GCC_PCIE_0_PIPE_CLK>; - clock-names = "pipe0"; - clock-output-names = "pcie_0_pipe_clk_src"; - resets = <&gcc GCC_PCIE_0_PHY_BCR>; - reset-names = "lane0"; - }; - - pciephy_1: lane@36000 { - ... - ... - }; - - phy@88eb000 { - compatible = "qcom,sdm845-qmp-usb3-uni-phy"; - reg = <0x88eb000 0x18c>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - clocks = <&gcc GCC_USB3_SEC_PHY_AUX_CLK>, - <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>, - <&gcc GCC_USB3_SEC_CLKREF_CLK>, - <&gcc GCC_USB3_SEC_PHY_COM_AUX_CLK>; - clock-names = "aux", "cfg_ahb", "ref", "com_aux"; - - resets = <&gcc GCC_USB3PHY_PHY_SEC_BCR>, - <&gcc GCC_USB3_PHY_SEC_BCR>; - reset-names = "phy", "common"; - - lane@88eb200 { - reg = <0x88eb200 0x128>, - <0x88eb400 0x1fc>, - <0x88eb800 0x218>, - <0x88eb600 0x70>; - #clock-cells = <0>; - #phy-cells = <0>; - clocks = <&gcc GCC_USB3_SEC_PHY_PIPE_CLK>; - clock-names = "pipe0"; - clock-output-names = "usb3_uni_phy_pipe_clk_src"; - }; - }; - - phy@1d87000 { - compatible = "qcom,sdm845-qmp-ufs-phy"; - reg = <0x1d87000 0x18c>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - clock-names = "ref", - "ref_aux"; - clocks = <&gcc GCC_UFS_MEM_CLKREF_CLK>, - <&gcc GCC_UFS_PHY_PHY_AUX_CLK>; - - lanes@1d87400 { - reg = <0x1d87400 0x108>, - <0x1d87600 0x1e0>, - <0x1d87c00 0x1dc>, - <0x1d87800 0x108>, - <0x1d87a00 0x1e0>; - #phy-cells = <0>; - }; - };
diff --git a/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml b/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml new file mode 100644 index 0000000..1118fe6 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml
@@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/qcom-usb-ipq4019-phy.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcom IPQ40xx Dakota HS/SS USB PHY + +maintainers: + - Robert Marko <robert.marko@sartura.hr> + +properties: + compatible: + enum: + - qcom,usb-ss-ipq4019-phy + - qcom,usb-hs-ipq4019-phy + + reg: + maxItems: 1 + + resets: + maxItems: 2 + + reset-names: + items: + - const: por_rst + - const: srif_rst + + "#phy-cells": + const: 0 + +required: + - compatible + - reg + - resets + - reset-names + - "#phy-cells" + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-ipq4019.h> + + hsphy@a8000 { + #phy-cells = <0>; + compatible = "qcom,usb-hs-ipq4019-phy"; + reg = <0xa8000 0x40>; + resets = <&gcc USB2_HSPHY_POR_ARES>, + <&gcc USB2_HSPHY_S_ARES>; + reset-names = "por_rst", "srif_rst"; + };
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt index ac96d64..a3bd1c4 100644 --- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt +++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
@@ -4,7 +4,8 @@ 2 USB PHY contains. Required properties: -- compatible: "renesas,usb-phy-r8a7743" if the device is a part of R8A7743 SoC. +- compatible: "renesas,usb-phy-r8a7742" if the device is a part of R8A7742 SoC. + "renesas,usb-phy-r8a7743" if the device is a part of R8A7743 SoC. "renesas,usb-phy-r8a7744" if the device is a part of R8A7744 SoC. "renesas,usb-phy-r8a7745" if the device is a part of R8A7745 SoC. "renesas,usb-phy-r8a77470" if the device is a part of R8A77470 SoC.
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt deleted file mode 100644 index 7734b21..0000000 --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt +++ /dev/null
@@ -1,70 +0,0 @@ -* Renesas R-Car generation 3 USB 2.0 PHY - -This file provides information on what the device node for the R-Car generation -3, RZ/G1C, RZ/G2 and RZ/A2 USB 2.0 PHY contain. - -Required properties: -- compatible: "renesas,usb2-phy-r7s9210" if the device is a part of an R7S9210 - SoC. - "renesas,usb2-phy-r8a77470" if the device is a part of an R8A77470 - SoC. - "renesas,usb2-phy-r8a774a1" if the device is a part of an R8A774A1 - SoC. - "renesas,usb2-phy-r8a774b1" if the device is a part of an R8A774B1 - SoC. - "renesas,usb2-phy-r8a774c0" if the device is a part of an R8A774C0 - SoC. - "renesas,usb2-phy-r8a7795" if the device is a part of an R8A7795 - SoC. - "renesas,usb2-phy-r8a7796" if the device is a part of an R8A7796 - SoC. - "renesas,usb2-phy-r8a77965" if the device is a part of an - R8A77965 SoC. - "renesas,usb2-phy-r8a77990" if the device is a part of an - R8A77990 SoC. - "renesas,usb2-phy-r8a77995" if the device is a part of an - R8A77995 SoC. - "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3, RZ/G2 or - RZ/A2 compatible device. - - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first - followed by the generic version. - -- reg: offset and length of the partial USB 2.0 Host register block. -- clocks: clock phandle and specifier pair(s). -- #phy-cells: see phy-bindings.txt in the same directory, must be <1> (and - using <0> is deprecated). - -The phandle's argument in the PHY specifier is the INT_STATUS bit of controller: -- 1 = USBH_INTA (OHCI) -- 2 = USBH_INTB (EHCI) -- 3 = UCOM_INT (OTG and BC) - -Optional properties: -To use a USB channel where USB 2.0 Host and HSUSB (USB 2.0 Peripheral) are -combined, the device tree node should set interrupt properties to use the -channel as USB OTG: -- interrupts: interrupt specifier for the PHY. -- vbus-supply: Phandle to a regulator that provides power to the VBUS. This - regulator will be managed during the PHY power on/off sequence. -- renesas,no-otg-pins: boolean, specify when a board does not provide proper - otg pins. -- dr_mode: string, indicates the working mode for the PHY. Can be "host", - "peripheral", or "otg". Should be set if otg controller is not used. - - -Example (R-Car H3): - - usb-phy@ee080200 { - compatible = "renesas,usb2-phy-r8a7795", "renesas,rcar-gen3-usb2-phy"; - reg = <0 0xee080200 0 0x700>; - interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 703>; - }; - - usb-phy@ee0a0200 { - compatible = "renesas,usb2-phy-r8a7795", "renesas,rcar-gen3-usb2-phy"; - reg = <0 0xee0a0200 0 0x700>; - clocks = <&cpg CPG_MOD 702>; - };
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt deleted file mode 100644 index 0fe433b..0000000 --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt +++ /dev/null
@@ -1,52 +0,0 @@ -* Renesas R-Car generation 3 USB 3.0 PHY - -This file provides information on what the device node for the R-Car generation -3 and RZ/G2 USB 3.0 PHY contain. -If you want to enable spread spectrum clock (ssc), you should use USB_EXTAL -instead of USB3_CLK. However, if you don't want to these features, you don't -need this driver. - -Required properties: -- compatible: "renesas,r8a774a1-usb3-phy" if the device is a part of an R8A774A1 - SoC. - "renesas,r8a774b1-usb3-phy" if the device is a part of an R8A774B1 - SoC. - "renesas,r8a7795-usb3-phy" if the device is a part of an R8A7795 - SoC. - "renesas,r8a7796-usb3-phy" if the device is a part of an R8A7796 - SoC. - "renesas,r8a77965-usb3-phy" if the device is a part of an - R8A77965 SoC. - "renesas,rcar-gen3-usb3-phy" for a generic R-Car Gen3 or RZ/G2 - compatible device. - - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first - followed by the generic version. - -- reg: offset and length of the USB 3.0 PHY register block. -- clocks: A list of phandles and clock-specifier pairs. -- clock-names: Name of the clocks. - - The funcional clock must be "usb3-if". - - The usb3's external clock must be "usb3s_clk". - - The usb2's external clock must be "usb_extal". If you want to use the ssc, - the clock-frequency must not be 0. -- #phy-cells: see phy-bindings.txt in the same directory, must be <0>. - -Optional properties: -- renesas,ssc-range: Enable/disable spread spectrum clock (ssc) by using - the following values as u32: - - 0 (or the property doesn't exist): disable the ssc - - 4980: enable the ssc as -4980 ppm - - 4492: enable the ssc as -4492 ppm - - 4003: enable the ssc as -4003 ppm - -Example (R-Car H3): - - usb-phy@e65ee000 { - compatible = "renesas,r8a7795-usb3-phy", - "renesas,rcar-gen3-usb3-phy"; - reg = <0 0xe65ee000 0 0x90>; - clocks = <&cpg CPG_MOD 328>, <&usb3s0_clk>, <&usb_extal>; - clock-names = "usb3-if", "usb3s_clk", "usb_extal"; - };
diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml new file mode 100644 index 0000000..440f09f --- /dev/null +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
@@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/renesas,usb2-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car generation 3 USB 2.0 PHY + +maintainers: + - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> + +properties: + compatible: + oneOf: + - items: + - const: renesas,usb2-phy-r8a77470 # RZ/G1C + + - items: + - enum: + - renesas,usb2-phy-r7s9210 # RZ/A2 + - renesas,usb2-phy-r8a774a1 # RZ/G2M + - renesas,usb2-phy-r8a774b1 # RZ/G2N + - renesas,usb2-phy-r8a774c0 # RZ/G2E + - renesas,usb2-phy-r8a7795 # R-Car H3 + - renesas,usb2-phy-r8a7796 # R-Car M3-W + - renesas,usb2-phy-r8a77961 # R-Car M3-W+ + - renesas,usb2-phy-r8a77965 # R-Car M3-N + - renesas,usb2-phy-r8a77990 # R-Car E3 + - renesas,usb2-phy-r8a77995 # R-Car D3 + - const: renesas,rcar-gen3-usb2-phy + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + items: + - const: fck + - const: usb_x1 + + '#phy-cells': + enum: [0, 1] # and 0 is deprecated. + description: | + The phandle's argument in the PHY specifier is the INT_STATUS bit of + controller. + - 1 = USBH_INTA (OHCI) + - 2 = USBH_INTB (EHCI) + - 3 = UCOM_INT (OTG and BC) + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + minItems: 1 + maxItems: 2 + items: + - description: reset of USB 2.0 host side + - description: reset of USB 2.0 peripheral side + + vbus-supply: + description: | + Phandle to a regulator that provides power to the VBUS. This regulator + will be managed during the PHY power on/off sequence. + + renesas,no-otg-pins: + $ref: /schemas/types.yaml#/definitions/flag + description: | + specify when a board does not provide proper otg pins. + + dr_mode: true + +if: + properties: + compatible: + items: + enum: + - renesas,usb2-phy-r7s9210 +then: + required: + - clock-names + +required: + - compatible + - reg + - clocks + - '#phy-cells' + +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> + + usb-phy@ee080200 { + compatible = "renesas,usb2-phy-r8a7795", "renesas,rcar-gen3-usb2-phy"; + reg = <0xee080200 0x700>; + interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 703>; + #phy-cells = <1>; + }; + + usb-phy@ee0a0200 { + compatible = "renesas,usb2-phy-r8a7795", "renesas,rcar-gen3-usb2-phy"; + reg = <0xee0a0200 0x700>; + clocks = <&cpg CPG_MOD 702>; + #phy-cells = <1>; + };
diff --git a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml new file mode 100644 index 0000000..68cf9dd --- /dev/null +++ b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml
@@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/renesas,usb3-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car generation 3 USB 3.0 PHY + +maintainers: + - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> + +properties: + compatible: + items: + - enum: + - renesas,r8a774a1-usb3-phy # RZ/G2M + - renesas,r8a774b1-usb3-phy # RZ/G2N + - renesas,r8a7795-usb3-phy # R-Car H3 + - renesas,r8a7796-usb3-phy # R-Car M3-W + - renesas,r8a77961-usb3-phy # R-Car M3-W+ + - renesas,r8a77965-usb3-phy # R-Car M3-N + - const: renesas,rcar-gen3-usb3-phy + + reg: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + # If you want to use the ssc, the clock-frequency of usb_extal + # must not be 0. + minItems: 2 + maxItems: 3 + items: + - const: usb3-if # The funcional clock + - const: usb3s_clk # The usb3's external clock + - const: usb_extal # The usb2's external clock + + '#phy-cells': + # see phy-bindings.txt in the same directory + const: 0 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + renesas,ssc-range: + description: | + Enable/disable spread spectrum clock (ssc). 0 or the property doesn't + exist means disabling the ssc. The actual value will be -<value> ppm. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 4003, 4492, 4980 ] + +required: + - compatible + - reg + - clocks + - clock-names + - '#phy-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7795-cpg-mssr.h> + #include <dt-bindings/power/r8a7795-sysc.h> + + usb-phy@e65ee000 { + compatible = "renesas,r8a7795-usb3-phy", "renesas,rcar-gen3-usb3-phy"; + reg = <0xe65ee000 0x90>; + clocks = <&cpg CPG_MOD 328>, <&usb3s0_clk>, <&usb_extal>; + clock-names = "usb3-if", "usb3s_clk", "usb_extal"; + #phy-cells = <0>; + };
diff --git a/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml index 72aca81..8a3032a 100644 --- a/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml +++ b/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml
@@ -59,7 +59,7 @@ - | dsi_dphy: phy@ff2e0000 { compatible = "rockchip,px30-dsi-dphy"; - reg = <0x0 0xff2e0000 0x0 0x10000>; + reg = <0xff2e0000 0x10000>; clocks = <&pmucru 13>, <&cru 12>; clock-names = "ref", "pclk"; resets = <&cru 12>;
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml new file mode 100644 index 0000000..86f4909 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml
@@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/socionext,uniphier-pcie-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier PCIe PHY + +description: | + This describes the devicetree bindings for PHY interface built into + PCIe controller implemented on Socionext UniPhier SoCs. + +maintainers: + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> + +properties: + compatible: + enum: + - socionext,uniphier-pro5-pcie-phy + - socionext,uniphier-ld20-pcie-phy + - socionext,uniphier-pxs3-pcie-phy + + reg: + description: PHY register region (offset and length) + + "#phy-cells": + const: 0 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + oneOf: + - items: # for Pro5 + - const: gio + - const: link + - const: link # for others + + resets: + minItems: 1 + maxItems: 2 + + reset-names: + oneOf: + - items: # for Pro5 + - const: gio + - const: link + - const: link # for others + + socionext,syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: A phandle to system control to set configurations for phy + +required: + - compatible + - reg + - "#phy-cells" + - clocks + - clock-names + - resets + - reset-names + +additionalProperties: false + +examples: + - | + pcie_phy: phy@66038000 { + compatible = "socionext,uniphier-ld20-pcie-phy"; + reg = <0x66038000 0x4000>; + #phy-cells = <0>; + clock-names = "link"; + clocks = <&sys_clk 24>; + reset-names = "link"; + resets = <&sys_rst 24>; + socionext,syscon = <&soc_glue>; + };
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml new file mode 100644 index 0000000..479b203 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml
@@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/socionext,uniphier-usb2-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier USB2 PHY + +description: | + This describes the devicetree bindings for PHY interface built into + USB2 controller implemented on Socionext UniPhier SoCs. + Pro4 SoC has both USB2 and USB3 host controllers, however, this USB3 + controller doesn't include its own High-Speed PHY. This needs to specify + USB2 PHY instead of USB3 HS-PHY. + +maintainers: + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> + +properties: + compatible: + enum: + - socionext,uniphier-pro4-usb2-phy + - socionext,uniphier-ld11-usb2-phy + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^phy@[0-9]+$": + type: object + additionalProperties: false + + properties: + reg: + minimum: 0 + maximum: 3 + description: + The ID number for the PHY + + "#phy-cells": + const: 0 + + required: + - reg + - "#phy-cells" + +required: + - compatible + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + // The UniPhier usb2-phy should be a subnode of a "syscon" compatible node. + + soc-glue@5f800000 { + compatible = "socionext,uniphier-ld11-soc-glue", "simple-mfd", "syscon"; + reg = <0x5f800000 0x2000>; + + usb-controller { + compatible = "socionext,uniphier-ld11-usb2-phy"; + #address-cells = <1>; + #size-cells = <0>; + + usb_phy0: phy@0 { + reg = <0>; + #phy-cells = <0>; + }; + + usb_phy1: phy@1 { + reg = <1>; + #phy-cells = <0>; + }; + + usb_phy2: phy@2 { + reg = <2>; + #phy-cells = <0>; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml new file mode 100644 index 0000000..f88d362 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
@@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/socionext,uniphier-usb3hs-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier USB3 High-Speed (HS) PHY + +description: | + This describes the devicetree bindings for PHY interfaces built into + USB3 controller implemented on Socionext UniPhier SoCs. + Although the controller includes High-Speed PHY and Super-Speed PHY, + this describes about High-Speed PHY. + +maintainers: + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> + +properties: + compatible: + enum: + - socionext,uniphier-pro5-usb3-hsphy + - socionext,uniphier-pxs2-usb3-hsphy + - socionext,uniphier-ld20-usb3-hsphy + - socionext,uniphier-pxs3-usb3-hsphy + + reg: + description: PHY register region (offset and length) + + "#phy-cells": + const: 0 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + oneOf: + - const: link # for PXs2 + - items: # for PXs3 + - const: link + - const: phy + + resets: + maxItems: 2 + + reset-names: + items: + - const: link + - const: phy + + vbus-supply: + description: A phandle to the regulator for USB VBUS + + nvmem-cells: + maxItems: 3 + description: + Phandles to nvmem cell that contains the trimming data. + Available only for HS-PHY implemented on LD20 and PXs3, and + if unspecified, default value is used. + + nvmem-cell-names: + items: + - const: rterm + - const: sel_t + - const: hs_i + description: + Should be the following names, which correspond to each nvmem-cells. + All of the 3 parameters associated with the above names are + required for each port, if any one is omitted, the trimming data + of the port will not be set at all. + +required: + - compatible + - reg + - "#phy-cells" + - clocks + - clock-names + - resets + - reset-names + +additionalProperties: false + +examples: + - | + usb-glue@65b00000 { + compatible = "socionext,uniphier-ld20-dwc3-glue", "simple-mfd"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x65b00000 0x400>; + + usb_hsphy0: hs-phy@200 { + compatible = "socionext,uniphier-ld20-usb3-hsphy"; + reg = <0x200 0x10>; + #phy-cells = <0>; + clock-names = "link", "phy"; + clocks = <&sys_clk 14>, <&sys_clk 16>; + reset-names = "link", "phy"; + resets = <&sys_rst 14>, <&sys_rst 16>; + vbus-supply = <&usb_vbus0>; + nvmem-cell-names = "rterm", "sel_t", "hs_i"; + nvmem-cells = <&usb_rterm0>, <&usb_sel_t0>, <&usb_hs_i0>; + }; + };
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml new file mode 100644 index 0000000..edff2c9 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml
@@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/socionext,uniphier-usb3ss-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier USB3 Super-Speed (SS) PHY + +description: | + This describes the devicetree bindings for PHY interfaces built into + USB3 controller implemented on Socionext UniPhier SoCs. + Although the controller includes High-Speed PHY and Super-Speed PHY, + this describes about Super-Speed PHY. + +maintainers: + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> + +properties: + compatible: + enum: + - socionext,uniphier-pro4-usb3-ssphy + - socionext,uniphier-pro5-usb3-ssphy + - socionext,uniphier-pxs2-usb3-ssphy + - socionext,uniphier-ld20-usb3-ssphy + - socionext,uniphier-pxs3-usb3-ssphy + + reg: + description: PHY register region (offset and length) + + "#phy-cells": + const: 0 + + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + oneOf: + - items: # for Pro4, Pro5 + - const: gio + - const: link + - items: # for PXs3 with phy-ext + - const: link + - const: phy + - const: phy-ext + - items: # for others + - const: link + - const: phy + + resets: + maxItems: 2 + + reset-names: + oneOf: + - items: # for Pro4,Pro5 + - const: gio + - const: link + - items: # for others + - const: link + - const: phy + + vbus-supply: + description: A phandle to the regulator for USB VBUS + +required: + - compatible + - reg + - "#phy-cells" + - clocks + - clock-names + - resets + - reset-names + - vbus-supply + +additionalProperties: false + +examples: + - | + usb-glue@65b00000 { + compatible = "socionext,uniphier-ld20-dwc3-glue", + "simple-mfd"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x65b00000 0x400>; + + usb_ssphy0: ss-phy@300 { + compatible = "socionext,uniphier-ld20-usb3-ssphy"; + reg = <0x300 0x10>; + #phy-cells = <0>; + clock-names = "link", "phy"; + clocks = <&sys_clk 14>, <&sys_clk 16>; + reset-names = "link", "phy"; + resets = <&sys_rst 14>, <&sys_rst 16>; + vbus-supply = <&usb_vbus0>; + }; + };
diff --git a/Documentation/devicetree/bindings/phy/uniphier-pcie-phy.txt b/Documentation/devicetree/bindings/phy/uniphier-pcie-phy.txt deleted file mode 100644 index 3cee372..0000000 --- a/Documentation/devicetree/bindings/phy/uniphier-pcie-phy.txt +++ /dev/null
@@ -1,36 +0,0 @@ -Socionext UniPhier PCIe PHY bindings - -This describes the devicetree bindings for PHY interface built into -PCIe controller implemented on Socionext UniPhier SoCs. - -Required properties: -- compatible: Should contain one of the following: - "socionext,uniphier-pro5-pcie-phy" - for Pro5 PHY - "socionext,uniphier-ld20-pcie-phy" - for LD20 PHY - "socionext,uniphier-pxs3-pcie-phy" - for PXs3 PHY -- reg: Specifies offset and length of the register set for the device. -- #phy-cells: Must be zero. -- clocks: A list of phandles to the clock gate for PCIe glue layer - including this phy. -- clock-names: For Pro5 only, should contain the following: - "gio", "link" - for Pro5 SoC -- resets: A list of phandles to the reset line for PCIe glue layer - including this phy. -- reset-names: For Pro5 only, should contain the following: - "gio", "link" - for Pro5 SoC - -Optional properties: -- socionext,syscon: A phandle to system control to set configurations - for phy. - -Refer to phy/phy-bindings.txt for the generic PHY binding properties. - -Example: - pcie_phy: phy@66038000 { - compatible = "socionext,uniphier-ld20-pcie-phy"; - reg = <0x66038000 0x4000>; - #phy-cells = <0>; - clocks = <&sys_clk 24>; - resets = <&sys_rst 24>; - socionext,syscon = <&soc_glue>; - };
diff --git a/Documentation/devicetree/bindings/phy/uniphier-usb2-phy.txt b/Documentation/devicetree/bindings/phy/uniphier-usb2-phy.txt deleted file mode 100644 index b43b282..0000000 --- a/Documentation/devicetree/bindings/phy/uniphier-usb2-phy.txt +++ /dev/null
@@ -1,45 +0,0 @@ -Socionext UniPhier USB2 PHY - -This describes the devicetree bindings for PHY interface built into -USB2 controller implemented on Socionext UniPhier SoCs. - -Pro4 SoC has both USB2 and USB3 host controllers, however, this USB3 -controller doesn't include its own High-Speed PHY. This needs to specify -USB2 PHY instead of USB3 HS-PHY. - -Required properties: -- compatible: Should contain one of the following: - "socionext,uniphier-pro4-usb2-phy" - for Pro4 SoC - "socionext,uniphier-ld11-usb2-phy" - for LD11 SoC - -Sub-nodes: -Each PHY should be represented as a sub-node. - -Sub-nodes required properties: -- #phy-cells: Should be 0. -- reg: The number of the PHY. - -Sub-nodes optional properties: -- vbus-supply: A phandle to the regulator for USB VBUS. - -Refer to phy/phy-bindings.txt for the generic PHY binding properties. - -Example: - soc-glue@5f800000 { - ... - usb-phy { - compatible = "socionext,uniphier-ld11-usb2-phy"; - usb_phy0: phy@0 { - reg = <0>; - #phy-cells = <0>; - }; - ... - }; - }; - - usb@5a800100 { - compatible = "socionext,uniphier-ehci", "generic-ehci"; - ... - phy-names = "usb"; - phys = <&usb_phy0>; - };
diff --git a/Documentation/devicetree/bindings/phy/uniphier-usb3-hsphy.txt b/Documentation/devicetree/bindings/phy/uniphier-usb3-hsphy.txt deleted file mode 100644 index 093d4f0..0000000 --- a/Documentation/devicetree/bindings/phy/uniphier-usb3-hsphy.txt +++ /dev/null
@@ -1,69 +0,0 @@ -Socionext UniPhier USB3 High-Speed (HS) PHY - -This describes the devicetree bindings for PHY interfaces built into -USB3 controller implemented on Socionext UniPhier SoCs. -Although the controller includes High-Speed PHY and Super-Speed PHY, -this describes about High-Speed PHY. - -Required properties: -- compatible: Should contain one of the following: - "socionext,uniphier-pro5-usb3-hsphy" - for Pro5 SoC - "socionext,uniphier-pxs2-usb3-hsphy" - for PXs2 SoC - "socionext,uniphier-ld20-usb3-hsphy" - for LD20 SoC - "socionext,uniphier-pxs3-usb3-hsphy" - for PXs3 SoC -- reg: Specifies offset and length of the register set for the device. -- #phy-cells: Should be 0. -- clocks: A list of phandles to the clock gate for USB3 glue layer. - According to the clock-names, appropriate clocks are required. -- clock-names: Should contain the following: - "gio", "link" - for Pro5 SoC - "phy", "phy-ext", "link" - for PXs3 SoC, "phy-ext" is optional. - "phy", "link" - for others -- resets: A list of phandles to the reset control for USB3 glue layer. - According to the reset-names, appropriate resets are required. -- reset-names: Should contain the following: - "gio", "link" - for Pro5 SoC - "phy", "link" - for others - -Optional properties: -- vbus-supply: A phandle to the regulator for USB VBUS. -- nvmem-cells: Phandles to nvmem cell that contains the trimming data. - Available only for HS-PHY implemented on LD20 and PXs3, and - if unspecified, default value is used. -- nvmem-cell-names: Should be the following names, which correspond to - each nvmem-cells. - All of the 3 parameters associated with the following names are - required for each port, if any one is omitted, the trimming data - of the port will not be set at all. - "rterm", "sel_t", "hs_i" - Each cell name for phy parameters - -Refer to phy/phy-bindings.txt for the generic PHY binding properties. - -Example: - - usb-glue@65b00000 { - compatible = "socionext,uniphier-ld20-dwc3-glue", - "simple-mfd"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x65b00000 0x400>; - - usb_vbus0: regulator { - ... - }; - - usb_hsphy0: hs-phy@200 { - compatible = "socionext,uniphier-ld20-usb3-hsphy"; - reg = <0x200 0x10>; - #phy-cells = <0>; - clock-names = "link", "phy"; - clocks = <&sys_clk 14>, <&sys_clk 16>; - reset-names = "link", "phy"; - resets = <&sys_rst 14>, <&sys_rst 16>; - vbus-supply = <&usb_vbus0>; - nvmem-cell-names = "rterm", "sel_t", "hs_i"; - nvmem-cells = <&usb_rterm0>, <&usb_sel_t0>, - <&usb_hs_i0>; - }; - ... - };
diff --git a/Documentation/devicetree/bindings/phy/uniphier-usb3-ssphy.txt b/Documentation/devicetree/bindings/phy/uniphier-usb3-ssphy.txt deleted file mode 100644 index 9df2bc2..0000000 --- a/Documentation/devicetree/bindings/phy/uniphier-usb3-ssphy.txt +++ /dev/null
@@ -1,58 +0,0 @@ -Socionext UniPhier USB3 Super-Speed (SS) PHY - -This describes the devicetree bindings for PHY interfaces built into -USB3 controller implemented on Socionext UniPhier SoCs. -Although the controller includes High-Speed PHY and Super-Speed PHY, -this describes about Super-Speed PHY. - -Required properties: -- compatible: Should contain one of the following: - "socionext,uniphier-pro4-usb3-ssphy" - for Pro4 SoC - "socionext,uniphier-pro5-usb3-ssphy" - for Pro5 SoC - "socionext,uniphier-pxs2-usb3-ssphy" - for PXs2 SoC - "socionext,uniphier-ld20-usb3-ssphy" - for LD20 SoC - "socionext,uniphier-pxs3-usb3-ssphy" - for PXs3 SoC -- reg: Specifies offset and length of the register set for the device. -- #phy-cells: Should be 0. -- clocks: A list of phandles to the clock gate for USB3 glue layer. - According to the clock-names, appropriate clocks are required. -- clock-names: - "gio", "link" - for Pro4 and Pro5 SoC - "phy", "phy-ext", "link" - for PXs3 SoC, "phy-ext" is optional. - "phy", "link" - for others -- resets: A list of phandles to the reset control for USB3 glue layer. - According to the reset-names, appropriate resets are required. -- reset-names: - "gio", "link" - for Pro4 and Pro5 SoC - "phy", "link" - for others - -Optional properties: -- vbus-supply: A phandle to the regulator for USB VBUS. - -Refer to phy/phy-bindings.txt for the generic PHY binding properties. - -Example: - - usb-glue@65b00000 { - compatible = "socionext,uniphier-ld20-dwc3-glue", - "simple-mfd"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x65b00000 0x400>; - - usb_vbus0: regulator { - ... - }; - - usb_ssphy0: ss-phy@300 { - compatible = "socionext,uniphier-ld20-usb3-ssphy"; - reg = <0x300 0x10>; - #phy-cells = <0>; - clock-names = "link", "phy"; - clocks = <&sys_clk 14>, <&sys_clk 16>; - reset-names = "link", "phy"; - resets = <&sys_rst 14>, <&sys_rst 16>; - vbus-supply = <&usb_vbus0>; - }; - ... - };
diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml index bfefd09..7556be6 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml
@@ -84,13 +84,12 @@ gpio-line-names: true input-debounce: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 1 - maxItems: 5 description: Debouncing periods in microseconds, one period per interrupt bank found in the controller + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 5 patternProperties: # It's pretty scary, but the basic idea is that: @@ -115,9 +114,8 @@ bias-pull-down: true drive-strength: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 10, 20, 30, 40 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [10, 20, 30, 40] required: - pins
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml index 7651a67..017d9593 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
@@ -33,26 +33,23 @@ then: patternProperties: "^function|groups$": - allOf: - - $ref: "/schemas/types.yaml#/definitions/string" - - enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, - ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, - DDCCLK, DDCDAT, EXTRST, FLACK, FLBUSY, FLWP, GPID, GPID0, GPID2, - GPID4, GPID6, GPIE0, GPIE2, GPIE4, GPIE6, I2C10, I2C11, I2C12, - I2C13, I2C14, I2C3, I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, LPCPD, - LPCPME, LPCRST, LPCSMI, MAC1LINK, MAC2LINK, MDIO1, MDIO2, NCTS1, - NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, - NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NDTS4, NRI1, NRI2, - NRI3, NRI4, NRTS1, NRTS2, NRTS3, OSCCLK, PWM0, PWM1, PWM2, PWM3, - PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1, RMII2, ROM16, - ROM8, ROMCS1, ROMCS2, ROMCS3, ROMCS4, RXD1, RXD2, RXD3, RXD4, - SALT1, SALT2, SALT3, SALT4, SD1, SD2, SGPMCK, SGPMI, SGPMLD, - SGPMO, SGPSCK, SGPSI0, SGPSI1, SGPSLD, SIOONCTRL, SIOPBI, SIOPBO, - SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1DEBUG, - SPI1PASSTHRU, SPICS1, TIMER3, TIMER4, TIMER5, TIMER6, TIMER7, - TIMER8, TXD1, TXD2, TXD3, TXD4, UART6, USB11D1, USB11H2, USB2D1, - USB2H1, USBCKI, VGABIOS_ROM, VGAHS, VGAVS, VPI18, VPI24, VPI30, - VPO12, VPO24, WDTRST1, WDTRST2 ] + $ref: "/schemas/types.yaml#/definitions/string" + enum: [ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, + ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT, + EXTRST, FLACK, FLBUSY, FLWP, GPID, GPID0, GPID2, GPID4, GPID6, GPIE0, + GPIE2, GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, I2C14, I2C3, I2C4, + I2C5, I2C6, I2C7, I2C8, I2C9, LPCPD, LPCPME, LPCRST, LPCSMI, MAC1LINK, + MAC2LINK, MDIO1, MDIO2, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, + NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, + NDTS4, NRI1, NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, OSCCLK, PWM0, + PWM1, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1, + RMII2, ROM16, ROM8, ROMCS1, ROMCS2, ROMCS3, ROMCS4, RXD1, RXD2, RXD3, + RXD4, SALT1, SALT2, SALT3, SALT4, SD1, SD2, SGPMCK, SGPMI, SGPMLD, + SGPMO, SGPSCK, SGPSI0, SGPSI1, SGPSLD, SIOONCTRL, SIOPBI, SIOPBO, + SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1DEBUG, SPI1PASSTHRU, + SPICS1, TIMER3, TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, TXD2, + TXD3, TXD4, UART6, USB11D1, USB11H2, USB2D1, USB2H1, USBCKI, VGABIOS_ROM, + VGAHS, VGAVS, VPI18, VPI24, VPI30, VPO12, VPO24, WDTRST1, WDTRST2] required: - compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml index 36feaf5..c643d6d 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
@@ -29,8 +29,7 @@ aspeed,external-nodes: minItems: 2 maxItems: 2 - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle-array description: | A cell of phandles to external controller nodes: 0: compatible with "aspeed,ast2500-gfx", "syscon" @@ -43,28 +42,25 @@ then: patternProperties: "^function|groups$": - allOf: - - $ref: "/schemas/types.yaml#/definitions/string" - - enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, - ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, - DDCCLK, DDCDAT, ESPI, FWSPICS1, FWSPICS2, GPID0, GPID2, GPID4, - GPID6, GPIE0, GPIE2, GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, - I2C14, I2C3, I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, LAD0, LAD1, - LAD2, LAD3, LCLK, LFRAME, LPCHC, LPCPD, LPCPLUS, LPCPME, LPCRST, - LPCSMI, LSIRQ, MAC1LINK, MAC2LINK, MDIO1, MDIO2, NCTS1, NCTS2, - NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, - NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, NRTS1, - NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PNOR, PWM0, PWM1, PWM2, - PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1, RMII2, RXD1, - RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13, SALT14, - SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, SALT9, SCL1, - SCL2, SD1, SD2, SDA1, SDA2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, - SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1CS1, - SPI1DEBUG, SPI1PASSTHRU, SPI2CK, SPI2CS0, SPI2CS1, SPI2MISO, - SPI2MOSI, TIMER3, TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, - TXD2, TXD3, TXD4, UART6, USB11BHID, USB2AD, USB2AH, USB2BD, - USB2BH, USBCKI, VGABIOSROM, VGAHS, VGAVS, VPI24, VPO, WDTRST1, - WDTRST2, ] + $ref: "/schemas/types.yaml#/definitions/string" + enum: [ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, + ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT, + ESPI, FWSPICS1, FWSPICS2, GPID0, GPID2, GPID4, GPID6, GPIE0, GPIE2, + GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, I2C14, I2C3, I2C4, I2C5, + I2C6, I2C7, I2C8, I2C9, LAD0, LAD1, LAD2, LAD3, LCLK, LFRAME, LPCHC, + LPCPD, LPCPLUS, LPCPME, LPCRST, LPCSMI, LSIRQ, MAC1LINK, MAC2LINK, + MDIO1, MDIO2, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, + NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, + NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PNOR, PWM0, + PWM1, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1, + RMII2, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13, + SALT14, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, SALT9, SCL1, + SCL2, SD1, SD2, SDA1, SDA2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, SIOPBO, + SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1CS1, SPI1DEBUG, + SPI1PASSTHRU, SPI2CK, SPI2CS0, SPI2CS1, SPI2MISO, SPI2MOSI, TIMER3, + TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, TXD2, TXD3, TXD4, UART6, + USB11BHID, USB2AD, USB2AH, USB2BD, USB2BH, USBCKI, VGABIOSROM, VGAHS, + VGAVS, VPI24, VPO, WDTRST1, WDTRST2] required: - compatible @@ -125,7 +121,7 @@ lhc: lhc@20 { compatible = "aspeed,ast2500-lhc"; - reg = <0x20 0x24 0x48 0x8>; + reg = <0x20 0x24>, <0x48 0x8>; }; }; };
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml index 45af29bc..1506726 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml
@@ -30,64 +30,58 @@ then: properties: function: - allOf: - - $ref: "/schemas/types.yaml#/definitions/string" - - enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, - ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMC, - ESPI, ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWSPIWP, GPIT0, - GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, - GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, I2C1, I2C10, I2C11, - I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, I2C6, - I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, I3C6, JTAGM, LHPD, LHSIRQ, - LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, MACLINK1, MACLINK2, - MACLINK3, MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4, NCTS1, NCTS2, - NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, - NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, NRTS1, - NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PWM0, PWM1, PWM10, PWM11, - PWM12, PWM13, PWM14, PWM15, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, - PWM8, PWM9, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, - RMII4, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, - SALT13, SALT14, SALT15, SALT16, SALT2, SALT3, SALT4, SALT5, - SALT6, SALT7, SALT8, SALT9, SD1, SD2, SGPM1, SGPS1, SIOONCTRL, - SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, - SPI1ABR, SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, - TACH10, TACH11, TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, - TACH4, TACH5, TACH6, TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, - THRU3, TXD1, TXD2, TXD3, TXD4, UART10, UART11, UART12, UART13, - UART6, UART7, UART8, UART9, USBAD, USBADP, USB2AH, USB2AHP, - USB2BD, USB2BH, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3, - WDTRST4, ] + $ref: "/schemas/types.yaml#/definitions/string" + enum: [ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, + ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMC, ESPI, ESPIALT, + FSI1, FSI2, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3, + GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, GPIU3, GPIU4, GPIU5, + GPIU6, GPIU7, I2C1, I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, + I2C2, I2C3, I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, + I3C6, JTAGM, LHPD, LHSIRQ, LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, + MACLINK1, MACLINK2, MACLINK3, MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4, + NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, + NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, + NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PWM0, PWM1, PWM10, PWM11, + PWM12, PWM13, PWM14, PWM15, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, PWM8, + PWM9, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4, + RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13, SALT14, + SALT15, SALT16, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, + SALT9, SD1, SD2, SGPM1, SGPS1, SIOONCTRL, SIOPBI, SIOPBO, SIOPWREQ, + SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1, SPI1WP, SPI2, + SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, TACH12, TACH13, TACH14, + TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, TACH7, TACH8, TACH9, THRU0, + THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, TXD4, UART10, UART11, UART12, + UART13, UART6, UART7, UART8, UART9, USBAD, USBADP, USB2AH, USB2AHP, + USB2BD, USB2BH, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3, WDTRST4] + groups: - allOf: - - $ref: "/schemas/types.yaml#/definitions/string" - - enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, - ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMCG1, - EMMCG4, EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, - FWQSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, - GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, - GPIU7, HVI3C3, HVI3C4, I2C1, I2C10, I2C11, I2C12, I2C13, I2C14, - I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, - I3C3, I3C4, I3C5, I3C6, JTAGM, LHPD, LHSIRQ, LPC, LPCHC, LPCPD, - LPCPME, LPCSMI, LSIRQ, MACLINK1, MACLINK2, MACLINK3, MACLINK4, - MDIO1, MDIO2, MDIO3, MDIO4, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, - NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, - NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4, - OSCCLK, PEWAKE, PWM0, PWM1, PWM10G0, PWM10G1, PWM11G0, PWM11G1, - PWM12G0, PWM12G1, PWM13G0, PWM13G1, PWM14G0, PWM14G1, PWM15G0, - PWM15G1, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, PWM8G0, PWM8G1, - PWM9G0, PWM9G1, QSPI1, QSPI2, RGMII1, RGMII2, RGMII3, RGMII4, - RMII1, RMII2, RMII3, RMII4, RXD1, RXD2, RXD3, RXD4, SALT1, - SALT10G0, SALT10G1, SALT11G0, SALT11G1, SALT12G0, SALT12G1, - SALT13G0, SALT13G1, SALT14G0, SALT14G1, SALT15G0, SALT15G1, - SALT16G0, SALT16G1, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, - SALT8, SALT9G0, SALT9G1, SD1, SD2, SD3, SGPM1, SGPS1, SIOONCTRL, - SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, - SPI1ABR, SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, - TACH10, TACH11, TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, - TACH4, TACH5, TACH6, TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, - THRU3, TXD1, TXD2, TXD3, TXD4, UART10, UART11, UART12G0, - UART12G1, UART13G0, UART13G1, UART6, UART7, UART8, UART9, USBA, - USBB, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3, WDTRST4, ] + $ref: "/schemas/types.yaml#/definitions/string" + enum: [ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, + ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMCG1, EMMCG4, + EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWQSPID, FWSPIWP, + GPIT0, GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, + GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, HVI3C3, HVI3C4, I2C1, I2C10, + I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, + I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, I3C6, JTAGM, LHPD, LHSIRQ, + LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, MACLINK1, MACLINK2, MACLINK3, + MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4, NCTS1, NCTS2, NCTS3, NCTS4, + NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, + NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4, + OSCCLK, PEWAKE, PWM0, PWM1, PWM10G0, PWM10G1, PWM11G0, PWM11G1, PWM12G0, + PWM12G1, PWM13G0, PWM13G1, PWM14G0, PWM14G1, PWM15G0, PWM15G1, PWM2, + PWM3, PWM4, PWM5, PWM6, PWM7, PWM8G0, PWM8G1, PWM9G0, PWM9G1, QSPI1, + QSPI2, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4, + RXD1, RXD2, RXD3, RXD4, SALT1, SALT10G0, SALT10G1, SALT11G0, SALT11G1, + SALT12G0, SALT12G1, SALT13G0, SALT13G1, SALT14G0, SALT14G1, SALT15G0, + SALT15G1, SALT16G0, SALT16G1, SALT2, SALT3, SALT4, SALT5, SALT6, + SALT7, SALT8, SALT9G0, SALT9G1, SD1, SD2, SD3, SGPM1, SGPS1, SIOONCTRL, + SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, + SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, + TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, + TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, + TXD4, UART10, UART11, UART12G0, UART12G1, UART13G0, UART13G1, UART6, + UART7, UART8, UART9, USBA, USBB, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, + WDTRST3, WDTRST4] required: - compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt index 3cab733..5682b20 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
@@ -9,13 +9,16 @@ "brcm,bcm2835-gpio" - BCM2835 compatible pinctrl "brcm,bcm7211-gpio" - BCM7211 compatible pinctrl "brcm,bcm2711-gpio" - BCM2711 compatible pinctrl + "brcm,bcm7211-gpio" - BCM7211 compatible pinctrl - reg: Should contain the physical address of the GPIO module's registers. - gpio-controller: Marks the device node as a GPIO controller. - #gpio-cells : Should be two. The first cell is the pin number and the second cell is used to specify optional parameters: - bit 0 specifies polarity (0 for normal, 1 for inverted) - interrupts : The interrupt outputs from the controller. One interrupt per - individual bank followed by the "all banks" interrupt. + individual bank followed by the "all banks" interrupt. For BCM7211, an + additional set of per-bank interrupt line and an "all banks" wake-up + interrupt may be specified. - interrupt-controller: Marks the device node as an interrupt controller. - #interrupt-cells : Should be 2. The first cell is the GPIO number.
diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.txt b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.txt deleted file mode 100644 index a874471..0000000 --- a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.txt +++ /dev/null
@@ -1,141 +0,0 @@ -Cirrus Logic Lochnagar Audio Development Board - -Lochnagar is an evaluation and development board for Cirrus Logic -Smart CODEC and Amp devices. It allows the connection of most Cirrus -Logic devices on mini-cards, as well as allowing connection of -various application processor systems to provide a full evaluation -platform. Audio system topology, clocking and power can all be -controlled through the Lochnagar, allowing the device under test -to be used in a variety of possible use cases. - -This binding document describes the binding for the pinctrl portion -of the driver. - -Also see these documents for generic binding information: - [1] GPIO : ../gpio/gpio.txt - [2] Pinctrl: ../pinctrl/pinctrl-bindings.txt - -And these for relevant defines: - [3] include/dt-bindings/pinctrl/lochnagar.h - -This binding must be part of the Lochnagar MFD binding: - [4] ../mfd/cirrus,lochnagar.txt - -Required properties: - - - compatible : One of the following strings: - "cirrus,lochnagar-pinctrl" - - - gpio-controller : Indicates this device is a GPIO controller. - - #gpio-cells : Must be 2. The first cell is the pin number, see - [3] for available pins and the second cell is used to specify - optional parameters, see [1]. - - gpio-ranges : Range of pins managed by the GPIO controller, see - [1]. Both the GPIO and Pinctrl base should be set to zero and the - count to the appropriate of the LOCHNAGARx_PIN_NUM_GPIOS define, - see [3]. - - - pinctrl-names : A pinctrl state named "default" must be defined. - - pinctrl-0 : A phandle to the default pinctrl state. - -Required sub-nodes: - -The pin configurations are defined as a child of the pinctrl states -node, see [2]. Each sub-node can have the following properties: - - groups : A list of groups to select (either this or "pins" must be - specified), available groups: - codec-aif1, codec-aif2, codec-aif3, dsp-aif1, dsp-aif2, psia1, - psia2, gf-aif1, gf-aif2, gf-aif3, gf-aif4, spdif-aif, usb-aif1, - usb-aif2, adat-aif, soundcard-aif - - pins : A list of pin names to select (either this or "groups" must - be specified), available pins: - fpga-gpio1, fpga-gpio2, fpga-gpio3, fpga-gpio4, fpga-gpio5, - fpga-gpio6, codec-gpio1, codec-gpio2, codec-gpio3, codec-gpio4, - codec-gpio5, codec-gpio6, codec-gpio7, codec-gpio8, dsp-gpio1, - dsp-gpio2, dsp-gpio3, dsp-gpio4, dsp-gpio5, dsp-gpio6, gf-gpio2, - gf-gpio3, gf-gpio7, codec-aif1-bclk, codec-aif1-rxdat, - codec-aif1-lrclk, codec-aif1-txdat, codec-aif2-bclk, - codec-aif2-rxdat, codec-aif2-lrclk, codec-aif2-txdat, - codec-aif3-bclk, codec-aif3-rxdat, codec-aif3-lrclk, - codec-aif3-txdat, dsp-aif1-bclk, dsp-aif1-rxdat, dsp-aif1-lrclk, - dsp-aif1-txdat, dsp-aif2-bclk, dsp-aif2-rxdat, - dsp-aif2-lrclk, dsp-aif2-txdat, psia1-bclk, psia1-rxdat, - psia1-lrclk, psia1-txdat, psia2-bclk, psia2-rxdat, psia2-lrclk, - psia2-txdat, gf-aif3-bclk, gf-aif3-rxdat, gf-aif3-lrclk, - gf-aif3-txdat, gf-aif4-bclk, gf-aif4-rxdat, gf-aif4-lrclk, - gf-aif4-txdat, gf-aif1-bclk, gf-aif1-rxdat, gf-aif1-lrclk, - gf-aif1-txdat, gf-aif2-bclk, gf-aif2-rxdat, gf-aif2-lrclk, - gf-aif2-txdat, dsp-uart1-rx, dsp-uart1-tx, dsp-uart2-rx, - dsp-uart2-tx, gf-uart2-rx, gf-uart2-tx, usb-uart-rx, - codec-pdmclk1, codec-pdmdat1, codec-pdmclk2, codec-pdmdat2, - codec-dmicclk1, codec-dmicdat1, codec-dmicclk2, codec-dmicdat2, - codec-dmicclk3, codec-dmicdat3, codec-dmicclk4, codec-dmicdat4, - dsp-dmicclk1, dsp-dmicdat1, dsp-dmicclk2, dsp-dmicdat2, i2c2-scl, - i2c2-sda, i2c3-scl, i2c3-sda, i2c4-scl, i2c4-sda, dsp-standby, - codec-mclk1, codec-mclk2, dsp-clkin, psia1-mclk, psia2-mclk, - gf-gpio1, gf-gpio5, dsp-gpio20, led1, led2 - - function : The mux function to select, available functions: - aif, fpga-gpio1, fpga-gpio2, fpga-gpio3, fpga-gpio4, fpga-gpio5, - fpga-gpio6, codec-gpio1, codec-gpio2, codec-gpio3, codec-gpio4, - codec-gpio5, codec-gpio6, codec-gpio7, codec-gpio8, dsp-gpio1, - dsp-gpio2, dsp-gpio3, dsp-gpio4, dsp-gpio5, dsp-gpio6, gf-gpio2, - gf-gpio3, gf-gpio7, gf-gpio1, gf-gpio5, dsp-gpio20, codec-clkout, - dsp-clkout, pmic-32k, spdif-clkout, clk-12m288, clk-11m2986, - clk-24m576, clk-22m5792, xmos-mclk, gf-clkout1, gf-mclk1, - gf-mclk3, gf-mclk2, gf-clkout2, codec-mclk1, codec-mclk2, - dsp-clkin, psia1-mclk, psia2-mclk, spdif-mclk, codec-irq, - codec-reset, dsp-reset, dsp-irq, dsp-standby, codec-pdmclk1, - codec-pdmdat1, codec-pdmclk2, codec-pdmdat2, codec-dmicclk1, - codec-dmicdat1, codec-dmicclk2, codec-dmicdat2, codec-dmicclk3, - codec-dmicdat3, codec-dmicclk4, codec-dmicdat4, dsp-dmicclk1, - dsp-dmicdat1, dsp-dmicclk2, dsp-dmicdat2, dsp-uart1-rx, - dsp-uart1-tx, dsp-uart2-rx, dsp-uart2-tx, gf-uart2-rx, - gf-uart2-tx, usb-uart-rx, usb-uart-tx, i2c2-scl, i2c2-sda, - i2c3-scl, i2c3-sda, i2c4-scl, i2c4-sda, spdif-aif, psia1, - psia1-bclk, psia1-lrclk, psia1-rxdat, psia1-txdat, psia2, - psia2-bclk, psia2-lrclk, psia2-rxdat, psia2-txdat, codec-aif1, - codec-aif1-bclk, codec-aif1-lrclk, codec-aif1-rxdat, - codec-aif1-txdat, codec-aif2, codec-aif2-bclk, codec-aif2-lrclk, - codec-aif2-rxdat, codec-aif2-txdat, codec-aif3, codec-aif3-bclk, - codec-aif3-lrclk, codec-aif3-rxdat, codec-aif3-txdat, dsp-aif1, - dsp-aif1-bclk, dsp-aif1-lrclk, dsp-aif1-rxdat, dsp-aif1-txdat, - dsp-aif2, dsp-aif2-bclk, dsp-aif2-lrclk, dsp-aif2-rxdat, - dsp-aif2-txdat, gf-aif3, gf-aif3-bclk, gf-aif3-lrclk, - gf-aif3-rxdat, gf-aif3-txdat, gf-aif4, gf-aif4-bclk, - gf-aif4-lrclk, gf-aif4-rxdat, gf-aif4-txdat, gf-aif1, - gf-aif1-bclk, gf-aif1-lrclk, gf-aif1-rxdat, gf-aif1-txdat, - gf-aif2, gf-aif2-bclk, gf-aif2-lrclk, gf-aif2-rxdat, - gf-aif2-txdat, usb-aif1, usb-aif2, adat-aif, soundcard-aif, - - - output-enable : Specifies that an AIF group will be used as a master - interface (either this or input-enable is required if a group is - being muxed to an AIF) - - input-enable : Specifies that an AIF group will be used as a slave - interface (either this or output-enable is required if a group is - being muxed to an AIF) - -Example: - -lochnagar-pinctrl { - compatible = "cirrus,lochnagar-pinctrl"; - - gpio-controller; - #gpio-cells = <2>; - gpio-ranges = <&lochnagar 0 0 LOCHNAGAR2_PIN_NUM_GPIOS>; - - pinctrl-names = "default"; - pinctrl-0 = <&pin-settings>; - - pin-settings: pin-settings { - ap-aif { - input-enable; - groups = "gf-aif1"; - function = "codec-aif3"; - }; - codec-aif { - output-enable; - groups = "codec-aif3"; - function = "gf-aif1"; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml new file mode 100644 index 0000000..420d748 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml
@@ -0,0 +1,190 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/cirrus,lochnagar.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic Lochnagar Audio Development Board + +maintainers: + - patches@opensource.cirrus.com + +description: | + Lochnagar is an evaluation and development board for Cirrus Logic + Smart CODEC and Amp devices. It allows the connection of most Cirrus + Logic devices on mini-cards, as well as allowing connection of various + application processor systems to provide a full evaluation platform. + Audio system topology, clocking and power can all be controlled through + the Lochnagar, allowing the device under test to be used in a variety of + possible use cases. + + This binding document describes the binding for the pinctrl portion of + the driver. + + Also see these documents for generic binding information: + [1] GPIO : ../gpio/gpio.txt + [2] Pinctrl: ../pinctrl/pinctrl-bindings.txt + + And these for relevant defines: + [3] include/dt-bindings/pinctrl/lochnagar.h + + This binding must be part of the Lochnagar MFD binding: + [4] ../mfd/cirrus,lochnagar.yaml + +properties: + compatible: + enum: + - cirrus,lochnagar-pinctrl + + gpio-controller: true + + '#gpio-cells': + description: + The first cell is the pin number and the second cell is used + to specify optional parameters. + const: 2 + + gpio-ranges: + description: + Range of pins managed by the GPIO controller, see [1]. Both the + GPIO and Pinctrl base should be set to zero and the count to the + appropriate of the LOCHNAGARx_PIN_NUM_GPIOS define, see [3]. + maxItems: 1 + + pinctrl-0: + description: + A phandle to the default pinctrl state. + + pinctrl-names: + description: + A pinctrl state named "default" must be defined. + const: default + + pin-settings: + type: object + patternProperties: + '-pins$': + description: + The pin configurations are defined as a child of the pinctrl + states node, see [2]. Each sub-node can have the following + properties. + type: object + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + + properties: + groups: + description: + A list of groups to select (either this or "pins" must be + specified), available groups. + enum: [ codec-aif1, codec-aif2, codec-aif3, dsp-aif1, + dsp-aif2, psia1, psia2, gf-aif1, gf-aif2, gf-aif3, + gf-aif4, spdif-aif, usb-aif1, usb-aif2, adat-aif, + soundcard-aif ] + + pins: + description: + A list of pin names to select (either this or "groups" must + be specified), available pins. + enum: [ fpga-gpio1, fpga-gpio2, fpga-gpio3, fpga-gpio4, + fpga-gpio5, fpga-gpio6, codec-gpio1, codec-gpio2, + codec-gpio3, codec-gpio4, codec-gpio5, codec-gpio6, + codec-gpio7, codec-gpio8, dsp-gpio1, dsp-gpio2, + dsp-gpio3, dsp-gpio4, dsp-gpio5, dsp-gpio6, + gf-gpio2, gf-gpio3, gf-gpio7, codec-aif1-bclk, + codec-aif1-rxdat, codec-aif1-lrclk, codec-aif1-txdat, + codec-aif2-bclk, codec-aif2-rxdat, codec-aif2-lrclk, + codec-aif2-txdat, codec-aif3-bclk, codec-aif3-rxdat, + codec-aif3-lrclk, codec-aif3-txdat, dsp-aif1-bclk, + dsp-aif1-rxdat, dsp-aif1-lrclk, dsp-aif1-txdat, + dsp-aif2-bclk, dsp-aif2-rxdat, dsp-aif2-lrclk, + dsp-aif2-txdat, psia1-bclk, psia1-rxdat, psia1-lrclk, + psia1-txdat, psia2-bclk, psia2-rxdat, psia2-lrclk, + psia2-txdat, gf-aif3-bclk, gf-aif3-rxdat, + gf-aif3-lrclk, gf-aif3-txdat, gf-aif4-bclk, + gf-aif4-rxdat, gf-aif4-lrclk, gf-aif4-txdat, + gf-aif1-bclk, gf-aif1-rxdat, gf-aif1-lrclk, + gf-aif1-txdat, gf-aif2-bclk, gf-aif2-rxdat, + gf-aif2-lrclk, gf-aif2-txdat, dsp-uart1-rx, + dsp-uart1-tx, dsp-uart2-rx, dsp-uart2-tx, + gf-uart2-rx, gf-uart2-tx, usb-uart-rx, codec-pdmclk1, + codec-pdmdat1, codec-pdmclk2, codec-pdmdat2, + codec-dmicclk1, codec-dmicdat1, codec-dmicclk2, + codec-dmicdat2, codec-dmicclk3, codec-dmicdat3, + codec-dmicclk4, codec-dmicdat4, dsp-dmicclk1, + dsp-dmicdat1, dsp-dmicclk2, dsp-dmicdat2, i2c2-scl, + i2c2-sda, i2c3-scl, i2c3-sda, i2c4-scl, i2c4-sda, + dsp-standby, codec-mclk1, codec-mclk2, dsp-clkin, + psia1-mclk, psia2-mclk, gf-gpio1, gf-gpio5, + dsp-gpio20, led1, led2 ] + + function: + description: + The mux function to select, available functions. + enum: [ aif, fpga-gpio1, fpga-gpio2, fpga-gpio3, fpga-gpio4, + fpga-gpio5, fpga-gpio6, codec-gpio1, codec-gpio2, + codec-gpio3, codec-gpio4, codec-gpio5, codec-gpio6, + codec-gpio7, codec-gpio8, dsp-gpio1, dsp-gpio2, + dsp-gpio3, dsp-gpio4, dsp-gpio5, dsp-gpio6, + gf-gpio2, gf-gpio3, gf-gpio7, gf-gpio1, gf-gpio5, + dsp-gpio20, codec-clkout, dsp-clkout, pmic-32k, + spdif-clkout, clk-12m288, clk-11m2986, clk-24m576, + clk-22m5792, xmos-mclk, gf-clkout1, gf-mclk1, + gf-mclk3, gf-mclk2, gf-clkout2, codec-mclk1, + codec-mclk2, dsp-clkin, psia1-mclk, psia2-mclk, + spdif-mclk, codec-irq, codec-reset, dsp-reset, + dsp-irq, dsp-standby, codec-pdmclk1, codec-pdmdat1, + codec-pdmclk2, codec-pdmdat2, codec-dmicclk1, + codec-dmicdat1, codec-dmicclk2, codec-dmicdat2, + codec-dmicclk3, codec-dmicdat3, codec-dmicclk4, + codec-dmicdat4, dsp-dmicclk1, dsp-dmicdat1, + dsp-dmicclk2, dsp-dmicdat2, dsp-uart1-rx, + dsp-uart1-tx, dsp-uart2-rx, dsp-uart2-tx, + gf-uart2-rx, gf-uart2-tx, usb-uart-rx, usb-uart-tx, + i2c2-scl, i2c2-sda, i2c3-scl, i2c3-sda, i2c4-scl, + i2c4-sda, spdif-aif, psia1, psia1-bclk, psia1-lrclk, + psia1-rxdat, psia1-txdat, psia2, psia2-bclk, + psia2-lrclk, psia2-rxdat, psia2-txdat, codec-aif1, + codec-aif1-bclk, codec-aif1-lrclk, codec-aif1-rxdat, + codec-aif1-txdat, codec-aif2, codec-aif2-bclk, + codec-aif2-lrclk, codec-aif2-rxdat, codec-aif2-txdat, + codec-aif3, codec-aif3-bclk, codec-aif3-lrclk, + codec-aif3-rxdat, codec-aif3-txdat, dsp-aif1, + dsp-aif1-bclk, dsp-aif1-lrclk, dsp-aif1-rxdat, + dsp-aif1-txdat, dsp-aif2, dsp-aif2-bclk, + dsp-aif2-lrclk, dsp-aif2-rxdat, dsp-aif2-txdat, + gf-aif3, gf-aif3-bclk, gf-aif3-lrclk, gf-aif3-rxdat, + gf-aif3-txdat, gf-aif4, gf-aif4-bclk, gf-aif4-lrclk, + gf-aif4-rxdat, gf-aif4-txdat, gf-aif1, gf-aif1-bclk, + gf-aif1-lrclk, gf-aif1-rxdat, gf-aif1-txdat, gf-aif2, + gf-aif2-bclk, gf-aif2-lrclk, gf-aif2-rxdat, + gf-aif2-txdat, usb-aif1, usb-aif2, adat-aif, + soundcard-aif ] + + output-enable: + description: + Specifies that an AIF group will be used as a master + interface (either this or input-enable is required if a + group is being muxed to an AIF) + + input-enable: + description: + Specifies that an AIF group will be used as a slave + interface (either this or output-enable is required if a + group is being muxed to an AIF) + + additionalProperties: false + + required: + - function + + additionalProperties: false + +required: + - compatible + - gpio-controller + - '#gpio-cells' + - gpio-ranges + - pinctrl-0 + - pinctrl-names
diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt deleted file mode 100644 index b0e36cf..0000000 --- a/Documentation/devicetree/bindings/pinctrl/cirrus,madera-pinctrl.txt +++ /dev/null
@@ -1,99 +0,0 @@ -Cirrus Logic Madera class audio codecs pinctrl driver - -The Cirrus Logic Madera codecs provide a number of GPIO functions for -interfacing to external hardware and to provide logic outputs to other devices. -Certain groups of GPIO pins also have an alternate function, normally as an -audio interface. - -The set of available GPIOs, functions and alternate function groups differs -between codecs so refer to the datasheet for the codec for further information -on what is supported on that device. - -The properties for this driver exist within the parent MFD driver node. - -See also - the core bindings for the parent MFD driver: - Documentation/devicetree/bindings/mfd/madera.txt - - the generic pinmix bindings: - Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt - -Required properties of parent mfd node: - - pinctrl-names : must be "default" - - pinctrl-0 : a phandle to the node containing the subnodes containing default - configurations - -Required subnodes: - One subnode is required to contain the default settings. It contains an - arbitrary number of configuration subnodes, one for each group or pin - configuration you want to apply as a default. - -Required properties of configuration subnodes: - - groups : name of one pin group to configure. One of: - aif1, aif2, aif3, aif4, mif1, mif2, mif3, pdmspk1, pdmspk2, - dmic4, dmic5, dmic6, - gpio1, gpio2, ..., gpio40 - The gpioN groups select the single pin of this name for configuration - -Optional properties of configuration subnodes: - Any configuration option not explicitly listed in the dts will be left at - chip default setting. - - - function : name of function to assign to this group. One of: - aif1, aif2, aif3, aif4, mif1, mif2, mif3, pdmspk1, pdmspk2, - dmic3, dmic4, dmic5, dmic6, - io, dsp-gpio, irq1, irq2, - fll1-clk, fll1-lock, fll2-clk, fll2-lock, fll3-clk, fll3-lock, - fllao-clk, fllao-lock, - opclk, opclk-async, pwm1, pwm2, spdif, - asrc1-in1-lock, asrc1-in2-lock, asrc2-in1-lock, asrc2-in2-lock, - spkl-short-circuit, spkr-short-circuit, spk-shutdown, - spk-overheat-shutdown, spk-overheat-warn, - timer1-sts, timer2-sts, timer3-sts, timer4-sts, timer5-sts, timer6-sts, - timer7-sts, timer8-sts, - log1-fifo-ne, log2-fifo-ne, log3-fifo-ne, log4-fifo-ne, log5-fifo-ne, - log6-fifo-ne, log7-fifo-ne, log8-fifo-ne, - - - bias-disable : disable pull-up and pull-down - - bias-bus-hold : enable buskeeper - - bias-pull-up : output is pulled-up - - bias-pull-down : output is pulled-down - - drive-push-pull : CMOS output - - drive-open-drain : open-drain output - - drive-strength : drive strength in mA. Valid values are 4 or 8 - - input-schmitt-enable : enable schmitt-trigger mode - - input-schmitt-disable : disable schmitt-trigger mode - - input-debounce : A value of 0 disables debounce, a value !=0 enables - debounce - - output-low : set the pin to output mode with low level - - output-high : set the pin to output mode with high level - -Example: - -cs47l85@0 { - compatible = "cirrus,cs47l85"; - - pinctrl-names = "default"; - pinctrl-0 = <&cs47l85_defaults>; - - cs47l85_defaults: cs47l85-gpio-defaults { - aif1 { - groups = "aif1"; - function = "aif1"; - bias-bus-hold; - }; - - aif2 { - groups = "aif2"; - function = "aif2"; - bias-bus-hold; - }; - - opclk { - groups = "gpio1"; - function = "opclk"; - bias-pull-up; - drive-strength = <8>; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml new file mode 100644 index 0000000..6bfc25d --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml
@@ -0,0 +1,122 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/cirrus,madera.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic Madera class audio CODECs pinctrl driver + +maintainers: + - patches@opensource.cirrus.com + +description: | + The Cirrus Logic Madera codecs provide a number of GPIO functions for + interfacing to external hardware and to provide logic outputs to other devices. + Certain groups of GPIO pins also have an alternate function, normally as an + audio interface. + + The set of available GPIOs, functions and alternate function groups differs + between CODECs so refer to the datasheet for the CODEC for further information + on what is supported on that device. + + The properties for this driver exist within the parent MFD driver node. + + See also the core bindings for the parent MFD driver: + + Documentation/devicetree/bindings/mfd/cirrus,madera.yaml + + And the generic pinmix bindings: + + Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt + +properties: + pinctrl-0: + description: + A phandle to the node containing the subnodes containing default + configurations. + + pinctrl-names: + description: + A pinctrl state named "default" must be defined. + const: default + + pin-settings: + description: + One subnode is required to contain the default settings. It + contains an arbitrary number of configuration subnodes, one for + each group or pin configuration you want to apply as a default. + type: object + patternProperties: + '-pins$': + type: object + allOf: + - $ref: "pincfg-node.yaml#" + - $ref: "pinmux-node.yaml#" + properties: + groups: + description: + Name of one pin group to configure. + enum: [ aif1, aif2, aif3, aif4, mif1, mif2, mif3, pdmspk1, + pdmspk2, dmic4, dmic5, dmic6, gpio1, gpio2, gpio3, + gpio4, gpio5, gpio6, gpio7, gpio7, gpio8, gpio9, + gpio10, gpio11, gpio12, gpio13, gpio14, gpio15, + gpio16, gpio17, gpio17, gpio18, gpio19, gpio20, + gpio21, gpio22, gpio23, gpio24, gpio25, gpio26, + gpio27, gpio27, gpio28, gpio29, gpio30, gpio31, + gpio32, gpio33, gpio34, gpio35, gpio36, gpio37, + gpio37, gpio38, gpio39 ] + + function: + description: + Name of function to assign to this group. + enum: [ aif1, aif2, aif3, aif4, mif1, mif2, mif3, + pdmspk1, pdmspk2, dmic3, dmic4, dmic5, + dmic6, io, dsp-gpio, irq1, irq2, fll1-clk, + fll1-lock, fll2-clk, fll2-lock, fll3-clk, + fll3-lock, fllao-clk, fllao-lock, opclk, + opclk-async, pwm1, pwm2, spdif, asrc1-in1-lock, + asrc1-in2-lock, asrc2-in1-lock, asrc2-in2-lock, + spkl-short-circuit, spkr-short-circuit, + spk-shutdown, spk-overheat-shutdown, + spk-overheat-warn, timer1-sts, timer2-sts, + timer3-sts, timer4-sts, timer5-sts, timer6-sts, + timer7-sts, timer8-sts, log1-fifo-ne, + log2-fifo-ne, log3-fifo-ne, log4-fifo-ne, + log5-fifo-ne, log6-fifo-ne, log7-fifo-ne, + log8-fifo-ne ] + + bias-disable: true + + bias-bus-hold: true + + bias-pull-up: true + + bias-pull-down: true + + drive-push-pull: true + + drive-open-drain: true + + drive-strength: + enum: [ 4, 8 ] + + input-schmitt-enable: true + + input-schmitt-disable: true + + input-debounce: true + + output-low: true + + output-high: true + + additionalProperties: false + + required: + - groups + + additionalProperties: false + +required: + - pinctrl-0 + - pinctrl-names
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml index d98a386..6d7d162 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml
@@ -37,22 +37,21 @@ be found in <arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h>. The last integer CONFIG is the pad setting value like pull-up on this pin. Please refer to i.MX8M Mini Reference Manual for detailed CONFIG settings. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-matrix - - items: - items: - - description: | - "mux_reg" indicates the offset of mux register. - - description: | - "conf_reg" indicates the offset of pad configuration register. - - description: | - "input_reg" indicates the offset of select input register. - - description: | - "mux_val" indicates the mux value to be applied. - - description: | - "input_val" indicates the select input value to be applied. - - description: | - "pad_setting" indicates the pad configuration value to be applied. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "mux_reg" indicates the offset of mux register. + - description: | + "conf_reg" indicates the offset of pad configuration register. + - description: | + "input_reg" indicates the offset of select input register. + - description: | + "mux_val" indicates the mux value to be applied. + - description: | + "input_val" indicates the select input value to be applied. + - description: | + "pad_setting" indicates the pad configuration value to be applied. required: - fsl,pins
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml index b9aa180..7131cfd 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml
@@ -37,22 +37,21 @@ be found in <arch/arm64/boot/dts/freescale/imx8mn-pinfunc.h>. The last integer CONFIG is the pad setting value like pull-up on this pin. Please refer to i.MX8M Nano Reference Manual for detailed CONFIG settings. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-matrix - - items: - items: - - description: | - "mux_reg" indicates the offset of mux register. - - description: | - "conf_reg" indicates the offset of pad configuration register. - - description: | - "input_reg" indicates the offset of select input register. - - description: | - "mux_val" indicates the mux value to be applied. - - description: | - "input_val" indicates the select input value to be applied. - - description: | - "pad_setting" indicates the pad configuration value to be applied. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "mux_reg" indicates the offset of mux register. + - description: | + "conf_reg" indicates the offset of pad configuration register. + - description: | + "input_reg" indicates the offset of select input register. + - description: | + "mux_val" indicates the mux value to be applied. + - description: | + "input_val" indicates the select input value to be applied. + - description: | + "pad_setting" indicates the pad configuration value to be applied. required: - fsl,pins
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml index 6297e78..d474bc1 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml
@@ -37,22 +37,21 @@ be found in <arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h>. The last integer CONFIG is the pad setting value like pull-up on this pin. Please refer to i.MX8M Plus Reference Manual for detailed CONFIG settings. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-matrix - - items: - items: - - description: | - "mux_reg" indicates the offset of mux register. - - description: | - "conf_reg" indicates the offset of pad configuration register. - - description: | - "input_reg" indicates the offset of select input register. - - description: | - "mux_val" indicates the mux value to be applied. - - description: | - "input_val" indicates the select input value to be applied. - - description: | - "pad_setting" indicates the pad configuration value to be applied. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "mux_reg" indicates the offset of mux register. + - description: | + "conf_reg" indicates the offset of pad configuration register. + - description: | + "input_reg" indicates the offset of select input register. + - description: | + "mux_val" indicates the mux value to be applied. + - description: | + "input_val" indicates the select input value to be applied. + - description: | + "pad_setting" indicates the pad configuration value to be applied. required: - fsl,pins
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml index b30c704..0af2b6c 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml
@@ -37,22 +37,21 @@ be found in <arch/arm64/boot/dts/freescale/imx8mq-pinfunc.h>. The last integer CONFIG is the pad setting value like pull-up on this pin. Please refer to i.MX8M Quad Reference Manual for detailed CONFIG settings. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-matrix - - items: - items: - - description: | - "mux_reg" indicates the offset of mux register. - - description: | - "conf_reg" indicates the offset of pad configuration register. - - description: | - "input_reg" indicates the offset of select input register. - - description: | - "mux_val" indicates the mux value to be applied. - - description: | - "input_val" indicates the select input value to be applied. - - description: | - "pad_setting" indicates the pad configuration value to be applied. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "mux_reg" indicates the offset of mux register. + - description: | + "conf_reg" indicates the offset of pad configuration register. + - description: | + "input_reg" indicates the offset of select input register. + - description: | + "mux_val" indicates the mux value to be applied. + - description: | + "input_val" indicates the select input value to be applied. + - description: | + "pad_setting" indicates the pad configuration value to be applied. required: - fsl,pins
diff --git a/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml b/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml index cd2b436..2c0acb4 100644 --- a/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml +++ b/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml
@@ -24,12 +24,10 @@ patternProperties: '-pins$': type: object - allOf: - - $ref: pincfg-node.yaml# - - $ref: pinmux-node.yaml# description: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. + $ref: pinmux-node.yaml# properties: function: true
diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt index 32a8a8f..0091244 100644 --- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt
@@ -2,8 +2,8 @@ ---------------------------------------------------- Required properties: - - compatible : Should be "mscc,ocelot-pinctrl" or - "mscc,jaguar2-pinctrl" + - compatible : Should be "mscc,ocelot-pinctrl", + "mscc,jaguar2-pinctrl" or "microchip,sparx5-pinctrl" - reg : Address and length of the register set for the device - gpio-controller : Indicates this device is a GPIO controller - #gpio-cells : Must be 2.
diff --git a/Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml b/Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml index 732d907..ef8877d 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml
@@ -122,11 +122,10 @@ this, "pins" or "pinmux" has to be specified) pinmux: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array description: The list of numeric pin ids and their mux settings that properties in the node apply to (either this, "pins" or "groups" have to be specified) + $ref: /schemas/types.yaml#/definitions/uint32-array pinctrl-pin-array: $ref: /schemas/types.yaml#/definitions/uint32-array
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml index 63d1cfe..b2de399 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml
@@ -49,8 +49,7 @@ description: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. - allOf: - - $ref: "/schemas/pinctrl/pincfg-node.yaml" + $ref: "/schemas/pinctrl/pincfg-node.yaml" properties: pins:
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml new file mode 100644 index 0000000..6dc3b52 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml
@@ -0,0 +1,147 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm8250-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. SM8250 TLMM block + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: | + This binding describes the Top Level Mode Multiplexer block found in the + SM8250 platform. + +properties: + compatible: + const: qcom,sm8250-pinctrl + + reg: + minItems: 3 + maxItems: 3 + + reg-names: + items: + - const: "west" + - const: "south" + - const: "north" + + 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: + '^.*$': + if: + type: object + then: + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-7][0-9])$" + - enum: [ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ aoss_cti, atest, audio_ref, cam_mclk, cci_async, cci_i2c, + cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4, cri_trng, + cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, + ddr_pxi2, ddr_pxi3, dp_hot, dp_lcd, gcc_gp1, gcc_gp2, gcc_gp3, gpio, + ibi_i3c, jitter_bist, lpass_slimbus, mdp_vsync, mdp_vsync0, + mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s0_data0, mi2s0_data1, + mi2s0_sck, mi2s0_ws, mi2s1_data0, mi2s1_data1, mi2s1_sck, mi2s1_ws, + mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws, pci_e0, pci_e1, + pci_e2, phase_flag, pll_bist, pll_bypassnl, pll_clk, pll_reset, + pri_mi2s, prng_rosc, qdss_cti, qdss_gpio, qspi0, qspi1, qspi2, qspi3, + qspi_clk, qspi_cs, qup0, qup1, qup10, qup11, qup12, qup13, qup14, + qup15, qup16, qup17, qup18, qup19, qup2, qup3, qup4, qup5, qup6, + qup7, qup8, qup9, qup_l4, qup_l5, qup_l6, sd_write, sdc40, sdc41, + sdc42, sdc43, sdc4_clk, sdc4_cmd, sec_mi2s, sp_cmu, tgu_ch0, tgu_ch1, + tgu_ch2, tgu_ch3, tsense_pwm1, tsense_pwm2, tsif0_clk, tsif0_data, + tsif0_en, tsif0_error, tsif0_sync, tsif1_clk, tsif1_data, tsif1_en, + tsif1_error, tsif1_sync, usb2phy_ac, usb_phy, vsense_trigger ] + + 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 + - function + + additionalProperties: false + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-controller + - '#interrupt-cells' + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + pinctrl@1f00000 { + compatible = "qcom,sm8250-pinctrl"; + reg = <0x0f100000 0x300000>, + <0x0f500000 0x300000>, + <0x0f900000 0x300000>; + reg-names = "west", "south", "north"; + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-ranges = <&tlmm 0 0 180>; + wakeup-parent = <&pdc>; + };
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt index 6eada23..b686131 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
@@ -13,6 +13,7 @@ - "renesas,pfc-emev2": for EMEV2 (EMMA Mobile EV2) compatible pin-controller. - "renesas,pfc-r8a73a4": for R8A73A4 (R-Mobile APE6) compatible pin-controller. - "renesas,pfc-r8a7740": for R8A7740 (R-Mobile A1) compatible pin-controller. + - "renesas,pfc-r8a7742": for R8A7742 (RZ/G1H) compatible pin-controller. - "renesas,pfc-r8a7743": for R8A7743 (RZ/G1M) compatible pin-controller. - "renesas,pfc-r8a7744": for R8A7744 (RZ/G1N) compatible pin-controller. - "renesas,pfc-r8a7745": for R8A7745 (RZ/G1E) compatible pin-controller.
diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index 2113cfa..d3eae61 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -110,8 +110,8 @@ uart2 { uart2_xfer: uart2-xfer { - rockchip,pins = <RK_GPIO1 8 1 &pcfg_pull_default>, - <RK_GPIO1 9 1 &pcfg_pull_default>; + rockchip,pins = <1 RK_PB0 1 &pcfg_pull_default>, + <1 RK_PB1 1 &pcfg_pull_default>; }; }; };
diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml index 46a0478..0857cbe 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
@@ -36,22 +36,22 @@ pins-are-numbered: true hwlocks: true + interrupts: + maxItems: 1 + st,syscfg: - allOf: - - $ref: "/schemas/types.yaml#/definitions/phandle-array" description: Should be phandle/offset/mask - Phandle to the syscon node which includes IRQ mux selection. - The offset of the IRQ mux selection register. - The field mask of IRQ mux, needed if different of 0xf. + $ref: "/schemas/types.yaml#/definitions/phandle-array" st,package: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [1, 2, 4, 8] description: Indicates the SOC package used. More details in include/dt-bindings/pinctrl/stm32-pinfunc.h - + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8] patternProperties: '^gpio@[0-9a-f]*$': @@ -78,33 +78,30 @@ maximum: 16 st,bank-name: - allOf: - - $ref: "/schemas/types.yaml#/definitions/string" - - enum: - - GPIOA - - GPIOB - - GPIOC - - GPIOD - - GPIOE - - GPIOF - - GPIOG - - GPIOH - - GPIOI - - GPIOJ - - GPIOK - - GPIOZ description: Should be a name string for this bank as specified in the datasheet. + $ref: "/schemas/types.yaml#/definitions/string" + enum: + - GPIOA + - GPIOB + - GPIOC + - GPIOD + - GPIOE + - GPIOF + - GPIOG + - GPIOH + - GPIOI + - GPIOJ + - GPIOK + - GPIOZ st,bank-ioport: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - - maximum: 11 - description: Should correspond to the EXTI IOport selection (EXTI line used to select GPIOs as interrupts). + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 11 required: - gpio-controller @@ -125,8 +122,7 @@ configuration, pullups, drive, output high/low and output speed. properties: pinmux: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32-array" + $ref: "/schemas/types.yaml#/definitions/uint32-array" description: | Integer array, represents gpio pin number and mux setting. Supported pin number and mux varies for different SoCs, and are @@ -180,9 +176,8 @@ 1: Medium speed 2: Fast speed 3: High speed - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [0, 1, 2, 3] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] required: - pinmux
diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml index 6c6079f..4f524f8 100644 --- a/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml +++ b/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml
@@ -23,48 +23,119 @@ properties: compatible: enum: + - amlogic,meson8-pwrc + - amlogic,meson8b-pwrc + - amlogic,meson8m2-pwrc + - amlogic,meson-gxbb-pwrc - amlogic,meson-g12a-pwrc - amlogic,meson-sm1-pwrc clocks: - minItems: 2 + minItems: 1 + maxItems: 2 clock-names: + minItems: 1 + maxItems: 2 items: - const: vpu - const: vapb resets: minItems: 11 + maxItems: 12 reset-names: - items: - - const: viu - - const: venc - - const: vcbus - - const: bt656 - - const: rdma - - const: venci - - const: vencp - - const: vdac - - const: vdi6 - - const: vencl - - const: vid_lock + minItems: 11 + maxItems: 12 "#power-domain-cells": const: 1 amlogic,ao-sysctrl: description: phandle to the AO sysctrl node - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle + +allOf: + - if: + properties: + compatible: + enum: + - amlogic,meson8b-pwrc + - amlogic,meson8m2-pwrc + then: + properties: + reset-names: + items: + - const: dblk + - const: pic_dc + - const: hdmi_apb + - const: hdmi_system + - const: venci + - const: vencp + - const: vdac + - const: vencl + - const: viu + - const: venc + - const: rdma + required: + - resets + - reset-names + + - if: + properties: + compatible: + enum: + - amlogic,meson-gxbb-pwrc + then: + properties: + reset-names: + items: + - const: viu + - const: venc + - const: vcbus + - const: bt656 + - const: dvin + - const: rdma + - const: venci + - const: vencp + - const: vdac + - const: vdi6 + - const: vencl + - const: vid_lock + required: + - resets + - reset-names + + - if: + properties: + compatible: + enum: + - amlogic,meson-g12a-pwrc + - amlogic,meson-sm1-pwrc + then: + properties: + reset-names: + items: + - const: viu + - const: venc + - const: vcbus + - const: bt656 + - const: rdma + - const: venci + - const: vencp + - const: vdac + - const: vdi6 + - const: vencl + - const: vid_lock + required: + - resets + - reset-names required: - compatible - clocks - clock-names - - resets - - reset-names - "#power-domain-cells" - amlogic,ao-sysctrl
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt deleted file mode 100644 index f0f5553..0000000 --- a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt +++ /dev/null
@@ -1,91 +0,0 @@ -Freescale i.MX General Power Controller -======================================= - -The i.MX6 General Power Control (GPC) block contains DVFS load tracking -counters and Power Gating Control (PGC). - -Required properties: -- compatible: Should be one of the following: - - fsl,imx6q-gpc - - fsl,imx6qp-gpc - - fsl,imx6sl-gpc - - fsl,imx6sx-gpc -- reg: should be register base and length as documented in the - datasheet -- interrupts: Should contain one interrupt specifier for the GPC interrupt -- clocks: Must contain an entry for each entry in clock-names. - See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. -- clock-names: Must include the following entries: - - ipg - -The power domains are generic power domain providers as documented in -Documentation/devicetree/bindings/power/power-domain.yaml. They are described as -subnodes of the power gating controller 'pgc' node of the GPC and should -contain the following: - -Required properties: -- reg: Must contain the DOMAIN_INDEX of this power domain - The following DOMAIN_INDEX values are valid for i.MX6Q: - ARM_DOMAIN 0 - PU_DOMAIN 1 - The following additional DOMAIN_INDEX value is valid for i.MX6SL: - DISPLAY_DOMAIN 2 - The following additional DOMAIN_INDEX value is valid for i.MX6SX: - PCI_DOMAIN 3 - -- #power-domain-cells: Should be 0 - -Optional properties: -- clocks: a number of phandles to clocks that need to be enabled during domain - power-up sequencing to ensure reset propagation into devices located inside - this power domain -- power-supply: a phandle to the regulator powering this domain - -Example: - - gpc: gpc@20dc000 { - compatible = "fsl,imx6q-gpc"; - reg = <0x020dc000 0x4000>; - interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>, - <0 90 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clks IMX6QDL_CLK_IPG>; - clock-names = "ipg"; - - pgc { - #address-cells = <1>; - #size-cells = <0>; - - power-domain@0 { - reg = <0>; - #power-domain-cells = <0>; - }; - - pd_pu: power-domain@1 { - reg = <1>; - #power-domain-cells = <0>; - power-supply = <®_pu>; - clocks = <&clks IMX6QDL_CLK_GPU3D_CORE>, - <&clks IMX6QDL_CLK_GPU3D_SHADER>, - <&clks IMX6QDL_CLK_GPU2D_CORE>, - <&clks IMX6QDL_CLK_GPU2D_AXI>, - <&clks IMX6QDL_CLK_OPENVG_AXI>, - <&clks IMX6QDL_CLK_VPU_AXI>; - }; - }; - }; - - -Specifying power domain for IP modules -====================================== - -IP cores belonging to a power domain should contain a 'power-domains' property -that is a phandle pointing to the power domain the device belongs to. - -Example of a device that is part of the PU power domain: - - vpu: vpu@2040000 { - reg = <0x02040000 0x3c000>; - /* ... */ - power-domains = <&pd_pu>; - /* ... */ - };
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml new file mode 100644 index 0000000..a055b3e --- /dev/null +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml
@@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/fsl,imx-gpc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX General Power Controller + +maintainers: + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + The i.MX6 General Power Control (GPC) block contains DVFS load tracking + counters and Power Gating Control (PGC). + + The power domains are generic power domain providers as documented in + Documentation/devicetree/bindings/power/power-domain.yaml. They are + described as subnodes of the power gating controller 'pgc' node of the GPC. + + IP cores belonging to a power domain should contain a 'power-domains' + property that is a phandle pointing to the power domain the device belongs + to. + +properties: + compatible: + enum: + - fsl,imx6q-gpc + - fsl,imx6qp-gpc + - fsl,imx6sl-gpc + - fsl,imx6sx-gpc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: ipg + + pgc: + type: object + description: list of power domains provided by this controller. + + patternProperties: + "power-domain@[0-9]$": + type: object + properties: + + '#power-domain-cells': + const: 0 + + reg: + description: | + The following DOMAIN_INDEX values are valid for i.MX6Q: + ARM_DOMAIN 0 + PU_DOMAIN 1 + The following additional DOMAIN_INDEX value is valid for i.MX6SL: + DISPLAY_DOMAIN 2 + The following additional DOMAIN_INDEX value is valid for i.MX6SX: + PCI_DOMAIN 3 + maxItems: 1 + + clocks: + description: | + A number of phandles to clocks that need to be enabled during domain + power-up sequencing to ensure reset propagation into devices located + inside this power domain. + minItems: 1 + maxItems: 7 + + power-supply: true + + required: + - '#power-domain-cells' + - reg + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - pgc + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx6qdl-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + gpc@20dc000 { + compatible = "fsl,imx6q-gpc"; + reg = <0x020dc000 0x4000>; + interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks IMX6QDL_CLK_IPG>; + clock-names = "ipg"; + + pgc { + #address-cells = <1>; + #size-cells = <0>; + + power-domain@0 { + reg = <0>; + #power-domain-cells = <0>; + }; + + pd_pu: power-domain@1 { + reg = <1>; + #power-domain-cells = <0>; + power-supply = <®_pu>; + clocks = <&clks IMX6QDL_CLK_GPU3D_CORE>, + <&clks IMX6QDL_CLK_GPU3D_SHADER>, + <&clks IMX6QDL_CLK_GPU2D_CORE>, + <&clks IMX6QDL_CLK_GPU2D_AXI>, + <&clks IMX6QDL_CLK_OPENVG_AXI>, + <&clks IMX6QDL_CLK_VPU_AXI>; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt deleted file mode 100644 index 6164920..0000000 --- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt +++ /dev/null
@@ -1,77 +0,0 @@ -Freescale i.MX General Power Controller v2 -========================================== - -The i.MX7S/D General Power Control (GPC) block contains Power Gating -Control (PGC) for various power domains. - -Required properties: - -- compatible: Should be one of: - - "fsl,imx7d-gpc" - - "fsl,imx8mq-gpc" - -- reg: should be register base and length as documented in the - datasheet - -- interrupts: Should contain GPC interrupt request 1 - -Power domains contained within GPC node are generic power domain -providers, documented in -Documentation/devicetree/bindings/power/power-domain.yaml, which are -described as subnodes of the power gating controller 'pgc' node, -which, in turn, is expected to contain the following: - -Required properties: - -- reg: Power domain index. Valid values are defined in - include/dt-bindings/power/imx7-power.h for fsl,imx7d-gpc and - include/dt-bindings/power/imx8m-power.h for fsl,imx8mq-gpc - -- #power-domain-cells: Should be 0 - -Optional properties: - -- power-supply: Power supply used to power the domain -- clocks: a number of phandles to clocks that need to be enabled during - domain power-up sequencing to ensure reset propagation into devices - located inside this power domain - -Example: - - gpc: gpc@303a0000 { - compatible = "fsl,imx7d-gpc"; - reg = <0x303a0000 0x1000>; - interrupt-controller; - interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>; - #interrupt-cells = <3>; - interrupt-parent = <&intc>; - - pgc { - #address-cells = <1>; - #size-cells = <0>; - - pgc_pcie_phy: power-domain@1 { - #power-domain-cells = <0>; - - reg = <1>; - power-supply = <®_1p0d>; - }; - }; - }; - - -Specifying power domain for IP modules -====================================== - -IP cores belonging to a power domain should contain a 'power-domains' -property that is a phandle for PGC node representing the domain. - -Example of a device that is part of the PCIE_PHY power domain: - - pcie: pcie@33800000 { - reg = <0x33800000 0x4000>, - <0x4ff00000 0x80000>; - /* ... */ - power-domains = <&pgc_pcie_phy>; - /* ... */ - };
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml new file mode 100644 index 0000000..bde09a0 --- /dev/null +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
@@ -0,0 +1,108 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/fsl,imx-gpcv2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX General Power Controller v2 + +maintainers: + - Andrey Smirnov <andrew.smirnov@gmail.com> + +description: | + The i.MX7S/D General Power Control (GPC) block contains Power Gating + Control (PGC) for various power domains. + + Power domains contained within GPC node are generic power domain + providers, documented in + Documentation/devicetree/bindings/power/power-domain.yaml, which are + described as subnodes of the power gating controller 'pgc' node. + + IP cores belonging to a power domain should contain a 'power-domains' + property that is a phandle for PGC node representing the domain. + +properties: + compatible: + enum: + - fsl,imx7d-gpc + - fsl,imx8mq-gpc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + pgc: + type: object + description: list of power domains provided by this controller. + + patternProperties: + "power-domain@[0-9]$": + type: object + properties: + + '#power-domain-cells': + const: 0 + + reg: + description: | + Power domain index. Valid values are defined in + include/dt-bindings/power/imx7-power.h for fsl,imx7d-gpc and + include/dt-bindings/power/imx8m-power.h for fsl,imx8mq-gpc + maxItems: 1 + + clocks: + description: | + A number of phandles to clocks that need to be enabled during domain + power-up sequencing to ensure reset propagation into devices located + inside this power domain. + minItems: 1 + maxItems: 5 + + power-supply: true + + required: + - '#power-domain-cells' + - reg + +required: + - compatible + - reg + - interrupts + - pgc + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + gpc@303a0000 { + compatible = "fsl,imx7d-gpc"; + reg = <0x303a0000 0x1000>; + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>; + + pgc { + #address-cells = <1>; + #size-cells = <0>; + + pgc_mipi_phy: power-domain@0 { + #power-domain-cells = <0>; + reg = <0>; + power-supply = <®_1p0d>; + }; + + pgc_pcie_phy: power-domain@1 { + #power-domain-cells = <0>; + reg = <1>; + power-supply = <®_1p0d>; + }; + + pgc_hsic_phy: power-domain@2 { + #power-domain-cells = <0>; + reg = <2>; + power-supply = <®_1p2>; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index ba60531..8058955 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -23,6 +23,7 @@ - qcom,sc7180-rpmhpd - qcom,sdm845-rpmhpd - qcom,sm8150-rpmhpd + - qcom,sm8250-rpmhpd '#power-domain-cells': const: 1
diff --git a/Documentation/devicetree/bindings/power/renesas,apmu.yaml b/Documentation/devicetree/bindings/power/renesas,apmu.yaml index 078b2cb..60a23b3 100644 --- a/Documentation/devicetree/bindings/power/renesas,apmu.yaml +++ b/Documentation/devicetree/bindings/power/renesas,apmu.yaml
@@ -18,6 +18,7 @@ compatible: items: - enum: + - renesas,r8a7742-apmu # RZ/G1H - renesas,r8a7743-apmu # RZ/G1M - renesas,r8a7744-apmu # RZ/G1N - renesas,r8a7745-apmu # RZ/G1E
diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml index e59331e1..55b6ab2 100644 --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
@@ -17,6 +17,7 @@ properties: compatible: enum: + - renesas,r8a7742-sysc # RZ/G1H - renesas,r8a7743-sysc # RZ/G1M - renesas,r8a7744-sysc # RZ/G1N - renesas,r8a7745-sysc # RZ/G1E
diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt deleted file mode 100644 index f7ce1d8..0000000 --- a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt +++ /dev/null
@@ -1,35 +0,0 @@ -SYSCON reboot mode driver - -This driver gets reboot mode magic value form reboot-mode driver -and stores it in a SYSCON mapped register. Then the bootloader -can read it and take different action according to the magic -value stored. - -This DT node should be represented as a sub-node of a "syscon", "simple-mfd" -node. - -Required properties: -- compatible: should be "syscon-reboot-mode" -- offset: offset in the register map for the storage register (in bytes) - -Optional property: -- mask: bits mask of the bits in the register to store the reboot mode magic value, - default set to 0xffffffff if missing. - -The rest of the properties should follow the generic reboot-mode description -found in reboot-mode.txt - -Example: - pmu: pmu@20004000 { - compatible = "rockchip,rk3066-pmu", "syscon", "simple-mfd"; - reg = <0x20004000 0x100>; - - reboot-mode { - compatible = "syscon-reboot-mode"; - offset = <0x40>; - mode-normal = <BOOT_NORMAL>; - mode-recovery = <BOOT_RECOVERY>; - mode-bootloader = <BOOT_FASTBOOT>; - mode-loader = <BOOT_BL_DOWNLOAD>; - }; - };
diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml new file mode 100644 index 0000000..9b1ffce --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
@@ -0,0 +1,55 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/syscon-reboot-mode.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic SYSCON reboot mode driver + +maintainers: + - Sebastian Reichel <sre@kernel.org> + +description: | + This driver gets reboot mode magic value from reboot-mode driver + and stores it in a SYSCON mapped register. Then the bootloader + can read it and take different action according to the magic + value stored. The SYSCON mapped register is retrieved from the + parental dt-node plus the offset. So the SYSCON reboot-mode node + should be represented as a sub-node of a "syscon", "simple-mfd" node. + +properties: + compatible: + const: syscon-reboot-mode + + mask: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Update only the register bits defined by the mask (32 bit) + + offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Offset in the register map for the mode register (in bytes) + +patternProperties: + "^mode-.+": + $ref: /schemas/types.yaml#/definitions/uint32 + description: Vendor-specific mode value written to the mode register + +additionalProperties: false + +required: + - compatible + - offset + +examples: + - | + #include <dt-bindings/soc/rockchip,boot-mode.h> + + reboot-mode { + compatible = "syscon-reboot-mode"; + offset = <0x40>; + mode-normal = <BOOT_NORMAL>; + mode-recovery = <BOOT_RECOVERY>; + mode-bootloader = <BOOT_FASTBOOT>; + mode-loader = <BOOT_BL_DOWNLOAD>; + }; +...
diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml index b80772c..da25097 100644 --- a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml
@@ -12,9 +12,12 @@ description: |+ This is a generic reset driver using syscon to map the reset register. The reset is generally performed with a write to the reset register - defined by the register map pointed by syscon reference plus the offset - with the value and mask defined in the reboot node. - Default will be little endian mode, 32 bit access only. + defined by the SYSCON register map base plus the offset with the value and + mask defined in the reboot node. Default will be little endian mode, 32 bit + access only. The SYSCON registers map is normally retrieved from the + parental dt-node. So the SYSCON reboot node should be represented as a + sub-node of a "syscon", "simple-mfd" node. Though the regmap property + pointing to the system controller node is also supported. properties: compatible: @@ -30,7 +33,10 @@ regmap: $ref: /schemas/types.yaml#/definitions/phandle - description: Phandle to the register map node. + deprecated: true + description: | + Phandle to the register map node. This property is deprecated in favor of + the syscon-reboot node been a child of a system controller node. value: $ref: /schemas/types.yaml#/definitions/uint32 @@ -38,7 +44,6 @@ required: - compatible - - regmap - offset additionalProperties: false
diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt index 3049cf8..5e29595 100644 --- a/Documentation/devicetree/bindings/power/supply/battery.txt +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
@@ -11,15 +11,21 @@ behavior should a replacement that changes the battery type occur without a corresponding update to the dtb. +Please note that not all charger drivers respect all of the properties. + Required Properties: - compatible: Must be "simple-battery" Optional Properties: + - over-voltage-threshold-microvolt: battery over-voltage limit + - re-charge-voltage-microvolt: limit to automatically start charging again - voltage-min-design-microvolt: drained battery voltage - voltage-max-design-microvolt: fully charged battery voltage - energy-full-design-microwatt-hours: battery design energy - charge-full-design-microamp-hours: battery design capacity + - trickle-charge-current-microamp: current for trickle-charge phase - precharge-current-microamp: current for pre-charge phase + - precharge-upper-limit-microvolt: limit when to change to constant charging - charge-term-current-microamp: current for charge termination phase - constant-charge-current-max-microamp: maximum constant input current - constant-charge-voltage-max-microvolt: maximum constant input voltage
diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.txt b/Documentation/devicetree/bindings/power/supply/bq27xxx.txt deleted file mode 100644 index 4fa8e08..0000000 --- a/Documentation/devicetree/bindings/power/supply/bq27xxx.txt +++ /dev/null
@@ -1,56 +0,0 @@ -TI BQ27XXX fuel gauge family - -Required properties: -- compatible: contains one of the following: - * "ti,bq27200" - BQ27200 - * "ti,bq27210" - BQ27210 - * "ti,bq27500" - deprecated, use revision specific property below - * "ti,bq27510" - deprecated, use revision specific property below - * "ti,bq27520" - deprecated, use revision specific property below - * "ti,bq27500-1" - BQ27500/1 - * "ti,bq27510g1" - BQ27510-g1 - * "ti,bq27510g2" - BQ27510-g2 - * "ti,bq27510g3" - BQ27510-g3 - * "ti,bq27520g1" - BQ27520-g1 - * "ti,bq27520g2" - BQ27520-g2 - * "ti,bq27520g3" - BQ27520-g3 - * "ti,bq27520g4" - BQ27520-g4 - * "ti,bq27521" - BQ27521 - * "ti,bq27530" - BQ27530 - * "ti,bq27531" - BQ27531 - * "ti,bq27541" - BQ27541 - * "ti,bq27542" - BQ27542 - * "ti,bq27546" - BQ27546 - * "ti,bq27742" - BQ27742 - * "ti,bq27545" - BQ27545 - * "ti,bq27411" - BQ27411 - * "ti,bq27421" - BQ27421 - * "ti,bq27425" - BQ27425 - * "ti,bq27426" - BQ27426 - * "ti,bq27441" - BQ27441 - * "ti,bq27621" - BQ27621 -- reg: integer, I2C address of the fuel gauge. - -Optional properties: -- monitored-battery: phandle of battery characteristics node - The fuel gauge uses the following battery properties: - + energy-full-design-microwatt-hours - + charge-full-design-microamp-hours - + voltage-min-design-microvolt - Both or neither of the *-full-design-*-hours properties must be set. - See Documentation/devicetree/bindings/power/supply/battery.txt - -Example: - - bat: battery { - compatible = "simple-battery"; - voltage-min-design-microvolt = <3200000>; - energy-full-design-microwatt-hours = <5290000>; - charge-full-design-microamp-hours = <1430000>; - }; - - bq27510g3: fuel-gauge@55 { - compatible = "ti,bq27510g3"; - reg = <0x55>; - monitored-battery = <&bat>; - };
diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml new file mode 100644 index 0000000..03d1020 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml
@@ -0,0 +1,91 @@ +# SPDX-License-Identifier: GPL-2.0 +# Copyright (C) 2020 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/power/supply/bq27xxx.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: TI BQ27XXX fuel gauge family + +maintainers: + - Pali Rohár <pali@kernel.org> + - Andrew F. Davis <afd@ti.com> + - Sebastian Reichel <sre@kernel.org> + +description: | + Support various Texas Instruments fuel gauge devices that share similar + register maps and power supply properties + +allOf: + - $ref: power-supply.yaml# + +properties: + compatible: + enum: + - ti,bq27200 + - ti,bq27210 + - ti,bq27500 # deprecated, use revision specific property below + - ti,bq27510 # deprecated, use revision specific property below + - ti,bq27520 # deprecated, use revision specific property below + - ti,bq27500-1 + - ti,bq27510g1 + - ti,bq27510g2 + - ti,bq27510g3 + - ti,bq27520g1 + - ti,bq27520g2 + - ti,bq27520g3 + - ti,bq27520g4 + - ti,bq27521 + - ti,bq27530 + - ti,bq27531 + - ti,bq27541 + - ti,bq27542 + - ti,bq27546 + - ti,bq27742 + - ti,bq27545 + - ti,bq27411 + - ti,bq27421 + - ti,bq27425 + - ti,bq27426 + - ti,bq27441 + - ti,bq27621 + + reg: + maxItems: 1 + description: integer, I2C address of the fuel gauge. + + monitored-battery: + description: | + phandle of battery characteristics node. + The fuel gauge uses the following battery properties: + - energy-full-design-microwatt-hours + - charge-full-design-microamp-hours + - voltage-min-design-microvolt + Both or neither of the *-full-design-*-hours properties must be set. + See Documentation/devicetree/bindings/power/supply/battery.txt + + power-supplies: true + +required: + - compatible + - reg +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + bat: battery { + compatible = "simple-battery"; + voltage-min-design-microvolt = <3200000>; + energy-full-design-microwatt-hours = <5290000>; + charge-full-design-microamp-hours = <1430000>; + }; + + bq27510g3: fuel-gauge@55 { + compatible = "ti,bq27510g3"; + reg = <0x55>; + monitored-battery = <&bat>; + }; + };
diff --git a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml new file mode 100644 index 0000000..2036977 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
@@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/cw2015_battery.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Battery driver for CW2015 shuntless fuel gauge by CellWise. + +maintainers: + - Tobias Schramm <t.schramm@manjaro.org> + +description: | + The driver can utilize information from a simple-battery linked via a + phandle in monitored-battery. If specified the driver uses the + charge-full-design-microamp-hours property of the battery. + +properties: + compatible: + const: cellwise,cw2015 + + reg: + maxItems: 1 + + cellwise,battery-profile: + description: | + This property specifies characteristics of the battery used. The format + of this binary blob is kept secret by CellWise. The only way to obtain + it is to mail two batteries to a test facility of CellWise and receive + back a test report with the binary blob. + $ref: /schemas/types.yaml#definitions/uint8-array + minItems: 64 + maxItems: 64 + + cellwise,monitor-interval-ms: + description: + Specifies the interval in milliseconds gauge values are polled at + minimum: 250 + + power-supplies: + description: + Specifies supplies used for charging the battery connected to this gauge + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 8 # Should be enough + + monitored-battery: + description: + Specifies the phandle of a simple-battery connected to this gauge + $ref: /schemas/types.yaml#/definitions/phandle + +required: + - compatible + - reg + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + cw2015@62 { + compatible = "cellwise,cw201x"; + reg = <0x62>; + cellwise,battery-profile = /bits/ 8 < + 0x17 0x67 0x80 0x73 0x6E 0x6C 0x6B 0x63 + 0x77 0x51 0x5C 0x58 0x50 0x4C 0x48 0x36 + 0x15 0x0C 0x0C 0x19 0x5B 0x7D 0x6F 0x69 + 0x69 0x5B 0x0C 0x29 0x20 0x40 0x52 0x59 + 0x57 0x56 0x54 0x4F 0x3B 0x1F 0x7F 0x17 + 0x06 0x1A 0x30 0x5A 0x85 0x93 0x96 0x2D + 0x48 0x77 0x9C 0xB3 0x80 0x52 0x94 0xCB + 0x2F 0x00 0x64 0xA5 0xB5 0x11 0xF0 0x11 + >; + cellwise,monitor-interval-ms = <5000>; + monitored-battery = <&bat>; + power-supplies = <&mains_charger>, <&usb_charger>; + }; + }; +
diff --git a/Documentation/devicetree/bindings/power/supply/power-supply.yaml b/Documentation/devicetree/bindings/power/supply/power-supply.yaml new file mode 100644 index 0000000..3bb02bb --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/power-supply.yaml
@@ -0,0 +1,40 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/power/supply/power-supply.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Power Supply Core Support + +maintainers: + - Sebastian Reichel <sre@kernel.org> + +properties: + power-supplies: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + This property is added to a supply in order to list the devices which + supply it power, referenced by their phandles. + +examples: + - | + power { + #address-cells = <1>; + #size-cells = <0>; + + usb_charger:charger@e { + compatible = "some,usb-charger"; + reg = <0xe>; + }; + + ac_charger:charger@c { + compatible = "some,ac-charger"; + reg = <0xc>; + }; + + battery:battery@b { + compatible = "some,battery"; + reg = <0xb>; + power-supplies = <&usb_charger>, <&ac_charger>; + }; + };
diff --git a/Documentation/devicetree/bindings/power/supply/power_supply.txt b/Documentation/devicetree/bindings/power/supply/power_supply.txt index 8391bfa..d9693e0 100644 --- a/Documentation/devicetree/bindings/power/supply/power_supply.txt +++ b/Documentation/devicetree/bindings/power/supply/power_supply.txt
@@ -1,23 +1,2 @@ -Power Supply Core Support - -Optional Properties: - - power-supplies : This property is added to a supply in order to list the - devices which supply it power, referenced by their phandles. - -Example: - - usb-charger: power@e { - compatible = "some,usb-charger"; - ... - }; - - ac-charger: power@c { - compatible = "some,ac-charger"; - ... - }; - - battery@b { - compatible = "some,battery"; - ... - power-supplies = <&usb-charger>, <&ac-charger>; - }; +This binding has been converted to yaml please see power-supply.yaml in this +directory.
diff --git a/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml b/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml new file mode 100644 index 0000000..7e0f73a --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml
@@ -0,0 +1,155 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/rohm,bd99954.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ROHM BD99954 Battery charger + +maintainers: + - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> + - Markus Laine <markus.laine@fi.rohmeurope.com> + - Mikko Mutanen <mikko.mutanen@fi.rohmeurope.com> + +description: | + The ROHM BD99954 is a Battery Management LSI for 1-4 cell Lithium-Ion + secondary battery intended to be used in space-constraint equipment such + as Low profile Notebook PC, Tablets and other applications. BD99954 + provides a Dual-source Battery Charger, two port BC1.2 detection and a + Battery Monitor. + + +properties: + compatible: + const: rohm,bd99954 +# +# The battery charging profile of BD99954. +# +# Curve (1) represents charging current. +# Curve (2) represents battery voltage. +# +# The BD99954 data sheet divides charging to three phases. +# a) Trickle-charge with constant current (8). +# b) pre-charge with constant current (6) +# c) fast-charge with: +# First a constant current (5) phase (CC) +# Then constant voltage (CV) phase (after the battery voltage has reached +# target level - until charging current has dropped to termination +# level (7) +# +# V ^ ^ I +# . . +# . . +# (4)- -.- - - - - - - - - - - - - - +++++++++++++++++++++++++++. +# . / . +# . ++++++/++ - - - - - - - - - - - - -.- - (5) +# . + / + . +# . + - -- . +# . + - + . +# . +.- -: . +# . .+ +` . +# . .- + | `/ . +# . .." + .: . +# . -" + -- . +# . (2) ..." + | :- . +# . ..."" + -: . +# (3)- -.-.""- - - - -+++++++++ - - - - - - -.:- - - - - - - - - .- - (6) +# . + `:. . +# . + | -: . +# . + -: . +# . + .. . +# . (1) + | "+++- - - -.- - (7) +# -++++++++++++++- - - - - - - - - - - - - - - - - + - - - .- - (8) +# . + - +# -------------------------------------------------+++++++++--> +# | | | CC | CV | +# | --trickle-- | -pre- | ---------fast----------- | +# +# The charger uses the following battery properties +# - trickle-charge-current-microamp: +# Current used at trickle-charge phase (8 in above chart) +# minimum: 64000 +# maximum: 1024000 +# multipleOf: 64000 +# - precharge-current-microamp: +# Current used at pre-charge phase (6 in above chart) +# minimum: 64000 +# maximum: 1024000 +# multipleOf: 64000 +# - constant-charge-current-max-microamp +# Current used at fast charge constant current phase (5 in above chart) +# minimum: 64000 +# maximum: 1024000 +# multipleOf: 64000 +# - constant-charge-voltage-max-microvolt +# The constant voltage used in fast charging phase (4 in above chart) +# minimum: 2560000 +# maximum: 19200000 +# multipleOf: 16000 +# - precharge-upper-limit-microvolt +# charging mode is changed from trickle charging to pre-charging +# when battery voltage exceeds this limit voltage (3 in above chart) +# minimum: 2048000 +# maximum: 19200000 +# multipleOf: 64000 +# - re-charge-voltage-microvolt +# minimum: 2560000 +# maximum: 19200000 +# multipleOf: 16000 +# re-charging is automatically started when battry has been discharging +# to the point where the battery voltage drops below this limit +# - over-voltage-threshold-microvolt +# battery is expected to be faulty if battery voltage exceeds this limit. +# Charger will then enter to a "battery faulty" -state +# minimum: 2560000 +# maximum: 19200000 +# multipleOf: 16000 +# - charge-term-current-microamp +# minimum: 0 +# maximum: 1024000 +# multipleOf: 64000 +# a charge cycle terminates when the battery voltage is above recharge +# threshold, and the current is below this setting (7 in above chart) +# See also Documentation/devicetree/bindings/power/supply/battery.txt + + monitored-battery: + description: + phandle of battery characteristics devicetree node + + rohm,vsys-regulation-microvolt: + description: system specific lower limit for system voltage. + minimum: 2560000 + maximum: 19200000 + multipleOf: 64000 + + rohm,vbus-input-current-limit-microamp: + description: system specific VBUS input current limit (in microamps). + minimum: 32000 + maximum: 16352000 + multipleOf: 32000 + + rohm,vcc-input-current-limit-microamp: + description: system specific VCC/VACP input current limit (in microamps). + minimum: 32000 + maximum: 16352000 + multipleOf: 32000 + +required: + - compatible + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + charger@9 { + compatible = "rohm,bd99954"; + monitored-battery = <&battery>; + reg = <0x9>; + interrupt-parent = <&gpio1>; + interrupts = <29 8>; + rohm,vsys-regulation-microvolt = <8960000>; + rohm,vbus-input-current-limit-microamp = <1472000>; + rohm,vcc-input-current-limit-microamp = <1472000>; + }; + };
diff --git a/Documentation/devicetree/bindings/power/supply/sbs,sbs-battery.yaml b/Documentation/devicetree/bindings/power/supply/sbs,sbs-battery.yaml new file mode 100644 index 0000000..a90b360 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/sbs,sbs-battery.yaml
@@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/sbs,sbs-battery.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SBS compliant battery + +maintainers: + - Sebastian Reichel <sre@kernel.org> + +description: | + Battery compatible with the smart battery system specifications + +properties: + + compatible: + oneOf: + - items: + - enum: + - ti,bq20z65 + - ti,bq20z75 + - enum: + - sbs,sbs-battery + - items: + - const: sbs,sbs-battery + + reg: + maxItems: 1 + + sbs,i2c-retry-count: + description: + The number of times to retry I2C transactions on I2C IO failure. + default: 0 + $ref: /schemas/types.yaml#/definitions/uint32 + + sbs,poll-retry-count: + description: + The number of times to try looking for new status after an external + change notification. + default: 0 + $ref: /schemas/types.yaml#/definitions/uint32 + + sbs,battery-detect-gpios: + description: + GPIO which signals battery detection. If this is not supplied, the bus + needs to be polled to detect the battery. + maxItems: 1 + + sbs,disable-charger-broadcasts: + description: + SBS batteries by default send broadcast messages to SBS compliant chargers to + configure max. charge current/voltage. If your hardware does not have an SBS + compliant charger it should be disabled via this property to avoid blocking + the bus. Also some SBS battery fuel gauges are known to have a buggy multi- + master implementation. + type: boolean + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + battery@b { + compatible = "ti,bq20z75", "sbs,sbs-battery"; + reg = <0xb>; + sbs,i2c-retry-count = <2>; + sbs,poll-retry-count = <10>; + sbs,battery-detect-gpios = <&gpio 122 GPIO_ACTIVE_HIGH>; + sbs,disable-charger-broadcasts; + }; + };
diff --git a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt deleted file mode 100644 index 4e78e51..0000000 --- a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt +++ /dev/null
@@ -1,27 +0,0 @@ -SBS sbs-battery -~~~~~~~~~~ - -Required properties : - - compatible: "<vendor>,<part-number>", "sbs,sbs-battery" as fallback. The - part number compatible string might be used in order to take care of - vendor specific registers. - Known <vendor>,<part-number>: - ti,bq20z75 - -Optional properties : - - sbs,i2c-retry-count : The number of times to retry i2c transactions on i2c - IO failure. - - sbs,poll-retry-count : The number of times to try looking for new status - after an external change notification. - - sbs,battery-detect-gpios : The gpio which signals battery detection and - a flag specifying its polarity. - -Example: - - battery@b { - compatible = "ti,bq20z75", "sbs,sbs-battery"; - reg = <0xb>; - sbs,i2c-retry-count = <2>; - sbs,poll-retry-count = <10>; - sbs,battery-detect-gpios = <&gpio-controller 122 1>; - }
diff --git a/Documentation/devicetree/bindings/property-units.txt b/Documentation/devicetree/bindings/property-units.txt index e9b8360..c80a110 100644 --- a/Documentation/devicetree/bindings/property-units.txt +++ b/Documentation/devicetree/bindings/property-units.txt
@@ -41,3 +41,7 @@ Pressure ---------------------------------------- -kpascal : kilopascal + +Throughput +---------------------------------------- +-kBps : kilobytes per second
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt b/Documentation/devicetree/bindings/pwm/imx-pwm.txt deleted file mode 100644 index 22f1c3d..0000000 --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt +++ /dev/null
@@ -1,27 +0,0 @@ -Freescale i.MX PWM controller - -Required properties: -- compatible : should be "fsl,<soc>-pwm" and one of the following - compatible strings: - - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1 - - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27 -- reg: physical base address and length of the controller's registers -- #pwm-cells: 2 for i.MX1 and 3 for i.MX27 and newer SoCs. See pwm.yaml - in this directory for a description of the cells format. -- clocks : Clock specifiers for both ipg and per clocks. -- clock-names : Clock names should include both "ipg" and "per" -See the clock consumer binding, - Documentation/devicetree/bindings/clock/clock-bindings.txt -- interrupts: The interrupt for the pwm controller - -Example: - -pwm1: pwm@53fb4000 { - #pwm-cells = <3>; - compatible = "fsl,imx53-pwm", "fsl,imx27-pwm"; - reg = <0x53fb4000 0x4000>; - clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>, - <&clks IMX5_CLK_PWM1_HF_GATE>; - clock-names = "ipg", "per"; - interrupts = <61>; -};
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml new file mode 100644 index 0000000..01df067 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
@@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/imx-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX PWM controller + +maintainers: + - Philipp Zabel <p.zabel@pengutronix.de> + +properties: + "#pwm-cells": + description: | + Should be 2 for i.MX1 and 3 for i.MX27 and newer SoCs. See pwm.yaml + in this directory for a description of the cells format. + enum: + - 2 + - 3 + + compatible: + enum: + - fsl,imx1-pwm + - fsl,imx27-pwm + + reg: + maxItems: 1 + + clocks: + items: + - description: SoC PWM ipg clock + - description: SoC PWM per clock + + clock-names: + items: + - const: ipg + - const: per + + interrupts: + maxItems: 1 + +required: + - "#pwm-cells" + - compatible + - reg + - clocks + - clock-names + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx5-clock.h> + + pwm@53fb4000 { + #pwm-cells = <3>; + compatible = "fsl,imx27-pwm"; + reg = <0x53fb4000 0x4000>; + clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>, + <&clks IMX5_CLK_PWM1_HF_GATE>; + clock-names = "ipg", "per"; + interrupts = <61>; + };
diff --git a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt deleted file mode 100644 index 5bf2095..0000000 --- a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt +++ /dev/null
@@ -1,22 +0,0 @@ -Freescale i.MX TPM PWM controller - -Required properties: -- compatible : Should be "fsl,imx7ulp-pwm". -- reg: Physical base address and length of the controller's registers. -- #pwm-cells: Should be 3. See pwm.yaml in this directory for a description of the cells format. -- clocks : The clock provided by the SoC to drive the PWM. -- interrupts: The interrupt for the PWM controller. - -Note: The TPM counter and period counter are shared between multiple channels, so all channels -should use same period setting. - -Example: - -tpm4: pwm@40250000 { - compatible = "fsl,imx7ulp-pwm"; - reg = <0x40250000 0x1000>; - assigned-clocks = <&pcc2 IMX7ULP_CLK_LPTPM4>; - assigned-clock-parents = <&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>; - clocks = <&pcc2 IMX7ULP_CLK_LPTPM4>; - #pwm-cells = <3>; -};
diff --git a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml new file mode 100644 index 0000000..fe9ef42 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml
@@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/imx-tpm-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX TPM PWM controller + +maintainers: + - Anson Huang <anson.huang@nxp.com> + +description: | + The TPM counter and period counter are shared between multiple + channels, so all channels should use same period setting. + +properties: + "#pwm-cells": + const: 3 + + compatible: + enum: + - fsl,imx7ulp-pwm + + reg: + maxItems: 1 + + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - "#pwm-cells" + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx7ulp-clock.h> + + pwm@40250000 { + compatible = "fsl,imx7ulp-pwm"; + reg = <0x40250000 0x1000>; + assigned-clocks = <&pcc2 IMX7ULP_CLK_LPTPM4>; + assigned-clock-parents = <&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>; + clocks = <&pcc2 IMX7ULP_CLK_LPTPM4>; + #pwm-cells = <3>; + };
diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt deleted file mode 100644 index a1b8a482..0000000 --- a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt +++ /dev/null
@@ -1,17 +0,0 @@ -Freescale MXS PWM controller - -Required properties: -- compatible: should be "fsl,imx23-pwm" -- reg: physical base address and length of the controller's registers -- #pwm-cells: should be 3. See pwm.yaml in this directory for a description of - the cells format. -- fsl,pwm-number: the number of PWM devices - -Example: - -pwm: pwm@80064000 { - compatible = "fsl,imx28-pwm", "fsl,imx23-pwm"; - reg = <0x80064000 0x2000>; - #pwm-cells = <3>; - fsl,pwm-number = <8>; -};
diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml b/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml new file mode 100644 index 0000000..da68f4a --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml
@@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/mxs-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale MXS PWM controller + +maintainers: + - Shawn Guo <shawn.guo@linaro.org> + - Anson Huang <anson.huang@nxp.com> + +properties: + compatible: + enum: + - fsl,imx23-pwm + + reg: + maxItems: 1 + + "#pwm-cells": + const: 3 + + fsl,pwm-number: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: u32 value representing the number of PWM devices + +required: + - compatible + - reg + - "#pwm-cells" + - fsl,pwm-number + +additionalProperties: false + +examples: + - | + pwm@80064000 { + compatible = "fsl,imx23-pwm"; + reg = <0x80064000 0x2000>; + #pwm-cells = <3>; + fsl,pwm-number = <8>; + };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml index ea7f329..fc799b0 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
@@ -49,17 +49,17 @@ are available. oneOf: - items: - - const: timers + - const: timers - items: - - const: timers - - const: pwm-tclk0 + - const: timers + - const: pwm-tclk0 - items: - - const: timers - - const: pwm-tclk1 + - const: timers + - const: pwm-tclk1 - items: - - const: timers - - const: pwm-tclk0 - - const: pwm-tclk1 + - const: timers + - const: pwm-tclk0 + - const: pwm-tclk1 interrupts: description: @@ -78,12 +78,11 @@ A list of PWM channels used as PWM outputs on particular platform. It is an array of up to 5 elements being indices of PWM channels (from 0 to 4), the order does not matter. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - uniqueItems: true - - items: - minimum: 0 - maximum: 4 + $ref: /schemas/types.yaml#/definitions/uint32-array + uniqueItems: true + items: + minimum: 0 + maximum: 4 required: - clocks
diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml index 945c14e..daadde9 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml
@@ -27,6 +27,7 @@ - renesas,pwm-r8a7794 # R-Car E2 - renesas,pwm-r8a7795 # R-Car H3 - renesas,pwm-r8a7796 # R-Car M3-W + - renesas,pwm-r8a77961 # R-Car M3-W+ - renesas,pwm-r8a77965 # R-Car M3-N - renesas,pwm-r8a77970 # R-Car V3M - renesas,pwm-r8a77980 # R-Car V3H @@ -68,7 +69,7 @@ pwm0: pwm@e6e30000 { compatible = "renesas,pwm-r8a7743", "renesas,pwm-rcar"; - reg = <0 0xe6e30000 0 0x8>; + reg = <0xe6e30000 0x8>; clocks = <&cpg CPG_MOD 523>; power-domains = <&sysc R8A7743_PD_ALWAYS_ON>; resets = <&cpg 523>;
diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt deleted file mode 100644 index a3106c7..0000000 --- a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt +++ /dev/null
@@ -1,40 +0,0 @@ -Anatop Voltage regulators - -Required properties: -- compatible: Must be "fsl,anatop-regulator" -- regulator-name: A string used as a descriptive name for regulator outputs -- anatop-reg-offset: Anatop MFD register offset -- anatop-vol-bit-shift: Bit shift for the register -- anatop-vol-bit-width: Number of bits used in the register -- anatop-min-bit-val: Minimum value of this register -- anatop-min-voltage: Minimum voltage of this regulator -- anatop-max-voltage: Maximum voltage of this regulator - -Optional properties: -- anatop-delay-reg-offset: Anatop MFD step time register offset -- anatop-delay-bit-shift: Bit shift for the step time register -- anatop-delay-bit-width: Number of bits used in the step time register -- vin-supply: The supply for this regulator -- anatop-enable-bit: Regulator enable bit offset - -Any property defined as part of the core regulator -binding, defined in regulator.txt, can also be used. - -Example: - - regulator-vddpu { - compatible = "fsl,anatop-regulator"; - regulator-name = "vddpu"; - regulator-min-microvolt = <725000>; - regulator-max-microvolt = <1300000>; - regulator-always-on; - anatop-reg-offset = <0x140>; - anatop-vol-bit-shift = <9>; - anatop-vol-bit-width = <5>; - anatop-delay-reg-offset = <0x170>; - anatop-delay-bit-shift = <24>; - anatop-delay-bit-width = <2>; - anatop-min-bit-val = <1>; - anatop-min-voltage = <725000>; - anatop-max-voltage = <1300000>; - };
diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml new file mode 100644 index 0000000..e7b3abe --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml
@@ -0,0 +1,94 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/anatop-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Anatop Voltage Regulators + +maintainers: + - Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org> + +allOf: + - $ref: "regulator.yaml#" + +properties: + compatible: + const: fsl,anatop-regulator + + regulator-name: true + + anatop-reg-offset: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: u32 value representing the anatop MFD register offset. + + anatop-vol-bit-shift: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: u32 value representing the bit shift for the register. + + anatop-vol-bit-width: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: u32 value representing the number of bits used in the register. + + anatop-min-bit-val: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: u32 value representing the minimum value of this register. + + anatop-min-voltage: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: u32 value representing the minimum voltage of this regulator. + + anatop-max-voltage: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: u32 value representing the maximum voltage of this regulator. + + anatop-delay-reg-offset: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: u32 value representing the anatop MFD step time register offset. + + anatop-delay-bit-shift: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: u32 value representing the bit shift for the step time register. + + anatop-delay-bit-width: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: u32 value representing the number of bits used in the step time register. + + anatop-enable-bit: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: u32 value representing regulator enable bit offset. + + vin-supply: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: input supply phandle. + +required: + - compatible + - regulator-name + - anatop-reg-offset + - anatop-vol-bit-shift + - anatop-vol-bit-width + - anatop-min-bit-val + - anatop-min-voltage + - anatop-max-voltage + +unevaluatedProperties: false + +examples: + - | + regulator-vddpu { + compatible = "fsl,anatop-regulator"; + regulator-name = "vddpu"; + regulator-min-microvolt = <725000>; + regulator-max-microvolt = <1300000>; + regulator-always-on; + anatop-reg-offset = <0x140>; + anatop-vol-bit-shift = <9>; + anatop-vol-bit-width = <5>; + anatop-delay-reg-offset = <0x170>; + anatop-delay-bit-shift = <24>; + anatop-delay-bit-width = <2>; + anatop-min-bit-val = <1>; + anatop-min-voltage = <725000>; + anatop-max-voltage = <1300000>; + };
diff --git a/Documentation/devicetree/bindings/regulator/arizona-regulator.txt b/Documentation/devicetree/bindings/regulator/arizona-regulator.txt deleted file mode 100644 index 69bf419..0000000 --- a/Documentation/devicetree/bindings/regulator/arizona-regulator.txt +++ /dev/null
@@ -1,18 +0,0 @@ -Cirrus Logic Arizona class audio SoCs - -These devices are audio SoCs with extensive digital capabilities and a range -of analogue I/O. - -This document lists regulator specific bindings, see the primary binding -document: - For Wolfson Microelectronic Arizona codecs: ../mfd/arizona.txt - For Cirrus Logic Madera codecs: ../mfd/madera.txt - -Optional properties: - - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA - -Optional subnodes: - - ldo1 : Initial data for the LDO1 regulator, as covered in - Documentation/devicetree/bindings/regulator/regulator.txt - - micvdd : Initial data for the MICVDD regulator, as covered in - Documentation/devicetree/bindings/regulator/regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/cirrus,lochnagar.txt b/Documentation/devicetree/bindings/regulator/cirrus,lochnagar.txt deleted file mode 100644 index 91974e6..0000000 --- a/Documentation/devicetree/bindings/regulator/cirrus,lochnagar.txt +++ /dev/null
@@ -1,82 +0,0 @@ -Cirrus Logic Lochnagar Audio Development Board - -Lochnagar is an evaluation and development board for Cirrus Logic -Smart CODEC and Amp devices. It allows the connection of most Cirrus -Logic devices on mini-cards, as well as allowing connection of -various application processor systems to provide a full evaluation -platform. Audio system topology, clocking and power can all be -controlled through the Lochnagar, allowing the device under test -to be used in a variety of possible use cases. - -This binding document describes the binding for the regulator portion -of the driver. - -Also see these documents for generic binding information: - [1] Regulator: ../regulator/regulator.txt - -This binding must be part of the Lochnagar MFD binding: - [2] ../mfd/cirrus,lochnagar.txt - -Optional sub-nodes: - - - VDDCORE : Initialisation data for the VDDCORE regulator, which - supplies the CODECs digital core if it has no build regulator for that - purpose. - Required Properties: - - compatible : One of the following strings: - "cirrus,lochnagar2-vddcore" - - SYSVDD-supply: Primary power supply for the Lochnagar. - - - MICVDD : Initialisation data for the MICVDD regulator, which - supplies the CODECs MICVDD. - Required Properties: - - compatible : One of the following strings: - "cirrus,lochnagar2-micvdd" - - SYSVDD-supply: Primary power supply for the Lochnagar. - - - MIC1VDD, MIC2VDD : Initialisation data for the MICxVDD supplies. - Required Properties: - - compatible : One of the following strings: - "cirrus,lochnagar2-mic1vdd", "cirrus,lochnagar2-mic2vdd" - Optional Properties: - - cirrus,micbias-input : A property selecting which of the CODEC - minicard micbias outputs should be used, valid values are 1 - 4. - - MICBIAS1-supply, MICBIAS2-supply: Regulator supplies for the - MICxVDD outputs, supplying the digital microphones, normally - supplied from the attached CODEC. - - - VDD1V8 : Recommended fixed regulator for the VDD1V8 regulator, which supplies the - CODECs analog and 1.8V digital supplies. - Required Properties: - - compatible : Should be set to "regulator-fixed" - - regulator-min-microvolt : Should be set to 1.8V - - regulator-max-microvolt : Should be set to 1.8V - - regulator-boot-on - - regulator-always-on - - vin-supply : Should be set to same supply as SYSVDD - -Example: - -lochnagar { - lochnagar-micvdd: MICVDD { - compatible = "cirrus,lochnagar2-micvdd"; - - SYSVDD-supply = <&wallvdd>; - - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; - - lochnagar-vdd1v8: VDD1V8 { - compatible = "regulator-fixed"; - - regulator-name = "VDD1V8"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - regulator-boot-on; - regulator-always-on; - - vin-supply = <&wallvdd>; - }; -}; -
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml b/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml index 9d3b284..6055903 100644 --- a/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml
@@ -46,24 +46,22 @@ 0: LOW 1: HIGH Default is LOW if nothing else is specified. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - maxItems: 8 - items: - enum: [ 0, 1 ] - default: 0 + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 8 + items: + enum: [0, 1] + default: 0 states: description: Selection of available voltages/currents provided by this regulator and matching GPIO configurations to achieve them. If there are no states in the "states" array, use a fixed regulator instead. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-matrix - - maxItems: 8 - items: - items: - - description: Voltage in microvolts - - description: GPIO group state value + $ref: /schemas/types.yaml#/definitions/uint32-matrix + maxItems: 8 + items: + items: + - description: Voltage in microvolts + - description: GPIO group state value startup-delay-us: description: startup time in microseconds @@ -81,12 +79,11 @@ regulator-type: description: Specifies what is being regulated. - allOf: - - $ref: /schemas/types.yaml#/definitions/string - - enum: - - voltage - - current - default: voltage + $ref: /schemas/types.yaml#/definitions/string + enum: + - voltage + - current + default: voltage required: - compatible
diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77826.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77826.yaml new file mode 100644 index 0000000..78c0b63 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max77826.yaml
@@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max77826.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim Integrated MAX77826 PMIC + +maintainers: + - Iskren Chernev <iskren.chernev@gmail.com> + +properties: + $nodename: + pattern: "pmic@[0-9a-f]{1,2}" + compatible: + enum: + - maxim,max77826 + + reg: + maxItems: 1 + + regulators: + type: object + $ref: regulator.yaml# + description: | + list of regulators provided by this controller, must be named + after their hardware counterparts LDO[1-15], BUCK and BUCKBOOST + + patternProperties: + "^LDO([1-9]|1[0-5])$": + type: object + $ref: regulator.yaml# + + "^BUCK|BUCKBOOST$": + type: object + $ref: regulator.yaml# + + additionalProperties: false + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@69 { + compatible = "maxim,max77826"; + reg = <0x69>; + + regulators { + LDO2 { + regulator-min-microvolt = <650000>; + regulator-max-microvolt = <3587500>; + }; + }; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml index f0acce2..90727fd 100644 --- a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml +++ b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml
@@ -27,17 +27,14 @@ patternProperties: "^buck[1-4]$": - allOf: - - $ref: "regulator.yaml#" + $ref: "regulator.yaml#" type: object "^ldo[1-4]$": - allOf: - - $ref: "regulator.yaml#" + $ref: "regulator.yaml#" type: object additionalProperties: false - additionalProperties: false required: - compatible
diff --git a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml index a682af0..12b8963 100644 --- a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml +++ b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml
@@ -21,17 +21,16 @@ regulators: type: object - allOf: - - $ref: regulator.yaml# + $ref: regulator.yaml# + description: | list of regulators provided by this controller, must be named after their hardware counterparts BUCK[1-4], one LDORTC, and LDO[2-5] properties: mps,switch-freq: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint8" - enum: [ 0, 1, 2, 3 ] + $ref: "/schemas/types.yaml#/definitions/uint8" + enum: [0, 1, 2, 3] default: 2 description: | switching frequency must be one of following corresponding value @@ -40,32 +39,27 @@ patternProperties: "^ldo[1-4]$": type: object - allOf: - - $ref: regulator.yaml# + $ref: regulator.yaml# "^ldortc$": type: object - allOf: - - $ref: regulator.yaml# + $ref: regulator.yaml# "^buck[1-4]$": type: object - allOf: - - $ref: regulator.yaml# + $ref: regulator.yaml# properties: mps,buck-softstart: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint8" - enum: [ 0, 1, 2, 3 ] + $ref: "/schemas/types.yaml#/definitions/uint8" + enum: [0, 1, 2, 3] description: | defines the soft start time of this buck, must be one of the following corresponding values 150us, 300us, 610us, 920us mps,buck-phase-delay: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint8" - enum: [ 0, 1, 2, 3 ] + $ref: "/schemas/types.yaml#/definitions/uint8" + enum: [0, 1, 2, 3] description: | defines the phase delay of this buck, must be one of the following corresponding values 0deg, 90deg, 180deg, 270deg @@ -75,7 +69,8 @@ description: | disables over voltage protection of this buck - additionalProperties: false + unevaluatedProperties: false + additionalProperties: false required:
diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml index 91a39a3..ec505db 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/regulator.yaml
@@ -123,9 +123,8 @@ 0: Disable active discharge. 1: Enable active discharge. Absence of this property will leave configuration to default. - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - enum: [ 0, 1 ] + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: [0, 1] regulator-coupled-with: description: Regulators with which the regulator is coupled. The linkage
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml index 71ce032..5ce587f 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml
@@ -24,10 +24,9 @@ patternProperties: "^LDO[1-7]$": type: object - allOf: - - $ref: regulator.yaml# description: Properties for single LDO regulator. + $ref: regulator.yaml# properties: regulator-name: @@ -35,12 +34,13 @@ description: should be "ldo1", ..., "ldo7" + unevaluatedProperties: false + "^BUCK[1-7]$": type: object - allOf: - - $ref: regulator.yaml# description: Properties for single BUCK regulator. + $ref: regulator.yaml# properties: regulator-name: @@ -49,40 +49,36 @@ should be "buck1", ..., "buck7" rohm,dvs-run-voltage: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - maximum: 3300000 description: PMIC default "RUN" state voltage in uV. See below table for bucks which support this. 0 means disabled. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 3300000 rohm,dvs-idle-voltage: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - maximum: 3300000 description: PMIC default "IDLE" state voltage in uV. See below table for bucks which support this. 0 means disabled. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 3300000 rohm,dvs-suspend-voltage: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - maximum: 3300000 description: PMIC default "SUSPEND" state voltage in uV. See below table for bucks which support this. 0 means disabled. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 3300000 rohm,dvs-lpsr-voltage: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - maximum: 3300000 description: PMIC default "LPSR" state voltage in uV. See below table for bucks which support this. 0 means disabled. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 3300000 # Supported default DVS states: # buck | run | idle | suspend | lpsr @@ -103,5 +99,7 @@ required: - regulator-name - additionalProperties: false + + unevaluatedProperties: false + additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml index a323b16..19d9408 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
@@ -30,8 +30,7 @@ patternProperties: "^LDO[1-7]$": type: object - allOf: - - $ref: regulator.yaml# + $ref: regulator.yaml# description: Properties for single LDO regulator. @@ -41,10 +40,11 @@ description: should be "ldo1", ..., "ldo7" + unevaluatedProperties: false + "^BUCK[1-8]$": type: object - allOf: - - $ref: regulator.yaml# + $ref: regulator.yaml# description: Properties for single BUCK regulator. @@ -55,28 +55,25 @@ should be "buck1", ..., "buck8" rohm,dvs-run-voltage: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - maximum: 1300000 + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 1300000 description: PMIC default "RUN" state voltage in uV. See below table for bucks which support this. 0 means disabled. rohm,dvs-idle-voltage: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - maximum: 1300000 + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 1300000 description: PMIC default "IDLE" state voltage in uV. See below table for bucks which support this. 0 means disabled. rohm,dvs-suspend-voltage: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - maximum: 1300000 + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 1300000 description: PMIC default "SUSPEND" state voltage in uV. See below table for bucks which support this. 0 means disabled. @@ -99,5 +96,7 @@ required: - regulator-name - additionalProperties: false + + unevaluatedProperties: false + additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml index 526fd00..07256a4 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
@@ -29,8 +29,7 @@ patternProperties: "^LDO[1-6]$": type: object - allOf: - - $ref: regulator.yaml# + $ref: regulator.yaml# description: Properties for single LDO regulator. @@ -40,10 +39,11 @@ description: should be "ldo1", ..., "ldo6" + unevaluatedProperties: false + "^BUCK[1-6]$": type: object - allOf: - - $ref: regulator.yaml# + $ref: regulator.yaml# description: Properties for single BUCK regulator. @@ -54,28 +54,25 @@ should be "buck1", ..., "buck6" rohm,dvs-run-voltage: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - maximum: 1300000 + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 1300000 description: PMIC default "RUN" state voltage in uV. See below table for bucks which support this. 0 means disabled. rohm,dvs-idle-voltage: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - maximum: 1300000 + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 1300000 description: PMIC default "IDLE" state voltage in uV. See below table for bucks which support this. 0 means disabled. rohm,dvs-suspend-voltage: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - maximum: 1300000 + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 1300000 description: PMIC default "SUSPEND" state voltage in uV. See below table for bucks which support this. 0 means disabled. @@ -93,5 +90,7 @@ required: - regulator-name - additionalProperties: false + + unevaluatedProperties: false + additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml index 64f1183..cb336b2 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml
@@ -23,8 +23,7 @@ - st,stm32mp1-booster st,syscfg: - allOf: - - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: "/schemas/types.yaml#/definitions/phandle-array" description: phandle to system configuration controller. vdda-supply:
diff --git a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml index 8d8f38f..e6322bc 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml
@@ -26,8 +26,7 @@ "^(reg11|reg18|usb33)$": type: object - allOf: - - $ref: "regulator.yaml#" + $ref: "regulator.yaml#" required: - compatible
diff --git a/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml b/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml new file mode 100644 index 0000000..a0aea73 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml
@@ -0,0 +1,37 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/wlf,arizona.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic/Wolfson Microelectronics Arizona/Madera class audio SoCs + +maintainers: + - patches@opensource.cirrus.com + +description: | + These devices are audio SoCs with extensive digital capabilities and a + range of analogue I/O. + + This document lists regulator specific bindings, see the primary binding + document. For Wolfson Microelectronic Arizona codecs ../mfd/wlf,arizona.yaml + and for Cirrus Logic Madera codecs ../mfd/madera.txt + +properties: + wlf,ldoena: + description: + GPIO specifier for the GPIO controlling LDOENA. + $ref: "/schemas/types.yaml#/definitions/phandle-array" + maxItems: 1 + + ldo1: + description: + Initial data for the LDO1 regulator. + $ref: "regulator.yaml#" + type: object + + micvdd: + description: + Initial data for the MICVDD regulator. + $ref: "regulator.yaml#" + type: object
diff --git a/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml b/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml new file mode 100644 index 0000000..c019f9f --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml
@@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/remoteproc/ingenic,vpu.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Ingenic Video Processing Unit bindings + +description: + Inside the Video Processing Unit (VPU) of the recent JZ47xx SoCs from + Ingenic is a second Xburst MIPS CPU very similar to the main core. + This document describes the devicetree bindings for this auxiliary + processor. + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +properties: + compatible: + const: ingenic,jz4770-vpu-rproc + + reg: + items: + - description: aux registers + - description: tcsm0 registers + - description: tcsm1 registers + - description: sram registers + + reg-names: + items: + - const: aux + - const: tcsm0 + - const: tcsm1 + - const: sram + + clocks: + items: + - description: aux clock + - description: vpu clock + + clock-names: + items: + - const: aux + - const: vpu + + interrupts: + description: VPU hardware interrupt + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/jz4770-cgu.h> + + vpu: video-decoder@132a0000 { + compatible = "ingenic,jz4770-vpu-rproc"; + + reg = <0x132a0000 0x20>, /* AUX */ + <0x132b0000 0x4000>, /* TCSM0 */ + <0x132c0000 0xc000>, /* TCSM1 */ + <0x132f0000 0x7000>; /* SRAM */ + reg-names = "aux", "tcsm0", "tcsm1", "sram"; + + clocks = <&cgu JZ4770_CLK_AUX>, <&cgu JZ4770_CLK_VPU>; + clock-names = "aux", "vpu"; + + interrupt-parent = <&cpuintc>; + interrupts = <3>; + };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt index 9938918..5473702 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
@@ -15,12 +15,16 @@ "qcom,qcs404-adsp-pas" "qcom,qcs404-cdsp-pas" "qcom,qcs404-wcss-pas" + "qcom,sc7180-mpss-pas" "qcom,sdm845-adsp-pas" "qcom,sdm845-cdsp-pas" "qcom,sm8150-adsp-pas" "qcom,sm8150-cdsp-pas" "qcom,sm8150-mpss-pas" "qcom,sm8150-slpi-pas" + "qcom,sm8250-adsp-pas" + "qcom,sm8250-cdsp-pas" + "qcom,sm8250-slpi-pas" - interrupts-extended: Usage: required @@ -44,8 +48,12 @@ qcom,sm8150-adsp-pas: qcom,sm8150-cdsp-pas: qcom,sm8150-slpi-pas: + qcom,sm8250-adsp-pas: + qcom,sm8250-cdsp-pas: + qcom,sm8250-slpi-pas: must be "wdog", "fatal", "ready", "handover", "stop-ack" qcom,qcs404-wcss-pas: + qcom,sc7180-mpss-pas: qcom,sm8150-mpss-pas: must be "wdog", "fatal", "ready", "handover", "stop-ack", "shutdown-ack" @@ -105,10 +113,14 @@ qcom,sdm845-cdsp-pas: qcom,sm8150-adsp-pas: qcom,sm8150-cdsp-pas: + qcom,sm8250-cdsp-pas: must be "cx", "load_state" + qcom,sc7180-mpss-pas: qcom,sm8150-mpss-pas: must be "cx", "load_state", "mss" + qcom,sm8250-adsp-pas: qcom,sm8150-slpi-pas: + qcom,sm8250-slpi-pas: must be "lcx", "lmx", "load_state" - memory-region:
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 88dfa3f..1f9a62e 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
@@ -79,7 +79,7 @@ "snoc_axi", "mnoc_axi", "qdss" qcom,sc7180-mss-pil: must be "iface", "bus", "xo", "snoc_axi", "mnoc_axi", - "mss_crypto", "mss_nav", "nav" + "nav" qcom,sdm845-mss-pil: must be "iface", "bus", "mem", "xo", "gpll0_mss", "snoc_axi", "mnoc_axi", "prng" @@ -102,6 +102,14 @@ must be "mss_restart", "pdc_reset" for the modem sub-system on SC7180, SDM845 SoCs +For devices where the mba and mpss sub-nodes are not specified, mba/mpss region +should be referenced as follows: +- memory-region: + Usage: required + Value type: <phandle> + Definition: reference to the reserved-memory for the mba region followed + by the mpss region + For the compatible strings below the following supplies are required: "qcom,q6v5-pil" "qcom,msm8916-mss-pil", @@ -173,16 +181,15 @@ For the compatible strings below the following phandle references are required: "qcom,sc7180-mss-pil" -- qcom,halt-nav-regs: +- qcom,spare-regs: Usage: required Value type: <prop-encoded-array> - Definition: reference to a list of 2 phandles with one offset each for - the modem sub-system running on SC7180 SoC. The first - phandle reference is to the mss clock node followed by the - offset within register space for nav halt register. The - second phandle reference is to a syscon representing TCSR - followed by the offset within syscon for conn_box_spare0 - register. + Definition: a phandle reference to a syscon representing TCSR followed + by the offset within syscon for conn_box_spare0 register + used by the modem sub-system running on SC7180 SoC. + +The Hexagon node must contain iommus property as described in ../iommu/iommu.txt +on platforms which do not have TrustZone. = SUBNODES: The Hexagon node must contain two subnodes, named "mba" and "mpss" representing
diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index c0d8386..4ffa252 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
@@ -25,25 +25,23 @@ maxItems: 3 resets: - maxItems: 1 + maxItems: 1 st,syscfg-holdboot: - allOf: - - $ref: "/schemas/types.yaml#/definitions/phandle-array" description: remote processor reset hold boot - Phandle of syscon block. - The offset of the hold boot setting register. - The field mask of the hold boot. + $ref: "/schemas/types.yaml#/definitions/phandle-array" maxItems: 1 st,syscfg-tz: - allOf: - - $ref: "/schemas/types.yaml#/definitions/phandle-array" description: Reference to the system configuration which holds the RCC trust zone mode - Phandle of syscon block. - The offset of the RCC trust zone mode register. - The field mask of the RCC trust zone mode. + $ref: "/schemas/types.yaml#/definitions/phandle-array" maxItems: 1 interrupts: @@ -90,8 +88,7 @@ (see ../reserved-memory/reserved-memory.txt) st,syscfg-pdds: - allOf: - - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: "/schemas/types.yaml#/definitions/phandle-array" description: | Reference to the system configuration which holds the remote 1st cell: phandle to syscon block
diff --git a/Documentation/devicetree/bindings/reserved-memory/ramoops.txt b/Documentation/devicetree/bindings/reserved-memory/ramoops.txt index 0eba562..b7886fe 100644 --- a/Documentation/devicetree/bindings/reserved-memory/ramoops.txt +++ b/Documentation/devicetree/bindings/reserved-memory/ramoops.txt
@@ -30,7 +30,7 @@ - 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 dump done on oops/panic +- 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 @@ -45,7 +45,16 @@ - unbuffered: if present, use unbuffered mappings to map the reserved region (defaults to buffered mappings) -- no-dump-oops: if present, only dump panics (defaults to panics and oops) +- 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/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt index bac4afa..4dd20de 100644 --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -77,6 +77,8 @@ 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 -------
diff --git a/Documentation/devicetree/bindings/reset/brcm,bcm7216-pcie-sata-rescal.yaml b/Documentation/devicetree/bindings/reset/brcm,bcm7216-pcie-sata-rescal.yaml index 512a33bd..dfce673 100644 --- a/Documentation/devicetree/bindings/reset/brcm,bcm7216-pcie-sata-rescal.yaml +++ b/Documentation/devicetree/bindings/reset/brcm,bcm7216-pcie-sata-rescal.yaml
@@ -7,7 +7,9 @@ title: BCM7216 RESCAL reset controller -description: This document describes the BCM7216 RESCAL reset controller which is responsible for controlling the reset of the SATA and PCIe0/1 instances on BCM7216. +description: This document describes the BCM7216 RESCAL reset controller + which is responsible for controlling the reset of the SATA and PCIe0/1 + instances on BCM7216. maintainers: - Florian Fainelli <f.fainelli@gmail.com>
diff --git a/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt b/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt index c2489e4..e10502d 100644 --- a/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt +++ b/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt
@@ -9,6 +9,8 @@ - For i.MX7 SoCs should be "fsl,imx7d-src", "syscon" - For i.MX8MQ SoCs should be "fsl,imx8mq-src", "syscon" - For i.MX8MM SoCs should be "fsl,imx8mm-src", "fsl,imx8mq-src", "syscon" + - For i.MX8MN SoCs should be "fsl,imx8mn-src", "fsl,imx8mq-src", "syscon" + - For i.MX8MP SoCs should be "fsl,imx8mp-src", "syscon" - reg: should be register base and length as documented in the datasheet - interrupts: Should contain SRC interrupt @@ -49,4 +51,6 @@ For list of all valid reset indices see <dt-bindings/reset/imx7-reset.h> for i.MX7, <dt-bindings/reset/imx8mq-reset.h> for i.MX8MQ and -<dt-bindings/reset/imx8mq-reset.h> for i.MX8MM +<dt-bindings/reset/imx8mq-reset.h> for i.MX8MM and +<dt-bindings/reset/imx8mq-reset.h> for i.MX8MN and +<dt-bindings/reset/imx8mp-reset.h> for i.MX8MP
diff --git a/Documentation/devicetree/bindings/reset/intel,rcu-gw.yaml b/Documentation/devicetree/bindings/reset/intel,rcu-gw.yaml index 8ac4372..6b2d56c 100644 --- a/Documentation/devicetree/bindings/reset/intel,rcu-gw.yaml +++ b/Documentation/devicetree/bindings/reset/intel,rcu-gw.yaml
@@ -21,8 +21,7 @@ intel,global-reset: description: Global reset register offset and bit offset. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-array items: - description: Register offset - description: Register bit offset
diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.yaml b/Documentation/devicetree/bindings/reset/renesas,rst.yaml index b5de1d1..4c2b429 100644 --- a/Documentation/devicetree/bindings/reset/renesas,rst.yaml +++ b/Documentation/devicetree/bindings/reset/renesas,rst.yaml
@@ -23,6 +23,7 @@ properties: compatible: enum: + - renesas,r8a7742-rst # RZ/G1H - renesas,r8a7743-rst # RZ/G1M - renesas,r8a7744-rst # RZ/G1N - renesas,r8a7745-rst # RZ/G1E
diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index 04819ad..f80ba2c 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -40,24 +40,18 @@ and identifies the type of the hart. mmu-type: - allOf: - - $ref: "/schemas/types.yaml#/definitions/string" - - enum: - - riscv,sv32 - - riscv,sv39 - - riscv,sv48 description: Identifies the MMU address translation mode used on this hart. These values originate from the RISC-V Privileged Specification document, available from https://riscv.org/specifications/ + $ref: "/schemas/types.yaml#/definitions/string" + enum: + - riscv,sv32 + - riscv,sv39 + - riscv,sv48 riscv,isa: - allOf: - - $ref: "/schemas/types.yaml#/definitions/string" - - enum: - - rv64imac - - rv64imafdc description: Identifies the specific RISC-V instruction set architecture supported by the hart. These are documented in the RISC-V @@ -67,6 +61,10 @@ While the isa strings in ISA specification are case insensitive, letters in the riscv,isa string must be all lowercase to simplify parsing. + $ref: "/schemas/types.yaml#/definitions/string" + enum: + - rv64imac + - rv64imafdc # RISC-V requires 'timebase-frequency' in /cpus, so disallow it here timebase-frequency: false
diff --git a/Documentation/devicetree/bindings/rng/arm-cctrng.yaml b/Documentation/devicetree/bindings/rng/arm-cctrng.yaml new file mode 100644 index 0000000..c471e4c --- /dev/null +++ b/Documentation/devicetree/bindings/rng/arm-cctrng.yaml
@@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/arm-cctrng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm TrustZone CryptoCell TRNG engine + +maintainers: + - Hadar Gat <hadar.gat@arm.com> + +description: |+ + Arm TrustZone CryptoCell TRNG (True Random Number Generator) engine. + +properties: + compatible: + enum: + - arm,cryptocell-713-trng + - arm,cryptocell-703-trng + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + arm,rosc-ratio: + description: + Arm TrustZone CryptoCell TRNG engine has 4 ring oscillators. + Sampling ratio values for these 4 ring oscillators. (from calibration) + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 4 + + clocks: + maxItems: 1 + +required: + - compatible + - interrupts + - reg + - arm,rosc-ratio + +additionalProperties: false + +examples: + - | + arm_cctrng: rng@60000000 { + compatible = "arm,cryptocell-713-trng"; + interrupts = <0 29 4>; + reg = <0x60000000 0x10000>; + arm,rosc-ratio = <5000 1000 500 0>; + };
diff --git a/Documentation/devicetree/bindings/rtc/dw-apb.txt b/Documentation/devicetree/bindings/rtc/dw-apb.txt deleted file mode 100644 index c703d51..0000000 --- a/Documentation/devicetree/bindings/rtc/dw-apb.txt +++ /dev/null
@@ -1,32 +0,0 @@ -* Designware APB timer - -Required properties: -- compatible: One of: - "snps,dw-apb-timer" - "snps,dw-apb-timer-sp" <DEPRECATED> - "snps,dw-apb-timer-osc" <DEPRECATED> -- reg: physical base address of the controller and length of memory mapped - region. -- interrupts: IRQ line for the timer. -- either clocks+clock-names or clock-frequency properties - -Optional properties: -- clocks : list of clock specifiers, corresponding to entries in - the clock-names property; -- clock-names : should contain "timer" and "pclk" entries, matching entries - in the clocks property. -- clock-frequency: The frequency in HZ of the timer. -- clock-freq: For backwards compatibility with picoxcell - -If using the clock specifiers, the pclk clock is optional, as not all -systems may use one. - - -Example: - timer@ffe00000 { - compatible = "snps,dw-apb-timer"; - interrupts = <0 170 4>; - reg = <0xffe00000 0x1000>; - clocks = <&timer_clk>, <&timer_pclk>; - clock-names = "timer", "pclk"; - };
diff --git a/Documentation/devicetree/bindings/rtc/renesas,sh-rtc.yaml b/Documentation/devicetree/bindings/rtc/renesas,sh-rtc.yaml index b95cb01..eff9df4 100644 --- a/Documentation/devicetree/bindings/rtc/renesas,sh-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/renesas,sh-rtc.yaml
@@ -43,6 +43,9 @@ items: enum: [ fck, rtc_x1, rtc_x3, extal ] + power-domains: + maxItems: 1 + required: - compatible - reg @@ -50,6 +53,7 @@ - interrupt-names - clocks - clock-names + - power-domains additionalProperties: false @@ -68,5 +72,6 @@ interrupt-names = "alarm", "period", "carry"; clocks = <&mstp6_clks R7S72100_CLK_RTC>, <&rtc_x1_clk>, <&rtc_x3_clk>, <&extal_clk>; + power-domains = <&cpg_clocks>; clock-names = "fck", "rtc_x1", "rtc_x3", "extal"; };
diff --git a/Documentation/devicetree/bindings/rtc/rtc-mxc.txt b/Documentation/devicetree/bindings/rtc/rtc-mxc.txt deleted file mode 100644 index 5bcd31d..0000000 --- a/Documentation/devicetree/bindings/rtc/rtc-mxc.txt +++ /dev/null
@@ -1,26 +0,0 @@ -* Real Time Clock of the i.MX SoCs - -RTC controller for the i.MX SoCs - -Required properties: -- compatible: Should be "fsl,imx1-rtc" or "fsl,imx21-rtc". -- reg: physical base address of the controller and length of memory mapped - region. -- interrupts: IRQ line for the RTC. -- clocks: should contain two entries: - * one for the input reference - * one for the the SoC RTC -- clock-names: should contain: - * "ref" for the input reference clock - * "ipg" for the SoC RTC clock - -Example: - -rtc@10007000 { - compatible = "fsl,imx21-rtc"; - reg = <0x10007000 0x1000>; - interrupts = <22>; - clocks = <&clks IMX27_CLK_CKIL>, - <&clks IMX27_CLK_RTC_IPG_GATE>; - clock-names = "ref", "ipg"; -};
diff --git a/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml b/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml new file mode 100644 index 0000000..4f263fa --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml
@@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/rtc-mxc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Real Time Clock of the i.MX SoCs + +allOf: + - $ref: "rtc.yaml#" + +maintainers: + - Philippe Reynes <tremyfr@gmail.com> + +properties: + compatible: + enum: + - fsl,imx1-rtc + - fsl,imx21-rtc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: input reference + - description: the SoC RTC clock + + clock-names: + items: + - const: ref + - const: ipg + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx27-clock.h> + + rtc@10007000 { + compatible = "fsl,imx21-rtc"; + reg = <0x10007000 0x1000>; + interrupts = <22>; + clocks = <&clks IMX27_CLK_CKIL>, + <&clks IMX27_CLK_RTC_IPG_GATE>; + clock-names = "ref", "ipg"; + };
diff --git a/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt deleted file mode 100644 index 79d7e87..0000000 --- a/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt +++ /dev/null
@@ -1,17 +0,0 @@ -* i.MX53 Secure Real Time Clock (SRTC) - -Required properties: -- compatible: should be: "fsl,imx53-rtc" -- reg: physical base address of the controller and length of memory mapped - region. -- clocks: should contain the phandle for the rtc clock -- interrupts: rtc alarm interrupt - -Example: - -rtc@53fa4000 { - compatible = "fsl,imx53-rtc"; - reg = <0x53fa4000 0x4000>; - interrupts = <24>; - clocks = <&clks IMX5_CLK_SRTC_GATE>; -};
diff --git a/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.yaml b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.yaml new file mode 100644 index 0000000..2d1a3066 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.yaml
@@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/rtc-mxc_v2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: i.MX53 Secure Real Time Clock (SRTC) + +allOf: + - $ref: "rtc.yaml#" + +maintainers: + - Patrick Bruenn <p.bruenn@beckhoff.com> + +properties: + compatible: + enum: + - fsl,imx53-rtc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx5-clock.h> + + rtc@53fa4000 { + compatible = "fsl,imx53-rtc"; + reg = <0x53fa4000 0x4000>; + interrupts = <24>; + clocks = <&clks IMX5_CLK_SRTC_GATE>; + };
diff --git a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml index 48c6caf..5456604 100644 --- a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml
@@ -32,16 +32,15 @@ maxItems: 1 st,syscfg: - allOf: - - $ref: "/schemas/types.yaml#/definitions/phandle-array" - - items: - minItems: 3 - maxItems: 3 + $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + minItems: 3 + maxItems: 3 description: | - Phandle/offset/mask triplet. The phandle to pwrcfg used to - access control register at offset, and change the dbp (Disable Backup - Protection) bit represented by the mask, mandatory to disable/enable backup - domain (RTC registers) write protection. + Phandle/offset/mask triplet. The phandle to pwrcfg used to + access control register at offset, and change the dbp (Disable Backup + Protection) bit represented by the mask, mandatory to disable/enable backup + domain (RTC registers) write protection. assigned-clocks: description: | @@ -78,14 +77,14 @@ const: st,stm32h7-rtc then: - properties: - clocks: - minItems: 2 - maxItems: 2 + properties: + clocks: + minItems: 2 + maxItems: 2 - required: - - clock-names - - st,syscfg + required: + - clock-names + - st,syscfg - if: properties: @@ -94,16 +93,16 @@ const: st,stm32mp1-rtc then: - properties: - clocks: - minItems: 2 - maxItems: 2 + properties: + clocks: + minItems: 2 + maxItems: 2 - assigned-clocks: false - assigned-clock-parents: false + assigned-clocks: false + assigned-clock-parents: false - required: - - clock-names + required: + - clock-names required: - compatible
diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt deleted file mode 100644 index 55700f2..0000000 --- a/Documentation/devicetree/bindings/serial/8250.txt +++ /dev/null
@@ -1,100 +0,0 @@ -* UART (Universal Asynchronous Receiver/Transmitter) - -Required properties: -- compatible : one of: - - "ns8250" - - "ns16450" - - "ns16550a" - - "ns16550" - - "ns16750" - - "ns16850" - - For Tegra20, must contain "nvidia,tegra20-uart" - - For other Tegra, must contain '"nvidia,<chip>-uart", - "nvidia,tegra20-uart"' where <chip> is tegra30, tegra114, tegra124, - tegra132, or tegra210. - - "nxp,lpc3220-uart" - - "ralink,rt2880-uart" - - For MediaTek BTIF, must contain '"mediatek,<chip>-btif", - "mediatek,mtk-btif"' where <chip> is mt7622, mt7623. - - "altr,16550-FIFO32" - - "altr,16550-FIFO64" - - "altr,16550-FIFO128" - - "fsl,16550-FIFO64" - - "fsl,ns16550" - - "intel,xscale-uart" - - "ti,da830-uart" - - "aspeed,ast2400-vuart" - - "aspeed,ast2500-vuart" - - "nuvoton,npcm750-uart" - - "serial" if the port type is unknown. -- reg : offset and length of the register set for the device. -- interrupts : should contain uart interrupt. -- clock-frequency : the input clock frequency for the UART - or - clocks phandle to refer to the clk used as per Documentation/devicetree - /bindings/clock/clock-bindings.txt - -Optional properties: -- current-speed : the current active speed of the UART. -- reg-offset : offset to apply to the mapbase from the start of the registers. -- reg-shift : quantity to shift the register offsets by. -- reg-io-width : the size (in bytes) of the IO accesses that should be - performed on the device. There are some systems that require 32-bit - accesses to the UART (e.g. TI davinci). -- used-by-rtas : set to indicate that the port is in use by the OpenFirmware - RTAS and should not be registered. -- no-loopback-test: set to indicate that the port does not implements loopback - test mode -- fifo-size: the fifo size of the UART. -- auto-flow-control: one way to enable automatic flow control support. The - driver is allowed to detect support for the capability even without this - property. -- tx-threshold: Specify the TX FIFO low water indication for parts with - programmable TX FIFO thresholds. -- resets : phandle + reset specifier pairs -- overrun-throttle-ms : how long to pause uart rx when input overrun is encountered. -- {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD - line respectively. It will use specified GPIO instead of the peripheral - function pin for the UART feature. If unsure, don't specify this property. -- aspeed,sirq-polarity-sense: Only applicable to aspeed,ast2500-vuart. - phandle to aspeed,ast2500-scu compatible syscon alongside register offset - and bit number to identify how the SIRQ polarity should be configured. - One possible data source is the LPC/eSPI mode bit. - Example: aspeed,sirq-polarity-sense = <&syscon 0x70 25> - -Note: -* fsl,ns16550: - ------------ - Freescale DUART is very similar to the PC16552D (and to a - pair of NS16550A), albeit with some nonstandard behavior such as - erratum A-004737 (relating to incorrect BRK handling). - - Represents a single port that is compatible with the DUART found - on many Freescale chips (examples include mpc8349, mpc8548, - mpc8641d, p4080 and ls2085a). - -Example: - - uart@80230000 { - compatible = "ns8250"; - reg = <0x80230000 0x100>; - clock-frequency = <3686400>; - interrupts = <10>; - reg-shift = <2>; - }; - -Example for OMAP UART using GPIO-based modem control signals: - - uart4: serial@49042000 { - compatible = "ti,omap3-uart"; - reg = <0x49042000 0x400>; - interrupts = <80>; - ti,hwmods = "uart4"; - clock-frequency = <48000000>; - cts-gpios = <&gpio3 5 GPIO_ACTIVE_LOW>; - rts-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>; - dtr-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; - dsr-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>; - dcd-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; - rng-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>; - };
diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml new file mode 100644 index 0000000..c1d4c19 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -0,0 +1,233 @@ +# Copyright 2020 Lubomir Rintel <lkundrak@v3.sk> +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/8250.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: UART (Universal Asynchronous Receiver/Transmitter) bindings + +maintainers: + - devicetree@vger.kernel.org + +allOf: + - $ref: /schemas/serial.yaml# + - if: + required: + - aspeed,sirq-polarity-sense + then: + properties: + compatible: + const: aspeed,ast2500-vuart + - if: + properties: + compatible: + const: mrvl,mmp-uart + then: + properties: + reg-shift: + const: 2 + required: + - reg-shift + - if: + not: + properties: + compatible: + items: + - enum: + - ns8250 + - ns16450 + - ns16550 + - ns16550a + then: + anyOf: + - required: [ clock-frequency ] + - required: [ clocks ] + +properties: + compatible: + oneOf: + - const: ns8250 + - const: ns16450 + - const: ns16550 + - const: ns16550a + - const: ns16850 + - const: aspeed,ast2400-vuart + - const: aspeed,ast2500-vuart + - const: intel,xscale-uart + - const: mrvl,pxa-uart + - const: nuvoton,npcm750-uart + - const: nvidia,tegra20-uart + - const: nxp,lpc3220-uart + - items: + - enum: + - altr,16550-FIFO32 + - altr,16550-FIFO64 + - altr,16550-FIFO128 + - fsl,16550-FIFO64 + - fsl,ns16550 + - andestech,uart16550 + - nxp,lpc1850-uart + - opencores,uart16550-rtlsvn105 + - ti,da830-uart + - const: ns16550a + - items: + - enum: + - ns16750 + - cavium,octeon-3860-uart + - xlnx,xps-uart16550-2.00.b + - ralink,rt2880-uart + - enum: + - ns16550 # Deprecated, unless the FIFO really is broken + - ns16550a + - items: + - enum: + - ralink,mt7620a-uart + - ralink,rt3052-uart + - ralink,rt3883-uart + - const: ralink,rt2880-uart + - enum: + - ns16550 # Deprecated, unless the FIFO really is broken + - ns16550a + - items: + - enum: + - mediatek,mt7622-btif + - mediatek,mt7623-btif + - const: mediatek,mtk-btif + - items: + - enum: + - mediatek,mt7622-btif + - mediatek,mt7623-btif + - const: mediatek,mtk-btif + - items: + - const: mrvl,mmp-uart + - const: intel,xscale-uart + - items: + - enum: + - nvidia,tegra30-uart + - nvidia,tegra114-uart + - nvidia,tegra124-uart + - nvidia,tegra186-uart + - nvidia,tegra194-uart + - nvidia,tegra210-uart + - const: nvidia,tegra20-uart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-frequency: true + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + current-speed: + $ref: /schemas/types.yaml#definitions/uint32 + description: The current active speed of the UART. + + reg-offset: + description: | + Offset to apply to the mapbase from the start of the registers. + + reg-shift: + description: Quantity to shift the register offsets by. + + reg-io-width: + description: | + The size (in bytes) of the IO accesses that should be performed on the + device. There are some systems that require 32-bit accesses to the + UART (e.g. TI davinci). + + used-by-rtas: + type: boolean + description: | + Set to indicate that the port is in use by the OpenFirmware RTAS and + should not be registered. + + no-loopback-test: + type: boolean + description: | + Set to indicate that the port does not implement loopback test mode. + + fifo-size: + $ref: /schemas/types.yaml#definitions/uint32 + description: The fifo size of the UART. + + auto-flow-control: + type: boolean + description: | + One way to enable automatic flow control support. The driver is + allowed to detect support for the capability even without this + property. + + tx-threshold: + $ref: /schemas/types.yaml#definitions/uint32 + description: | + Specify the TX FIFO low water indication for parts with programmable + TX FIFO thresholds. + + overrun-throttle-ms: + description: | + How long to pause uart rx when input overrun is encountered. + + rts-gpios: true + cts-gpios: true + dtr-gpios: true + dsr-gpios: true + rng-gpios: true + dcd-gpios: true + + aspeed,sirq-polarity-sense: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: | + Phandle to aspeed,ast2500-scu compatible syscon alongside register + offset and bit number to identify how the SIRQ polarity should be + configured. One possible data source is the LPC/eSPI mode bit. Only + applicable to aspeed,ast2500-vuart. + +required: + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + serial@80230000 { + compatible = "ns8250"; + reg = <0x80230000 0x100>; + interrupts = <10>; + reg-shift = <2>; + clock-frequency = <48000000>; + }; + - | + #include <dt-bindings/gpio/gpio.h> + serial@49042000 { + compatible = "andestech,uart16550", "ns16550a"; + reg = <0x49042000 0x400>; + interrupts = <80>; + clock-frequency = <48000000>; + cts-gpios = <&gpio3 5 GPIO_ACTIVE_LOW>; + rts-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>; + dtr-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; + dsr-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>; + dcd-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; + rng-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>; + }; + - | + #include <dt-bindings/clock/aspeed-clock.h> + serial@1e787000 { + compatible = "aspeed,ast2500-vuart"; + reg = <0x1e787000 0x40>; + reg-shift = <2>; + interrupts = <8>; + clocks = <&syscon ASPEED_CLK_APB>; + no-loopback-test; + aspeed,sirq-polarity-sense = <&syscon 0x70 25>; + }; + +...
diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml index d4178ab..75ebc995 100644 --- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml +++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
@@ -24,18 +24,18 @@ oneOf: - description: Always-on power domain UART controller items: - - enum: + - enum: + - amlogic,meson6-uart + - amlogic,meson8-uart + - amlogic,meson8b-uart + - amlogic,meson-gx-uart + - const: amlogic,meson-ao-uart + - description: Everything-Else power domain UART controller + enum: - amlogic,meson6-uart - amlogic,meson8-uart - amlogic,meson8b-uart - amlogic,meson-gx-uart - - const: amlogic,meson-ao-uart - - description: Everything-Else power domain UART controller - enum: - - amlogic,meson6-uart - - amlogic,meson8-uart - - amlogic,meson8b-uart - - amlogic,meson-gx-uart reg: maxItems: 1
diff --git a/Documentation/devicetree/bindings/serial/ingenic,uart.txt b/Documentation/devicetree/bindings/serial/ingenic,uart.txt deleted file mode 100644 index 24ed876..0000000 --- a/Documentation/devicetree/bindings/serial/ingenic,uart.txt +++ /dev/null
@@ -1,28 +0,0 @@ -* Ingenic SoC UART - -Required properties: -- compatible : One of: - - "ingenic,jz4740-uart", - - "ingenic,jz4760-uart", - - "ingenic,jz4770-uart", - - "ingenic,jz4775-uart", - - "ingenic,jz4780-uart", - - "ingenic,x1000-uart". -- reg : offset and length of the register set for the device. -- interrupts : should contain uart interrupt. -- clocks : phandles to the module & baud clocks. -- clock-names: tuple listing input clock names. - Required elements: "baud", "module" - -Example: - -uart0: serial@10030000 { - compatible = "ingenic,jz4740-uart"; - reg = <0x10030000 0x100>; - - interrupt-parent = <&intc>; - interrupts = <9>; - - clocks = <&ext>, <&cgu JZ4740_CLK_UART0>; - clock-names = "baud", "module"; -};
diff --git a/Documentation/devicetree/bindings/serial/ingenic,uart.yaml b/Documentation/devicetree/bindings/serial/ingenic,uart.yaml new file mode 100644 index 0000000..c023d65 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/ingenic,uart.yaml
@@ -0,0 +1,94 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/ingenic,uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs UART controller devicetree bindings + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +properties: + $nodename: + pattern: "^serial@[0-9a-f]+$" + + compatible: + oneOf: + - enum: + - ingenic,jz4740-uart + - ingenic,jz4760-uart + - ingenic,jz4780-uart + - ingenic,x1000-uart + - items: + - enum: + - ingenic,jz4770-uart + - ingenic,jz4775-uart + - const: ingenic,jz4760-uart + - items: + - const: ingenic,jz4725b-uart + - const: ingenic,jz4740-uart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Baud clock + - description: UART module clock + + clock-names: + items: + - const: baud + - const: module + + dmas: + items: + - description: DMA controller phandle and request line for RX + - description: DMA controller phandle and request line for TX + + dma-names: + items: + - const: rx + - const: tx + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + +examples: + - | + #include <dt-bindings/clock/jz4780-cgu.h> + #include <dt-bindings/dma/jz4780-dma.h> + #include <dt-bindings/gpio/gpio.h> + serial@10032000 { + compatible = "ingenic,jz4780-uart"; + reg = <0x10032000 0x100>; + + interrupt-parent = <&intc>; + interrupts = <49>; + + clocks = <&ext>, <&cgu JZ4780_CLK_UART2>; + clock-names = "baud", "module"; + + dmas = <&dma JZ4780_DMA_UART2_RX 0xffffffff>, + <&dma JZ4780_DMA_UART2_TX 0xffffffff>; + dma-names = "rx", "tx"; + + bluetooth { + compatible = "brcm,bcm4330-bt"; + reset-gpios = <&gpf 8 GPIO_ACTIVE_HIGH>; + vcc-supply = <&wlan0_power>; + device-wakeup-gpios = <&gpf 5 GPIO_ACTIVE_HIGH>; + host-wakeup-gpios = <&gpf 6 GPIO_ACTIVE_HIGH>; + shutdown-gpios = <&gpf 4 GPIO_ACTIVE_LOW>; + }; + };
diff --git a/Documentation/devicetree/bindings/serial/mrvl-serial.txt b/Documentation/devicetree/bindings/serial/mrvl-serial.txt deleted file mode 100644 index d744340..0000000 --- a/Documentation/devicetree/bindings/serial/mrvl-serial.txt +++ /dev/null
@@ -1,4 +0,0 @@ -PXA UART controller - -Required properties: -- compatible : should be "mrvl,mmp-uart" or "mrvl,pxa-uart".
diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt index c1091a9..0fa8e3e 100644 --- a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt +++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
@@ -21,6 +21,8 @@ the second cell is used to specify the GPIO polarity: 0 = active high, 1 = active low. +- irda-mode-ports: An array that lists the indices of the port that + should operate in IrDA mode. Example: sc16is750: sc16is750@51 { @@ -55,6 +57,8 @@ the second cell is used to specify the GPIO polarity: 0 = active high, 1 = active low. +- irda-mode-ports: An array that lists the indices of the port that + should operate in IrDA mode. Example: sc16is750: sc16is750@0 {
diff --git a/Documentation/devicetree/bindings/serial/pl011.yaml b/Documentation/devicetree/bindings/serial/pl011.yaml index 1a64d59..c23c93b 100644 --- a/Documentation/devicetree/bindings/serial/pl011.yaml +++ b/Documentation/devicetree/bindings/serial/pl011.yaml
@@ -88,17 +88,15 @@ description: Rate at which poll occurs when auto-poll is set. default 100ms. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - default: 100 + $ref: /schemas/types.yaml#/definitions/uint32 + default: 100 poll-timeout-ms: description: Poll timeout when auto-poll is set, default 3000ms. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - default: 3000 + $ref: /schemas/types.yaml#/definitions/uint32 + default: 3000 required: - compatible
diff --git a/Documentation/devicetree/bindings/serial/qca,ar9330-uart.txt b/Documentation/devicetree/bindings/serial/qca,ar9330-uart.txt deleted file mode 100644 index 7d65126..0000000 --- a/Documentation/devicetree/bindings/serial/qca,ar9330-uart.txt +++ /dev/null
@@ -1,31 +0,0 @@ -* Qualcomm Atheros AR9330 High-Speed UART - -Required properties: - -- compatible: Must be "qca,ar9330-uart" - -- reg: Specifies the physical base address of the controller and - the length of the memory mapped region. - -- interrupts: Specifies the interrupt source of the parent interrupt - controller. The format of the interrupt specifier depends on the - parent interrupt controller. - -Additional requirements: - - Each UART port must have an alias correctly numbered in "aliases" - node. - -Example: - - aliases { - serial0 = &uart0; - }; - - uart0: uart@18020000 { - compatible = "qca,ar9330-uart"; - reg = <0x18020000 0x14>; - - interrupt-parent = <&intc>; - interrupts = <3>; - };
diff --git a/Documentation/devicetree/bindings/serial/qca,ar9330-uart.yaml b/Documentation/devicetree/bindings/serial/qca,ar9330-uart.yaml new file mode 100644 index 0000000..a344369 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/qca,ar9330-uart.yaml
@@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/qca,ar9330-uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Atheros AR9330 High-Speed UART + +maintainers: + - Oleksij Rempel <o.rempel@pengutronix.de> + +allOf: + - $ref: /schemas/serial.yaml# + +properties: + compatible: + const: qca,ar9330-uart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: uart + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + serial@18020000 { + compatible = "qca,ar9330-uart"; + reg = <0x18020000 0x14>; + clocks = <&ref>; + clock-names = "uart"; + interrupt-parent = <&intc>; + interrupts = <3>; + }; +...
diff --git a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml new file mode 100644 index 0000000..82aefdb --- /dev/null +++ b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml
@@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/serial/renesas,em-uart.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Renesas EMMA Mobile UART Interface + +maintainers: + - Magnus Damm <magnus.damm@gmail.com> + +allOf: + - $ref: serial.yaml# + +properties: + compatible: + const: renesas,em-uart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: sclk + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + uart0: serial@e1020000 { + compatible = "renesas,em-uart"; + reg = <0xe1020000 0x38>; + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&usia_u0_sclk>; + clock-names = "sclk"; + };
diff --git a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml index 9110152..6b04c04 100644 --- a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml
@@ -24,6 +24,7 @@ - items: - enum: + - renesas,hscif-r8a7742 # RZ/G1H - renesas,hscif-r8a7743 # RZ/G1M - renesas,hscif-r8a7744 # RZ/G1N - renesas,hscif-r8a7745 # RZ/G1E
diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml index 70392b9..570b379 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
@@ -33,6 +33,7 @@ - items: - enum: + - renesas,scif-r8a7742 # RZ/G1H - renesas,scif-r8a7743 # RZ/G1M - renesas,scif-r8a7744 # RZ/G1N - renesas,scif-r8a7745 # RZ/G1E
diff --git a/Documentation/devicetree/bindings/serial/renesas,scifa.yaml b/Documentation/devicetree/bindings/serial/renesas,scifa.yaml index b28bcb2..78b8e20 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scifa.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scifa.yaml
@@ -24,13 +24,14 @@ - items: - enum: - - renesas,scifa-r8a7743 # R8A7743 RZ/G1M - - renesas,scifa-r8a7744 # R8A7744 RZ/G1N - - renesas,scifa-r8a7745 # R8A7745 RZ/G1E - - renesas,scifa-r8a7790 # R8A7790 R-Car H2 - - renesas,scifa-r8a7791 # R8A7791 R-Car M2-W - - renesas,scifa-r8a7793 # R8A7793 R-Car M2-N - - renesas,scifa-r8a7794 # R8A7794 R-Car E2 + - renesas,scifa-r8a7742 # RZ/G1H + - renesas,scifa-r8a7743 # RZ/G1M + - renesas,scifa-r8a7744 # RZ/G1N + - renesas,scifa-r8a7745 # RZ/G1E + - renesas,scifa-r8a7790 # R-Car H2 + - renesas,scifa-r8a7791 # R-Car M2-W + - renesas,scifa-r8a7793 # R-Car M2-N + - renesas,scifa-r8a7794 # R-Car E2 - const: renesas,rcar-gen2-scifa # R-Car Gen2 and RZ/G1 - const: renesas,scifa # generic SCIFA compatible UART
diff --git a/Documentation/devicetree/bindings/serial/renesas,scifb.yaml b/Documentation/devicetree/bindings/serial/renesas,scifb.yaml index 57205cb..b083970 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scifb.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scifb.yaml
@@ -24,6 +24,7 @@ - items: - enum: + - renesas,scifb-r8a7742 # RZ/G1H - renesas,scifb-r8a7743 # RZ/G1M - renesas,scifb-r8a7744 # RZ/G1N - renesas,scifb-r8a7745 # RZ/G1E
diff --git a/Documentation/devicetree/bindings/serial/rs485.yaml b/Documentation/devicetree/bindings/serial/rs485.yaml index d4beaf11..fe90569 100644 --- a/Documentation/devicetree/bindings/serial/rs485.yaml +++ b/Documentation/devicetree/bindings/serial/rs485.yaml
@@ -6,40 +6,43 @@ title: RS485 serial communications Bindings -description: The RTS signal is capable of automatically controlling - line direction for the built-in half-duplex mode. - The properties described hereafter shall be given to a - half-duplex capable UART node. +description: The RTS signal is capable of automatically controlling line + direction for the built-in half-duplex mode. The properties described + hereafter shall be given to a half-duplex capable UART node. maintainers: - - Rob Herring <robh@kernel.org> + - Rob Herring <robh@kernel.org> properties: rs485-rts-delay: description: prop-encoded-array <a b> - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - items: - items: - - description: - Delay between rts signal and beginning of data sent in milliseconds. - It corresponds to the delay before sending data. - default: 0 - maximum: 1000 - - description: - Delay between end of data sent and rts signal in milliseconds. - It corresponds to the delay after sending data and actual release of the line. - default: 0 - maximum: 1000 + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + items: + - description: Delay between rts signal and beginning of data sent in + milliseconds. It corresponds to the delay before sending data. + default: 0 + maximum: 1000 + - description: Delay between end of data sent and rts signal in milliseconds. + It corresponds to the delay after sending data and actual release + of the line. + default: 0 + maximum: 1000 rs485-rts-active-low: description: drive RTS low when sending (default is high). $ref: /schemas/types.yaml#/definitions/flag linux,rs485-enabled-at-boot-time: - description: enables the rs485 feature at boot time. It can be disabled later with proper ioctl. + description: enables the rs485 feature at boot time. It can be disabled + later with proper ioctl. $ref: /schemas/types.yaml#/definitions/flag rs485-rx-during-tx: - description: enables the receiving of data even while sending data. - $ref: /schemas/types.yaml#/definitions/flag + description: enables the receiving of data even while sending data. + $ref: /schemas/types.yaml#/definitions/flag + + rs485-term-gpios: + description: GPIO pin to enable RS485 bus termination. + maxItems: 1 +...
diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml index 9d2ce34..96414ac 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -29,6 +29,13 @@ reg: maxItems: 1 + reg-io-width: + description: | + The size (in bytes) of the IO accesses that should be performed + on the device. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 4 ] + clocks: minItems: 2 maxItems: 5 @@ -51,9 +58,8 @@ samsung,uart-fifosize: description: The fifo size supported by the UART channel. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [16, 64, 256] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [16, 64, 256] required: - compatible
diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml index 53204d9..8645d0e 100644 --- a/Documentation/devicetree/bindings/serial/serial.yaml +++ b/Documentation/devicetree/bindings/serial/serial.yaml
@@ -67,6 +67,14 @@ (wired and enabled by pinmux configuration). This depends on both the UART hardware and the board wiring. + rx-tx-swap: + type: boolean + description: RX and TX pins are swapped. + + cts-rts-swap: + type: boolean + description: CTS and RTS pins are swapped. + if: required: - uart-has-rtscts
diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml b/Documentation/devicetree/bindings/serial/sifive-serial.yaml index e8d3aed..92283f6 100644 --- a/Documentation/devicetree/bindings/serial/sifive-serial.yaml +++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
@@ -55,7 +55,7 @@ compatible = "sifive,fu540-c000-uart", "sifive,uart0"; interrupt-parent = <&plic0>; interrupts = <80>; - reg = <0x0 0x10010000 0x0 0x1000>; + reg = <0x10010000 0x1000>; clocks = <&prci PRCI_CLK_TLCLK>; };
diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml index 238c441..75b8521e 100644 --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
@@ -48,6 +48,12 @@ minItems: 1 maxItems: 2 + cts-gpios: + maxItems: 1 + + rts-gpios: + maxItems: 1 + wakeup-source: true rs485-rts-delay: true @@ -55,6 +61,14 @@ linux,rs485-enabled-at-boot-time: true rs485-rx-during-tx: true +if: + required: + - st,hw-flow-ctrl +then: + properties: + cts-gpios: false + rts-gpios: false + required: - compatible - reg
diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml index cb008fd..02b2d5b 100644 --- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml +++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml
@@ -26,11 +26,11 @@ compatible: oneOf: - items: - - enum: - - amlogic,meson8-canvas - - amlogic,meson8b-canvas - - amlogic,meson8m2-canvas - - const: amlogic,canvas + - enum: + - amlogic,meson8-canvas + - amlogic,meson8b-canvas + - amlogic,meson8m2-canvas + - const: amlogic,canvas - const: amlogic,canvas # GXBB and newer SoCs reg:
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt index 4fc571e7..953add1 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
@@ -19,6 +19,7 @@ "qcom,sc7180-aoss-qmp" "qcom,sdm845-aoss-qmp" "qcom,sm8150-aoss-qmp" + "qcom,sm8250-aoss-qmp" - reg: Usage: required
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt index f8fa71f..2e2f6dc 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
@@ -65,30 +65,30 @@ compatible = "qcom,apr-v2"; qcom,apr-domain = <APR_DOMAIN_ADSP>; - q6core@3 { + apr-service@3 { compatible = "qcom,q6core"; reg = <APR_SVC_ADSP_CORE>; }; - q6afe@4 { + apr-service@4 { compatible = "qcom,q6afe"; reg = <APR_SVC_AFE>; dais { #sound-dai-cells = <1>; - hdmi@1 { - reg = <1>; + dai@1 { + reg = <HDMI_RX>; }; }; }; - q6asm@7 { + apr-service@7 { compatible = "qcom,q6asm"; reg = <APR_SVC_ASM>; ... }; - q6adm@8 { + apr-service@8 { compatible = "qcom,q6adm"; reg = <APR_SVC_ADM>; ... @@ -106,26 +106,26 @@ qcom,glink-channels = "apr_audio_svc"; qcom,apr-domain = <APR_DOMAIN_ADSP>; - q6core { + apr-service@3 { compatible = "qcom,q6core"; reg = <APR_SVC_ADSP_CORE>; }; - q6afe: q6afe { + q6afe: apr-service@4 { compatible = "qcom,q6afe"; reg = <APR_SVC_AFE>; qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd"; ... }; - q6asm: q6asm { + q6asm: apr-service@7 { compatible = "qcom,q6asm"; reg = <APR_SVC_ASM>; qcom,protection-domain = "tms/servreg", "msm/slpi/sensor_pd"; ... }; - q6adm: q6adm { + 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,geni-se.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt deleted file mode 100644 index dab7ca9..0000000 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt +++ /dev/null
@@ -1,94 +0,0 @@ -Qualcomm Technologies, Inc. GENI Serial Engine QUP Wrapper Controller - -Generic Interface (GENI) based Qualcomm Universal Peripheral (QUP) wrapper -is a programmable module for supporting a wide range of serial interfaces -like UART, SPI, I2C, I3C, etc. A single QUP module can provide upto 8 Serial -Interfaces, using its internal Serial Engines. The GENI Serial Engine QUP -Wrapper controller is modeled as a node with zero or more child nodes each -representing a serial engine. - -Required properties: -- compatible: Must be "qcom,geni-se-qup". -- reg: Must contain QUP register address and length. -- clock-names: Must contain "m-ahb" and "s-ahb". -- clocks: AHB clocks needed by the device. - -Required properties if child node exists: -- #address-cells: Must be <1> for Serial Engine Address -- #size-cells: Must be <1> for Serial Engine Address Size -- ranges: Must be present - -Properties for children: - -A GENI based QUP wrapper controller node can contain 0 or more child nodes -representing serial devices. These serial devices can be a QCOM UART, I2C -controller, SPI controller, or some combination of aforementioned devices. -Please refer below the child node definitions for the supported serial -interface protocols. - -Qualcomm Technologies Inc. GENI Serial Engine based I2C Controller - -Required properties: -- compatible: Must be "qcom,geni-i2c". -- reg: Must contain QUP register address and length. -- interrupts: Must contain I2C interrupt. -- clock-names: Must contain "se". -- clocks: Serial engine core clock needed by the device. -- #address-cells: Must be <1> for I2C device address. -- #size-cells: Must be <0> as I2C addresses have no size component. - -Optional property: -- clock-frequency: Desired I2C bus clock frequency in Hz. - When missing default to 100000Hz. - -Child nodes should conform to I2C bus binding as described in i2c.txt. - -Qualcomm Technologies Inc. GENI Serial Engine based UART Controller - -Required properties: -- compatible: Must be "qcom,geni-debug-uart" or "qcom,geni-uart". -- reg: Must contain UART register location and length. -- interrupts: Must contain UART core interrupts. -- clock-names: Must contain "se". -- clocks: Serial engine core clock needed by the device. - -Qualcomm Technologies Inc. GENI Serial Engine based SPI Controller -node binding is described in -Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.txt. - -Example: - geniqup@8c0000 { - compatible = "qcom,geni-se-qup"; - reg = <0x8c0000 0x6000>; - clock-names = "m-ahb", "s-ahb"; - clocks = <&clock_gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>, - <&clock_gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - i2c0: i2c@a94000 { - compatible = "qcom,geni-i2c"; - reg = <0xa94000 0x4000>; - interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>; - clock-names = "se"; - clocks = <&clock_gcc GCC_QUPV3_WRAP0_S5_CLK>; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&qup_1_i2c_5_active>; - pinctrl-1 = <&qup_1_i2c_5_sleep>; - #address-cells = <1>; - #size-cells = <0>; - }; - - uart0: serial@a88000 { - compatible = "qcom,geni-debug-uart"; - reg = <0xa88000 0x7000>; - interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>; - clock-names = "se"; - clocks = <&clock_gcc GCC_QUPV3_WRAP0_S0_CLK>; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&qup_1_uart_3_active>; - pinctrl-1 = <&qup_1_uart_3_sleep>; - }; - - }
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml new file mode 100644 index 0000000..a2b29cc --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
@@ -0,0 +1,222 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/qcom/qcom,geni-se.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: GENI Serial Engine QUP Wrapper Controller + +maintainers: + - Mukesh Savaliya <msavaliy@codeaurora.org> + - Akash Asthana <akashast@codeaurora.org> + +description: | + Generic Interface (GENI) based Qualcomm Universal Peripheral (QUP) wrapper + is a programmable module for supporting a wide range of serial interfaces + like UART, SPI, I2C, I3C, etc. A single QUP module can provide upto 8 Serial + Interfaces, using its internal Serial Engines. The GENI Serial Engine QUP + Wrapper controller is modeled as a node with zero or more child nodes each + representing a serial engine. + +properties: + compatible: + enum: + - qcom,geni-se-qup + + reg: + description: QUP wrapper common register address and length. + maxItems: 1 + + clock-names: + items: + - const: m-ahb + - const: s-ahb + + clocks: + items: + - description: Master AHB Clock + - description: Slave AHB Clock + + "#address-cells": + const: 2 + + "#size-cells": + const: 2 + + ranges: true + + interconnects: + maxItems: 1 + + interconnect-names: + const: qup-core + +required: + - compatible + - reg + - clock-names + - clocks + - "#address-cells" + - "#size-cells" + - ranges + +patternProperties: + "^.*@[0-9a-f]+$": + type: object + description: Common properties for GENI Serial Engine based I2C, SPI and + UART controller. + + properties: + reg: + description: GENI Serial Engine register address and length. + maxItems: 1 + + clock-names: + const: se + + clocks: + description: Serial engine core clock needed by the device. + maxItems: 1 + + interconnects: + minItems: 2 + maxItems: 3 + + interconnect-names: + minItems: 2 + items: + - const: qup-core + - const: qup-config + - const: qup-memory + + required: + - reg + - clock-names + - clocks + + "spi@[0-9a-f]+$": + type: object + description: GENI serial engine based SPI controller. SPI in master mode + supports up to 50MHz, up to four chip selects, programmable + data path from 4 bits to 32 bits and numerous protocol + variants. + $ref: /spi/spi-controller.yaml# + + properties: + compatible: + enum: + - qcom,geni-spi + + interrupts: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + required: + - compatible + - interrupts + - "#address-cells" + - "#size-cells" + + "i2c@[0-9a-f]+$": + type: object + description: GENI serial engine based I2C controller. + $ref: /schemas/i2c/i2c-controller.yaml# + + properties: + compatible: + enum: + - qcom,geni-i2c + + interrupts: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + clock-frequency: + description: Desired I2C bus clock frequency in Hz. + default: 100000 + + required: + - compatible + - interrupts + - "#address-cells" + - "#size-cells" + + "serial@[0-9a-f]+$": + type: object + description: GENI Serial Engine based UART Controller. + $ref: /schemas/serial.yaml# + + properties: + compatible: + enum: + - qcom,geni-uart + - qcom,geni-debug-uart + + interrupts: + minItems: 1 + maxItems: 2 + items: + - description: UART core irq + - description: Wakeup irq (RX GPIO) + + required: + - compatible + - interrupts + + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + geniqup@8c0000 { + compatible = "qcom,geni-se-qup"; + reg = <0 0x008c0000 0 0x6000>; + clock-names = "m-ahb", "s-ahb"; + clocks = <&gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>, + <&gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + + i2c0: i2c@a94000 { + compatible = "qcom,geni-i2c"; + reg = <0 0xa94000 0 0x4000>; + interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "se"; + clocks = <&gcc GCC_QUPV3_WRAP0_S5_CLK>; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&qup_1_i2c_5_active>; + pinctrl-1 = <&qup_1_i2c_5_sleep>; + #address-cells = <1>; + #size-cells = <0>; + }; + + uart0: serial@a88000 { + compatible = "qcom,geni-uart"; + reg = <0 0xa88000 0 0x7000>; + interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "se"; + clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&qup_1_uart_3_active>; + pinctrl-1 = <&qup_1_uart_3_sleep>; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml b/Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml new file mode 100644 index 0000000..a1a8423 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
@@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/ti/k3-socinfo.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments K3 Multicore SoC platforms chipid module + +maintainers: + - Tero Kristo <t-kristo@ti.com> + - Nishanth Menon <nm@ti.com> + +description: | + Texas Instruments (ARM64) K3 Multicore SoC platforms chipid module is + represented by CTRLMMR_xxx_JTAGID register which contains information about + SoC id and revision. + +properties: + $nodename: + pattern: "^chipid@[0-9a-f]+$" + + compatible: + items: + - const: ti,am654-chipid + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + chipid@43000014 { + compatible = "ti,am654-chipid"; + reg = <0x43000014 0x4>; + };
diff --git a/Documentation/devicetree/bindings/sound/adi,adau7118.yaml b/Documentation/devicetree/bindings/sound/adi,adau7118.yaml index 76ee695..fb78967 100644 --- a/Documentation/devicetree/bindings/sound/adi,adau7118.yaml +++ b/Documentation/devicetree/bindings/sound/adi,adau7118.yaml
@@ -35,23 +35,21 @@ adi,decimation-ratio: description: | This property set's the decimation ratio of PDM to PCM audio data. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [64, 32, 16] - default: 64 + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [64, 32, 16] + default: 64 adi,pdm-clk-map: description: | The ADAU7118 has two PDM clocks for the four Inputs. Each input must be assigned to one of these two clocks. This property set's the mapping between the clocks and the inputs. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 4 - maxItems: 4 - items: - maximum: 1 - default: [0, 0, 1, 1] + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 4 + maxItems: 4 + items: + maximum: 1 + default: [0, 0, 1, 1] required: - "#sound-dai-cells"
diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml index ea1d2ef..be390ac 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml
@@ -57,32 +57,31 @@ 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. - allOf: - - $ref: /schemas/types.yaml#definitions/non-unique-string-array - - minItems: 2 - maxItems: 18 - items: - enum: - # Audio Pins on the SoC - - HP - - HPCOM - - LINEIN - - LINEOUT - - MIC1 - - MIC2 - - MIC3 + $ref: /schemas/types.yaml#definitions/non-unique-string-array + minItems: 2 + maxItems: 18 + items: + enum: + # Audio Pins on the SoC + - HP + - HPCOM + - LINEIN + - LINEOUT + - MIC1 + - MIC2 + - MIC3 - # Microphone Biases from the SoC - - HBIAS - - MBIAS + # Microphone Biases from the SoC + - HBIAS + - MBIAS - # Board Connectors - - Headphone - - Headset Mic - - Line In - - Line Out - - Mic - - Speaker + # Board Connectors + - Headphone + - Headset Mic + - Line In + - Line Out + - Mic + - Speaker allwinner,codec-analog-controls: $ref: /schemas/types.yaml#/definitions/phandle
diff --git a/Documentation/devicetree/bindings/sound/amlogic,aiu.yaml b/Documentation/devicetree/bindings/sound/amlogic,aiu.yaml index a61bccf..f9344ad 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,aiu.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,aiu.yaml
@@ -86,7 +86,7 @@ aiu: audio-controller@5400 { compatible = "amlogic,aiu-gxl", "amlogic,aiu"; #sound-dai-cells = <2>; - reg = <0x0 0x5400 0x0 0x2ac>; + reg = <0x5400 0x2ac>; interrupts = <GIC_SPI 48 IRQ_TYPE_EDGE_RISING>, <GIC_SPI 50 IRQ_TYPE_EDGE_RISING>; interrupt-names = "i2s", "spdif"; @@ -110,4 +110,3 @@ "spdif_mclk_sel"; resets = <&reset RESET_AIU>; }; -
diff --git a/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml b/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml index f778d33..51a0c30 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml
@@ -45,7 +45,7 @@ toacodec: audio-controller@740 { compatible = "amlogic,g12a-toacodec"; - reg = <0x0 0x740 0x0 0x4>; + reg = <0x740 0x4>; #sound-dai-cells = <1>; resets = <&clkc_audio AUD_RESET_TOACODEC>; };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml b/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml index b7c38c2..04014e6 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml
@@ -49,10 +49,9 @@ acodec: audio-controller@32000 { compatible = "amlogic,t9015"; - reg = <0x0 0x32000 0x0 0x14>; + reg = <0x32000 0x14>; #sound-dai-cells = <0>; clocks = <&clkc CLKID_AUDIO_CODEC>; clock-names = "pclk"; resets = <&reset RESET_AUDIO_CODEC>; }; -
diff --git a/Documentation/devicetree/bindings/sound/cirrus,lochnagar.txt b/Documentation/devicetree/bindings/sound/cirrus,lochnagar.txt deleted file mode 100644 index 41ae269..0000000 --- a/Documentation/devicetree/bindings/sound/cirrus,lochnagar.txt +++ /dev/null
@@ -1,39 +0,0 @@ -Cirrus Logic Lochnagar Audio Development Board - -Lochnagar is an evaluation and development board for Cirrus Logic -Smart CODEC and Amp devices. It allows the connection of most Cirrus -Logic devices on mini-cards, as well as allowing connection of -various application processor systems to provide a full evaluation -platform. Audio system topology, clocking and power can all be -controlled through the Lochnagar, allowing the device under test -to be used in a variety of possible use cases. - -This binding document describes the binding for the audio portion -of the driver. - -This binding must be part of the Lochnagar MFD binding: - [4] ../mfd/cirrus,lochnagar.txt - -Required properties: - - - compatible : One of the following strings: - "cirrus,lochnagar2-soundcard" - - - #sound-dai-cells : Must be set to 1. - - - clocks : Contains an entry for each entry in clock-names. - - clock-names : Must include the following clocks: - "mclk" Master clock source for the sound card, should normally - be set to LOCHNAGAR_SOUNDCARD_MCLK provided by the Lochnagar - clock driver. - -Example: - -lochnagar-sc { - compatible = "cirrus,lochnagar2-soundcard"; - - #sound-dai-cells = <1>; - - clocks = <&lochnagar_clk LOCHNAGAR_SOUNDCARD_MCLK>; - clock-names = "mclk"; -};
diff --git a/Documentation/devicetree/bindings/sound/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/sound/cirrus,lochnagar.yaml new file mode 100644 index 0000000..cea612d --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cirrus,lochnagar.yaml
@@ -0,0 +1,52 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/cirrus,lochnagar.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic Lochnagar Audio Development Board + +maintainers: + - patches@opensource.cirrus.com + +description: | + Lochnagar is an evaluation and development board for Cirrus Logic + Smart CODEC and Amp devices. It allows the connection of most Cirrus + Logic devices on mini-cards, as well as allowing connection of various + application processor systems to provide a full evaluation platform. + Audio system topology, clocking and power can all be controlled through + the Lochnagar, allowing the device under test to be used in a variety of + possible use cases. + + This binding document describes the binding for the audio portion of the + driver. + + This binding must be part of the Lochnagar MFD binding: + [1] ../mfd/cirrus,lochnagar.yaml + +properties: + compatible: + enum: + - cirrus,lochnagar2-soundcard + + '#sound-dai-cells': + description: + The first cell indicating the audio interface. + const: 1 + + clocks: + description: + Master clock source for the sound card, should normally be set to + LOCHNAGAR_SOUNDCARD_MCLK provided by the Lochnagar clock driver. + maxItems: 1 + + clock-names: + const: mclk + +required: + - compatible + - '#sound-dai-cells' + - clocks + - clock-names + +additionalProperties: false
diff --git a/Documentation/devicetree/bindings/sound/cirrus,madera.yaml b/Documentation/devicetree/bindings/sound/cirrus,madera.yaml new file mode 100644 index 0000000..c4cd58b --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cirrus,madera.yaml
@@ -0,0 +1,113 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/cirrus,madera.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic Madera class audio CODECs + +maintainers: + - patches@opensource.cirrus.com + +description: | + This describes audio configuration bindings for these codecs. + + See also the core bindings for the parent MFD driver: + + Documentation/devicetree/bindings/mfd/cirrus,madera.yaml + + and defines for values used in these bindings: + + include/dt-bindings/sound/madera.h + + The properties are all contained in the parent MFD node. + +properties: + '#sound-dai-cells': + description: + The first cell indicating the audio interface. + const: 1 + + cirrus,inmode: + description: + A list of input mode settings for each input. A maximum + of 24 cells, with four cells per input in the order INnAL, + INnAR INnBL INnBR. For non-muxed inputs the first two cells + for that input set the mode for the left and right channel + and the second two cells must be 0. For muxed inputs the + first two cells for that input set the mode of the left and + right A inputs and the second two cells set the mode of the + left and right B inputs. Valid mode values are one of the + MADERA_INMODE_xxx. If the array is shorter than the number + of inputs the unspecified inputs default to MADERA_INMODE_DIFF. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 24 + items: + minimum: 0 + maximum: 1 + default: 0 + + cirrus,out-mono: + description: + Mono bit for each output, maximum of six cells if the array + is shorter outputs will be set to stereo. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 6 + items: + minimum: 0 + maximum: 1 + default: 0 + + cirrus,dmic-ref: + description: | + Indicates how the MICBIAS pins have been externally connected + to DMICs on each input, one cell per input. + + <IN1 IN2 IN3 ...> + + A value of 0 indicates MICVDD and is the default, + other values depend on the codec: For CS47L35 one of the + CS47L35_DMIC_REF_xxx values For all other codecs one of + the MADERA_DMIC_REF_xxx values Also see the datasheet for a + description of the INn_DMIC_SUP field. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 6 + items: + minimum: 0 + maximum: 3 + default: 0 + + cirrus,max-channels-clocked: + description: + Maximum number of channels that I2S clocks will be generated + for. Useful when clock master for systems where the I2S bus + has multiple data lines. One cell for each AIF, use a value + of zero for AIFs that should be handled normally. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 4 + items: + default: 0 + + cirrus,pdm-fmt: + description: + PDM speaker data format, must contain 2 cells (OUT5 and + OUT6). See the PDM_SPKn_FMT field in the datasheet for a + description of this value. The second cell is ignored for + codecs that do not have OUT6. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + + cirrus,pdm-mute: + description: | + PDM mute format, must contain 2 cells (OUT5 and OUT6). See the + PDM_SPKn_CTRL_1 register in the datasheet for a description + of this value. The second cell is ignored for codecs that + do not have OUT6. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2
diff --git a/Documentation/devicetree/bindings/sound/da7213.txt b/Documentation/devicetree/bindings/sound/da7213.txt index 5890280..94584c9 100644 --- a/Documentation/devicetree/bindings/sound/da7213.txt +++ b/Documentation/devicetree/bindings/sound/da7213.txt
@@ -1,9 +1,9 @@ -Dialog Semiconductor DA7213 Audio Codec bindings +Dialog Semiconductor DA7212/DA7213 Audio Codec bindings ====== Required properties: -- compatible : Should be "dlg,da7213" +- compatible : Should be "dlg,da7212" or "dlg,da7213" - reg: Specifies the I2C slave address Optional properties: @@ -21,6 +21,10 @@ - dlg,dmic-clkrate : DMIC clock frequency (Hz). [<1500000>, <3000000>] + - VDDA-supply : Regulator phandle for Analogue power supply + - VDDMIC-supply : Regulator phandle for Mic Bias + - VDDIO-supply : Regulator phandle for I/O power supply + ====== Example:
diff --git a/Documentation/devicetree/bindings/sound/fsl,asrc.txt b/Documentation/devicetree/bindings/sound/fsl,asrc.txt index cb9a251..998b4c8 100644 --- a/Documentation/devicetree/bindings/sound/fsl,asrc.txt +++ b/Documentation/devicetree/bindings/sound/fsl,asrc.txt
@@ -51,6 +51,10 @@ will be in use as default. Otherwise, the big endian mode will be in use for all the device registers. + - fsl,asrc-format : Defines a mutual sample format used by DPCM Back + Ends, which can replace the fsl,asrc-width. + The value is 2 (S16_LE), or 6 (S24_LE). + Example: asrc: asrc@2034000 {
diff --git a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml new file mode 100644 index 0000000..32d547a --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml
@@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,easrc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Asynchronous Sample Rate Converter (ASRC) Controller + +maintainers: + - Shengjiu Wang <shengjiu.wang@nxp.com> + +properties: + $nodename: + pattern: "^easrc@.*" + + compatible: + const: fsl,imx8mn-easrc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Peripheral clock + + clock-names: + items: + - const: mem + + dmas: + maxItems: 8 + + dma-names: + items: + - const: ctx0_rx + - const: ctx0_tx + - const: ctx1_rx + - const: ctx1_tx + - const: ctx2_rx + - const: ctx2_tx + - const: ctx3_rx + - const: ctx3_tx + + firmware-name: + $ref: /schemas/types.yaml#/definitions/string + const: imx/easrc/easrc-imx8mn.bin + description: The coefficient table for the filters + + fsl,asrc-rate: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 8000 + maximum: 192000 + description: Defines a mutual sample rate used by DPCM Back Ends + + fsl,asrc-format: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [2, 6, 10, 32, 36] + default: 2 + description: + Defines a mutual sample format used by DPCM Back Ends + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + - firmware-name + - fsl,asrc-rate + - fsl,asrc-format + +examples: + - | + #include <dt-bindings/clock/imx8mn-clock.h> + + easrc: easrc@300c0000 { + compatible = "fsl,imx8mn-easrc"; + reg = <0x300c0000 0x10000>; + interrupts = <0x0 122 0x4>; + clocks = <&clk IMX8MN_CLK_ASRC_ROOT>; + clock-names = "mem"; + dmas = <&sdma2 16 23 0> , <&sdma2 17 23 0>, + <&sdma2 18 23 0> , <&sdma2 19 23 0>, + <&sdma2 20 23 0> , <&sdma2 21 23 0>, + <&sdma2 22 23 0> , <&sdma2 23 23 0>; + dma-names = "ctx0_rx", "ctx0_tx", + "ctx1_rx", "ctx1_tx", + "ctx2_rx", "ctx2_tx", + "ctx3_rx", "ctx3_tx"; + firmware-name = "imx/easrc/easrc-imx8mn.bin"; + fsl,asrc-rate = <8000>; + fsl,asrc-format = <2>; + };
diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt index 0e6e2166..0a2480a 100644 --- a/Documentation/devicetree/bindings/sound/fsl,esai.txt +++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt
@@ -12,6 +12,7 @@ "fsl,imx35-esai", "fsl,vf610-esai", "fsl,imx6ull-esai", + "fsl,imx8qm-esai", - reg : Offset and length of the register set for the device.
diff --git a/Documentation/devicetree/bindings/sound/madera.txt b/Documentation/devicetree/bindings/sound/madera.txt deleted file mode 100644 index 5e669ce..0000000 --- a/Documentation/devicetree/bindings/sound/madera.txt +++ /dev/null
@@ -1,67 +0,0 @@ -Cirrus Logic Madera class audio codecs - -This describes audio configuration bindings for these codecs. - -See also the core bindings for the parent MFD driver: -See Documentation/devicetree/bindings/mfd/madera.txt - -and defines for values used in these bindings: -include/dt-bindings/sound/madera.h - -These properties are all contained in the parent MFD node. - -Optional properties: - - cirrus,dmic-ref : Indicates how the MICBIAS pins have been externally - connected to DMICs on each input, one cell per input. - <IN1 IN2 IN3 ...> - A value of 0 indicates MICVDD and is the default, other values depend on the - codec: - For CS47L35 one of the CS47L35_DMIC_REF_xxx values - For all other codecs one of the MADERA_DMIC_REF_xxx values - Also see the datasheet for a description of the INn_DMIC_SUP field. - - - cirrus,inmode : A list of input mode settings for each input. A maximum of - 16 cells, with four cells per input in the order INnAL, INnAR INnBL INnBR. - For non-muxed inputs the first two cells for that input set the mode for - the left and right channel and the second two cells must be 0. - For muxed inputs the first two cells for that input set the mode of the - left and right A inputs and the second two cells set the mode of the left - and right B inputs. - Valid mode values are one of the MADERA_INMODE_xxx. If the array is shorter - than the number of inputs the unspecified inputs default to - MADERA_INMODE_DIFF. - - - cirrus,out-mono : Mono bit for each output, maximum of six cells if the - array is shorter outputs will be set to stereo. - - - cirrus,max-channels-clocked : Maximum number of channels that I2S clocks - will be generated for. Useful when clock master for systems where the I2S - bus has multiple data lines. - One cell for each AIF, use a value of zero for AIFs that should be handled - normally. - - - cirrus,pdm-fmt : PDM speaker data format, must contain 2 cells - (OUT5 and OUT6). See the PDM_SPKn_FMT field in the datasheet for a - description of this value. - The second cell is ignored for codecs that do not have OUT6. - - - cirrus,pdm-mute : PDM mute format, must contain 2 cells - (OUT5 and OUT6). See the PDM_SPKn_CTRL_1 register in the datasheet for a - description of this value. - The second cell is ignored for codecs that do not have OUT6. - -Example: - -cs47l35@0 { - compatible = "cirrus,cs47l35"; - - cirrus,dmic-ref = <0 0 CS47L35_DMIC_REF_MICBIAS1B 0>; - cirrus,inmode = < - MADERA_INMODE_DMIC MADERA_INMODE_DMIC /* IN1A digital */ - MADERA_INMODE_SE MADERA_INMODE_SE /* IN1B single-ended */ - MADERA_INMODE_DIFF MADERA_INMODE_DIFF /* IN2 differential */ - 0 0 /* not used on this codec */ - >; - cirrus,out-mono = <0 0 0 0 0 0>; - cirrus,max-channels-clocked = <2 0 0>; -};
diff --git a/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml b/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml new file mode 100644 index 0000000..6d20a24 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml
@@ -0,0 +1,122 @@ +# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/marvell,mmp-sspa.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvel SSPA Digital Audio Interface Bindings + +maintainers: + - Lubomir Rintel <lkundrak@v3.sk> + +properties: + $nodename: + pattern: "^audio-controller(@.*)?$" + + compatible: + const: marvell,mmp-sspa + + reg: + items: + - description: RX block + - description: TX block + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Clock for the Audio block + - description: I2S bit clock + + clock-names: + items: + - const: audio + - const: bitclk + + power-domains: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + + dmas: + items: + - description: TX DMA Channel + - description: RX DMA Channel + + dma-names: + items: + - const: tx + - const: rx + + port: + type: object + + properties: + endpoint: + type: object + + properties: + remote-endpoint: true + + frame-master: + type: boolean + description: SoC generates the frame clock + + bitclock-master: + type: boolean + description: SoC generates the bit clock + + dai-format: + $ref: /schemas/types.yaml#/definitions/string + description: The digital audio format + const: i2s + + required: + - remote-endpoint + + required: + - endpoint + + additionalProperties: false + +required: + - "#sound-dai-cells" + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/marvell,mmp2.h> + + audio-controller@d42a0c00 { + compatible = "marvell,mmp-sspa"; + reg = <0xd42a0c00 0x30>, + <0xd42a0c80 0x30>; + interrupts = <2>; + clock-names = "audio", "bitclk"; + clocks = <&soc_clocks 127>, + <&audio_clk 1>; + #sound-dai-cells = <0>; + dmas = <&adma0 0>, <&adma0 1>; + dma-names = "tx", "rx"; + port { + endpoint { + remote-endpoint = <&rt5631_0>; + frame-master; + bitclock-master; + dai-format = "i2s"; + }; + }; + }; + +...
diff --git a/Documentation/devicetree/bindings/sound/nau8810.txt b/Documentation/devicetree/bindings/sound/nau8810.txt index 05830e4..7deaa45 100644 --- a/Documentation/devicetree/bindings/sound/nau8810.txt +++ b/Documentation/devicetree/bindings/sound/nau8810.txt
@@ -1,10 +1,11 @@ -NAU8810 audio CODEC +NAU8810/NAU8812/NAU8814 audio CODEC This device supports I2C only. Required properties: - - compatible : "nuvoton,nau8810" + - compatible : One of "nuvoton,nau8810" or "nuvoton,nau8812" or + "nuvoton,nau8814" - reg : the I2C address of the device.
diff --git a/Documentation/devicetree/bindings/sound/nau8825.txt b/Documentation/devicetree/bindings/sound/nau8825.txt index d16d968..388a7bc 100644 --- a/Documentation/devicetree/bindings/sound/nau8825.txt +++ b/Documentation/devicetree/bindings/sound/nau8825.txt
@@ -101,5 +101,5 @@ nuvoton,crosstalk-enable; clock-names = "mclk"; - clocks = <&tegra_car TEGRA210_CLK_CLK_OUT_2>; + clocks = <&tegra_pmc TEGRA_PMC_CLK_OUT_2>; };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt index a8f2b0c..bbd581a 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt
@@ -29,6 +29,7 @@ - nvidia,hp-det-gpios : The GPIO that detect headphones are plugged in - nvidia,int-mic-en-gpios : The GPIO that enables the internal microphone - nvidia,ext-mic-en-gpios : The GPIO that enables the external microphone +- nvidia,headset : The Mic Jack represents state of the headset microphone pin Example:
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt index 21c6483..32c2cdb 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt
@@ -30,6 +30,8 @@ - reg : Must contain an address for each entry in reg-names. - reg-names : A list which must include the following entries: * "lpass-lpaif" +- #address-cells : Must be 1 +- #size-cells : Must be 0 @@ -37,6 +39,20 @@ - qcom,adsp : Phandle for the audio DSP node +By default, the driver uses up to 4 MI2S SD lines, for a total of 8 channels. +The SD lines to use can be configured by adding subnodes for each of the DAIs. + +Required properties for each DAI (represented by a subnode): +- reg : Must be one of the DAI IDs + (usually part of dt-bindings header) +- qcom,playback-sd-lines: List of serial data lines to use for playback + Each SD line should be represented by a number from 0-3. +- qcom,capture-sd-lines : List of serial data lines to use for capture + Each SD line should be represented by a number from 0-3. + +Note that adding a subnode changes the default to "no lines configured", +so both playback and capture lines should be configured when a subnode is added. + Example: lpass@28100000 { @@ -51,4 +67,13 @@ reg = <0x28100000 0x10000>; reg-names = "lpass-lpaif"; qcom,adsp = <&adsp>; + + #address-cells = <1>; + #size-cells = <0>; + + /* Optional to set different MI2S SD lines */ + dai@3 { + reg = <MI2S_QUATERNARY>; + qcom,playback-sd-lines = <0 1>; + }; };
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6adm.txt b/Documentation/devicetree/bindings/sound/qcom,q6adm.txt index bbae426..15c353a 100644 --- a/Documentation/devicetree/bindings/sound/qcom,q6adm.txt +++ b/Documentation/devicetree/bindings/sound/qcom,q6adm.txt
@@ -29,7 +29,7 @@ Definition: Must be 0 = EXAMPLE -q6adm@8 { +apr-service@8 { compatible = "qcom,q6adm"; reg = <APR_SVC_ADM>; q6routing: routing {
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6afe.txt b/Documentation/devicetree/bindings/sound/qcom,q6afe.txt index d74888b..4916dd6 100644 --- a/Documentation/devicetree/bindings/sound/qcom,q6afe.txt +++ b/Documentation/devicetree/bindings/sound/qcom,q6afe.txt
@@ -100,7 +100,7 @@ = EXAMPLE -q6afe@4 { +apr-service@4 { compatible = "qcom,q6afe"; reg = <APR_SVC_AFE>; @@ -110,12 +110,12 @@ #address-cells = <1>; #size-cells = <0>; - hdmi@1 { - reg = <1>; + dai@1 { + reg = <HDMI_RX>; }; - tdm@24 { - reg = <24>; + dai@24 { + reg = <PRIMARY_TDM_RX_0>; qcom,tdm-sync-mode = <1>: qcom,tdm-sync-src = <1>; qcom,tdm-data-out = <0>; @@ -125,8 +125,8 @@ }; - tdm@25 { - reg = <25>; + dai@25 { + reg = <PRIMARY_TDM_TX_0>; qcom,tdm-sync-mode = <1>: qcom,tdm-sync-src = <1>; qcom,tdm-data-out = <0>; @@ -135,43 +135,43 @@ qcom,tdm-data-align = <0>; }; - prim-mi2s-rx@16 { - reg = <16>; + dai@16 { + reg = <PRIMARY_MI2S_RX>; qcom,sd-lines = <0 2>; }; - prim-mi2s-tx@17 { - reg = <17>; + dai@17 { + reg = <PRIMARY_MI2S_TX>; qcom,sd-lines = <1>; }; - sec-mi2s-rx@18 { - reg = <18>; + dai@18 { + reg = <SECONDARY_MI2S_RX>; qcom,sd-lines = <0 3>; }; - sec-mi2s-tx@19 { - reg = <19>; + dai@19 { + reg = <SECONDARY_MI2S_TX>; qcom,sd-lines = <1>; }; - tert-mi2s-rx@20 { - reg = <20>; + dai@20 { + reg = <TERTIARY_MI2S_RX>; qcom,sd-lines = <1 3>; }; - tert-mi2s-tx@21 { - reg = <21>; + dai@21 { + reg = <TERTIARY_MI2S_TX>; qcom,sd-lines = <0>; }; - quat-mi2s-rx@22 { - reg = <22>; + dai@22 { + reg = <QUATERNARY_MI2S_RX>; qcom,sd-lines = <0>; }; - quat-mi2s-tx@23 { - reg = <23>; + dai@23 { + reg = <QUATERNARY_MI2S_TX>; qcom,sd-lines = <1>; }; };
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6asm.txt b/Documentation/devicetree/bindings/sound/qcom,q6asm.txt index 9f5378c..6b9a88d 100644 --- a/Documentation/devicetree/bindings/sound/qcom,q6asm.txt +++ b/Documentation/devicetree/bindings/sound/qcom,q6asm.txt
@@ -51,13 +51,16 @@ = EXAMPLE -q6asm@7 { +apr-service@7 { compatible = "qcom,q6asm"; reg = <APR_SVC_ASM>; q6asmdai: dais { compatible = "qcom,q6asm-dais"; + #address-cells = <1>; + #size-cells = <0>; #sound-dai-cells = <1>; - mm@0 { + + dai@0 { reg = <0>; direction = <2>; is-compress-dai;
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6core.txt b/Documentation/devicetree/bindings/sound/qcom,q6core.txt index 7f36ff8..5cd4cc9 100644 --- a/Documentation/devicetree/bindings/sound/qcom,q6core.txt +++ b/Documentation/devicetree/bindings/sound/qcom,q6core.txt
@@ -15,7 +15,7 @@ example "qcom,q6core-v2.0" = EXAMPLE -q6core@3 { +apr-service@3 { compatible = "qcom,q6core"; reg = <APR_SVC_ADSP_CORE>; };
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml index a495d5f..e8f716b 100644 --- a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml
@@ -102,8 +102,7 @@ gpio@42: type: object - allOf: - - $ref: ../gpio/qcom,wcd934x-gpio.yaml# + $ref: ../gpio/qcom,wcd934x-gpio.yaml# patternProperties: "^.*@[0-9a-f]+$":
diff --git a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml index d1b6555..8a4406b 100644 --- a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
@@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/sound/renesas,fsi.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas FSI Sound Driver Device Tree Bindings +title: Renesas FIFO-buffered Serial Interface (FSI) maintainers: - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> @@ -17,16 +17,16 @@ oneOf: # for FSI2 SoC - items: - - enum: - - renesas,fsi2-sh73a0 - - renesas,fsi2-r8a7740 - - enum: - - renesas,sh_fsi2 + - enum: + - renesas,fsi2-sh73a0 # SH-Mobile AG5 + - renesas,fsi2-r8a7740 # R-Mobile A1 + - enum: + - renesas,sh_fsi2 # for Generic - items: - - enum: - - renesas,sh_fsi - - renesas,sh_fsi2 + - enum: + - renesas,sh_fsi + - renesas,sh_fsi2 reg: maxItems: 1 @@ -34,6 +34,15 @@ interrupts: maxItems: 1 + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + '#sound-dai-cells': + const: 1 + fsia,spdif-connection: $ref: /schemas/types.yaml#/definitions/flag description: FSI is connected by S/PDIF @@ -62,16 +71,24 @@ - compatible - reg - interrupts + - clocks + - power-domains + - '#sound-dai-cells' additionalProperties: false examples: - | - sh_fsi2: sound@ec230000 { + #include <dt-bindings/clock/r8a7740-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + sh_fsi2: sound@fe1f0000 { compatible = "renesas,fsi2-r8a7740", "renesas,sh_fsi2"; - reg = <0xec230000 0x400>; - interrupts = <0 146 0x4>; + reg = <0xfe1f0000 0x400>; + interrupts = <GIC_SPI 9 0x4>; + clocks = <&mstp3_clks R8A7740_CLK_FSI>; + power-domains = <&pd_a4mp>; + #sound-dai-cells = <1>; fsia,spdif-connection; fsia,stream-mode-support; fsia,use-internal-clock;
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index 797fd03..1596f0d 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -263,6 +263,7 @@ "renesas,rcar_sound-gen2" if generation2 (or RZ/G1) "renesas,rcar_sound-gen3" if generation3 (or RZ/G2) Examples with soctypes are: + - "renesas,rcar_sound-r8a7742" (RZ/G1H) - "renesas,rcar_sound-r8a7743" (RZ/G1M) - "renesas,rcar_sound-r8a7744" (RZ/G1N) - "renesas,rcar_sound-r8a7745" (RZ/G1E)
diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml index 7cd0e27..acb2b88 100644 --- a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml
@@ -24,6 +24,7 @@ - rockchip,rk3188-i2s - rockchip,rk3228-i2s - rockchip,rk3288-i2s + - rockchip,rk3308-i2s - rockchip,rk3328-i2s - rockchip,rk3366-i2s - rockchip,rk3368-i2s @@ -47,25 +48,27 @@ - const: i2s_hclk dmas: - items: - - description: TX DMA Channel - - description: RX DMA Channel + minItems: 1 + maxItems: 2 dma-names: - items: - - const: tx + oneOf: - const: rx + - items: + - const: tx + - const: rx + + power-domains: + maxItems: 1 rockchip,capture-channels: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 default: 2 description: Max capture channels, if not set, 2 channels default. rockchip,playback-channels: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 default: 8 description: Max playback channels, if not set, 8 channels default.
diff --git a/Documentation/devicetree/bindings/sound/rockchip-spdif.txt b/Documentation/devicetree/bindings/sound/rockchip-spdif.txt deleted file mode 100644 index ec20c12..0000000 --- a/Documentation/devicetree/bindings/sound/rockchip-spdif.txt +++ /dev/null
@@ -1,45 +0,0 @@ -* Rockchip SPDIF transceiver - -The S/PDIF audio block is a stereo transceiver that allows the -processor to receive and transmit digital audio via an coaxial cable or -a fibre cable. - -Required properties: - -- compatible: should be one of the following: - - "rockchip,rk3066-spdif" - - "rockchip,rk3188-spdif" - - "rockchip,rk3228-spdif" - - "rockchip,rk3288-spdif" - - "rockchip,rk3328-spdif" - - "rockchip,rk3366-spdif" - - "rockchip,rk3368-spdif" - - "rockchip,rk3399-spdif" -- reg: physical base address of the controller and length of memory mapped - region. -- interrupts: should contain the SPDIF interrupt. -- dmas: DMA specifiers for tx dma. See the DMA client binding, - Documentation/devicetree/bindings/dma/dma.txt -- dma-names: should be "tx" -- clocks: a list of phandle + clock-specifier pairs, one for each entry - in clock-names. -- clock-names: should contain following: - - "hclk": clock for SPDIF controller - - "mclk" : clock for SPDIF bus - -Required properties on RK3288: - - rockchip,grf: the phandle of the syscon node for the general register - file (GRF) - -Example for the rk3188 SPDIF controller: - -spdif: spdif@1011e000 { - compatible = "rockchip,rk3188-spdif", "rockchip,rk3066-spdif"; - reg = <0x1011e000 0x2000>; - interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&dmac1_s 8>; - dma-names = "tx"; - clock-names = "hclk", "mclk"; - clocks = <&cru HCLK_SPDIF>, <&cru SCLK_SPDIF>; - #sound-dai-cells = <0>; -};
diff --git a/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml new file mode 100644 index 0000000..c467152 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml
@@ -0,0 +1,101 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/rockchip-spdif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip SPDIF transceiver + +description: + The S/PDIF audio block is a stereo transceiver that allows the + processor to receive and transmit digital audio via a coaxial or + fibre cable. + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + oneOf: + - const: rockchip,rk3066-spdif + - const: rockchip,rk3228-spdif + - const: rockchip,rk3328-spdif + - const: rockchip,rk3366-spdif + - const: rockchip,rk3368-spdif + - const: rockchip,rk3399-spdif + - items: + - enum: + - rockchip,rk3188-spdif + - rockchip,rk3288-spdif + - const: rockchip,rk3066-spdif + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: clock for SPDIF bus + - description: clock for SPDIF controller + + clock-names: + items: + - const: mclk + - const: hclk + + dmas: + maxItems: 1 + + dma-names: + const: tx + + power-domains: + maxItems: 1 + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of the syscon node for the GRF register. + Required property on RK3288. + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + - "#sound-dai-cells" + +if: + properties: + compatible: + contains: + const: rockchip,rk3288-spdif + +then: + required: + - rockchip,grf + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3188-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + spdif: spdif@1011e000 { + compatible = "rockchip,rk3188-spdif", "rockchip,rk3066-spdif"; + reg = <0x1011e000 0x2000>; + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru SCLK_SPDIF>, <&cru HCLK_SPDIF>; + clock-names = "mclk", "hclk"; + dmas = <&dmac1_s 8>; + dma-names = "tx"; + #sound-dai-cells = <0>; + };
diff --git a/Documentation/devicetree/bindings/sound/rt1016.txt b/Documentation/devicetree/bindings/sound/rt1016.txt new file mode 100644 index 0000000..2310f8f --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rt1016.txt
@@ -0,0 +1,17 @@ +RT1016 Stereo Class D Audio Amplifier + +This device supports I2C only. + +Required properties: + +- compatible : "realtek,rt1016". + +- reg : The I2C address of the device. + + +Example: + +rt1016: codec@1a { + compatible = "realtek,rt1016"; + reg = <0x1a>; +};
diff --git a/Documentation/devicetree/bindings/sound/rt1308.txt b/Documentation/devicetree/bindings/sound/rt1308.txt old mode 100755 new mode 100644
diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt deleted file mode 100644 index 79954cd6..0000000 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ /dev/null
@@ -1,351 +0,0 @@ -Simple-Card: - -Simple-Card specifies audio DAI connections of SoC <-> codec. - -Required properties: - -- compatible : "simple-audio-card" - -Optional properties: - -- simple-audio-card,name : User specified audio sound card name, one string - property. -- simple-audio-card,widgets : Please refer to widgets.txt. -- simple-audio-card,routing : 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. -- simple-audio-card,mclk-fs : Multiplication factor between stream rate and codec - mclk. When defined, mclk-fs property defined in - dai-link sub nodes are ignored. -- simple-audio-card,hp-det-gpio : Reference to GPIO that signals when - headphones are attached. -- simple-audio-card,mic-det-gpio : Reference to GPIO that signals when - a microphone is attached. -- simple-audio-card,aux-devs : List of phandles pointing to auxiliary devices, such - as amplifiers, to be added to the sound card. -- simple-audio-card,pin-switches : List of strings containing the widget names for - which pin switches must be created. - -Optional subnodes: - -- simple-audio-card,dai-link : Container for dai-link level - properties and the CPU and CODEC - sub-nodes. This container may be - omitted when the card has only one - DAI link. See the examples and the - section below. - -Dai-link subnode properties and subnodes: - -If dai-link subnode is omitted and the subnode properties are directly -under "sound"-node the subnode property and subnode names have to be -prefixed with "simple-audio-card,"-prefix. - -Required dai-link subnodes: - -- cpu : CPU sub-node -- codec : CODEC sub-node - -Optional dai-link subnode properties: - -- format : CPU/CODEC common audio format. - "i2s", "right_j", "left_j" , "dsp_a" - "dsp_b", "ac97", "pdm", "msb", "lsb" -- frame-master : Indicates dai-link frame master. - phandle to a cpu or codec subnode. -- bitclock-master : Indicates dai-link bit clock master. - phandle to a cpu or codec subnode. -- bitclock-inversion : bool property. Add this if the - dai-link uses bit clock inversion. -- frame-inversion : bool property. Add this if the - dai-link uses frame clock inversion. -- mclk-fs : Multiplication factor between stream - rate and codec mclk, applied only for - the dai-link. - -For backward compatibility the frame-master and bitclock-master -properties can be used as booleans in codec subnode to indicate if the -codec is the dai-link frame or bit clock master. In this case there -should be no dai-link node, the same properties should not be present -at sound-node level, and the bitclock-inversion and frame-inversion -properties should also be placed in the codec node if needed. - -Required CPU/CODEC subnodes properties: - -- sound-dai : phandle and port of CPU/CODEC - -Optional CPU/CODEC subnodes properties: - -- dai-tdm-slot-num : Please refer to tdm-slot.txt. -- dai-tdm-slot-width : Please refer to tdm-slot.txt. -- clocks / system-clock-frequency : specify subnode's clock if needed. - it can be specified via "clocks" if system has - clock node (= common clock), or "system-clock-frequency" - (if system doens't support common clock) - If a clock is specified, it is - enabled with clk_prepare_enable() - in dai startup() and disabled with - clk_disable_unprepare() in dai - shutdown(). - If a clock is specified and a - multiplication factor is given with - mclk-fs, the clock will be set to the - calculated mclk frequency when the - stream starts. -- system-clock-direction-out : specifies clock direction as 'out' on - initialization. It is useful for some aCPUs with - fixed clocks. - -------------------------------------------- -Example 1 - single DAI link: -------------------------------------------- - -sound { - compatible = "simple-audio-card"; - simple-audio-card,name = "VF610-Tower-Sound-Card"; - simple-audio-card,format = "left_j"; - simple-audio-card,bitclock-master = <&dailink0_master>; - simple-audio-card,frame-master = <&dailink0_master>; - simple-audio-card,widgets = - "Microphone", "Microphone Jack", - "Headphone", "Headphone Jack", - "Speaker", "External Speaker"; - simple-audio-card,routing = - "MIC_IN", "Microphone Jack", - "Headphone Jack", "HP_OUT", - "External Speaker", "LINE_OUT"; - - simple-audio-card,cpu { - sound-dai = <&sh_fsi2 0>; - }; - - dailink0_master: simple-audio-card,codec { - sound-dai = <&ak4648>; - clocks = <&osc>; - }; -}; - -&i2c0 { - ak4648: ak4648@12 { - #sound-dai-cells = <0>; - compatible = "asahi-kasei,ak4648"; - reg = <0x12>; - }; -}; - -sh_fsi2: sh_fsi2@ec230000 { - #sound-dai-cells = <1>; - compatible = "renesas,sh_fsi2"; - reg = <0xec230000 0x400>; - interrupt-parent = <&gic>; - interrupts = <0 146 0x4>; -}; - -------------------------------------------- -Example 2 - many DAI links: -------------------------------------------- - -sound { - compatible = "simple-audio-card"; - simple-audio-card,name = "Cubox Audio"; - - simple-audio-card,dai-link@0 { /* I2S - HDMI */ - reg = <0>; - format = "i2s"; - cpu { - sound-dai = <&audio1 0>; - }; - codec { - sound-dai = <&tda998x 0>; - }; - }; - - simple-audio-card,dai-link@1 { /* S/PDIF - HDMI */ - reg = <1>; - cpu { - sound-dai = <&audio1 1>; - }; - codec { - sound-dai = <&tda998x 1>; - }; - }; - - simple-audio-card,dai-link@2 { /* S/PDIF - S/PDIF */ - reg = <2>; - cpu { - sound-dai = <&audio1 1>; - }; - codec { - sound-dai = <&spdif_codec>; - }; - }; -}; - -------------------------------------------- -Example 3 - route audio from IMX6 SSI2 through TLV320DAC3100 codec -through TPA6130A2 amplifier to headphones: -------------------------------------------- - -&i2c0 { - codec: tlv320dac3100@18 { - compatible = "ti,tlv320dac3100"; - ... - } - - amp: tpa6130a2@60 { - compatible = "ti,tpa6130a2"; - ... - } -} - -sound { - compatible = "simple-audio-card"; - ... - simple-audio-card,widgets = - "Headphone", "Headphone Jack"; - simple-audio-card,routing = - "Headphone Jack", "HPLEFT", - "Headphone Jack", "HPRIGHT", - "LEFTIN", "HPL", - "RIGHTIN", "HPR"; - simple-audio-card,aux-devs = <&>; - simple-audio-card,cpu { - sound-dai = <&ssi2>; - }; - simple-audio-card,codec { - sound-dai = <&codec>; - clocks = ... - }; -}; - -------------------------------------------- -Example 4. Sampling Rate Conversion -------------------------------------------- - -sound { - compatible = "simple-audio-card"; - - simple-audio-card,name = "rsnd-ak4643"; - simple-audio-card,format = "left_j"; - simple-audio-card,bitclock-master = <&sndcodec>; - simple-audio-card,frame-master = <&sndcodec>; - - simple-audio-card,convert-rate = <48000>; - - simple-audio-card,prefix = "ak4642"; - simple-audio-card,routing = "ak4642 Playback", "DAI0 Playback", - "DAI0 Capture", "ak4642 Capture"; - - sndcpu: simple-audio-card,cpu { - sound-dai = <&rcar_sound>; - }; - - sndcodec: simple-audio-card,codec { - sound-dai = <&ak4643>; - system-clock-frequency = <11289600>; - }; -}; - -------------------------------------------- -Example 5. 2 CPU 1 Codec (Mixing) -------------------------------------------- -sound { - compatible = "simple-audio-card"; - - simple-audio-card,name = "rsnd-ak4643"; - simple-audio-card,format = "left_j"; - simple-audio-card,bitclock-master = <&dpcmcpu>; - simple-audio-card,frame-master = <&dpcmcpu>; - - simple-audio-card,routing = "ak4642 Playback", "DAI0 Playback", - "ak4642 Playback", "DAI1 Playback"; - - dpcmcpu: cpu@0 { - sound-dai = <&rcar_sound 0>; - }; - - cpu@1 { - sound-dai = <&rcar_sound 1>; - }; - - codec { - prefix = "ak4642"; - sound-dai = <&ak4643>; - clocks = <&audio_clock>; - }; -}; - -------------------------------------------- -Example 6 - many DAI links with DPCM: -------------------------------------------- - -CPU0 ------ ak4613 -CPU1 ------ PCM3168A-p /* DPCM 1ch/2ch */ -CPU2 --/ /* DPCM 3ch/4ch */ -CPU3 --/ /* DPCM 5ch/6ch */ -CPU4 --/ /* DPCM 7ch/8ch */ -CPU5 ------ PCM3168A-c - -sound { - compatible = "simple-audio-card"; - - simple-audio-card,routing = - "pcm3168a Playback", "DAI1 Playback", - "pcm3168a Playback", "DAI2 Playback", - "pcm3168a Playback", "DAI3 Playback", - "pcm3168a Playback", "DAI4 Playback"; - - simple-audio-card,dai-link@0 { - format = "left_j"; - bitclock-master = <&sndcpu0>; - frame-master = <&sndcpu0>; - - sndcpu0: cpu { - sound-dai = <&rcar_sound 0>; - }; - codec { - sound-dai = <&ak4613>; - }; - }; - simple-audio-card,dai-link@1 { - format = "i2s"; - bitclock-master = <&sndcpu1>; - frame-master = <&sndcpu1>; - - convert-channels = <8>; /* TDM Split */ - - sndcpu1: cpu@0 { - sound-dai = <&rcar_sound 1>; - }; - cpu@1 { - sound-dai = <&rcar_sound 2>; - }; - cpu@2 { - sound-dai = <&rcar_sound 3>; - }; - cpu@3 { - sound-dai = <&rcar_sound 4>; - }; - codec { - mclk-fs = <512>; - prefix = "pcm3168a"; - dai-tdm-slot-num = <8>; - sound-dai = <&pcm3168a 0>; - }; - }; - simple-audio-card,dai-link@2 { - format = "i2s"; - bitclock-master = <&sndcpu2>; - frame-master = <&sndcpu2>; - - sndcpu2: cpu { - sound-dai = <&rcar_sound 5>; - }; - codec { - mclk-fs = <512>; - prefix = "pcm3168a"; - sound-dai = <&pcm3168a 1>; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/sound/simple-card.yaml b/Documentation/devicetree/bindings/sound/simple-card.yaml new file mode 100644 index 0000000..8132d0c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/simple-card.yaml
@@ -0,0 +1,482 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/simple-card.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Simple Audio Card Driver Device Tree Bindings + +maintainers: + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> + +definitions: + + frame-master: + description: Indicates dai-link frame master. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + + bitclock-master: + description: Indicates dai-link bit clock master + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + + frame-inversion: + description: dai-link uses frame clock inversion + $ref: /schemas/types.yaml#/definitions/flag + + bitclock-inversion: + description: dai-link uses bit clock inversion + $ref: /schemas/types.yaml#/definitions/flag + + dai-tdm-slot-num: + description: see tdm-slot.txt. + $ref: /schemas/types.yaml#/definitions/uint32 + + dai-tdm-slot-width: + description: see tdm-slot.txt. + $ref: /schemas/types.yaml#/definitions/uint32 + + system-clock-frequency: + description: | + If a clock is specified and a multiplication factor is given with + mclk-fs, the clock will be set to the calculated mclk frequency + when the stream starts. + $ref: /schemas/types.yaml#/definitions/uint32 + + system-clock-direction-out: + description: | + specifies clock direction as 'out' on initialization. + It is useful for some aCPUs with fixed clocks. + $ref: /schemas/types.yaml#/definitions/flag + + mclk-fs: + description: | + Multiplication factor between stream rate and codec mclk. + When defined, mclk-fs property defined in dai-link sub nodes are ignored. + $ref: /schemas/types.yaml#/definitions/uint32 + + aux-devs: + description: | + List of phandles pointing to auxiliary devices, such + as amplifiers, to be added to the sound card. + $ref: /schemas/types.yaml#/definitions/phandle-array + + convert-rate: + description: CPU to Codec rate convert. + $ref: /schemas/types.yaml#/definitions/uint32 + + convert-channels: + description: CPU to Codec rate channels. + $ref: /schemas/types.yaml#/definitions/uint32 + + prefix: + description: "device name prefix" + $ref: /schemas/types.yaml#/definitions/string + + 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 + + widgets: + description: User specified audio sound widgets. + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + + pin-switches: + description: the widget names for which pin switches must be created. + $ref: /schemas/types.yaml#/definitions/string-array + + format: + description: audio format. + items: + enum: + - i2s + - right_j + - left_j + - dsp_a + - dsp_b + - ac97 + - pdm + - msb + - lsb + + dai: + type: object + properties: + sound-dai: + maxItems: 1 + + # common properties + mclk-fs: + $ref: "#/definitions/mclk-fs" + prefix: + $ref: "#/definitions/prefix" + frame-inversion: + $ref: "#/definitions/frame-inversion" + bitclock-inversion: + $ref: "#/definitions/bitclock-inversion" + frame-master: + $ref: /schemas/types.yaml#/definitions/flag + bitclock-master: + $ref: /schemas/types.yaml#/definitions/flag + + dai-tdm-slot-num: + $ref: "#/definitions/dai-tdm-slot-num" + dai-tdm-slot-width: + $ref: "#/definitions/dai-tdm-slot-width" + clocks: + maxItems: 1 + system-clock-frequency: + $ref: "#/definitions/system-clock-frequency" + system-clock-direction-out: + $ref: "#/definitions/system-clock-direction-out" + required: + - sound-dai + +properties: + compatible: + contains: + enum: + - simple-audio-card + - simple-scu-audio-card + + "#address-cells": + const: 1 + "#size-cells": + const: 0 + + label: + $ref: "#/definitions/label" + + simple-audio-card,name: + description: User specified audio sound card name. + $ref: /schemas/types.yaml#/definitions/string + +# use patternProperties to avoid naming "xxx,yyy" issue +patternProperties: + "^simple-audio-card,widgets$": + $ref: "#/definitions/widgets" + "^simple-audio-card,routing$": + $ref: "#/definitions/routing" + "^simple-audio-card,cpu(@[0-9a-f]+)?": + $ref: "#/definitions/dai" + "^simple-audio-card,codec(@[0-9a-f]+)?": + $ref: "#/definitions/dai" + + # common properties + "^simple-audio-card,frame-master$": + $ref: "#/definitions/frame-master" + "^simple-audio-card,bitclock-master$": + $ref: "#/definitions/bitclock-master" + "^simple-audio-card,frame-inversion$": + $ref: "#/definitions/frame-inversion" + "^simple-audio-card,bitclock-inversion$": + $ref: "#/definitions/bitclock-inversion" + "^simple-audio-card,format$": + $ref: "#/definitions/format" + "^simple-audio-card,mclk-fs$": + $ref: "#/definitions/mclk-fs" + "^simple-audio-card,aux-devs$": + $ref: "#/definitions/aux-devs" + "^simple-audio-card,convert-rate$": + $ref: "#/definitions/convert-rate" + "^simple-audio-card,convert-channels$": + $ref: "#/definitions/convert-channels" + "^simple-audio-card,prefix$": + $ref: "#/definitions/prefix" + "^simple-audio-card,pin-switches$": + $ref: "#/definitions/pin-switches" + "^simple-audio-card,hp-det-gpio$": + maxItems: 1 + "^simple-audio-card,mic-det-gpio$": + maxItems: 1 + + "^simple-audio-card,dai-link(@[0-9a-f]+)?$": + description: | + Container for dai-link level properties and the CPU and CODEC sub-nodes. + This container may be omitted when the card has only one DAI link. + type: object + properties: + reg: + maxItems: 1 + + # common properties + frame-master: + $ref: "#/definitions/frame-master" + bitclock-master: + $ref: "#/definitions/bitclock-master" + frame-inversion: + $ref: "#/definitions/frame-inversion" + bitclock-inversion: + $ref: "#/definitions/bitclock-inversion" + format: + $ref: "#/definitions/format" + mclk-fs: + $ref: "#/definitions/mclk-fs" + aux-devs: + $ref: "#/definitions/aux-devs" + convert-rate: + $ref: "#/definitions/convert-rate" + convert-channels: + $ref: "#/definitions/convert-channels" + prefix: + $ref: "#/definitions/prefix" + pin-switches: + $ref: "#/definitions/pin-switches" + hp-det-gpio: + maxItems: 1 + mic-det-gpio: + maxItems: 1 + + patternProperties: + "^cpu(@[0-9a-f]+)?": + $ref: "#/definitions/dai" + "^codec(@[0-9a-f]+)?": + $ref: "#/definitions/dai" + additionalProperties: false + +required: + - compatible + +additionalProperties: false + +examples: +#-------------------- +# single DAI link +#-------------------- + - | + sound { + compatible = "simple-audio-card"; + simple-audio-card,name = "VF610-Tower-Sound-Card"; + simple-audio-card,format = "left_j"; + simple-audio-card,bitclock-master = <&dailink0_master>; + simple-audio-card,frame-master = <&dailink0_master>; + simple-audio-card,widgets = + "Microphone", "Microphone Jack", + "Headphone", "Headphone Jack", + "Speaker", "External Speaker"; + simple-audio-card,routing = + "MIC_IN", "Microphone Jack", + "Headphone Jack", "HP_OUT", + "External Speaker", "LINE_OUT"; + + simple-audio-card,cpu { + sound-dai = <&sh_fsi2 0>; + }; + + dailink0_master: simple-audio-card,codec { + sound-dai = <&ak4648>; + clocks = <&osc>; + }; + }; + +#-------------------- +# Multi DAI links +#-------------------- + - | + sound { + compatible = "simple-audio-card"; + simple-audio-card,name = "Cubox Audio"; + + #address-cells = <1>; + #size-cells = <0>; + + simple-audio-card,dai-link@0 { /* I2S - HDMI */ + reg = <0>; + format = "i2s"; + cpu { + sound-dai = <&audio0>; + }; + codec { + sound-dai = <&tda998x0>; + }; + }; + + simple-audio-card,dai-link@1 { /* S/PDIF - HDMI */ + reg = <1>; + cpu { + sound-dai = <&audio1>; + }; + codec { + sound-dai = <&tda998x1>; + }; + }; + + simple-audio-card,dai-link@2 { /* S/PDIF - S/PDIF */ + reg = <2>; + cpu { + sound-dai = <&audio2>; + }; + codec { + sound-dai = <&spdif_codec>; + }; + }; + }; + +#-------------------- +# route audio from IMX6 SSI2 through TLV320DAC3100 codec +# through TPA6130A2 amplifier to headphones: +#-------------------- + - | + sound { + compatible = "simple-audio-card"; + + simple-audio-card,widgets = + "Headphone", "Headphone Jack"; + simple-audio-card,routing = + "Headphone Jack", "HPLEFT", + "Headphone Jack", "HPRIGHT", + "LEFTIN", "HPL", + "RIGHTIN", "HPR"; + simple-audio-card,aux-devs = <&>; + simple-audio-card,cpu { + sound-dai = <&ssi2>; + }; + simple-audio-card,codec { + sound-dai = <&codec>; + clocks = <&clocks>; + }; + }; + +#-------------------- +# Sampling Rate Conversion +#-------------------- + - | + sound { + compatible = "simple-audio-card"; + + simple-audio-card,name = "rsnd-ak4643"; + simple-audio-card,format = "left_j"; + simple-audio-card,bitclock-master = <&sndcodec>; + simple-audio-card,frame-master = <&sndcodec>; + + simple-audio-card,convert-rate = <48000>; + + simple-audio-card,prefix = "ak4642"; + simple-audio-card,routing = "ak4642 Playback", "DAI0 Playback", + "DAI0 Capture", "ak4642 Capture"; + + sndcpu: simple-audio-card,cpu { + sound-dai = <&rcar_sound>; + }; + + sndcodec: simple-audio-card,codec { + sound-dai = <&ak4643>; + system-clock-frequency = <11289600>; + }; + }; + +#-------------------- +# 2 CPU 1 Codec (Mixing) +#-------------------- + - | + sound { + compatible = "simple-audio-card"; + + simple-audio-card,name = "rsnd-ak4643"; + simple-audio-card,format = "left_j"; + simple-audio-card,bitclock-master = <&dpcmcpu>; + simple-audio-card,frame-master = <&dpcmcpu>; + + simple-audio-card,convert-rate = <48000>; + simple-audio-card,convert-channels = <2>; + + simple-audio-card,routing = "ak4642 Playback", "DAI0 Playback", + "ak4642 Playback", "DAI1 Playback"; + + dpcmcpu: simple-audio-card,cpu@0 { + sound-dai = <&rcar_sound 0>; + }; + + simple-audio-card,cpu@1 { + sound-dai = <&rcar_sound 1>; + }; + + simple-audio-card,codec { + prefix = "ak4642"; + sound-dai = <&ak4643>; + clocks = <&audio_clock>; + }; + }; + +#-------------------- +# Multi DAI links with DPCM: +# +# CPU0 ------ ak4613 +# CPU1 ------ PCM3168A-p /* DPCM 1ch/2ch */ +# CPU2 --/ /* DPCM 3ch/4ch */ +# CPU3 --/ /* DPCM 5ch/6ch */ +# CPU4 --/ /* DPCM 7ch/8ch */ +# CPU5 ------ PCM3168A-c +#-------------------- + - | + sound { + compatible = "simple-audio-card"; + + simple-audio-card,routing = + "pcm3168a Playback", "DAI1 Playback", + "pcm3168a Playback", "DAI2 Playback", + "pcm3168a Playback", "DAI3 Playback", + "pcm3168a Playback", "DAI4 Playback"; + + simple-audio-card,dai-link@0 { + format = "left_j"; + bitclock-master = <&sndcpu0>; + frame-master = <&sndcpu0>; + + sndcpu0: cpu { + sound-dai = <&rcar_sound 0>; + }; + codec { + sound-dai = <&ak4613>; + }; + }; + + simple-audio-card,dai-link@1 { + format = "i2s"; + bitclock-master = <&sndcpu1>; + frame-master = <&sndcpu1>; + + convert-channels = <8>; /* TDM Split */ + + sndcpu1: cpu@0 { + sound-dai = <&rcar_sound 1>; + }; + cpu@1 { + sound-dai = <&rcar_sound 2>; + }; + cpu@2 { + sound-dai = <&rcar_sound 3>; + }; + cpu@3 { + sound-dai = <&rcar_sound 4>; + }; + codec { + mclk-fs = <512>; + prefix = "pcm3168a"; + dai-tdm-slot-num = <8>; + sound-dai = <&pcm3168a 0>; + }; + }; + + simple-audio-card,dai-link@2 { + format = "i2s"; + bitclock-master = <&sndcpu2>; + frame-master = <&sndcpu2>; + + sndcpu2: cpu { + sound-dai = <&rcar_sound 5>; + }; + codec { + mclk-fs = <512>; + prefix = "pcm3168a"; + sound-dai = <&pcm3168a 1>; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/sound/tdm-slot.txt b/Documentation/devicetree/bindings/sound/tdm-slot.txt index 34cf70e..4bb513a 100644 --- a/Documentation/devicetree/bindings/sound/tdm-slot.txt +++ b/Documentation/devicetree/bindings/sound/tdm-slot.txt
@@ -14,8 +14,8 @@ dai-tdm-slot-tx-mask = <0 1>; dai-tdm-slot-rx-mask = <1 0>; -And for each spcified driver, there could be one .of_xlate_tdm_slot_mask() -to specify a explicit mapping of the channels and the slots. If it's absent +And for each specified driver, there could be one .of_xlate_tdm_slot_mask() +to specify an explicit mapping of the channels and the slots. If it's absent the default snd_soc_of_xlate_tdm_slot_mask() will be used to generating the tx and rx masks.
diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml index ab2268c..2e6ac5d 100644 --- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml +++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml
@@ -49,9 +49,8 @@ 0 - Mic bias is set to VREF 1 - Mic bias is set to VREF × 1.096 6 - Mic bias is set to AVDD - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [0, 1, 6] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 6] ti,vref-source: description: | @@ -59,9 +58,55 @@ 0 - Set VREF to 2.75V 1 - Set VREF to 2.5V 2 - Set VREF to 1.375V - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [0, 1, 2] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + + ti,pdm-edge-select: + description: | + Defines the PDMCLK sampling edge configuration for the PDM inputs. This + array is defined as <PDMIN1 PDMIN2 PDMIN3 PDMIN4>. + + 0 - (default) Odd channel is latched on the negative edge and even + channel is latched on the the positive edge. + 1 - Odd channel is latched on the positive edge and even channel is + latched on the the negative edge. + + PDMIN1 - PDMCLK latching edge used for channel 1 and 2 data + PDMIN2 - PDMCLK latching edge used for channel 3 and 4 data + PDMIN3 - PDMCLK latching edge used for channel 5 and 6 data + PDMIN4 - PDMCLK latching edge used for channel 7 and 8 data + + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 4 + items: + maximum: 1 + default: [0, 0, 0, 0] + + ti,gpi-config: + description: | + Defines the configuration for the general purpose input pins (GPI). + The array is defined as <GPI1 GPI2 GPI3 GPI4>. + + 0 - (default) disabled + 1 - GPIX is configured as a general-purpose input (GPI) + 2 - GPIX is configured as a master clock input (MCLK) + 3 - GPIX is configured as an ASI input for daisy-chain (SDIN) + 4 - GPIX is configured as a PDM data input for channel 1 and channel + (PDMDIN1) + 5 - GPIX is configured as a PDM data input for channel 3 and channel + (PDMDIN2) + 6 - GPIX is configured as a PDM data input for channel 5 and channel + (PDMDIN3) + 7 - GPIX is configured as a PDM data input for channel 7 and channel + (PDMDIN4) + + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 4 + items: + maximum: 7 + default: [0, 0, 0, 0] required: - compatible @@ -77,6 +122,8 @@ compatible = "ti,tlv320adc5140"; reg = <0x4c>; ti,mic-bias-source = <6>; + ti,pdm-edge-select = <0 1 0 1>; + ti,gpi-config = <4 5 6 7>; reset-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>; }; };
diff --git a/Documentation/devicetree/bindings/sound/wlf,arizona.txt b/Documentation/devicetree/bindings/sound/wlf,arizona.txt deleted file mode 100644 index e172c62..0000000 --- a/Documentation/devicetree/bindings/sound/wlf,arizona.txt +++ /dev/null
@@ -1,53 +0,0 @@ -Cirrus Logic Arizona class audio SoCs - -These devices are audio SoCs with extensive digital capabilities and a range -of analogue I/O. - -This document lists sound specific bindings, see the primary binding -document: - ../mfd/arizona.txt - -Optional properties: - - - wlf,inmode : A list of INn_MODE register values, where n is the number - of input signals. Valid values are 0 (Differential), 1 (Single-ended) and - 2 (Digital Microphone). If absent, INn_MODE registers set to 0 by default. - If present, values must be specified less than or equal to the number of - input signals. If values less than the number of input signals, elements - that have not been specified are set to 0 by default. Entries are: - <IN1, IN2, IN3, IN4> (wm5102, wm5110, wm8280, wm8997) - <IN1A, IN2A, IN1B, IN2B> (wm8998, wm1814) - - wlf,out-mono : A list of boolean values indicating whether each output is - mono or stereo. Position within the list indicates the output affected - (eg. First entry in the list corresponds to output 1). A non-zero value - indicates a mono output. If present, the number of values should be less - than or equal to the number of outputs, if less values are supplied the - additional outputs will be treated as stereo. - - - wlf,dmic-ref : DMIC reference voltage source for each input, can be - selected from either MICVDD or one of the MICBIAS's, defines - (ARIZONA_DMIC_xxxx) are provided in <dt-bindings/mfd/arizona.txt>. If - present, the number of values should be less than or equal to the - number of inputs, unspecified inputs will use the chip default. - - - wlf,max-channels-clocked : The maximum number of channels to be clocked on - each AIF, useful for I2S systems with multiple data lines being mastered. - Specify one cell for each AIF to be configured, specify zero for AIFs that - should be handled normally. - If present, number of cells must be less than or equal to the number of - AIFs. If less than the number of AIFs, for cells that have not been - specified the corresponding AIFs will be treated as default setting. - - - wlf,spk-fmt : PDM speaker data format, must contain 2 cells (OUT5 and OUT6). - See the datasheet for values. - The second cell is ignored for codecs that do not have OUT6 (wm5102, wm8997, - wm8998, wm1814) - - - wlf,spk-mute : PDM speaker mute setting, must contain 2 cells (OUT5 and OUT6). - See the datasheet for values. - The second cell is ignored for codecs that do not have OUT6 (wm5102, wm8997, - wm8998, wm1814) - - - wlf,out-volume-limit : The volume limit value that should be applied to each - output channel. See the datasheet for exact values. Channels are specified - in the order OUT1L, OUT1R, OUT2L, OUT2R, etc.
diff --git a/Documentation/devicetree/bindings/sound/wlf,arizona.yaml b/Documentation/devicetree/bindings/sound/wlf,arizona.yaml new file mode 100644 index 0000000..22d54be --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,arizona.yaml
@@ -0,0 +1,114 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,arizona.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic/Wolfson Microelectronics Arizona class audio SoCs + +maintainers: + - patches@opensource.cirrus.com + +description: | + These devices are audio SoCs with extensive digital capabilities and a range + of analogue I/O. + + This document lists sound specific bindings, see the primary binding + document ../mfd/arizona.yaml + +properties: + '#sound-dai-cells': + description: + The first cell indicating the audio interface. + const: 1 + + wlf,inmode: + description: + A list of INn_MODE register values, where n is the number of input + signals. Valid values are 0 (Differential), 1 (Single-ended) and + 2 (Digital Microphone). If absent, INn_MODE registers set to 0 by + default. If present, values must be specified less than or equal + to the number of input signals. If values less than the number of + input signals, elements that have not been specified are set to 0 by + default. Entries are <IN1, IN2, IN3, IN4> (wm5102, wm5110, wm8280, + wm8997) and <IN1A, IN2A, IN1B, IN2B> (wm8998, wm1814) + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 4 + items: + minimum: 0 + maximum: 2 + default: 0 + + wlf,out-mono: + description: + A list of boolean values indicating whether each output is mono + or stereo. Position within the list indicates the output affected + (eg. First entry in the list corresponds to output 1). A non-zero + value indicates a mono output. If present, the number of values + should be less than or equal to the number of outputs, if less values + are supplied the additional outputs will be treated as stereo. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 6 + items: + minimum: 0 + maximum: 1 + default: 0 + + wlf,dmic-ref: + description: + DMIC reference voltage source for each input, can be selected from + either MICVDD or one of the MICBIAS's, defines (ARIZONA_DMIC_xxxx) + are provided in dt-bindings/mfd/arizona.h. If present, the number + of values should be less than or equal to the number of inputs, + unspecified inputs will use the chip default. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 4 + items: + minimum: 0 + maximum: 3 + default: 0 + + wlf,max-channels-clocked: + description: + The maximum number of channels to be clocked on each AIF, useful for + I2S systems with multiple data lines being mastered. Specify one + cell for each AIF to be configured, specify zero for AIFs that should + be handled normally. If present, number of cells must be less than + or equal to the number of AIFs. If less than the number of AIFs, for + cells that have not been specified the corresponding AIFs will be + treated as default setting. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 3 + items: + default: 0 + + wlf,spk-fmt: + description: + PDM speaker data format, must contain 2 cells (OUT5 and OUT6). See + the datasheet for values. The second cell is ignored for codecs that + do not have OUT6 (wm5102, wm8997, wm8998, wm1814) + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + + wlf,spk-mute: + description: + PDM speaker mute setting, must contain 2 cells (OUT5 and OUT6). See + the datasheet for values. The second cell is ignored for codecs that + do not have OUT6 (wm5102, wm8997, wm8998, wm1814) + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + + wlf,out-volume-limit: + description: + The volume limit value that should be applied to each output + channel. See the datasheet for exact values. Channels are specified + in the order OUT1L, OUT1R, OUT2L, OUT2R, etc. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 12
diff --git a/Documentation/devicetree/bindings/sound/wm8994.txt b/Documentation/devicetree/bindings/sound/wm8994.txt index 68cccc4..367b58c 100644 --- a/Documentation/devicetree/bindings/sound/wm8994.txt +++ b/Documentation/devicetree/bindings/sound/wm8994.txt
@@ -14,9 +14,15 @@ - #gpio-cells : Must be 2. The first cell is the pin number and the second cell is used to specify optional parameters (currently unused). - - AVDD2-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply, - SPKVDD1-supply, SPKVDD2-supply : power supplies for the device, as covered - in Documentation/devicetree/bindings/regulator/regulator.txt + - power supplies for the device, as covered in + Documentation/devicetree/bindings/regulator/regulator.txt, depending + on compatible: + - for wlf,wm1811 and wlf,wm8958: + AVDD1-supply, AVDD2-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, + DCVDD-supply, CPVDD-supply, SPKVDD1-supply, SPKVDD2-supply + - for wlf,wm8994: + AVDD1-supply, AVDD2-supply, DBVDD-supply, DCVDD-supply, CPVDD-supply, + SPKVDD1-supply, SPKVDD2-supply Optional properties: @@ -73,11 +79,11 @@ lineout1-se; + AVDD1-supply = <®ulator>; AVDD2-supply = <®ulator>; CPVDD-supply = <®ulator>; - DBVDD1-supply = <®ulator>; - DBVDD2-supply = <®ulator>; - DBVDD3-supply = <®ulator>; + DBVDD-supply = <®ulator>; + DCVDD-supply = <®ulator>; SPKVDD1-supply = <®ulator>; SPKVDD2-supply = <®ulator>; };
diff --git a/Documentation/devicetree/bindings/sound/zl38060.yaml b/Documentation/devicetree/bindings/sound/zl38060.yaml new file mode 100644 index 0000000..338e2a1 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/zl38060.yaml
@@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/zl38060.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ZL38060 Connected Home Audio Processor from Microsemi. + +description: | + The ZL38060 is a "Connected Home Audio Processor" from Microsemi, + which consists of a Digital Signal Processor (DSP), several Digital + Audio Interfaces (DAIs), analog outputs, and a block of 14 GPIOs. + +maintainers: + - Jaroslav Kysela <perex@perex.cz> + - Takashi Iwai <tiwai@suse.com> + +properties: + compatible: + const: mscc,zl38060 + + reg: + description: + SPI device address. + maxItems: 1 + + spi-max-frequency: + maximum: 24000000 + + reset-gpios: + description: + A GPIO line handling reset of the chip. As the line is active low, + it should be marked GPIO_ACTIVE_LOW (see ../gpio/gpio.txt) + maxItems: 1 + + '#gpio-cells': + const: 2 + + gpio-controller: true + + '#sound-dai-cells': + const: 0 + +required: + - compatible + - reg + - '#gpio-cells' + - gpio-controller + - '#sound-dai-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + codec: zl38060@0 { + gpio-controller; + #gpio-cells = <2>; + #sound-dai-cells = <0>; + compatible = "mscc,zl38060"; + reg = <0>; + spi-max-frequency = <12000000>; + reset-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; + }; + };
diff --git a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.txt b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.txt index ad7ac80..f5e518d 100644 --- a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.txt +++ b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.txt
@@ -26,6 +26,16 @@ "brcm,spi-bcm-qspi", "brcm,spi-brcmstb-qspi" : MSPI+BSPI on BRCMSTB SoCs "brcm,spi-bcm-qspi", "brcm,spi-brcmstb-mspi" : Second Instance of MSPI BRCMSTB SoCs + "brcm,spi-bcm7425-qspi", "brcm,spi-bcm-qspi", "brcm,spi-brcmstb-mspi" : Second Instance of MSPI + BRCMSTB SoCs + "brcm,spi-bcm7429-qspi", "brcm,spi-bcm-qspi", "brcm,spi-brcmstb-mspi" : Second Instance of MSPI + BRCMSTB SoCs + "brcm,spi-bcm7435-qspi", "brcm,spi-bcm-qspi", "brcm,spi-brcmstb-mspi" : Second Instance of MSPI + BRCMSTB SoCs + "brcm,spi-bcm7216-qspi", "brcm,spi-bcm-qspi", "brcm,spi-brcmstb-mspi" : Second Instance of MSPI + BRCMSTB SoCs + "brcm,spi-bcm7278-qspi", "brcm,spi-bcm-qspi", "brcm,spi-brcmstb-mspi" : Second Instance of MSPI + BRCMSTB SoCs "brcm,spi-bcm-qspi", "brcm,spi-nsp-qspi" : MSPI+BSPI on Cygnus, NSP "brcm,spi-bcm-qspi", "brcm,spi-ns2-qspi" : NS2 SoCs
diff --git a/Documentation/devicetree/bindings/spi/marvell,mmp2-ssp.yaml b/Documentation/devicetree/bindings/spi/marvell,mmp2-ssp.yaml new file mode 100644 index 0000000..0abcac3 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/marvell,mmp2-ssp.yaml
@@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2019,2020 Lubomir Rintel <lkundrak@v3.sk> +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/marvell,mmp2-ssp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PXA2xx SSP SPI Controller bindings + +maintainers: + - Lubomir Rintel <lkundrak@v3.sk> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + const: marvell,mmp2-ssp + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + ready-gpios: + description: | + GPIO used to signal a SPI master that the FIFO is filled and we're + ready to service a transfer. Only useful in slave mode. + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +dependencies: + ready-gpios: [ spi-slave ] + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/marvell,mmp2.h> + spi@d4035000 { + compatible = "marvell,mmp2-ssp"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xd4035000 0x1000>; + clocks = <&soc_clocks MMP2_CLK_SSP0>; + interrupts = <0>; + }; + +...
diff --git a/Documentation/devicetree/bindings/spi/mikrotik,rb4xx-spi.yaml b/Documentation/devicetree/bindings/spi/mikrotik,rb4xx-spi.yaml new file mode 100644 index 0000000..4ddb42a --- /dev/null +++ b/Documentation/devicetree/bindings/spi/mikrotik,rb4xx-spi.yaml
@@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/mikrotik,rb4xx-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MikroTik RB4xx series SPI master + +maintainers: + - Gabor Juhos <juhosg@openwrt.org> + - Bert Vermeulen <bert@biot.com> + +allOf: + - $ref: "spi-controller.yaml#" + +properties: + compatible: + const: mikrotik,rb4xx-spi + + reg: + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + spi: spi@1f000000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "mikrotik,rb4xx-spi"; + reg = <0x1f000000 0x10>; + }; + +... \ No newline at end of file
diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml index 5c16cf5..0178831 100644 --- a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml
@@ -8,12 +8,12 @@ title: Qualcomm Quad Serial Peripheral Interface (QSPI) maintainers: - - Mukesh Savaliya <msavaliy@codeaurora.org> - - Akash Asthana <akashast@codeaurora.org> + - Mukesh Savaliya <msavaliy@codeaurora.org> + - Akash Asthana <akashast@codeaurora.org> -description: - The QSPI controller allows SPI protocol communication in single, dual, or quad - wire transmission modes for read/write access to slaves such as NOR flash. +description: The QSPI controller allows SPI protocol communication in single, + dual, or quad wire transmission modes for read/write access to slaves such + as NOR flash. allOf: - $ref: /spi/spi-controller.yaml#
diff --git a/Documentation/devicetree/bindings/spi/renesas,hspi.yaml b/Documentation/devicetree/bindings/spi/renesas,hspi.yaml index c429cf4..f492cb9 100644 --- a/Documentation/devicetree/bindings/spi/renesas,hspi.yaml +++ b/Documentation/devicetree/bindings/spi/renesas,hspi.yaml
@@ -16,8 +16,8 @@ compatible: items: - enum: - - renesas,hspi-r8a7778 # R-Car M1A - - renesas,hspi-r8a7779 # R-Car H1 + - renesas,hspi-r8a7778 # R-Car M1A + - renesas,hspi-r8a7779 # R-Car H1 - const: renesas,hspi reg:
diff --git a/Documentation/devicetree/bindings/spi/renesas,rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml new file mode 100644 index 0000000..c54ac05 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml
@@ -0,0 +1,144 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/renesas,rspi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas (Quad) Serial Peripheral Interface (RSPI/QSPI) + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,rspi-sh7757 # SH7757 + - const: renesas,rspi # Legacy SH + + - items: + - enum: + - renesas,rspi-r7s72100 # RZ/A1H + - renesas,rspi-r7s9210 # RZ/A2 + - const: renesas,rspi-rz # RZ/A + + - items: + - enum: + - renesas,qspi-r8a7743 # RZ/G1M + - renesas,qspi-r8a7744 # RZ/G1N + - renesas,qspi-r8a7745 # RZ/G1E + - renesas,qspi-r8a77470 # RZ/G1C + - renesas,qspi-r8a7790 # R-Car H2 + - renesas,qspi-r8a7791 # R-Car M2-W + - renesas,qspi-r8a7792 # R-Car V2H + - renesas,qspi-r8a7793 # R-Car M2-N + - renesas,qspi-r8a7794 # R-Car E2 + - const: renesas,qspi # R-Car Gen2 and RZ/G1 + + reg: + maxItems: 1 + + interrupts: + oneOf: + - items: + - description: A combined interrupt + - items: + - description: Error interrupt (SPEI) + - description: Receive Interrupt (SPRI) + - description: Transmit Interrupt (SPTI) + + interrupt-names: + oneOf: + - items: + - const: mux + - items: + - const: error + - const: rx + - const: tx + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + description: + Must contain a list of pairs of references to DMA specifiers, one for + transmission, and one for reception. + + dma-names: + minItems: 2 + maxItems: 4 + items: + enum: + - tx + - rx + + num-cs: + description: | + Total number of native chip selects. + Hardware limitations related to chip selects: + - When using GPIO chip selects, at least one native chip select must + be left unused, as it will be driven anyway. + minimum: 1 + maximum: 2 + default: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - '#address-cells' + - '#size-cells' + +allOf: + - $ref: spi-controller.yaml# + - if: + properties: + compatible: + contains: + enum: + - renesas,rspi-rz + then: + properties: + interrupts: + minItems: 3 + required: + - interrupt-names + + - if: + properties: + compatible: + contains: + enum: + - renesas,qspi + then: + required: + - resets + +examples: + - | + #include <dt-bindings/clock/r8a7791-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7791-sysc.h> + + qspi: spi@e6b10000 { + compatible = "renesas,qspi-r8a7791", "renesas,qspi"; + reg = <0xe6b10000 0x2c>; + interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 917>; + dmas = <&dmac0 0x17>, <&dmac0 0x18>, <&dmac1 0x17>, <&dmac1 0x18>; + dma-names = "tx", "rx", "tx", "rx"; + power-domains = <&sysc R8A7791_PD_ALWAYS_ON>; + resets = <&cpg 917>; + num-cs = <1>; + #address-cells = <1>; + #size-cells = <0>; + };
diff --git a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml index b6c1dd2..e84edcf 100644 --- a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml +++ b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml
@@ -96,43 +96,39 @@ renesas,dtdl: description: delay sync signal (setup) in transmit mode. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: - - 0 # no bit delay - - 50 # 0.5-clock-cycle delay - - 100 # 1-clock-cycle delay - - 150 # 1.5-clock-cycle delay - - 200 # 2-clock-cycle delay + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # no bit delay + - 50 # 0.5-clock-cycle delay + - 100 # 1-clock-cycle delay + - 150 # 1.5-clock-cycle delay + - 200 # 2-clock-cycle delay renesas,syncdl: description: delay sync signal (hold) in transmit mode - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: - - 0 # no bit delay - - 50 # 0.5-clock-cycle delay - - 100 # 1-clock-cycle delay - - 150 # 1.5-clock-cycle delay - - 200 # 2-clock-cycle delay - - 300 # 3-clock-cycle delay + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # no bit delay + - 50 # 0.5-clock-cycle delay + - 100 # 1-clock-cycle delay + - 150 # 1.5-clock-cycle delay + - 200 # 2-clock-cycle delay + - 300 # 3-clock-cycle delay renesas,tx-fifo-size: # deprecated for soctype-specific bindings description: | Override the default TX fifo size. Unit is words. Ignored if 0. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - maxItems: 1 + $ref: /schemas/types.yaml#/definitions/uint32 + maxItems: 1 default: 64 renesas,rx-fifo-size: # deprecated for soctype-specific bindings description: | Override the default RX fifo size. Unit is words. Ignored if 0. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - maxItems: 1 + $ref: /schemas/types.yaml#/definitions/uint32 + maxItems: 1 default: 64 required: @@ -149,7 +145,7 @@ msiof0: spi@e6e20000 { compatible = "renesas,msiof-r8a7791", "renesas,rcar-gen2-msiof"; - reg = <0 0xe6e20000 0 0x0064>; + reg = <0xe6e20000 0x0064>; interrupts = <0 156 IRQ_TYPE_LEVEL_HIGH>; clocks = <&mstp0_clks R8A7791_CLK_MSIOF0>; dmas = <&dmac0 0x51>, <&dmac0 0x52>;
diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt deleted file mode 100644 index 3ed08ee..0000000 --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt +++ /dev/null
@@ -1,41 +0,0 @@ -Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface. - -Required properties: -- compatible : "snps,dw-apb-ssi" or "mscc,<soc>-spi", where soc is "ocelot" or - "jaguar2", or "amazon,alpine-dw-apb-ssi" -- reg : The register base for the controller. For "mscc,<soc>-spi", a second - register set is required (named ICPU_CFG:SPI_MST) -- interrupts : One interrupt, used by the controller. -- #address-cells : <1>, as required by generic SPI binding. -- #size-cells : <0>, also as required by generic SPI binding. -- clocks : phandles for the clocks, see the description of clock-names below. - The phandle for the "ssi_clk" is required. The phandle for the "pclk" clock - is optional. If a single clock is specified but no clock-name, it is the - "ssi_clk" clock. If both clocks are listed, the "ssi_clk" must be first. - -Optional properties: -- clock-names : Contains the names of the clocks: - "ssi_clk", for the core clock used to generate the external SPI clock. - "pclk", the interface clock, required for register access. If a clock domain - used to enable this clock then it should be named "pclk_clkdomain". -- cs-gpios : Specifies the gpio pins to be used for chipselects. -- num-cs : The number of chipselects. If omitted, this will default to 4. -- reg-io-width : The I/O register width (in bytes) implemented by this - device. Supported values are 2 or 4 (the default). - -Child nodes as per the generic SPI binding. - -Example: - - spi@fff00000 { - compatible = "snps,dw-apb-ssi"; - reg = <0xfff00000 0x1000>; - interrupts = <0 154 4>; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&spi_m_clk>; - num-cs = <2>; - cs-gpios = <&gpio0 13 0>, - <&gpio0 14 0>; - }; -
diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml new file mode 100644 index 0000000..c62cbe7 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
@@ -0,0 +1,133 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/snps,dw-apb-ssi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface + +maintainers: + - Mark Brown <broonie@kernel.org> + +allOf: + - $ref: "spi-controller.yaml#" + - if: + properties: + compatible: + contains: + enum: + - mscc,ocelot-spi + - mscc,jaguar2-spi + then: + properties: + reg: + minItems: 2 + +properties: + compatible: + oneOf: + - description: Generic DW SPI Controller + enum: + - snps,dw-apb-ssi + - snps,dwc-ssi-1.01a + - description: Microsemi Ocelot/Jaguar2 SoC SPI Controller + items: + - enum: + - mscc,ocelot-spi + - mscc,jaguar2-spi + - const: snps,dw-apb-ssi + - description: Amazon Alpine SPI Controller + const: amazon,alpine-dw-apb-ssi + - description: Renesas RZ/N1 SPI Controller + items: + - const: renesas,rzn1-spi + - const: snps,dw-apb-ssi + - description: Intel Keem Bay SPI Controller + const: intel,keembay-ssi + + reg: + minItems: 1 + items: + - description: DW APB SSI controller memory mapped registers + - description: SPI MST region map + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + items: + - description: SPI Controller reference clock source + - description: APB interface clock source + + clock-names: + minItems: 1 + items: + - const: ssi_clk + - const: pclk + + resets: + maxItems: 1 + + reset-names: + const: spi + + reg-io-width: + $ref: /schemas/types.yaml#/definitions/uint32 + description: I/O register width (in bytes) implemented by this device + default: 4 + enum: [ 2, 4 ] + + num-cs: + default: 4 + minimum: 1 + maximum: 4 + + dmas: + items: + - description: TX DMA Channel + - description: RX DMA Channel + + dma-names: + items: + - const: tx + - const: rx + +patternProperties: + "^.*@[0-9a-f]+$": + type: object + properties: + reg: + minimum: 0 + maximum: 3 + + spi-rx-bus-width: + const: 1 + + spi-tx-bus-width: + const: 1 + +unevaluatedProperties: false + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - interrupts + - clocks + +examples: + - | + spi@fff00000 { + compatible = "snps,dw-apb-ssi"; + reg = <0xfff00000 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <0 154 4>; + clocks = <&spi_m_clk>; + num-cs = <2>; + cs-gpios = <&gpio0 13 0>, + <&gpio0 14 0>; + }; +...
diff --git a/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml b/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml new file mode 100644 index 0000000..c254092 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml
@@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/socionext,uniphier-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier SPI controller + +description: | + UniPhier SoCs have SCSSI which supports SPI single channel. + +maintainers: + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> + - Keiji Hayashibara <hayashibara.keiji@socionext.com> + +allOf: + - $ref: spi-controller.yaml# + +properties: + "#address-cells": true + "#size-cells": true + + compatible: + const: socionext,uniphier-scssi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - resets + - "#address-cells" + - "#size-cells" + +examples: + - | + spi0: spi@54006000 { + compatible = "socionext,uniphier-scssi"; + reg = <0x54006000 0x100>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <0 39 4>; + clocks = <&peri_clk 11>; + resets = <&peri_rst 11>; + };
diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index d8e5509..c6a2f54 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml
@@ -115,24 +115,22 @@ Maximum SPI clocking speed of the device in Hz. spi-rx-bus-width: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 1, 2, 4, 8 ] - - default: 1 description: Bus width to the SPI bus used for read transfers. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8] + default: 1 spi-rx-delay-us: description: Delay, in microseconds, after a read transfer. spi-tx-bus-width: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 1, 2, 4, 8 ] - - default: 1 description: Bus width to the SPI bus used for write transfers. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8] + default: 1 spi-tx-delay-us: description:
diff --git a/Documentation/devicetree/bindings/spi/spi-dw.txt b/Documentation/devicetree/bindings/spi/spi-dw.txt deleted file mode 100644 index 7b63ed6..0000000 --- a/Documentation/devicetree/bindings/spi/spi-dw.txt +++ /dev/null
@@ -1,24 +0,0 @@ -Synopsys DesignWare SPI master - -Required properties: -- compatible: should be "snps,designware-spi" -- #address-cells: see spi-bus.txt -- #size-cells: see spi-bus.txt -- reg: address and length of the spi master registers -- interrupts: should contain one interrupt -- clocks: spi clock phandle -- num-cs: see spi-bus.txt - -Optional properties: -- cs-gpios: see spi-bus.txt - -Example: - -spi: spi@4020a000 { - compatible = "snps,designware-spi"; - interrupts = <11 1>; - reg = <0x4020a000 0x1000>; - clocks = <&pclk>; - num-cs = <2>; - cs-gpios = <&banka 0 0>; -};
diff --git a/Documentation/devicetree/bindings/spi/spi-pl022.yaml b/Documentation/devicetree/bindings/spi/spi-pl022.yaml index dfb697c..2299902 100644 --- a/Documentation/devicetree/bindings/spi/spi-pl022.yaml +++ b/Documentation/devicetree/bindings/spi/spi-pl022.yaml
@@ -51,7 +51,7 @@ pl022,rt: description: indicates the controller should run the message pump with realtime - priority to minimise the transfer latency on the bus (boolean) + priority to minimise the transfer latency on the bus (boolean) type: boolean dmas: @@ -80,55 +80,48 @@ properties: pl022,interface: description: SPI interface type - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - enum: - - 0 # SPI - - 1 # Texas Instruments Synchronous Serial Frame Format - - 2 # Microwire (Half Duplex) + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: + - 0 # SPI + - 1 # Texas Instruments Synchronous Serial Frame Format + - 2 # Microwire (Half Duplex) pl022,com-mode: description: Specifies the transfer mode - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - enum: - - 0 # interrupt mode - - 1 # polling mode - - 2 # DMA mode - default: 1 + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: + - 0 # interrupt mode + - 1 # polling mode + - 2 # DMA mode + default: 1 pl022,rx-level-trig: description: Rx FIFO watermark level - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - maximum: 4 + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 4 pl022,tx-level-trig: description: Tx FIFO watermark level - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - maximum: 4 + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 4 pl022,ctrl-len: description: Microwire interface - Control length - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0x03 - maximum: 0x1f + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0x03 + maximum: 0x1f pl022,wait-state: description: Microwire interface - Wait state - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - enum: [ 0, 1 ] + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: [0, 1] pl022,duplex: description: Microwire interface - Full/Half duplex - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - enum: [ 0, 1 ] + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: [0, 1] required: - compatible
diff --git a/Documentation/devicetree/bindings/spi/spi-pxa2xx.txt b/Documentation/devicetree/bindings/spi/spi-pxa2xx.txt deleted file mode 100644 index e30e0c2..0000000 --- a/Documentation/devicetree/bindings/spi/spi-pxa2xx.txt +++ /dev/null
@@ -1,27 +0,0 @@ -PXA2xx SSP SPI Controller - -Required properties: -- compatible: Must be "marvell,mmp2-ssp". -- reg: Offset and length of the device's register set. -- interrupts: Should be the interrupt number. -- clocks: Should contain a single entry describing the clock input. -- #address-cells: Number of cells required to define a chip select address. -- #size-cells: Should be zero. - -Optional properties: -- cs-gpios: list of GPIO chip selects. See the SPI bus bindings, - Documentation/devicetree/bindings/spi/spi-bus.txt -- spi-slave: Empty property indicating the SPI controller is used in slave mode. -- ready-gpios: GPIO used to signal a SPI master that the FIFO is filled - and we're ready to service a transfer. Only useful in slave mode. - -Child nodes represent devices on the SPI bus - See ../spi/spi-bus.txt - -Example: - ssp1: spi@d4035000 { - compatible = "marvell,mmp2-ssp"; - reg = <0xd4035000 0x1000>; - clocks = <&soc_clocks MMP2_CLK_SSP0>; - interrupts = <0>; - };
diff --git a/Documentation/devicetree/bindings/spi/spi-rspi.txt b/Documentation/devicetree/bindings/spi/spi-rspi.txt deleted file mode 100644 index 421722b..0000000 --- a/Documentation/devicetree/bindings/spi/spi-rspi.txt +++ /dev/null
@@ -1,73 +0,0 @@ -Device tree configuration for Renesas RSPI/QSPI driver - -Required properties: -- compatible : For Renesas Serial Peripheral Interface on legacy SH: - "renesas,rspi-<soctype>", "renesas,rspi" as fallback. - For Renesas Serial Peripheral Interface on RZ/A: - "renesas,rspi-<soctype>", "renesas,rspi-rz" as fallback. - For Quad Serial Peripheral Interface on R-Car Gen2 and - RZ/G1 devices: - "renesas,qspi-<soctype>", "renesas,qspi" as fallback. - Examples with soctypes are: - - "renesas,rspi-sh7757" (SH) - - "renesas,rspi-r7s72100" (RZ/A1H) - - "renesas,rspi-r7s9210" (RZ/A2) - - "renesas,qspi-r8a7743" (RZ/G1M) - - "renesas,qspi-r8a7744" (RZ/G1N) - - "renesas,qspi-r8a7745" (RZ/G1E) - - "renesas,qspi-r8a77470" (RZ/G1C) - - "renesas,qspi-r8a7790" (R-Car H2) - - "renesas,qspi-r8a7791" (R-Car M2-W) - - "renesas,qspi-r8a7792" (R-Car V2H) - - "renesas,qspi-r8a7793" (R-Car M2-N) - - "renesas,qspi-r8a7794" (R-Car E2) -- reg : Address start and address range size of the device -- interrupts : A list of interrupt-specifiers, one for each entry in - interrupt-names. - If interrupt-names is not present, an interrupt specifier - for a single muxed interrupt. -- interrupt-names : A list of interrupt names. Should contain (if present): - - "error" for SPEI, - - "rx" for SPRI, - - "tx" to SPTI, - - "mux" for a single muxed interrupt. -- num-cs : Number of chip selects. Some RSPI cores have more than 1. -- #address-cells : Must be <1> -- #size-cells : Must be <0> - -Optional properties: -- clocks : Must contain a reference to the functional clock. -- dmas : Must contain a list of two references to DMA specifiers, - one for transmission, and one for reception. -- dma-names : Must contain a list of two DMA names, "tx" and "rx". - -Pinctrl properties might be needed, too. See -Documentation/devicetree/bindings/pinctrl/renesas,*. - -Examples: - - spi0: spi@e800c800 { - compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz"; - reg = <0xe800c800 0x24>; - interrupts = <0 238 IRQ_TYPE_LEVEL_HIGH>, - <0 239 IRQ_TYPE_LEVEL_HIGH>, - <0 240 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "error", "rx", "tx"; - interrupt-parent = <&gic>; - num-cs = <1>; - #address-cells = <1>; - #size-cells = <0>; - }; - - spi: spi@e6b10000 { - compatible = "renesas,qspi-r8a7791", "renesas,qspi"; - reg = <0 0xe6b10000 0 0x2c>; - interrupt-parent = <&gic>; - interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp9_clks R8A7791_CLK_QSPI_MOD>; - num-cs = <1>; - #address-cells = <1>; - #size-cells = <0>; - dmas = <&dmac0 0x17>, <&dmac0 0x18>; - dma-names = "tx", "rx"; - };
diff --git a/Documentation/devicetree/bindings/spi/spi-sifive.yaml b/Documentation/devicetree/bindings/spi/spi-sifive.yaml index 140e435..4932205 100644 --- a/Documentation/devicetree/bindings/spi/spi-sifive.yaml +++ b/Documentation/devicetree/bindings/spi/spi-sifive.yaml
@@ -32,11 +32,10 @@ https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/spi reg: - maxItems: 1 - - description: - Physical base address and size of SPI registers map - A second (optional) range can indicate memory mapped flash + minItems: 1 + items: + - description: SPI registers region + - description: Memory mapped flash region interrupts: maxItems: 1 @@ -50,18 +49,16 @@ sifive,fifo-depth: description: Depth of hardware queues; defaults to 8 - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - enum: [ 8 ] - - default: 8 + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: [8] + default: 8 sifive,max-bits-per-word: description: Maximum bits per word; defaults to 8 - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - enum: [ 0, 1, 2, 3, 4, 5, 6, 7, 8 ] - - default: 8 + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: [0, 1, 2, 3, 4, 5, 6, 7, 8] + default: 8 required: - compatible @@ -73,7 +70,7 @@ - | spi: spi@10040000 { compatible = "sifive,fu540-c000-spi", "sifive,spi0"; - reg = <0x0 0x10040000 0x0 0x1000 0x0 0x20000000 0x0 0x10000000>; + reg = <0x10040000 0x1000>, <0x20000000 0x10000000>; interrupt-parent = <&plic>; interrupts = <51>; clocks = <&tlclk>;
diff --git a/Documentation/devicetree/bindings/spi/spi-uniphier.txt b/Documentation/devicetree/bindings/spi/spi-uniphier.txt deleted file mode 100644 index e120157..0000000 --- a/Documentation/devicetree/bindings/spi/spi-uniphier.txt +++ /dev/null
@@ -1,28 +0,0 @@ -Socionext UniPhier SPI controller driver - -UniPhier SoCs have SCSSI which supports SPI single channel. - -Required properties: - - compatible: should be "socionext,uniphier-scssi" - - reg: address and length of the spi master registers - - #address-cells: must be <1>, see spi-bus.txt - - #size-cells: must be <0>, see spi-bus.txt - - interrupts: a single interrupt specifier - - pinctrl-names: should be "default" - - pinctrl-0: pin control state for the default mode - - clocks: a phandle to the clock for the device - - resets: a phandle to the reset control for the device - -Example: - -spi0: spi@54006000 { - compatible = "socionext,uniphier-scssi"; - reg = <0x54006000 0x100>; - #address-cells = <1>; - #size-cells = <0>; - interrupts = <0 39 4>; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_spi0>; - clocks = <&peri_clk 11>; - resets = <&peri_rst 11>; -};
diff --git a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml index 3665a5f..1a342ce 100644 --- a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml
@@ -24,8 +24,8 @@ reg-names: items: - - const: qspi - - const: qspi_mm + - const: qspi + - const: qspi_mm clocks: maxItems: 1
diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt b/Documentation/devicetree/bindings/spi/ti_qspi.txt index e65fde4..47b184b 100644 --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -29,7 +29,7 @@ Example: For am4372: -qspi: qspi@4b300000 { +qspi: qspi@47900000 { compatible = "ti,am4372-qspi"; reg = <0x47900000 0x100>, <0x30000000 0x4000000>; reg-names = "qspi_base", "qspi_mmap";
diff --git a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml index 4b55094..f582593 100644 --- a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml +++ b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
@@ -29,8 +29,8 @@ - const: allwinner,sun4i-a10-system-control - const: allwinner,sun5i-a13-system-control - items: - - const: allwinner,sun7i-a20-system-control - - const: allwinner,sun4i-a10-system-control + - const: allwinner,sun7i-a20-system-control + - const: allwinner,sun4i-a10-system-control - const: allwinner,sun8i-a23-system-control - const: allwinner,sun8i-h3-system-control - const: allwinner,sun50i-a64-sram-controller @@ -38,11 +38,11 @@ - const: allwinner,sun50i-a64-system-control - const: allwinner,sun50i-h5-system-control - items: - - const: allwinner,sun50i-h6-system-control - - const: allwinner,sun50i-a64-system-control + - const: allwinner,sun50i-h6-system-control + - const: allwinner,sun50i-a64-system-control - items: - - const: allwinner,suniv-f1c100s-system-control - - const: allwinner,sun4i-a10-system-control + - const: allwinner,suniv-f1c100s-system-control + - const: allwinner,sun4i-a10-system-control reg: maxItems: 1 @@ -69,44 +69,44 @@ - const: allwinner,sun4i-a10-sram-d - const: allwinner,sun50i-a64-sram-c - items: - - const: allwinner,sun5i-a13-sram-a3-a4 - - const: allwinner,sun4i-a10-sram-a3-a4 + - const: allwinner,sun5i-a13-sram-a3-a4 + - const: allwinner,sun4i-a10-sram-a3-a4 - items: - - const: allwinner,sun7i-a20-sram-a3-a4 - - const: allwinner,sun4i-a10-sram-a3-a4 + - const: allwinner,sun7i-a20-sram-a3-a4 + - const: allwinner,sun4i-a10-sram-a3-a4 - items: - - const: allwinner,sun5i-a13-sram-c1 - - const: allwinner,sun4i-a10-sram-c1 + - const: allwinner,sun5i-a13-sram-c1 + - const: allwinner,sun4i-a10-sram-c1 - items: - - const: allwinner,sun7i-a20-sram-c1 - - const: allwinner,sun4i-a10-sram-c1 + - const: allwinner,sun7i-a20-sram-c1 + - const: allwinner,sun4i-a10-sram-c1 - items: - - const: allwinner,sun8i-a23-sram-c1 - - const: allwinner,sun4i-a10-sram-c1 + - const: allwinner,sun8i-a23-sram-c1 + - const: allwinner,sun4i-a10-sram-c1 - items: - - const: allwinner,sun8i-h3-sram-c1 - - const: allwinner,sun4i-a10-sram-c1 + - const: allwinner,sun8i-h3-sram-c1 + - const: allwinner,sun4i-a10-sram-c1 - items: - - const: allwinner,sun50i-a64-sram-c1 - - const: allwinner,sun4i-a10-sram-c1 + - const: allwinner,sun50i-a64-sram-c1 + - const: allwinner,sun4i-a10-sram-c1 - items: - - const: allwinner,sun50i-h5-sram-c1 - - const: allwinner,sun4i-a10-sram-c1 + - const: allwinner,sun50i-h5-sram-c1 + - const: allwinner,sun4i-a10-sram-c1 - items: - - const: allwinner,sun50i-h6-sram-c1 - - const: allwinner,sun4i-a10-sram-c1 + - const: allwinner,sun50i-h6-sram-c1 + - const: allwinner,sun4i-a10-sram-c1 - items: - - const: allwinner,sun5i-a13-sram-d - - const: allwinner,sun4i-a10-sram-d + - const: allwinner,sun5i-a13-sram-d + - const: allwinner,sun4i-a10-sram-d - items: - - const: allwinner,sun7i-a20-sram-d - - const: allwinner,sun4i-a10-sram-d + - const: allwinner,sun7i-a20-sram-d + - const: allwinner,sun4i-a10-sram-d - items: - - const: allwinner,suniv-f1c100s-sram-d - - const: allwinner,sun4i-a10-sram-d + - const: allwinner,suniv-f1c100s-sram-d + - const: allwinner,sun4i-a10-sram-d - items: - - const: allwinner,sun50i-h6-sram-c - - const: allwinner,sun50i-a64-sram-c + - const: allwinner,sun50i-h6-sram-c + - const: allwinner,sun50i-a64-sram-c required: - "#address-cells"
diff --git a/Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt b/Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt deleted file mode 100644 index 6b42fda..0000000 --- a/Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt +++ /dev/null
@@ -1,16 +0,0 @@ -Rockchip SRAM for pmu: ------------------------------- - -The sram of pmu is used to store the function of resume from maskrom(the 1st -level loader). This is a common use of the "pmu-sram" because it keeps power -even in low power states in the system. - -Required node properties: -- compatible : should be "rockchip,rk3288-pmu-sram" -- reg : physical base address and the size of the registers window - -Example: - sram@ff720000 { - compatible = "rockchip,rk3288-pmu-sram", "mmio-sram"; - reg = <0xff720000 0x1000>; - };
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index 7b83cc6..19d116f 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -29,6 +29,7 @@ enum: - mmio-sram - atmel,sama5d2-securam + - rockchip,rk3288-pmu-sram reg: maxItems: 1 @@ -73,6 +74,8 @@ - allwinner,sun50i-a64-sram-c - amlogic,meson8-smp-sram - amlogic,meson8b-smp-sram + - amlogic,meson-gxbb-scp-shmem + - amlogic,meson-axg-scp-shmem - renesas,smp-sram - rockchip,rk3066-smp-sram - samsung,exynos4210-sysram @@ -118,9 +121,18 @@ required: - compatible - reg - - "#address-cells" - - "#size-cells" - - ranges + +if: + properties: + compatible: + contains: + const: rockchip,rk3288-pmu-sram + +else: + required: + - "#address-cells" + - "#size-cells" + - ranges additionalProperties: false @@ -224,6 +236,16 @@ }; - | + // Rockchip's rk3288 SoC uses the sram of pmu to store the function of + // resume from maskrom(the 1st level loader). This is a common use of + // the "pmu-sram" because it keeps power even in low power states + // in the system. + sram@ff720000 { + compatible = "rockchip,rk3288-pmu-sram", "mmio-sram"; + reg = <0xff720000 0x1000>; + }; + + - | // Allwinner's A80 SoC uses part of the secure sram for hotplugging of the // primary core (cpu0). Once the core gets powered up it checks if a magic // value is set at a specific location. If it is then the BROM will jump
diff --git a/Documentation/devicetree/bindings/submitting-patches.rst b/Documentation/devicetree/bindings/submitting-patches.rst new file mode 100644 index 0000000..0aab2b3 --- /dev/null +++ b/Documentation/devicetree/bindings/submitting-patches.rst
@@ -0,0 +1,91 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================================== +Submitting devicetree (DT) binding patches +========================================== + +I. For patch submitters +======================= + + 0) Normal patch submission rules from Documentation/process/submitting-patches.rst + applies. + + 1) The Documentation/ and include/dt-bindings/ portion of the patch should + be a separate patch. The preferred subject prefix for binding patches is:: + + "dt-bindings: <binding dir>: ..." + + The 80 characters of the subject are precious. It is recommended to not + use "Documentation" or "doc" because that is implied. All bindings are + docs. Repeating "binding" again should also be avoided. + + 2) DT binding files are written in DT schema format using json-schema + vocabulary and YAML file format. The DT binding files must pass validation + by running:: + + make dt_binding_check + + See ../writing-schema.rst for more details about schema and tools setup. + + 3) DT binding files should be dual licensed. The preferred license tag is + (GPL-2.0-only OR BSD-2-Clause). + + 4) Submit the entire series to the devicetree mailinglist at + + devicetree@vger.kernel.org + + and Cc: the DT maintainers. Use scripts/get_maintainer.pl to identify + all of the DT maintainers. + + 5) The Documentation/ portion of the patch should come in the series before + the code implementing the binding. + + 6) Any compatible strings used in a chip or board DTS file must be + previously documented in the corresponding DT binding text file + in Documentation/devicetree/bindings. This rule applies even if + the Linux device driver does not yet match on the compatible + string. [ checkpatch will emit warnings if this step is not + followed as of commit bff5da4335256513497cc8c79f9a9d1665e09864 + ("checkpatch: add DT compatible string documentation checks"). ] + + 7) The wildcard "<chip>" may be used in compatible strings, as in + the following example: + + - compatible: Must contain '"nvidia,<chip>-pcie", + "nvidia,tegra20-pcie"' where <chip> is tegra30, tegra132, ... + + As in the above example, the known values of "<chip>" should be + documented if it is used. + + 8) If a documented compatible string is not yet matched by the + driver, the documentation should also include a compatible + string that is matched by the driver (as in the "nvidia,tegra20-pcie" + example above). + + +II. For kernel maintainers +========================== + + 1) If you aren't comfortable reviewing a given binding, reply to it and ask + the devicetree maintainers for guidance. This will help them prioritize + which ones to review and which ones are ok to let go. + + 2) For driver (not subsystem) bindings: If you are comfortable with the + binding, and it hasn't received an Acked-by from the devicetree + maintainers after a few weeks, go ahead and take it. + + Subsystem bindings (anything affecting more than a single device) + then getting a devicetree maintainer to review it is required. + + 3) For a series going though multiple trees, the binding patch should be + kept with the driver using the binding. + +III. Notes +========== + + 0) Please see ...bindings/ABI.txt for details regarding devicetree ABI. + + 1) This document is intended as a general familiarization with the process as + decided at the 2013 Kernel Summit. When in doubt, the current word of the + devicetree maintainers overrules this document. In that situation, a patch + updating this document would be appreciated.
diff --git a/Documentation/devicetree/bindings/submitting-patches.txt b/Documentation/devicetree/bindings/submitting-patches.txt deleted file mode 100644 index 98bee62..0000000 --- a/Documentation/devicetree/bindings/submitting-patches.txt +++ /dev/null
@@ -1,85 +0,0 @@ - - Submitting devicetree (DT) binding patches - -I. For patch submitters - - 0) Normal patch submission rules from Documentation/process/submitting-patches.rst - applies. - - 1) The Documentation/ and include/dt-bindings/ portion of the patch should - be a separate patch. The preferred subject prefix for binding patches is: - - "dt-bindings: <binding dir>: ..." - - The 80 characters of the subject are precious. It is recommended to not - use "Documentation" or "doc" because that is implied. All bindings are - docs. Repeating "binding" again should also be avoided. - - 2) DT binding files are written in DT schema format using json-schema - vocabulary and YAML file format. The DT binding files must pass validation - by running: - - make dt_binding_check - - See ../writing-schema.rst for more details about schema and tools setup. - - 3) DT binding files should be dual licensed. The preferred license tag is - (GPL-2.0-only OR BSD-2-Clause). - - 4) Submit the entire series to the devicetree mailinglist at - - devicetree@vger.kernel.org - - and Cc: the DT maintainers. Use scripts/get_maintainer.pl to identify - all of the DT maintainers. - - 5) The Documentation/ portion of the patch should come in the series before - the code implementing the binding. - - 6) Any compatible strings used in a chip or board DTS file must be - previously documented in the corresponding DT binding text file - in Documentation/devicetree/bindings. This rule applies even if - the Linux device driver does not yet match on the compatible - string. [ checkpatch will emit warnings if this step is not - followed as of commit bff5da4335256513497cc8c79f9a9d1665e09864 - ("checkpatch: add DT compatible string documentation checks"). ] - - 7) The wildcard "<chip>" may be used in compatible strings, as in - the following example: - - - compatible: Must contain '"nvidia,<chip>-pcie", - "nvidia,tegra20-pcie"' where <chip> is tegra30, tegra132, ... - - As in the above example, the known values of "<chip>" should be - documented if it is used. - - 8) If a documented compatible string is not yet matched by the - driver, the documentation should also include a compatible - string that is matched by the driver (as in the "nvidia,tegra20-pcie" - example above). - - -II. For kernel maintainers - - 1) If you aren't comfortable reviewing a given binding, reply to it and ask - the devicetree maintainers for guidance. This will help them prioritize - which ones to review and which ones are ok to let go. - - 2) For driver (not subsystem) bindings: If you are comfortable with the - binding, and it hasn't received an Acked-by from the devicetree - maintainers after a few weeks, go ahead and take it. - - Subsystem bindings (anything affecting more than a single device) - then getting a devicetree maintainer to review it is required. - - 3) For a series going though multiple trees, the binding patch should be - kept with the driver using the binding. - -III. Notes - - 0) Please see ...bindings/ABI.txt for details regarding devicetree ABI. - - 1) This document is intended as a general familiarization with the process as - decided at the 2013 Kernel Summit. When in doubt, the current word of the - devicetree maintainers overrules this document. In that situation, a patch - updating this document would be appreciated.
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml index e43ec50..999c6b3 100644 --- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -13,11 +13,11 @@ properties: compatible: - items: - - enum: - - amlogic,g12a-cpu-thermal - - amlogic,g12a-ddr-thermal - - const: amlogic,g12a-thermal + items: + - enum: + - amlogic,g12a-cpu-thermal + - amlogic,g12a-ddr-thermal + - const: amlogic,g12a-thermal reg: maxItems: 1
diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.txt b/Documentation/devicetree/bindings/thermal/imx-thermal.txt deleted file mode 100644 index 823e4176..0000000 --- a/Documentation/devicetree/bindings/thermal/imx-thermal.txt +++ /dev/null
@@ -1,61 +0,0 @@ -* Temperature Monitor (TEMPMON) on Freescale i.MX SoCs - -Required properties: -- compatible : must be one of following: - - "fsl,imx6q-tempmon" for i.MX6Q, - - "fsl,imx6sx-tempmon" for i.MX6SX, - - "fsl,imx7d-tempmon" for i.MX7S/D. -- interrupts : the interrupt output of the controller: - i.MX6Q has one IRQ which will be triggered when temperature is higher than high threshold, - i.MX6SX and i.MX7S/D have two more IRQs than i.MX6Q, one is IRQ_LOW and the other is IRQ_PANIC, - when temperature is below than low threshold, IRQ_LOW will be triggered, when temperature - is higher than panic threshold, system will auto reboot by SRC module. -- fsl,tempmon : phandle pointer to system controller that contains TEMPMON - control registers, e.g. ANATOP on imx6q. -- nvmem-cells: A phandle to the calibration cells provided by ocotp. -- nvmem-cell-names: Should be "calib", "temp_grade". - -Deprecated properties: -- fsl,tempmon-data : phandle pointer to fuse controller that contains TEMPMON - calibration data, e.g. OCOTP on imx6q. The details about calibration data - can be found in SoC Reference Manual. - -Direct access to OCOTP via fsl,tempmon-data is incorrect on some newer chips -because it does not handle OCOTP clock requirements. - -Optional properties: -- clocks : thermal sensor's clock source. - -Example: -ocotp: ocotp@21bc000 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,imx6sx-ocotp", "syscon"; - reg = <0x021bc000 0x4000>; - clocks = <&clks IMX6SX_CLK_OCOTP>; - - tempmon_calib: calib@38 { - reg = <0x38 4>; - }; - - tempmon_temp_grade: temp-grade@20 { - reg = <0x20 4>; - }; -}; - -tempmon: tempmon { - compatible = "fsl,imx6sx-tempmon", "fsl,imx6q-tempmon"; - interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; - fsl,tempmon = <&anatop>; - nvmem-cells = <&tempmon_calib>, <&tempmon_temp_grade>; - nvmem-cell-names = "calib", "temp_grade"; - clocks = <&clks IMX6SX_CLK_PLL3_USB_OTG>; -}; - -Legacy method (Deprecated): -tempmon { - compatible = "fsl,imx6q-tempmon"; - fsl,tempmon = <&anatop>; - fsl,tempmon-data = <&ocotp>; - clocks = <&clks 172>; -};
diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml new file mode 100644 index 0000000..aedac16 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
@@ -0,0 +1,102 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/imx-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX Thermal Binding + +maintainers: + - Shawn Guo <shawn.guo@linaro.org> + - Anson Huang <Anson.Huang@nxp.com> + +properties: + compatible: + enum: + - fsl,imx6q-tempmon + - fsl,imx6sx-tempmon + - fsl,imx7d-tempmon + + interrupts: + description: | + The interrupt output of the controller, i.MX6Q has IRQ_HIGH which + will be triggered when temperature is higher than high threshold, + i.MX6SX and i.MX7S/D have two more IRQs than i.MX6Q, one is IRQ_LOW + and the other is IRQ_PANIC, when temperature is lower than low + threshold, IRQ_LOW will be triggered, when temperature is higher + than panic threshold, IRQ_PANIC will be triggered, and system can + be configured to auto reboot by SRC module for IRQ_PANIC. IRQ_HIGH, + IRQ_LOW and IRQ_PANIC share same interrupt output of controller. + maxItems: 1 + + nvmem-cells: + items: + - description: Phandle to the calibration data provided by ocotp + - description: Phandle to the temperature grade provided by ocotp + + nvmem-cell-names: + items: + - const: calib + - const: temp_grade + + fsl,tempmon: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: Phandle to anatop system controller node. + + fsl,tempmon-data: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: | + Deprecated property, phandle pointer to fuse controller that contains + TEMPMON calibration data, e.g. OCOTP on imx6q. The details about + calibration data can be found in SoC Reference Manual. + deprecated: true + + clocks: + maxItems: 1 + +required: + - compatible + - interrupts + - fsl,tempmon + - nvmem-cells + - nvmem-cell-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx6sx-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + efuse@21bc000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,imx6sx-ocotp", "syscon"; + reg = <0x021bc000 0x4000>; + clocks = <&clks IMX6SX_CLK_OCOTP>; + + tempmon_calib: calib@38 { + reg = <0x38 4>; + }; + + tempmon_temp_grade: temp-grade@20 { + reg = <0x20 4>; + }; + }; + + anatop@20c8000 { + compatible = "fsl,imx6q-anatop", "syscon", "simple-mfd"; + reg = <0x020c8000 0x1000>; + interrupts = <0 49 IRQ_TYPE_LEVEL_HIGH>, + <0 54 IRQ_TYPE_LEVEL_HIGH>, + <0 127 IRQ_TYPE_LEVEL_HIGH>; + + tempmon { + compatible = "fsl,imx6sx-tempmon"; + interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; + fsl,tempmon = <&anatop>; + nvmem-cells = <&tempmon_calib>, <&tempmon_temp_grade>; + nvmem-cell-names = "calib", "temp_grade"; + clocks = <&clks IMX6SX_CLK_PLL3_USB_OTG>; + }; + };
diff --git a/Documentation/devicetree/bindings/thermal/imx8mm-thermal.txt b/Documentation/devicetree/bindings/thermal/imx8mm-thermal.txt deleted file mode 100644 index 3629d3c..0000000 --- a/Documentation/devicetree/bindings/thermal/imx8mm-thermal.txt +++ /dev/null
@@ -1,15 +0,0 @@ -* Thermal Monitoring Unit (TMU) on Freescale i.MX8MM SoC - -Required properties: -- compatible : Must be "fsl,imx8mm-tmu" or "fsl,imx8mp-tmu". -- reg : Address range of TMU registers. -- clocks : TMU's clock source. -- #thermal-sensor-cells : Should be 0 or 1. See ./thermal.txt for a description. - -Example: -tmu: tmu@30260000 { - compatible = "fsl,imx8mm-tmu"; - reg = <0x30260000 0x10000>; - clocks = <&clk IMX8MM_CLK_TMU_ROOT>; - #thermal-sensor-cells = <0>; -};
diff --git a/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml b/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml new file mode 100644 index 0000000..3885287 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
@@ -0,0 +1,58 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/imx8mm-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8M Mini Thermal Binding + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +description: | + i.MX8MM has TMU IP to allow temperature measurement, there are + currently two distinct major versions of the IP that is supported + by a single driver. The IP versions are named v1 and v2, v1 is + for i.MX8MM which has ONLY 1 sensor, v2 is for i.MX8MP which has + 2 sensors. + +properties: + compatible: + enum: + - fsl,imx8mm-tmu + - fsl,imx8mp-tmu + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + "#thermal-sensor-cells": + description: | + Number of cells required to uniquely identify the thermal + sensors, 0 for ONLY one sensor and 1 for multiple sensors. + enum: + - 0 + - 1 + +required: + - compatible + - reg + - clocks + - '#thermal-sensor-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mm-clock.h> + + thermal-sensor@30260000 { + compatible = "fsl,imx8mm-tmu"; + reg = <0x30260000 0x10000>; + clocks = <&clk IMX8MM_CLK_TMU_ROOT>; + #thermal-sensor-cells = <0>; + }; + +...
diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 2ddd39d..d7be931 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
@@ -73,12 +73,11 @@ - const: calib_sel "#qcom,sensors": - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - minimum: 1 - - maximum: 16 description: Number of sensors enabled on this platform + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 16 "#thermal-sensor-cells": const: 1
diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt deleted file mode 100644 index 2993fa7..0000000 --- a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt +++ /dev/null
@@ -1,60 +0,0 @@ -* DT bindings for Renesas R-Car Gen3 Thermal Sensor driver - -On R-Car Gen3 SoCs, the thermal sensor controllers (TSC) control the thermal -sensors (THS) which are the analog circuits for measuring temperature (Tj) -inside the LSI. - -Required properties: -- compatible : "renesas,<soctype>-thermal", - Examples with soctypes are: - - "renesas,r8a774a1-thermal" (RZ/G2M) - - "renesas,r8a774b1-thermal" (RZ/G2N) - - "renesas,r8a7795-thermal" (R-Car H3) - - "renesas,r8a7796-thermal" (R-Car M3-W) - - "renesas,r8a77961-thermal" (R-Car M3-W+) - - "renesas,r8a77965-thermal" (R-Car M3-N) - - "renesas,r8a77980-thermal" (R-Car V3H) -- reg : Address ranges of the thermal registers. Each sensor - needs one address range. Sorting must be done in - increasing order according to datasheet, i.e. - TSC1, TSC2, ... -- clocks : Must contain a reference to the functional clock. -- #thermal-sensor-cells : must be <1>. - -Optional properties: - -- interrupts : interrupts routed to the TSC (must be 3). -- power-domain : Must contain a reference to the power domain. This - property is mandatory if the thermal sensor instance - is part of a controllable power domain. - -Example: - - tsc: thermal@e6198000 { - compatible = "renesas,r8a7795-thermal"; - reg = <0 0xe6198000 0 0x100>, - <0 0xe61a0000 0 0x100>, - <0 0xe61a8000 0 0x100>; - interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 522>; - power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; - #thermal-sensor-cells = <1>; - }; - - thermal-zones { - sensor_thermal1: sensor-thermal1 { - polling-delay-passive = <250>; - polling-delay = <1000>; - thermal-sensors = <&tsc 0>; - - trips { - sensor1_crit: sensor1-crit { - temperature = <90000>; - hysteresis = <2000>; - type = "critical"; - }; - }; - }; - };
diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml new file mode 100644 index 0000000..b1a55ae --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
@@ -0,0 +1,99 @@ +# SPDX-License-Identifier: GPL-2.0-only +# Copyright (C) 2020 Renesas Electronics Corp. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/rcar-gen3-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car Gen3 Thermal Sensor + +description: + On R-Car Gen3 SoCs, the thermal sensor controllers (TSC) control the thermal + sensors (THS) which are the analog circuits for measuring temperature (Tj) + inside the LSI. + +maintainers: + - Niklas Söderlund <niklas.soderlund@ragnatech.se> + +properties: + compatible: + enum: + - renesas,r8a774a1-thermal # RZ/G2M + - renesas,r8a774b1-thermal # RZ/G2N + - renesas,r8a7795-thermal # R-Car H3 + - renesas,r8a7796-thermal # R-Car M3-W + - renesas,r8a77961-thermal # R-Car M3-W+ + - renesas,r8a77965-thermal # R-Car M3-N + - renesas,r8a77980-thermal # R-Car V3H + reg: + minItems: 2 + maxItems: 3 + items: + - description: TSC1 registers + - description: TSC2 registers + - description: TSC3 registers + + interrupts: + items: + - description: TEMP1 interrupt + - description: TEMP2 interrupt + - description: TEMP3 interrupt + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + "#thermal-sensor-cells": + const: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - resets + - "#thermal-sensor-cells" + +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> + + tsc: thermal@e6198000 { + compatible = "renesas,r8a7795-thermal"; + reg = <0xe6198000 0x100>, + <0xe61a0000 0x100>, + <0xe61a8000 0x100>; + interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 522>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 522>; + #thermal-sensor-cells = <1>; + }; + + thermal-zones { + sensor_thermal: sensor-thermal { + polling-delay-passive = <250>; + polling-delay = <1000>; + thermal-sensors = <&tsc 0>; + + trips { + sensor1_crit: sensor1-crit { + temperature = <90000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml b/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml index d2f4f1b..0994693 100644 --- a/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml
@@ -20,6 +20,7 @@ - const: renesas,rcar-thermal # Generic without thermal-zone - items: - enum: + - renesas,thermal-r8a7742 # RZ/G1H - renesas,thermal-r8a7743 # RZ/G1M - renesas,thermal-r8a7744 # RZ/G1N - const: renesas,rcar-gen2-thermal # Generic thermal-zone @@ -94,8 +95,8 @@ thermal@e61f0000 { compatible = "renesas,thermal-r8a73a4", "renesas,rcar-thermal"; - reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>, - <0 0xe61f0200 0 0x38>, <0 0xe61f0300 0 0x38>; + reg = <0xe61f0000 0x14>, <0xe61f0100 0x38>, + <0xe61f0200 0x38>, <0xe61f0300 0x38>; interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; clocks = <&mstp5_clks R8A73A4_CLK_THERMAL>; power-domains = <&pd_c5>; @@ -111,7 +112,7 @@ compatible = "renesas,thermal-r8a7790", "renesas,rcar-gen2-thermal", "renesas,rcar-thermal"; - reg = <0 0xe61f0000 0 0x10>, <0 0xe61f0100 0 0x38>; + reg = <0xe61f0000 0x10>, <0xe61f0100 0x38>; interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 522>; power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
diff --git a/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml new file mode 100644 index 0000000..553c9dc --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
@@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/socionext,uniphier-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier thermal monitor + +description: | + This describes the devicetree bindings for thermal monitor supported by + PVT(Process, Voltage and Temperature) monitoring unit implemented on + Socionext UniPhier SoCs. + +maintainers: + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> + +properties: + compatible: + enum: + - socionext,uniphier-pxs2-thermal + - socionext,uniphier-ld20-thermal + - socionext,uniphier-pxs3-thermal + + interrupts: + maxItems: 1 + + "#thermal-sensor-cells": + const: 0 + + socionext,tmod-calibration: + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 2 + description: + A pair of calibrated values referred from PVT, in case that the values + aren't set on SoC, like a reference board. + +required: + - compatible + - interrupts + - "#thermal-sensor-cells" + +additionalProperties: false + +examples: + - | + // The UniPhier thermal should be a subnode of a "syscon" compatible node. + + sysctrl@61840000 { + compatible = "socionext,uniphier-ld20-sysctrl", + "simple-mfd", "syscon"; + reg = <0x61840000 0x10000>; + + pvtctl: thermal { + compatible = "socionext,uniphier-ld20-thermal"; + interrupts = <0 3 1>; + #thermal-sensor-cells = <0>; + }; + };
diff --git a/Documentation/devicetree/bindings/thermal/sprd-thermal.yaml b/Documentation/devicetree/bindings/thermal/sprd-thermal.yaml index 058c4cc..af2ff93 100644 --- a/Documentation/devicetree/bindings/thermal/sprd-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/sprd-thermal.yaml
@@ -83,7 +83,7 @@ - | ap_thm0: thermal@32200000 { compatible = "sprd,ums512-thermal"; - reg = <0 0x32200000 0 0x10000>; + reg = <0x32200000 0x10000>; clock-names = "enable"; clocks = <&aonapb_gate 32>; #thermal-sensor-cells = <1>;
diff --git a/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml b/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml new file mode 100644 index 0000000..5145883 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
@@ -0,0 +1,116 @@ +# SPDX-License-Identifier: (GPL-2.0) +# Copyright 2020 Linaro Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/thermal-cooling-devices.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Thermal cooling device binding + +maintainers: + - Amit Kucheria <amitk@kernel.org> + +description: | + Thermal management is achieved in devicetree by describing the sensor hardware + and the software abstraction of cooling devices and thermal zones required to + take appropriate action to mitigate thermal overload. + + The following node types are used to completely describe a thermal management + system in devicetree: + - thermal-sensor: device that measures temperature, has SoC-specific bindings + - cooling-device: device used to dissipate heat either passively or actively + - thermal-zones: a container of the following node types used to describe all + thermal data for the platform + + This binding describes the cooling devices. + + There are essentially two ways to provide control on power dissipation: + - Passive cooling: by means of regulating device performance. A typical + passive cooling mechanism is a CPU that has dynamic voltage and frequency + scaling (DVFS), and uses lower frequencies as cooling states. + - Active cooling: by means of activating devices in order to remove the + dissipated heat, e.g. regulating fan speeds. + + Any cooling device has a range of cooling states (i.e. different levels of + heat dissipation). They also have a way to determine the state of cooling in + which the device is. For example, a fan's cooling states correspond to the + different fan speeds possible. Cooling states are referred to by single + unsigned integers, where larger numbers mean greater heat dissipation. The + precise set of cooling states associated with a device should be defined in + a particular device's binding. + +select: true + +properties: + "#cooling-cells": + description: + Must be 2, in order to specify minimum and maximum cooling state used in + the cooling-maps reference. The first cell is the minimum cooling state + and the second cell is the maximum cooling state requested. + const: 2 + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/thermal/thermal.h> + + // Example 1: Cpufreq cooling device on CPU0 + cpus { + #address-cells = <2>; + #size-cells = <0>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x0>; + enable-method = "psci"; + cpu-idle-states = <&LITTLE_CPU_SLEEP_0 + &LITTLE_CPU_SLEEP_1 + &CLUSTER_SLEEP_0>; + capacity-dmips-mhz = <607>; + dynamic-power-coefficient = <100>; + qcom,freq-domain = <&cpufreq_hw 0>; + #cooling-cells = <2>; + next-level-cache = <&L2_0>; + L2_0: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + L3_0: l3-cache { + compatible = "cache"; + }; + }; + }; + + /* ... */ + + }; + + /* ... */ + + thermal-zones { + cpu0-thermal { + polling-delay-passive = <250>; + polling-delay = <1000>; + + thermal-sensors = <&tsens0 1>; + + trips { + cpu0_alert0: trip-point0 { + temperature = <90000>; + hysteresis = <2000>; + type = "passive"; + }; + }; + + cooling-maps { + map0 { + trip = <&cpu0_alert0>; + /* Corresponds to 1000MHz in OPP table */ + cooling-device = <&CPU0 5 5>; + }; + }; + }; + + /* ... */ + }; +...
diff --git a/Documentation/devicetree/bindings/thermal/thermal-idle.yaml b/Documentation/devicetree/bindings/thermal/thermal-idle.yaml new file mode 100644 index 0000000..7a922f5 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/thermal-idle.yaml
@@ -0,0 +1,145 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2020 Linaro Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/thermal-idle.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Thermal idle cooling device binding + +maintainers: + - Daniel Lezcano <daniel.lezcano@linaro.org> + +description: | + The thermal idle cooling device allows the system to passively + mitigate the temperature on the device by injecting idle cycles, + forcing it to cool down. + + This binding describes the thermal idle node. + +properties: + $nodename: + const: thermal-idle + description: | + A thermal-idle node describes the idle cooling device properties to + cool down efficiently the attached thermal zone. + + '#cooling-cells': + const: 2 + description: | + Must be 2, in order to specify minimum and maximum cooling state used in + the cooling-maps reference. The first cell is the minimum cooling state + and the second cell is the maximum cooling state requested. + + duration-us: + description: | + The idle duration in microsecond the device should cool down. + + exit-latency-us: + description: | + The exit latency constraint in microsecond for the injected + idle state for the device. It is the latency constraint to + apply when selecting an idle state from among all the present + ones. + +required: + - '#cooling-cells' + +examples: + - | + #include <dt-bindings/thermal/thermal.h> + + // Example: Combining idle cooling device on big CPUs with cpufreq cooling device + cpus { + #address-cells = <2>; + #size-cells = <0>; + + /* ... */ + + cpu_b0: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a72"; + reg = <0x0 0x100>; + enable-method = "psci"; + capacity-dmips-mhz = <1024>; + dynamic-power-coefficient = <436>; + #cooling-cells = <2>; /* min followed by max */ + cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>; + thermal-idle { + #cooling-cells = <2>; + duration-us = <10000>; + exit-latency-us = <500>; + }; + }; + + cpu_b1: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a72"; + reg = <0x0 0x101>; + enable-method = "psci"; + capacity-dmips-mhz = <1024>; + dynamic-power-coefficient = <436>; + #cooling-cells = <2>; /* min followed by max */ + cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>; + thermal-idle { + #cooling-cells = <2>; + duration-us = <10000>; + exit-latency-us = <500>; + }; + }; + + /* ... */ + + }; + + /* ... */ + + thermal_zones { + cpu_thermal: cpu { + polling-delay-passive = <100>; + polling-delay = <1000>; + + /* ... */ + + trips { + cpu_alert0: cpu_alert0 { + temperature = <65000>; + hysteresis = <2000>; + type = "passive"; + }; + + cpu_alert1: cpu_alert1 { + temperature = <70000>; + hysteresis = <2000>; + type = "passive"; + }; + + cpu_alert2: cpu_alert2 { + temperature = <75000>; + hysteresis = <2000>; + type = "passive"; + }; + + cpu_crit: cpu_crit { + temperature = <95000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + + cooling-maps { + map0 { + trip = <&cpu_alert1>; + cooling-device = <&{/cpus/cpu@100/thermal-idle} 0 15 >, + <&{/cpus/cpu@101/thermal-idle} 0 15>; + }; + + map1 { + trip = <&cpu_alert2>; + cooling-device = + <&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu_b1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/thermal/thermal-sensor.yaml b/Documentation/devicetree/bindings/thermal/thermal-sensor.yaml new file mode 100644 index 0000000..fcd25a0 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/thermal-sensor.yaml
@@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0) +# Copyright 2020 Linaro Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/thermal-sensor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Thermal sensor binding + +maintainers: + - Amit Kucheria <amitk@kernel.org> + +description: | + Thermal management is achieved in devicetree by describing the sensor hardware + and the software abstraction of thermal zones required to take appropriate + action to mitigate thermal overloads. + + The following node types are used to completely describe a thermal management + system in devicetree: + - thermal-sensor: device that measures temperature, has SoC-specific bindings + - cooling-device: device used to dissipate heat either passively or actively + - thermal-zones: a container of the following node types used to describe all + thermal data for the platform + + This binding describes the thermal-sensor. + + Thermal sensor devices provide temperature sensing capabilities on thermal + zones. Typical devices are I2C ADC converters and bandgaps. Thermal sensor + devices may control one or more internal sensors. + +properties: + "#thermal-sensor-cells": + description: + Used to uniquely identify a thermal sensor instance within an IC. Will be + 0 on sensor nodes with only a single sensor and at least 1 on nodes + containing several internal sensors. + enum: [0, 1] + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + // Example 1: SDM845 TSENS + soc: soc@0 { + #address-cells = <2>; + #size-cells = <2>; + + /* ... */ + + tsens0: thermal-sensor@c263000 { + compatible = "qcom,sdm845-tsens", "qcom,tsens-v2"; + reg = <0 0x0c263000 0 0x1ff>, /* TM */ + <0 0x0c222000 0 0x1ff>; /* SROT */ + #qcom,sensors = <13>; + interrupts = <GIC_SPI 506 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 508 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "uplow", "critical"; + #thermal-sensor-cells = <1>; + }; + + tsens1: thermal-sensor@c265000 { + compatible = "qcom,sdm845-tsens", "qcom,tsens-v2"; + reg = <0 0x0c265000 0 0x1ff>, /* TM */ + <0 0x0c223000 0 0x1ff>; /* SROT */ + #qcom,sensors = <8>; + interrupts = <GIC_SPI 507 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 509 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "uplow", "critical"; + #thermal-sensor-cells = <1>; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml new file mode 100644 index 0000000..b8515d3 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
@@ -0,0 +1,341 @@ +# SPDX-License-Identifier: (GPL-2.0) +# Copyright 2020 Linaro Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/thermal-zones.yaml# +$schema: http://devicetree.org/meta-schemas/base.yaml# + +title: Thermal zone binding + +maintainers: + - Amit Kucheria <amitk@kernel.org> + +description: | + Thermal management is achieved in devicetree by describing the sensor hardware + and the software abstraction of cooling devices and thermal zones required to + take appropriate action to mitigate thermal overloads. + + The following node types are used to completely describe a thermal management + system in devicetree: + - thermal-sensor: device that measures temperature, has SoC-specific bindings + - cooling-device: device used to dissipate heat either passively or actively + - thermal-zones: a container of the following node types used to describe all + thermal data for the platform + + This binding describes the thermal-zones. + + The polling-delay properties of a thermal-zone are bound to the maximum dT/dt + (temperature derivative over time) in two situations for a thermal zone: + 1. when passive cooling is activated (polling-delay-passive) + 2. when the zone just needs to be monitored (polling-delay) or when + active cooling is activated. + + The maximum dT/dt is highly bound to hardware power consumption and + dissipation capability. The delays should be chosen to account for said + max dT/dt, such that a device does not cross several trip boundaries + unexpectedly between polls. Choosing the right polling delays shall avoid + having the device in temperature ranges that may damage the silicon structures + and reduce silicon lifetime. + +properties: + $nodename: + const: thermal-zones + description: + A /thermal-zones node is required in order to use the thermal framework to + manage input from the various thermal zones in the system in order to + mitigate thermal overload conditions. It does not represent a real device + in the system, but acts as a container to link a thermal sensor device, + platform-data regarding temperature thresholds and the mitigation actions + to take when the temperature crosses those thresholds. + +patternProperties: + "^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$": + type: object + description: + Each thermal zone node contains information about how frequently it + must be checked, the sensor responsible for reporting temperature for + this zone, one sub-node containing the various trip points for this + zone and one sub-node containing all the zone cooling-maps. + + properties: + polling-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The maximum number of milliseconds to wait between polls when + checking this thermal zone. Setting this to 0 disables the polling + timers setup by the thermal framework and assumes that the thermal + sensors in this zone support interrupts. + + polling-delay-passive: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The maximum number of milliseconds to wait between polls when + checking this thermal zone while doing passive cooling. Setting + this to 0 disables the polling timers setup by the thermal + framework and assumes that the thermal sensors in this zone + support interrupts. + + thermal-sensors: + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + description: + The thermal sensor phandle and sensor specifier used to monitor this + thermal zone. + + coefficients: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + An array of integers containing the coefficients of a linear equation + that binds all the sensors listed in this thermal zone. + + The linear equation used is as follows, + z = c0 * x0 + c1 * x1 + ... + c(n-1) * x(n-1) + cn + where c0, c1, .., cn are the coefficients. + + Coefficients default to 1 in case this property is not specified. The + coefficients are ordered and are matched with sensors by means of the + sensor ID. Additional coefficients are interpreted as constant offset. + + sustainable-power: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + An estimate of the sustainable power (in mW) that this thermal zone + can dissipate at the desired control temperature. For reference, the + sustainable power of a 4-inch phone is typically 2000mW, while on a + 10-inch tablet is around 4500mW. + + trips: + type: object + description: + This node describes a set of points in the temperature domain at + which the thermal framework needs to take action. The actions to + be taken are defined in another node called cooling-maps. + + patternProperties: + "^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$": + type: object + + properties: + temperature: + $ref: /schemas/types.yaml#/definitions/int32 + minimum: -273000 + maximum: 200000 + description: + An integer expressing the trip temperature in millicelsius. + + hysteresis: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + An unsigned integer expressing the hysteresis delta with + respect to the trip temperature property above, also in + millicelsius. Any cooling action initiated by the framework is + maintained until the temperature falls below + (trip temperature - hysteresis). This potentially prevents a + situation where the trip gets constantly triggered soon after + cooling action is removed. + + type: + $ref: /schemas/types.yaml#/definitions/string + enum: + - active # enable active cooling e.g. fans + - passive # enable passive cooling e.g. throttling cpu + - hot # send notification to driver + - critical # send notification to driver, trigger shutdown + description: | + There are four valid trip types: active, passive, hot, + critical. + + The critical trip type is used to set the maximum + temperature threshold above which the HW becomes + unstable and underlying firmware might even trigger a + reboot. Hitting the critical threshold triggers a system + shutdown. + + The hot trip type can be used to send a notification to + the thermal driver (if a .notify callback is registered). + The action to be taken is left to the driver. + + The passive trip type can be used to slow down HW e.g. run + the CPU, GPU, bus at a lower frequency. + + The active trip type can be used to control other HW to + help in cooling e.g. fans can be sped up or slowed down + + required: + - temperature + - hysteresis + - type + additionalProperties: false + + additionalProperties: false + + cooling-maps: + type: object + description: + This node describes the action to be taken when a thermal zone + crosses one of the temperature thresholds described in the trips + node. The action takes the form of a mapping relation between a + trip and the target cooling device state. + + patternProperties: + "^map[-a-zA-Z0-9]*$": + type: object + + properties: + trip: + $ref: /schemas/types.yaml#/definitions/phandle + description: + A phandle of a trip point node within this thermal zone. + + cooling-device: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + A list of cooling device phandles along with the minimum + and maximum cooling state specifiers for each cooling + device. Using the THERMAL_NO_LIMIT (-1UL) constant in the + cooling-device phandle limit specifier lets the framework + use the minimum and maximum cooling state for that cooling + device automatically. + + contribution: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 100 + description: + The percentage contribution of the cooling devices at the + specific trip temperature referenced in this map + to this thermal zone + + required: + - trip + - cooling-device + additionalProperties: false + + required: + - polling-delay + - polling-delay-passive + - thermal-sensors + - trips + additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/thermal/thermal.h> + + // Example 1: SDM845 TSENS + soc: soc@0 { + #address-cells = <2>; + #size-cells = <2>; + + /* ... */ + + tsens0: thermal-sensor@c263000 { + compatible = "qcom,sdm845-tsens", "qcom,tsens-v2"; + reg = <0 0x0c263000 0 0x1ff>, /* TM */ + <0 0x0c222000 0 0x1ff>; /* SROT */ + #qcom,sensors = <13>; + interrupts = <GIC_SPI 506 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 508 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "uplow", "critical"; + #thermal-sensor-cells = <1>; + }; + + tsens1: thermal-sensor@c265000 { + compatible = "qcom,sdm845-tsens", "qcom,tsens-v2"; + reg = <0 0x0c265000 0 0x1ff>, /* TM */ + <0 0x0c223000 0 0x1ff>; /* SROT */ + #qcom,sensors = <8>; + interrupts = <GIC_SPI 507 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 509 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "uplow", "critical"; + #thermal-sensor-cells = <1>; + }; + }; + + /* ... */ + + thermal-zones { + cpu0-thermal { + polling-delay-passive = <250>; + polling-delay = <1000>; + + thermal-sensors = <&tsens0 1>; + + trips { + cpu0_alert0: trip-point0 { + temperature = <90000>; + hysteresis = <2000>; + type = "passive"; + }; + + cpu0_alert1: trip-point1 { + temperature = <95000>; + hysteresis = <2000>; + type = "passive"; + }; + + cpu0_crit: cpu_crit { + temperature = <110000>; + hysteresis = <1000>; + type = "critical"; + }; + }; + + cooling-maps { + map0 { + trip = <&cpu0_alert0>; + /* Corresponds to 1400MHz in OPP table */ + cooling-device = <&CPU0 3 3>, <&CPU1 3 3>, + <&CPU2 3 3>, <&CPU3 3 3>; + }; + + map1 { + trip = <&cpu0_alert1>; + /* Corresponds to 1000MHz in OPP table */ + cooling-device = <&CPU0 5 5>, <&CPU1 5 5>, + <&CPU2 5 5>, <&CPU3 5 5>; + }; + }; + }; + + /* ... */ + + cluster0-thermal { + polling-delay-passive = <250>; + polling-delay = <1000>; + + thermal-sensors = <&tsens0 5>; + + trips { + cluster0_alert0: trip-point0 { + temperature = <90000>; + hysteresis = <2000>; + type = "hot"; + }; + cluster0_crit: cluster0_crit { + temperature = <110000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + /* ... */ + + gpu-top-thermal { + polling-delay-passive = <250>; + polling-delay = <1000>; + + thermal-sensors = <&tsens0 11>; + + trips { + gpu1_alert0: trip-point0 { + temperature = <90000>; + hysteresis = <2000>; + type = "hot"; + }; + }; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/thermal/ti,am654-thermal.yaml b/Documentation/devicetree/bindings/thermal/ti,am654-thermal.yaml new file mode 100644 index 0000000..25b9209 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/ti,am654-thermal.yaml
@@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/ti,am654-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments AM654 VTM (DTS) binding + +maintainers: + - Keerthy <j-keerthy@ti.com> + +properties: + compatible: + const: ti,am654-vtm + + reg: + maxItems: 1 + + power-domains: + maxItems: 1 + + "#thermal-sensor-cells": + const: 1 + +required: + - compatible + - reg + - power-domains + - "#thermal-sensor-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/soc/ti,sci_pm_domain.h> + vtm: thermal@42050000 { + compatible = "ti,am654-vtm"; + reg = <0x0 0x42050000 0x0 0x25c>; + power-domains = <&k3_pds 80 TI_SCI_PD_EXCLUSIVE>; + #thermal-sensor-cells = <1>; + }; + + mpu0_thermal: mpu0_thermal { + polling-delay-passive = <250>; /* milliseconds */ + polling-delay = <500>; /* milliseconds */ + thermal-sensors = <&vtm0 0>; + + trips { + mpu0_crit: mpu0_crit { + temperature = <125000>; /* milliCelsius */ + hysteresis = <2000>; /* milliCelsius */ + type = "critical"; + }; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/thermal/uniphier-thermal.txt b/Documentation/devicetree/bindings/thermal/uniphier-thermal.txt deleted file mode 100644 index ceb92a9..0000000 --- a/Documentation/devicetree/bindings/thermal/uniphier-thermal.txt +++ /dev/null
@@ -1,65 +0,0 @@ -* UniPhier Thermal bindings - -This describes the devicetree bindings for thermal monitor supported by -PVT(Process, Voltage and Temperature) monitoring unit implemented on Socionext -UniPhier SoCs. - -Required properties: -- compatible : - - "socionext,uniphier-pxs2-thermal" : For UniPhier PXs2 SoC - - "socionext,uniphier-ld20-thermal" : For UniPhier LD20 SoC - - "socionext,uniphier-pxs3-thermal" : For UniPhier PXs3 SoC -- interrupts : IRQ for the temperature alarm -- #thermal-sensor-cells : Should be 0. See ./thermal.txt for details. - -Optional properties: -- socionext,tmod-calibration: A pair of calibrated values referred from PVT, - in case that the values aren't set on SoC, - like a reference board. - -Example: - - sysctrl@61840000 { - compatible = "socionext,uniphier-ld20-sysctrl", - "simple-mfd", "syscon"; - reg = <0x61840000 0x10000>; - ... - pvtctl: pvtctl { - compatible = "socionext,uniphier-ld20-thermal"; - interrupts = <0 3 1>; - #thermal-sensor-cells = <0>; - }; - ... - }; - - thermal-zones { - cpu_thermal { - polling-delay-passive = <250>; /* 250ms */ - polling-delay = <1000>; /* 1000ms */ - thermal-sensors = <&pvtctl>; - - trips { - cpu_crit: cpu_crit { - temperature = <110000>; /* 110C */ - hysteresis = <2000>; - type = "critical"; - }; - cpu_alert: cpu_alert { - temperature = <100000>; /* 100C */ - hysteresis = <2000>; - type = "passive"; - }; - }; - - cooling-maps { - map0 { - trip = <&cpu_alert>; - cooling-device = <&cpu0 (-1) (-1)>; - }; - map1 { - trip = <&cpu_alert>; - cooling-device = <&cpu2 (-1) (-1)>; - }; - }; - }; - };
diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml index fa25567..2c75105 100644 --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
@@ -28,10 +28,10 @@ - arm,armv7-timer - items: - enum: - - arm,armv7-timer + - arm,armv7-timer - items: - enum: - - arm,armv8-timer + - arm,armv8-timer interrupts: items: @@ -51,6 +51,12 @@ description: If present, the timer is powered through an always-on power domain, therefore it never loses context. + allwinner,erratum-unknown1: + type: boolean + description: Indicates the presence of an erratum found in Allwinner SoCs, + where reading certain values from the counter is unreliable. This also + affects writes to the tval register, due to the implicit counter read. + fsl,erratum-a008585: type: boolean description: Indicates the presence of QorIQ erratum A-008585, which says
diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml index 582bbef..d83a1f9 100644 --- a/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml
@@ -20,7 +20,7 @@ compatible: items: - enum: - - arm,armv7-timer-mem + - arm,armv7-timer-mem reg: maxItems: 1 @@ -65,10 +65,9 @@ description: A timer node has up to 8 frame sub-nodes, each with the following properties. properties: frame-number: - allOf: - - $ref: "/schemas/types.yaml#/definitions/uint32" - - minimum: 0 - maximum: 7 + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 7 interrupts: minItems: 1 @@ -77,7 +76,7 @@ - description: physical timer irq - description: virtual timer irq - reg : + reg: minItems: 1 maxItems: 2 items:
diff --git a/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt b/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt deleted file mode 100644 index eeee6cd..0000000 --- a/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt +++ /dev/null
@@ -1,21 +0,0 @@ -Cadence TTC - Triple Timer Counter - -Required properties: -- compatible : Should be "cdns,ttc". -- reg : Specifies base physical address and size of the registers. -- interrupts : A list of 3 interrupts; one per timer channel. -- clocks: phandle to the source clock - -Optional properties: -- timer-width: Bit width of the timer, necessary if not 16. - -Example: - -ttc0: ttc0@f8001000 { - interrupt-parent = <&intc>; - interrupts = < 0 10 4 0 11 4 0 12 4 >; - compatible = "cdns,ttc"; - reg = <0xF8001000 0x1000>; - clocks = <&cpu_clk 3>; - timer-width = <32>; -};
diff --git a/Documentation/devicetree/bindings/timer/cdns,ttc.yaml b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml new file mode 100644 index 0000000..c532b60 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml
@@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/cdns,ttc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence TTC - Triple Timer Counter + +maintainers: + - Michal Simek <michal.simek@xilinx.com> + +properties: + compatible: + const: cdns,ttc + + reg: + maxItems: 1 + + interrupts: + minItems: 3 + maxItems: 3 + description: | + A list of 3 interrupts; one per timer channel. + + clocks: + maxItems: 1 + + timer-width: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: | + Bit width of the timer, necessary if not 16. + +required: + - compatible + - reg + - interrupts + - clocks + +examples: + - | + ttc0: ttc0@f8001000 { + interrupt-parent = <&intc>; + interrupts = <0 10 4>, <0 11 4>, <0 12 4>; + compatible = "cdns,ttc"; + reg = <0xF8001000 0x1000>; + clocks = <&cpu_clk 3>; + timer-width = <32>; + };
diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt deleted file mode 100644 index 5d8fd5b..0000000 --- a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt +++ /dev/null
@@ -1,45 +0,0 @@ -Freescale i.MX General Purpose Timer (GPT) - -Required properties: - -- compatible : should be one of following: - for i.MX1: - - "fsl,imx1-gpt"; - for i.MX21: - - "fsl,imx21-gpt"; - for i.MX27: - - "fsl,imx27-gpt", "fsl,imx21-gpt"; - for i.MX31: - - "fsl,imx31-gpt"; - for i.MX25: - - "fsl,imx25-gpt", "fsl,imx31-gpt"; - for i.MX50: - - "fsl,imx50-gpt", "fsl,imx31-gpt"; - for i.MX51: - - "fsl,imx51-gpt", "fsl,imx31-gpt"; - for i.MX53: - - "fsl,imx53-gpt", "fsl,imx31-gpt"; - for i.MX6Q: - - "fsl,imx6q-gpt", "fsl,imx31-gpt"; - for i.MX6DL: - - "fsl,imx6dl-gpt"; - for i.MX6SL: - - "fsl,imx6sl-gpt", "fsl,imx6dl-gpt"; - for i.MX6SX: - - "fsl,imx6sx-gpt", "fsl,imx6dl-gpt"; -- reg : specifies base physical address and size of the registers. -- interrupts : should be the gpt interrupt. -- clocks : the clocks provided by the SoC to drive the timer, must contain - an entry for each entry in clock-names. -- clock-names : must include "ipg" entry first, then "per" entry. - -Example: - -gpt1: timer@10003000 { - compatible = "fsl,imx27-gpt", "fsl,imx21-gpt"; - reg = <0x10003000 0x1000>; - interrupts = <26>; - clocks = <&clks IMX27_CLK_GPT1_IPG_GATE>, - <&clks IMX27_CLK_PER1_GATE>; - clock-names = "ipg", "per"; -};
diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml new file mode 100644 index 0000000..883f7f4 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
@@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/fsl,imxgpt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX General Purpose Timer (GPT) + +maintainers: + - Sascha Hauer <s.hauer@pengutronix.de> + +properties: + compatible: + oneOf: + - const: fsl,imx1-gpt + - const: fsl,imx21-gpt + - items: + - const: fsl,imx27-gpt + - const: fsl,imx21-gpt + - const: fsl,imx31-gpt + - items: + - enum: + - fsl,imx25-gpt + - fsl,imx50-gpt + - fsl,imx51-gpt + - fsl,imx53-gpt + - fsl,imx6q-gpt + - const: fsl,imx31-gpt + - const: fsl,imx6dl-gpt + - items: + - enum: + - fsl,imx6sl-gpt + - fsl,imx6sx-gpt + - const: fsl,imx6dl-gpt + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: SoC GPT ipg clock + - description: SoC GPT per clock + + clock-names: + items: + - const: ipg + - const: per + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx27-clock.h> + + timer@10003000 { + compatible = "fsl,imx27-gpt", "fsl,imx21-gpt"; + reg = <0x10003000 0x1000>; + interrupts = <26>; + clocks = <&clks IMX27_CLK_GPT1_IPG_GATE>, + <&clks IMX27_CLK_PER1_GATE>; + clock-names = "ipg", "per"; + };
diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.txt b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt deleted file mode 100644 index 91f7049..0000000 --- a/Documentation/devicetree/bindings/timer/ingenic,tcu.txt +++ /dev/null
@@ -1,138 +0,0 @@ -Ingenic JZ47xx SoCs Timer/Counter Unit devicetree bindings -========================================================== - -For a description of the TCU hardware and drivers, have a look at -Documentation/mips/ingenic-tcu.rst. - -Required properties: - -- compatible: Must be one of: - * ingenic,jz4740-tcu - * ingenic,jz4725b-tcu - * ingenic,jz4770-tcu - * ingenic,x1000-tcu - followed by "simple-mfd". -- reg: Should be the offset/length value corresponding to the TCU registers -- clocks: List of phandle & clock specifiers for clocks external to the TCU. - The "pclk", "rtc" and "ext" clocks should be provided. The "tcu" clock - should be provided if the SoC has it. -- clock-names: List of name strings for the external clocks. -- #clock-cells: Should be <1>; - Clock consumers specify this argument to identify a clock. The valid values - may be found in <dt-bindings/clock/ingenic,tcu.h>. -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. The value should be 1. -- interrupts : Specifies the interrupt the controller is connected to. - -Optional properties: - -- ingenic,pwm-channels-mask: Bitmask of TCU channels reserved for PWM use. - Default value is 0xfc. - - -Children nodes -========================================================== - - -PWM node: ---------- - -Required properties: - -- compatible: Must be one of: - * ingenic,jz4740-pwm - * ingenic,jz4725b-pwm -- #pwm-cells: Should be 3. See ../pwm/pwm.yaml for a description of the cell - format. -- clocks: List of phandle & clock specifiers for the TCU clocks. -- clock-names: List of name strings for the TCU clocks. - - -Watchdog node: --------------- - -Required properties: - -- compatible: Must be "ingenic,jz4740-watchdog" -- clocks: phandle to the WDT clock -- clock-names: should be "wdt" - - -OS Timer node: ---------- - -Required properties: - -- compatible: Must be one of: - * ingenic,jz4725b-ost - * ingenic,jz4770-ost -- clocks: phandle to the OST clock -- clock-names: should be "ost" -- interrupts : Specifies the interrupt the OST is connected to. - - -Example -========================================================== - -#include <dt-bindings/clock/jz4770-cgu.h> -#include <dt-bindings/clock/ingenic,tcu.h> - -/ { - tcu: timer@10002000 { - compatible = "ingenic,jz4770-tcu", "simple-mfd"; - reg = <0x10002000 0x1000>; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0x0 0x10002000 0x1000>; - - #clock-cells = <1>; - - clocks = <&cgu JZ4770_CLK_RTC - &cgu JZ4770_CLK_EXT - &cgu JZ4770_CLK_PCLK>; - clock-names = "rtc", "ext", "pclk"; - - interrupt-controller; - #interrupt-cells = <1>; - - interrupt-parent = <&intc>; - interrupts = <27 26 25>; - - watchdog: watchdog@0 { - compatible = "ingenic,jz4740-watchdog"; - reg = <0x0 0xc>; - - clocks = <&tcu TCU_CLK_WDT>; - clock-names = "wdt"; - }; - - pwm: pwm@40 { - compatible = "ingenic,jz4740-pwm"; - reg = <0x40 0x80>; - - #pwm-cells = <3>; - - clocks = <&tcu TCU_CLK_TIMER0 - &tcu TCU_CLK_TIMER1 - &tcu TCU_CLK_TIMER2 - &tcu TCU_CLK_TIMER3 - &tcu TCU_CLK_TIMER4 - &tcu TCU_CLK_TIMER5 - &tcu TCU_CLK_TIMER6 - &tcu TCU_CLK_TIMER7>; - clock-names = "timer0", "timer1", "timer2", "timer3", - "timer4", "timer5", "timer6", "timer7"; - }; - - ost: timer@e0 { - compatible = "ingenic,jz4770-ost"; - reg = <0xe0 0x20>; - - clocks = <&tcu TCU_CLK_OST>; - clock-names = "ost"; - - interrupts = <15>; - }; - }; -};
diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml new file mode 100644 index 0000000..03893e6 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml
@@ -0,0 +1,280 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/ingenic,tcu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs Timer/Counter Unit (TCU) devicetree bindings + +description: | + For a description of the TCU hardware and drivers, have a look at + Documentation/mips/ingenic-tcu.rst. + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +select: + properties: + compatible: + contains: + enum: + - ingenic,jz4740-tcu + - ingenic,jz4725b-tcu + - ingenic,jz4770-tcu + - ingenic,jz4780-tcu + - ingenic,x1000-tcu + required: + - compatible + +properties: + $nodename: + pattern: "^timer@[0-9a-f]+$" + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + "#clock-cells": + const: 1 + + "#interrupt-cells": + const: 1 + + interrupt-controller: true + + ranges: true + + compatible: + oneOf: + - items: + - enum: + - ingenic,jz4740-tcu + - ingenic,jz4725b-tcu + - ingenic,jz4770-tcu + - ingenic,x1000-tcu + - const: simple-mfd + - items: + - const: ingenic,jz4780-tcu + - const: ingenic,jz4770-tcu + - const: simple-mfd + + reg: + maxItems: 1 + + clocks: + items: + - description: RTC clock + - description: EXT clock + - description: PCLK clock + - description: TCU clock + minItems: 3 + + clock-names: + items: + - const: rtc + - const: ext + - const: pclk + - const: tcu + minItems: 3 + + interrupts: + items: + - description: TCU0 interrupt + - description: TCU1 interrupt + - description: TCU2 interrupt + minItems: 1 + + assigned-clocks: + minItems: 1 + maxItems: 8 + + assigned-clock-parents: + minItems: 1 + maxItems: 8 + + assigned-clock-rates: + minItems: 1 + maxItems: 8 + + ingenic,pwm-channels-mask: + description: Bitmask of TCU channels reserved for PWM use. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x00 + maximum: 0xff + default: 0xfc + +patternProperties: + "^watchdog@[a-f0-9]+$": + type: object + $ref: ../watchdog/watchdog.yaml# + properties: + compatible: + oneOf: + - enum: + - ingenic,jz4740-watchdog + - ingenic,jz4780-watchdog + - items: + - const: ingenic,jz4770-watchdog + - const: ingenic,jz4740-watchdog + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: wdt + + required: + - compatible + - reg + - clocks + - clock-names + + "^pwm@[a-f0-9]+$": + type: object + $ref: ../pwm/pwm.yaml# + properties: + compatible: + oneOf: + - enum: + - ingenic,jz4740-pwm + - items: + - enum: + - ingenic,jz4770-pwm + - ingenic,jz4780-pwm + - const: ingenic,jz4740-pwm + + reg: + maxItems: 1 + + clocks: + minItems: 6 + maxItems: 8 + + clock-names: + items: + - const: timer0 + - const: timer1 + - const: timer2 + - const: timer3 + - const: timer4 + - const: timer5 + - const: timer6 + - const: timer7 + minItems: 6 + + required: + - compatible + - reg + - clocks + - clock-names + + "^timer@[a-f0-9]+$": + type: object + properties: + compatible: + oneOf: + - enum: + - ingenic,jz4725b-ost + - ingenic,jz4770-ost + - items: + - const: ingenic,jz4780-ost + - const: ingenic,jz4770-ost + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: ost + + interrupts: + maxItems: 1 + + required: + - compatible + - reg + - clocks + - clock-names + - interrupts + + additionalProperties: false + +required: + - "#clock-cells" + - "#interrupt-cells" + - interrupt-controller + - compatible + - reg + - clocks + - clock-names + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/jz4770-cgu.h> + #include <dt-bindings/clock/ingenic,tcu.h> + tcu: timer@10002000 { + compatible = "ingenic,jz4770-tcu", "simple-mfd"; + reg = <0x10002000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x10002000 0x1000>; + + #clock-cells = <1>; + + clocks = <&cgu JZ4770_CLK_RTC>, + <&cgu JZ4770_CLK_EXT>, + <&cgu JZ4770_CLK_PCLK>; + clock-names = "rtc", "ext", "pclk"; + + interrupt-controller; + #interrupt-cells = <1>; + + interrupt-parent = <&intc>; + interrupts = <27 26 25>; + + watchdog: watchdog@0 { + compatible = "ingenic,jz4770-watchdog", "ingenic,jz4740-watchdog"; + reg = <0x0 0xc>; + + clocks = <&tcu TCU_CLK_WDT>; + clock-names = "wdt"; + }; + + pwm: pwm@40 { + compatible = "ingenic,jz4770-pwm", "ingenic,jz4740-pwm"; + reg = <0x40 0x80>; + + #pwm-cells = <3>; + + clocks = <&tcu TCU_CLK_TIMER0>, + <&tcu TCU_CLK_TIMER1>, + <&tcu TCU_CLK_TIMER2>, + <&tcu TCU_CLK_TIMER3>, + <&tcu TCU_CLK_TIMER4>, + <&tcu TCU_CLK_TIMER5>, + <&tcu TCU_CLK_TIMER6>, + <&tcu TCU_CLK_TIMER7>; + clock-names = "timer0", "timer1", "timer2", "timer3", + "timer4", "timer5", "timer6", "timer7"; + }; + + ost: timer@e0 { + compatible = "ingenic,jz4770-ost"; + reg = <0xe0 0x20>; + + clocks = <&tcu TCU_CLK_OST>; + clock-names = "ost"; + + interrupts = <15>; + }; + };
diff --git a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt deleted file mode 100644 index d576599..0000000 --- a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt +++ /dev/null
@@ -1,25 +0,0 @@ -NXP System Counter Module(sys_ctr) - -The system counter(sys_ctr) is a programmable system counter which provides -a shared time base to Cortex A15, A7, A53, A73, etc. it is intended for use in -applications where the counter is always powered and support multiple, -unrelated clocks. The compare frame inside can be used for timer purpose. - -Required properties: - -- compatible : should be "nxp,sysctr-timer" -- reg : Specifies the base physical address and size of the comapre - frame and the counter control, read & compare. -- interrupts : should be the first compare frames' interrupt -- clocks : Specifies the counter clock. -- clock-names: Specifies the clock's name of this module - -Example: - - system_counter: timer@306a0000 { - compatible = "nxp,sysctr-timer"; - reg = <0x306a0000 0x20000>;/* system-counter-rd & compare */ - clocks = <&clk_8m>; - clock-names = "per"; - interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>; - };
diff --git a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml new file mode 100644 index 0000000..830211c --- /dev/null +++ b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml
@@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/nxp,sysctr-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP System Counter Module(sys_ctr) + +maintainers: + - Bai Ping <ping.bai@nxp.com> + +description: | + The system counter(sys_ctr) is a programmable system counter + which provides a shared time base to Cortex A15, A7, A53, A73, + etc. it is intended for use in applications where the counter + is always powered and support multiple, unrelated clocks. The + compare frame inside can be used for timer purpose. + +properties: + compatible: + const: nxp,sysctr-timer + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: per + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + timer@306a0000 { + compatible = "nxp,sysctr-timer"; + reg = <0x306a0000 0x20000>; + clocks = <&clk_8m>; + clock-names = "per"; + interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>; + };
diff --git a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt deleted file mode 100644 index f82087b..0000000 --- a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt +++ /dev/null
@@ -1,28 +0,0 @@ -NXP Low Power Timer/Pulse Width Modulation Module (TPM) - -The Timer/PWM Module (TPM) supports input capture, output compare, -and the generation of PWM signals to control electric motor and power -management applications. The counter, compare and capture registers -are clocked by an asynchronous clock that can remain enabled in low -power modes. TPM can support global counter bus where one TPM drives -the counter bus for the others, provided bit width is the same. - -Required properties: - -- compatible : should be "fsl,imx7ulp-tpm" -- reg : Specifies base physical address and size of the register sets - for the clock event device and clock source device. -- interrupts : Should be the clock event device interrupt. -- clocks : The clocks provided by the SoC to drive the timer, must contain - an entry for each entry in clock-names. -- clock-names : Must include the following entries: "ipg" and "per". - -Example: -tpm5: tpm@40260000 { - compatible = "fsl,imx7ulp-tpm"; - reg = <0x40260000 0x1000>; - interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clks IMX7ULP_CLK_NIC1_BUS_DIV>, - <&clks IMX7ULP_CLK_LPTPM5>; - clock-names = "ipg", "per"; -};
diff --git a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml new file mode 100644 index 0000000..edd9585 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml
@@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/nxp,tpm-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Low Power Timer/Pulse Width Modulation Module (TPM) + +maintainers: + - Dong Aisheng <aisheng.dong@nxp.com> + +description: | + The Timer/PWM Module (TPM) supports input capture, output compare, + and the generation of PWM signals to control electric motor and power + management applications. The counter, compare and capture registers + are clocked by an asynchronous clock that can remain enabled in low + power modes. TPM can support global counter bus where one TPM drives + the counter bus for the others, provided bit width is the same. + +properties: + compatible: + const: fsl,imx7ulp-tpm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: SoC TPM ipg clock + - description: SoC TPM per clock + + clock-names: + items: + - const: ipg + - const: per + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx7ulp-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + timer@40260000 { + compatible = "fsl,imx7ulp-tpm"; + reg = <0x40260000 0x1000>; + interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, + <&pcc2 IMX7ULP_CLK_LPTPM5>; + clock-names = "ipg", "per"; + };
diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt b/Documentation/devicetree/bindings/timer/renesas,cmt.txt deleted file mode 100644 index a747fab..0000000 --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt +++ /dev/null
@@ -1,110 +0,0 @@ -* Renesas R-Car Compare Match Timer (CMT) - -The CMT is a multi-channel 16/32/48-bit timer/counter with configurable clock -inputs and programmable compare match. - -Channels share hardware resources but their counter and compare match value -are independent. A particular CMT instance can implement only a subset of the -channels supported by the CMT model. Channel indices represent the hardware -position of the channel in the CMT and don't match the channel numbers in the -datasheets. - -Required Properties: - - - compatible: must contain one or more of the following: - - "renesas,r8a73a4-cmt0" for the 32-bit CMT0 device included in r8a73a4. - - "renesas,r8a73a4-cmt1" for the 48-bit CMT1 device included in r8a73a4. - - "renesas,r8a7740-cmt0" for the 32-bit CMT0 device included in r8a7740. - - "renesas,r8a7740-cmt1" for the 48-bit CMT1 device included in r8a7740. - - "renesas,r8a7740-cmt2" for the 32-bit CMT2 device included in r8a7740. - - "renesas,r8a7740-cmt3" for the 32-bit CMT3 device included in r8a7740. - - "renesas,r8a7740-cmt4" for the 32-bit CMT4 device included in r8a7740. - - "renesas,r8a7743-cmt0" for the 32-bit CMT0 device included in r8a7743. - - "renesas,r8a7743-cmt1" for the 48-bit CMT1 device included in r8a7743. - - "renesas,r8a7744-cmt0" for the 32-bit CMT0 device included in r8a7744. - - "renesas,r8a7744-cmt1" for the 48-bit CMT1 device included in r8a7744. - - "renesas,r8a7745-cmt0" for the 32-bit CMT0 device included in r8a7745. - - "renesas,r8a7745-cmt1" for the 48-bit CMT1 device included in r8a7745. - - "renesas,r8a77470-cmt0" for the 32-bit CMT0 device included in r8a77470. - - "renesas,r8a77470-cmt1" for the 48-bit CMT1 device included in r8a77470. - - "renesas,r8a774a1-cmt0" for the 32-bit CMT0 device included in r8a774a1. - - "renesas,r8a774a1-cmt1" for the 48-bit CMT devices included in r8a774a1. - - "renesas,r8a774b1-cmt0" for the 32-bit CMT0 device included in r8a774b1. - - "renesas,r8a774b1-cmt1" for the 48-bit CMT devices included in r8a774b1. - - "renesas,r8a774c0-cmt0" for the 32-bit CMT0 device included in r8a774c0. - - "renesas,r8a774c0-cmt1" for the 48-bit CMT devices included in r8a774c0. - - "renesas,r8a7790-cmt0" for the 32-bit CMT0 device included in r8a7790. - - "renesas,r8a7790-cmt1" for the 48-bit CMT1 device included in r8a7790. - - "renesas,r8a7791-cmt0" for the 32-bit CMT0 device included in r8a7791. - - "renesas,r8a7791-cmt1" for the 48-bit CMT1 device included in r8a7791. - - "renesas,r8a7792-cmt0" for the 32-bit CMT0 device included in r8a7792. - - "renesas,r8a7792-cmt1" for the 48-bit CMT1 device included in r8a7792. - - "renesas,r8a7793-cmt0" for the 32-bit CMT0 device included in r8a7793. - - "renesas,r8a7793-cmt1" for the 48-bit CMT1 device included in r8a7793. - - "renesas,r8a7794-cmt0" for the 32-bit CMT0 device included in r8a7794. - - "renesas,r8a7794-cmt1" for the 48-bit CMT1 device included in r8a7794. - - "renesas,r8a7795-cmt0" for the 32-bit CMT0 device included in r8a7795. - - "renesas,r8a7795-cmt1" for the 48-bit CMT devices included in r8a7795. - - "renesas,r8a7796-cmt0" for the 32-bit CMT0 device included in r8a7796. - - "renesas,r8a7796-cmt1" for the 48-bit CMT devices included in r8a7796. - - "renesas,r8a77965-cmt0" for the 32-bit CMT0 device included in r8a77965. - - "renesas,r8a77965-cmt1" for the 48-bit CMT devices included in r8a77965. - - "renesas,r8a77970-cmt0" for the 32-bit CMT0 device included in r8a77970. - - "renesas,r8a77970-cmt1" for the 48-bit CMT devices included in r8a77970. - - "renesas,r8a77980-cmt0" for the 32-bit CMT0 device included in r8a77980. - - "renesas,r8a77980-cmt1" for the 48-bit CMT devices included in r8a77980. - - "renesas,r8a77990-cmt0" for the 32-bit CMT0 device included in r8a77990. - - "renesas,r8a77990-cmt1" for the 48-bit CMT devices included in r8a77990. - - "renesas,r8a77995-cmt0" for the 32-bit CMT0 device included in r8a77995. - - "renesas,r8a77995-cmt1" for the 48-bit CMT devices included in r8a77995. - - "renesas,sh73a0-cmt0" for the 32-bit CMT0 device included in sh73a0. - - "renesas,sh73a0-cmt1" for the 48-bit CMT1 device included in sh73a0. - - "renesas,sh73a0-cmt2" for the 32-bit CMT2 device included in sh73a0. - - "renesas,sh73a0-cmt3" for the 32-bit CMT3 device included in sh73a0. - - "renesas,sh73a0-cmt4" for the 32-bit CMT4 device included in sh73a0. - - - "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car Gen2 - and RZ/G1. - - "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car Gen2 - and RZ/G1. - These are fallbacks for r8a73a4, R-Car Gen2 and RZ/G1 entries - listed above. - - "renesas,rcar-gen3-cmt0" for 32-bit CMT0 devices included in R-Car Gen3 - and RZ/G2. - - "renesas,rcar-gen3-cmt1" for 48-bit CMT devices included in R-Car Gen3 - and RZ/G2. - These are fallbacks for R-Car Gen3 and RZ/G2 entries listed - above. - - - reg: base address and length of the registers block for the timer module. - - interrupts: interrupt-specifier for the timer, one per channel. - - clocks: a list of phandle + clock-specifier pairs, one for each entry - in clock-names. - - clock-names: must contain "fck" for the functional clock. - - -Example: R8A7790 (R-Car H2) CMT0 and CMT1 nodes - - cmt0: timer@ffca0000 { - compatible = "renesas,r8a7790-cmt0", "renesas,rcar-gen2-cmt0"; - reg = <0 0xffca0000 0 0x1004>; - interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>, - <0 142 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp1_clks R8A7790_CLK_CMT0>; - clock-names = "fck"; - }; - - cmt1: timer@e6130000 { - compatible = "renesas,r8a7790-cmt1", "renesas,rcar-gen2-cmt1"; - reg = <0 0xe6130000 0 0x1004>; - interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>, - <0 121 IRQ_TYPE_LEVEL_HIGH>, - <0 122 IRQ_TYPE_LEVEL_HIGH>, - <0 123 IRQ_TYPE_LEVEL_HIGH>, - <0 124 IRQ_TYPE_LEVEL_HIGH>, - <0 125 IRQ_TYPE_LEVEL_HIGH>, - <0 126 IRQ_TYPE_LEVEL_HIGH>, - <0 127 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp3_clks R8A7790_CLK_CMT1>; - clock-names = "fck"; - };
diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.yaml b/Documentation/devicetree/bindings/timer/renesas,cmt.yaml new file mode 100644 index 0000000..7e4dc56 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.yaml
@@ -0,0 +1,182 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/renesas,cmt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas Compare Match Timer (CMT) + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> + +description: + The CMT is a multi-channel 16/32/48-bit timer/counter with configurable clock + inputs and programmable compare match. + + Channels share hardware resources but their counter and compare match values + are independent. A particular CMT instance can implement only a subset of the + channels supported by the CMT model. Channel indices represent the hardware + position of the channel in the CMT and don't match the channel numbers in the + datasheets. + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,r8a7740-cmt0 # 32-bit CMT0 on R-Mobile A1 + - renesas,r8a7740-cmt1 # 48-bit CMT1 on R-Mobile A1 + - renesas,r8a7740-cmt2 # 32-bit CMT2 on R-Mobile A1 + - renesas,r8a7740-cmt3 # 32-bit CMT3 on R-Mobile A1 + - renesas,r8a7740-cmt4 # 32-bit CMT4 on R-Mobile A1 + - renesas,sh73a0-cmt0 # 32-bit CMT0 on SH-Mobile AG5 + - renesas,sh73a0-cmt1 # 48-bit CMT1 on SH-Mobile AG5 + - renesas,sh73a0-cmt2 # 32-bit CMT2 on SH-Mobile AG5 + - renesas,sh73a0-cmt3 # 32-bit CMT3 on SH-Mobile AG5 + - renesas,sh73a0-cmt4 # 32-bit CMT4 on SH-Mobile AG5 + + - items: + - enum: + - renesas,r8a73a4-cmt0 # 32-bit CMT0 on R-Mobile APE6 + - renesas,r8a7743-cmt0 # 32-bit CMT0 on RZ/G1M + - renesas,r8a7744-cmt0 # 32-bit CMT0 on RZ/G1N + - renesas,r8a7745-cmt0 # 32-bit CMT0 on RZ/G1E + - renesas,r8a77470-cmt0 # 32-bit CMT0 on RZ/G1C + - renesas,r8a7790-cmt0 # 32-bit CMT0 on R-Car H2 + - renesas,r8a7791-cmt0 # 32-bit CMT0 on R-Car M2-W + - renesas,r8a7792-cmt0 # 32-bit CMT0 on R-Car V2H + - renesas,r8a7793-cmt0 # 32-bit CMT0 on R-Car M2-N + - renesas,r8a7794-cmt0 # 32-bit CMT0 on R-Car E2 + - const: renesas,rcar-gen2-cmt0 # 32-bit CMT0 on R-Mobile APE6, R-Car Gen2 and RZ/G1 + + - items: + - enum: + - renesas,r8a73a4-cmt1 # 48-bit CMT1 on R-Mobile APE6 + - renesas,r8a7743-cmt1 # 48-bit CMT1 on RZ/G1M + - renesas,r8a7744-cmt1 # 48-bit CMT1 on RZ/G1N + - renesas,r8a7745-cmt1 # 48-bit CMT1 on RZ/G1E + - renesas,r8a77470-cmt1 # 48-bit CMT1 on RZ/G1C + - renesas,r8a7790-cmt1 # 48-bit CMT1 on R-Car H2 + - renesas,r8a7791-cmt1 # 48-bit CMT1 on R-Car M2-W + - renesas,r8a7792-cmt1 # 48-bit CMT1 on R-Car V2H + - renesas,r8a7793-cmt1 # 48-bit CMT1 on R-Car M2-N + - renesas,r8a7794-cmt1 # 48-bit CMT1 on R-Car E2 + - const: renesas,rcar-gen2-cmt1 # 48-bit CMT1 on R-Mobile APE6, R-Car Gen2 and RZ/G1 + + - items: + - enum: + - renesas,r8a774a1-cmt0 # 32-bit CMT0 on RZ/G2M + - renesas,r8a774b1-cmt0 # 32-bit CMT0 on RZ/G2N + - renesas,r8a774c0-cmt0 # 32-bit CMT0 on RZ/G2E + - renesas,r8a7795-cmt0 # 32-bit CMT0 on R-Car H3 + - renesas,r8a7796-cmt0 # 32-bit CMT0 on R-Car M3-W + - renesas,r8a77965-cmt0 # 32-bit CMT0 on R-Car M3-N + - renesas,r8a77970-cmt0 # 32-bit CMT0 on R-Car V3M + - renesas,r8a77980-cmt0 # 32-bit CMT0 on R-Car V3H + - renesas,r8a77990-cmt0 # 32-bit CMT0 on R-Car E3 + - renesas,r8a77995-cmt0 # 32-bit CMT0 on R-Car D3 + - const: renesas,rcar-gen3-cmt0 # 32-bit CMT0 on R-Car Gen3 and RZ/G2 + + - items: + - enum: + - renesas,r8a774a1-cmt1 # 48-bit CMT on RZ/G2M + - renesas,r8a774b1-cmt1 # 48-bit CMT on RZ/G2N + - renesas,r8a774c0-cmt1 # 48-bit CMT on RZ/G2E + - renesas,r8a7795-cmt1 # 48-bit CMT on R-Car H3 + - renesas,r8a7796-cmt1 # 48-bit CMT on R-Car M3-W + - renesas,r8a77965-cmt1 # 48-bit CMT on R-Car M3-N + - renesas,r8a77970-cmt1 # 48-bit CMT on R-Car V3M + - renesas,r8a77980-cmt1 # 48-bit CMT on R-Car V3H + - renesas,r8a77990-cmt1 # 48-bit CMT on R-Car E3 + - renesas,r8a77995-cmt1 # 48-bit CMT on R-Car D3 + - const: renesas,rcar-gen3-cmt1 # 48-bit CMT on R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 8 + + clocks: + maxItems: 1 + + clock-names: + const: fck + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + +allOf: + - if: + properties: + compatible: + contains: + enum: + - renesas,rcar-gen2-cmt0 + - renesas,rcar-gen3-cmt0 + then: + properties: + interrupts: + minItems: 2 + maxItems: 2 + + - if: + properties: + compatible: + contains: + enum: + - renesas,rcar-gen2-cmt1 + - renesas,rcar-gen3-cmt1 + then: + properties: + interrupts: + minItems: 8 + maxItems: 8 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7790-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7790-sysc.h> + cmt0: timer@ffca0000 { + compatible = "renesas,r8a7790-cmt0", "renesas,rcar-gen2-cmt0"; + reg = <0xffca0000 0x1004>; + interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 124>; + clock-names = "fck"; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 124>; + }; + + cmt1: timer@e6130000 { + compatible = "renesas,r8a7790-cmt1", "renesas,rcar-gen2-cmt1"; + reg = <0xe6130000 0x1004>; + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 329>; + clock-names = "fck"; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 329>; + };
diff --git a/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml b/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml new file mode 100644 index 0000000..233d74d --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml
@@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/renesas,em-sti.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas EMMA Mobile System Timer + +maintainers: + - Magnus Damm <magnus.damm@gmail.com> + +properties: + compatible: + const: renesas,em-sti + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: sclk + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + timer@e0180000 { + compatible = "renesas,em-sti"; + reg = <0xe0180000 0x54>; + interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&sti_sclk>; + clock-names = "sclk"; + };
diff --git a/Documentation/devicetree/bindings/timer/renesas,mtu2.txt b/Documentation/devicetree/bindings/timer/renesas,mtu2.txt deleted file mode 100644 index ba0a34d..0000000 --- a/Documentation/devicetree/bindings/timer/renesas,mtu2.txt +++ /dev/null
@@ -1,42 +0,0 @@ -* Renesas Multi-Function Timer Pulse Unit 2 (MTU2) - -The MTU2 is a multi-purpose, multi-channel timer/counter with configurable -clock inputs and programmable compare match. - -Channels share hardware resources but their counter and compare match value -are independent. The MTU2 hardware supports five channels indexed from 0 to 4. - -Required Properties: - - - compatible: must be one or more of the following: - - "renesas,mtu2-r7s72100" for the r7s72100 MTU2 - - "renesas,mtu2" for any MTU2 - This is a fallback for the above renesas,mtu2-* entries - - - reg: base address and length of the registers block for the timer module. - - - interrupts: interrupt specifiers for the timer, one for each entry in - interrupt-names. - - interrupt-names: must contain one entry named "tgi?a" for each enabled - channel, where "?" is the channel index expressed as one digit from "0" to - "4". - - - clocks: a list of phandle + clock-specifier pairs, one for each entry - in clock-names. - - clock-names: must contain "fck" for the functional clock. - - -Example: R7S72100 (RZ/A1H) MTU2 node - - mtu2: timer@fcff0000 { - compatible = "renesas,mtu2-r7s72100", "renesas,mtu2"; - reg = <0xfcff0000 0x400>; - interrupts = <0 139 IRQ_TYPE_LEVEL_HIGH>, - <0 146 IRQ_TYPE_LEVEL_HIGH>, - <0 150 IRQ_TYPE_LEVEL_HIGH>, - <0 154 IRQ_TYPE_LEVEL_HIGH>, - <0 159 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "tgi0a", "tgi1a", "tgi2a", "tgi3a", "tgi4a"; - clocks = <&mstp3_clks R7S72100_CLK_MTU2>; - clock-names = "fck"; - };
diff --git a/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml b/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml new file mode 100644 index 0000000..15d8ddd --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml
@@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/renesas,mtu2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas Multi-Function Timer Pulse Unit 2 (MTU2) + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> + +description: + The MTU2 is a multi-purpose, multi-channel timer/counter with configurable clock inputs + and programmable compare match. + + Channels share hardware resources but their counter and compare match value are + independent. The MTU2 hardware supports five channels indexed from 0 to 4. + +properties: + compatible: + items: + - enum: + - renesas,mtu2-r7s72100 # RZ/A1H + - const: renesas,mtu2 + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 5 + description: One entry for each enabled channel. + + interrupt-names: + minItems: 1 + items: + - const: tgi0a + - const: tgi1a + - const: tgi2a + - const: tgi3a + - const: tgi4a + + clocks: + maxItems: 1 + + clock-names: + const: fck + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r7s72100-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + mtu2: timer@fcff0000 { + compatible = "renesas,mtu2-r7s72100", "renesas,mtu2"; + reg = <0xfcff0000 0x400>; + interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "tgi0a"; + clocks = <&mstp3_clks R7S72100_CLK_MTU2>; + clock-names = "fck"; + power-domains = <&cpg_clocks>; + };
diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.txt b/Documentation/devicetree/bindings/timer/renesas,ostm.txt deleted file mode 100644 index 81a78f8..0000000 --- a/Documentation/devicetree/bindings/timer/renesas,ostm.txt +++ /dev/null
@@ -1,31 +0,0 @@ -* Renesas OS Timer (OSTM) - -The OSTM is a multi-channel 32-bit timer/counter with fixed clock -source that can operate in either interval count down timer or free-running -compare match mode. - -Channels are independent from each other. - -Required Properties: - - - compatible: must be one or more of the following: - - "renesas,r7s72100-ostm" for the R7S72100 (RZ/A1) OSTM - - "renesas,r7s9210-ostm" for the R7S9210 (RZ/A2) OSTM - - "renesas,ostm" for any OSTM - This is a fallback for the above renesas,*-ostm entries - - - reg: base address and length of the register block for a timer channel. - - - interrupts: interrupt specifier for the timer channel. - - - clocks: clock specifier for the timer channel. - -Example: R7S72100 (RZ/A1H) OSTM node - - ostm0: timer@fcfec000 { - compatible = "renesas,r7s72100-ostm", "renesas,ostm"; - reg = <0xfcfec000 0x30>; - interrupts = <GIC_SPI 102 IRQ_TYPE_EDGE_RISING>; - clocks = <&mstp5_clks R7S72100_CLK_OSTM0>; - power-domains = <&cpg_clocks>; - };
diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml new file mode 100644 index 0000000..600d47a --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml
@@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/renesas,ostm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas OS Timer (OSTM) + +maintainers: + - Chris Brandt <chris.brandt@renesas.com> + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: + The OSTM is a multi-channel 32-bit timer/counter with fixed clock source that + can operate in either interval count down timer or free-running compare match + mode. + + Channels are independent from each other. + +properties: + compatible: + items: + - enum: + - renesas,r7s72100-ostm # RZ/A1H + - renesas,r7s9210-ostm # RZ/A2M + - const: renesas,ostm # Generic + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r7s72100-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + ostm0: timer@fcfec000 { + compatible = "renesas,r7s72100-ostm", "renesas,ostm"; + reg = <0xfcfec000 0x30>; + interrupts = <GIC_SPI 102 IRQ_TYPE_EDGE_RISING>; + clocks = <&mstp5_clks R7S72100_CLK_OSTM0>; + power-domains = <&cpg_clocks>; + };
diff --git a/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml b/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml new file mode 100644 index 0000000..5d300ef --- /dev/null +++ b/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
@@ -0,0 +1,88 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/snps,dw-apb-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare APB Timer + +maintainers: + - Daniel Lezcano <daniel.lezcano@linaro.org> + +properties: + compatible: + oneOf: + - const: snps,dw-apb-timer + - enum: + - snps,dw-apb-timer-sp + - snps,dw-apb-timer-osc + deprecated: true + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + items: + - description: Timer ticks reference clock source + - description: APB interface clock source + + clock-names: + minItems: 1 + items: + - const: timer + - const: pclk + + clock-frequency: true + + clock-freq: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: | + Has the same meaning as the 'clock-frequency' property - timer clock + frequency in HZ, but is defined only for the backwards compatibility + with the picoxcell platform. + +unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + +oneOf: + - required: + - clocks + - clock-names + - required: + - clock-frequency + - required: + - clock-freq + +examples: + - | + timer@ffe00000 { + compatible = "snps,dw-apb-timer"; + interrupts = <0 170 4>; + reg = <0xffe00000 0x1000>; + clocks = <&timer_clk>, <&timer_pclk>; + clock-names = "timer", "pclk"; + }; + - | + timer@ffe00000 { + compatible = "snps,dw-apb-timer"; + interrupts = <0 170 4>; + reg = <0xffe00000 0x1000>; + clocks = <&timer_clk>; + clock-names = "timer"; + }; + - | + timer@ffe00000 { + compatible = "snps,dw-apb-timer"; + interrupts = <0 170 4>; + reg = <0xffe00000 0x1000>; + clock-frequency = <25000000>; + }; +...
diff --git a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml index c8a2a920..4d13e6b 100644 --- a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml
@@ -25,6 +25,20 @@ power-domains: maxItems: 1 + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + + "#address-cells": + const: 2 + + "#size-cells": + const: 2 + + ranges: true + required: - compatible - reg @@ -39,30 +53,39 @@ Documentation/devicetree/bindings/ufs/cdns,ufshc.txt for binding documentation of child node +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/interrupt-controller/arm-gic.h> - ufs_wrapper: ufs-wrapper@4e80000 { - compatible = "ti,j721e-ufs"; - reg = <0x0 0x4e80000 0x0 0x100>; - power-domains = <&k3_pds 277>; - clocks = <&k3_clks 277 1>; - assigned-clocks = <&k3_clks 277 1>; - assigned-clock-parents = <&k3_clks 277 4>; - #address-cells = <2>; - #size-cells = <2>; + bus { + #address-cells = <2>; + #size-cells = <2>; - ufs@4e84000 { - compatible = "cdns,ufshc-m31-16nm", "jedec,ufs-2.0"; - reg = <0x0 0x4e84000 0x0 0x10000>; - interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>; - freq-table-hz = <19200000 19200000>; - power-domains = <&k3_pds 277>; - clocks = <&k3_clks 277 1>; - assigned-clocks = <&k3_clks 277 1>; - assigned-clock-parents = <&k3_clks 277 4>; - clock-names = "core_clk"; - }; + ufs-wrapper@4e80000 { + compatible = "ti,j721e-ufs"; + reg = <0x0 0x4e80000 0x0 0x100>; + power-domains = <&k3_pds 277>; + clocks = <&k3_clks 277 1>; + assigned-clocks = <&k3_clks 277 1>; + assigned-clock-parents = <&k3_clks 277 4>; + + ranges = <0x0 0x0 0x0 0x4e80000 0x0 0x14000>; + #address-cells = <2>; + #size-cells = <2>; + + ufs@4000 { + compatible = "cdns,ufshc-m31-16nm", "jedec,ufs-2.0"; + reg = <0x0 0x4000 0x0 0x10000>; + interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>; + freq-table-hz = <19200000 19200000>; + power-domains = <&k3_pds 277>; + clocks = <&k3_clks 277 1>; + assigned-clocks = <&k3_clks 277 1>; + assigned-clock-parents = <&k3_clks 277 4>; + clock-names = "core_clk"; + }; + }; };
diff --git a/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt b/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt deleted file mode 100644 index 9a8b631..0000000 --- a/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt +++ /dev/null
@@ -1,42 +0,0 @@ -Amlogic Meson GX DWC3 USB SoC controller - -Required properties: -- compatible: depending on the SoC this should contain one of: - * amlogic,meson-axg-dwc3 - * amlogic,meson-gxl-dwc3 -- clocks: a handle for the "USB general" clock -- clock-names: must be "usb_general" -- resets: a handle for the shared "USB OTG" reset line -- reset-names: must be "usb_otg" - -Required child node: -A child node must exist to represent the core DWC3 IP block. The name of -the node is not important. The content of the node is defined in dwc3.txt. - -PHY documentation is provided in the following places: -- Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt -- Documentation/devicetree/bindings/phy/meson-gxl-usb3-phy.txt - -Example device nodes: - usb0: usb@ff500000 { - compatible = "amlogic,meson-axg-dwc3"; - #address-cells = <2>; - #size-cells = <2>; - ranges; - - clocks = <&clkc CLKID_USB>; - clock-names = "usb_general"; - resets = <&reset RESET_USB_OTG>; - reset-names = "usb_otg"; - - dwc3: dwc3@ff500000 { - compatible = "snps,dwc3"; - reg = <0x0 0xff500000 0x0 0x100000>; - interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; - dr_mode = "host"; - maximum-speed = "high-speed"; - snps,dis_u2_susphy_quirk; - phys = <&usb3_phy>, <&usb2_phy0>; - phy-names = "usb2-phy", "usb3-phy"; - }; - };
diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml index b0e5e0f..5b04a7d 100644 --- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml +++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
@@ -25,9 +25,13 @@ The Amlogic A1 embeds a DWC3 USB IP Core configured for USB2 in host-only mode. + The Amlogic GXL & GXM SoCs doesn't embed an USB3 PHY. + properties: compatible: enum: + - amlogic,meson-gxl-usb-ctrl + - amlogic,meson-gxm-usb-ctrl - amlogic,meson-g12a-usb-ctrl - amlogic,meson-a1-usb-ctrl @@ -41,6 +45,11 @@ clocks: minItems: 1 + maxItems: 3 + + clock-names: + minItems: 1 + maxItems: 3 resets: minItems: 1 @@ -52,10 +61,8 @@ maxItems: 1 phy-names: - items: - - const: usb2-phy0 # USB2 PHY0 if USBHOST_A port is used - - const: usb2-phy1 # USB2 PHY1 if USBOTG_B port is used - - const: usb3-phy0 # USB3 PHY if USB3_0 is used + minItems: 1 + maxItems: 3 phys: minItems: 1 @@ -93,10 +100,68 @@ properties: compatible: enum: + - amlogic,meson-g12a-usb-ctrl + + then: + properties: + phy-names: + items: + - const: usb2-phy0 # USB2 PHY0 if USBHOST_A port is used + - const: usb2-phy1 # USB2 PHY1 if USBOTG_B port is used + - const: usb3-phy0 # USB3 PHY if USB3_0 is used + - if: + properties: + compatible: + enum: + - amlogic,meson-gxl-usb-ctrl + + then: + properties: + clocks: + minItems: 2 + clock-names: + items: + - const: usb_ctrl + - const: ddr + phy-names: + items: + - const: usb2-phy0 # USB2 PHY0 if USBHOST_A port is used + - const: usb2-phy1 # USB2 PHY1 if USBOTG_B port is used + required: + - clock-names + - if: + properties: + compatible: + enum: + - amlogic,meson-gxm-usb-ctrl + + then: + properties: + clocks: + minItems: 2 + clock-names: + items: + - const: usb_ctrl + - const: ddr + phy-names: + items: + - const: usb2-phy0 # USB2 PHY0 if USBHOST_A port is used + - const: usb2-phy1 # USB2 PHY1 if USBOTG_B port is used + - const: usb2-phy2 # USB2 PHY2 if USBOTG_C port is used + + required: + - clock-names + - if: + properties: + compatible: + enum: - amlogic,meson-a1-usb-ctrl then: properties: + phy-names: + items: + - const: usb2-phy1 # USB2 PHY1 if USBOTG_B port is used clocks: minItems: 3 clock-names: @@ -111,7 +176,7 @@ - | usb: usb@ffe09000 { compatible = "amlogic,meson-g12a-usb-ctrl"; - reg = <0x0 0xffe09000 0x0 0xa0>; + reg = <0xffe09000 0xa0>; interrupts = <16>; #address-cells = <1>; #size-cells = <1>; @@ -147,4 +212,3 @@ snps,quirk-frame-length-adjustment; }; }; -
diff --git a/Documentation/devicetree/bindings/usb/aspeed,usb-vhub.yaml b/Documentation/devicetree/bindings/usb/aspeed,usb-vhub.yaml index 06399ba..e4e83d3 100644 --- a/Documentation/devicetree/bindings/usb/aspeed,usb-vhub.yaml +++ b/Documentation/devicetree/bindings/usb/aspeed,usb-vhub.yaml
@@ -38,19 +38,64 @@ aspeed,vhub-downstream-ports: description: Number of downstream ports supported by the Virtual Hub - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - default: 5 - minimum: 1 - maximum: 7 + $ref: /schemas/types.yaml#/definitions/uint32 + default: 5 + minimum: 1 + maximum: 7 aspeed,vhub-generic-endpoints: description: Number of generic endpoints supported by the Virtual Hub - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - default: 15 - minimum: 1 - maximum: 21 + $ref: /schemas/types.yaml#/definitions/uint32 + default: 15 + minimum: 1 + maximum: 21 + + vhub-vendor-id: + description: vhub Vendor ID + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 65535 + + vhub-product-id: + description: vhub Product ID + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 65535 + + vhub-device-revision: + description: vhub Device Revision in binary-coded decimal + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 65535 + + vhub-strings: + type: object + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + patternProperties: + '^string@[0-9a-f]+$': + type: object + description: string descriptors of the specific language + + properties: + reg: + maxItems: 1 + description: 16-bit Language Identifier defined by USB-IF + + manufacturer: + description: vhub manufacturer + $ref: /schemas/types.yaml#/definitions/string + + product: + description: vhub product name + $ref: /schemas/types.yaml#/definitions/string + + serial-number: + description: vhub device serial number + $ref: /schemas/types.yaml#/definitions/string required: - compatible @@ -74,4 +119,19 @@ aspeed,vhub-generic-endpoints = <15>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usb2ad_default>; + + vhub-vendor-id = <0x1d6b>; + vhub-product-id = <0x0107>; + vhub-device-revision = <0x0100>; + vhub-strings { + #address-cells = <1>; + #size-cells = <0>; + + string@0409 { + reg = <0x0409>; + manufacturer = "ASPEED"; + product = "USB Virtual Hub"; + serial-number = "0000"; + }; + }; };
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt index 44e8015..423b99a 100644 --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -88,13 +88,15 @@ - clock-names: Should contain two strings "pclk" for the peripheral clock "hclk" for the host clock + +Deprecated property: - ep childnode: To specify the number of endpoints and their properties. Optional properties: - atmel,vbus-gpio: If present, specifies a gpio that allows to detect whether vbus is present (USB is connected). -Required child node properties: +Deprecated child node properties: - name: Name of the endpoint. - reg: Num of the endpoint. - atmel,fifo-size: Size of the fifo. @@ -112,56 +114,4 @@ clocks = <&utmi>, <&udphs_clk>; clock-names = "hclk", "pclk"; atmel,vbus-gpio = <&pioB 19 0>; - - ep@0 { - reg = <0>; - atmel,fifo-size = <64>; - atmel,nb-banks = <1>; - }; - - ep@1 { - reg = <1>; - atmel,fifo-size = <1024>; - atmel,nb-banks = <2>; - atmel,can-dma; - atmel,can-isoc; - }; - - ep@2 { - reg = <2>; - atmel,fifo-size = <1024>; - atmel,nb-banks = <2>; - atmel,can-dma; - atmel,can-isoc; - }; - - ep@3 { - reg = <3>; - atmel,fifo-size = <1024>; - atmel,nb-banks = <3>; - atmel,can-dma; - }; - - ep@4 { - reg = <4>; - atmel,fifo-size = <1024>; - atmel,nb-banks = <3>; - atmel,can-dma; - }; - - ep@5 { - reg = <5>; - atmel,fifo-size = <1024>; - atmel,nb-banks = <3>; - atmel,can-dma; - atmel,can-isoc; - }; - - ep@6 { - reg = <6>; - atmel,fifo-size = <1024>; - atmel,nb-banks = <3>; - atmel,can-dma; - atmel,can-isoc; - }; };
diff --git a/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml b/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml new file mode 100644 index 0000000..2a9acf2 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml
@@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/brcm,bcm7445-ehci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom STB USB EHCI Controller Device Tree Bindings + +allOf: + - $ref: "usb-hcd.yaml" + +maintainers: + - Al Cooper <alcooperx@gmail.com> + +properties: + compatible: + const: brcm,bcm7445-ehci + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + description: Clock specifier for the EHCI clock + + clock-names: + const: sw_usb + + phys: + maxItems: 1 + + phy-names: + const: usbphy + +required: + - compatible + - reg + - interrupts + - phys + - clocks + +additionalProperties: false + +examples: + - | + usb@f0b00300 { + compatible = "brcm,bcm7445-ehci"; + reg = <0xf0b00300 0xa8>; + interrupts = <0x0 0x5a 0x0>; + phys = <&usbphy_0 0x0>; + phy-names = "usbphy"; + clocks = <&usb20>; + clock-names = "sw_usb"; + }; + +...
diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index 0d6d850..9352a8e 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml
@@ -62,14 +62,14 @@ resets: items: - - description: common reset - - description: ecc reset + - description: common reset + - description: ecc reset minItems: 1 reset-names: items: - - const: dwc2 - - const: dwc2-ecc + - const: dwc2 + - const: dwc2-ecc minItems: 1 phys: @@ -78,6 +78,9 @@ phy-names: const: usb2-phy + power-domains: + maxItems: 1 + vbus-supply: description: reference to the VBUS regulator. Depending on the current mode this is enabled (in "host" mode") or disabled (in "peripheral" mode). The
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 9946ff9..d03edf9 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -15,8 +15,6 @@ Exception for clocks: clocks are optional if the parent node (i.e. glue-layer) is compatible to one of the following: - "amlogic,meson-axg-dwc3" - "amlogic,meson-gxl-dwc3" "cavium,octeon-7130-usb-uctl" "qcom,dwc3" "samsung,exynos5250-dwusb3"
diff --git a/Documentation/devicetree/bindings/usb/ehci-mv.txt b/Documentation/devicetree/bindings/usb/ehci-mv.txt deleted file mode 100644 index 3355898..0000000 --- a/Documentation/devicetree/bindings/usb/ehci-mv.txt +++ /dev/null
@@ -1,23 +0,0 @@ -* Marvell PXA/MMP EHCI controller. - -Required properties: - -- compatible: must be "marvell,pxau2o-ehci" -- reg: physical base addresses of the controller and length of memory mapped region -- interrupts: one EHCI controller interrupt should be described here -- clocks: phandle list of usb clocks -- clock-names: should be "USBCLK" -- phys: phandle for the PHY device -- phy-names: should be "usb" - -Example: - - ehci0: usb-ehci@d4208000 { - compatible = "marvell,pxau2o-ehci"; - reg = <0xd4208000 0x200>; - interrupts = <44>; - clocks = <&soc_clocks MMP2_CLK_USB>; - clock-names = "USBCLK"; - phys = <&usb_otg_phy>; - phy-names = "usb"; - };
diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml index 10edd05..69f3f26 100644 --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
@@ -6,19 +6,30 @@ title: USB EHCI Controller Device Tree Bindings -allOf: - - $ref: "usb-hcd.yaml" - maintainers: - Greg Kroah-Hartman <gregkh@linuxfoundation.org> +allOf: + - $ref: "usb-hcd.yaml" + - if: + properties: + compatible: + not: + contains: + const: ibm,usb-ehci-440epx + then: + properties: + reg: + maxItems: 1 + properties: compatible: contains: const: generic-ehci reg: - maxItems: 1 + minItems: 1 + maxItems: 2 interrupts: maxItems: 1 @@ -36,6 +47,9 @@ - if a USB DRD channel: first clock should be host and second one should be peripheral + power-domains: + maxItems: 1 + big-endian: $ref: /schemas/types.yaml#/definitions/flag description: @@ -74,6 +88,9 @@ phy-names: const: usb + iommus: + maxItems: 1 + required: - compatible - reg @@ -87,7 +104,7 @@ compatible = "ibm,usb-ehci-440epx", "generic-ehci"; interrupt-parent = <&UIC0>; interrupts = <0x1a 4>; - reg = <0 0xe0000300 90 0 0xe0000390 70>; + reg = <0xe0000300 90>, <0xe0000390 70>; big-endian; };
diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml index bcffec1..2178bcc 100644 --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
@@ -36,6 +36,9 @@ - if a USB DRD channel: first clock should be host and second one should be peripheral + power-domains: + maxItems: 1 + big-endian: $ref: /schemas/types.yaml#/definitions/flag description: @@ -73,6 +76,9 @@ phy-names: const: usb + iommus: + maxItems: 1 + required: - compatible - reg
diff --git a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml index c2d2ee4..c334aea 100644 --- a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml +++ b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml
@@ -42,6 +42,9 @@ phys: description: PHY specifier for the USB PHY + usb-role-switch: + type: boolean + required: - compatible - reg
diff --git a/Documentation/devicetree/bindings/usb/keystone-usb.txt b/Documentation/devicetree/bindings/usb/keystone-usb.txt deleted file mode 100644 index 77df82e..0000000 --- a/Documentation/devicetree/bindings/usb/keystone-usb.txt +++ /dev/null
@@ -1,56 +0,0 @@ -TI Keystone Soc USB Controller - -DWC3 GLUE - -Required properties: - - compatible: should be - "ti,keystone-dwc3" for Keystone 2 SoCs - "ti,am654-dwc3" for AM654 SoC - - #address-cells, #size-cells : should be '1' if the device has sub-nodes - with 'reg' property. - - reg : Address and length of the register set for the USB subsystem on - the SOC. - - interrupts : The irq number of this device that is used to interrupt the - MPU. - - ranges: allows valid 1:1 translation between child's address space and - parent's address space. - -SoC-specific Required Properties: -The following are mandatory properties for Keystone 2 66AK2HK, 66AK2L and 66AK2E -SoCs only: - -- clocks: Clock ID for USB functional clock. -- clock-names: Must be "usb". - - -The following are mandatory properties for 66AK2G and AM654: - -- power-domains: Should contain a phandle to a PM domain provider node - and an args specifier containing the USB device id - value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt - -Sub-nodes: -The dwc3 core should be added as subnode to Keystone DWC3 glue. -- dwc3 : - The binding details of dwc3 can be found in: - Documentation/devicetree/bindings/usb/dwc3.txt - -Example: - usb: usb@2680000 { - compatible = "ti,keystone-dwc3"; - #address-cells = <1>; - #size-cells = <1>; - reg = <0x2680000 0x10000>; - clocks = <&clkusb>; - clock-names = "usb"; - interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>; - ranges; - - dwc3@2690000 { - compatible = "synopsys,dwc3"; - reg = <0x2690000 0x70000>; - interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>; - usb-phy = <&usb_phy>, <&usb_phy>; - }; - };
diff --git a/Documentation/devicetree/bindings/usb/marvell,pxau2o-ehci.yaml b/Documentation/devicetree/bindings/usb/marvell,pxau2o-ehci.yaml new file mode 100644 index 0000000..3cf93dd --- /dev/null +++ b/Documentation/devicetree/bindings/usb/marvell,pxau2o-ehci.yaml
@@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2019,2020 Lubomir Rintel <lkundrak@v3.sk> +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/marvell,pxau2o-ehci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell PXA/MMP EHCI bindings + +maintainers: + - Lubomir Rintel <lkundrak@v3.sk> + +allOf: + - $ref: usb-hcd.yaml# + +properties: + compatible: + const: marvell,pxau2o-ehci + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: USBCLK + + phys: + maxItems: 1 + + phy-names: + const: usb + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - phys + - phy-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/marvell,mmp2.h> + usb@d4208000 { + compatible = "marvell,pxau2o-ehci"; + reg = <0xd4208000 0x200>; + interrupts = <44>; + clocks = <&soc_clocks MMP2_CLK_USB>; + clock-names = "USBCLK"; + phys = <&usb_otg_phy>; + phy-names = "usb"; + }; + +...
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml index b84ed8ee..0073763 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml
@@ -21,6 +21,7 @@ - enum: - nvidia,tegra210-xudc # For Tegra210 - nvidia,tegra186-xudc # For Tegra186 + - nvidia,tegra194-xudc # For Tegra194 reg: minItems: 2 @@ -63,13 +64,11 @@ - const: hs_src power-domains: - maxItems: 2 items: - description: XUSBB(device) power-domain - description: XUSBA(superspeed) power-domain power-domain-names: - maxItems: 2 items: - const: dev - const: ss @@ -144,6 +143,7 @@ contains: enum: - nvidia,tegra186-xudc + - nvidia,tegra194-xudc then: properties: reg: @@ -163,9 +163,9 @@ usb@700d0000 { compatible = "nvidia,tegra210-xudc"; - reg = <0x0 0x700d0000 0x0 0x8000>, - <0x0 0x700d8000 0x0 0x1000>, - <0x0 0x700d9000 0x0 0x1000>; + reg = <0x700d0000 0x8000>, + <0x700d8000 0x1000>, + <0x700d9000 0x1000>; reg-names = "base", "fpci", "ipfs"; interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt deleted file mode 100644 index fbdd017..0000000 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt +++ /dev/null
@@ -1,104 +0,0 @@ -Qualcomm SuperSpeed DWC3 USB SoC controller - -Required properties: -- compatible: Compatible list, contains - "qcom,dwc3" - "qcom,msm8996-dwc3" for msm8996 SOC. - "qcom,msm8998-dwc3" for msm8998 SOC. - "qcom,sdm845-dwc3" for sdm845 SOC. -- reg: Offset and length of register set for QSCRATCH wrapper -- power-domains: specifies a phandle to PM domain provider node -- clocks: A list of phandle + clock-specifier pairs for the - clocks listed in clock-names -- clock-names: Should contain the following: - "core" Master/Core clock, have to be >= 125 MHz for SS - operation and >= 60MHz for HS operation - "mock_utmi" Mock utmi clock needed for ITP/SOF generation in - host mode. Its frequency should be 19.2MHz. - "sleep" Sleep clock, used for wakeup when USB3 core goes - into low power mode (U3). - -Optional clocks: - "iface" System bus AXI clock. - Not present on "qcom,msm8996-dwc3" compatible. - "cfg_noc" System Config NOC clock. - Not present on "qcom,msm8996-dwc3" compatible. -- assigned-clocks: Should be: - MOCK_UTMI_CLK - MASTER_CLK -- assigned-clock-rates: Should be: - 19.2Mhz (192000000) for MOCK_UTMI_CLK - >=125Mhz (125000000) for MASTER_CLK in SS mode - >=60Mhz (60000000) for MASTER_CLK in HS mode - -Optional properties: -- resets: Phandle to reset control that resets core and wrapper. -- interrupts: specifies interrupts from controller wrapper used - to wakeup from low power/susepnd state. Must contain - one or more entry for interrupt-names property -- interrupt-names: Must include the following entries: - - "hs_phy_irq": The interrupt that is asserted when a - wakeup event is received on USB2 bus - - "ss_phy_irq": The interrupt that is asserted when a - wakeup event is received on USB3 bus - - "dm_hs_phy_irq" and "dp_hs_phy_irq": Separate - interrupts for any wakeup event on DM and DP lines -- qcom,select-utmi-as-pipe-clk: if present, disable USB3 pipe_clk requirement. - Used when dwc3 operates without SSPHY and only - HS/FS/LS modes are supported. - -Required child node: -A child node must exist to represent the core DWC3 IP block. The name of -the node is not important. The content of the node is defined in dwc3.txt. - -Phy documentation is provided in the following places: -Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt - USB3 QMP PHY -Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml - USB2 QUSB2 PHY - -Example device nodes: - - hs_phy: phy@100f8800 { - compatible = "qcom,qusb2-v2-phy"; - ... - }; - - ss_phy: phy@100f8830 { - compatible = "qcom,qmp-v3-usb3-phy"; - ... - }; - - usb3_0: usb30@a6f8800 { - compatible = "qcom,dwc3"; - reg = <0xa6f8800 0x400>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - interrupts = <0 131 0>, <0 486 0>, <0 488 0>, <0 489 0>; - interrupt-names = "hs_phy_irq", "ss_phy_irq", - "dm_hs_phy_irq", "dp_hs_phy_irq"; - - clocks = <&gcc GCC_USB30_PRIM_MASTER_CLK>, - <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>, - <&gcc GCC_USB30_PRIM_SLEEP_CLK>; - clock-names = "core", "mock_utmi", "sleep"; - - assigned-clocks = <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>, - <&gcc GCC_USB30_PRIM_MASTER_CLK>; - assigned-clock-rates = <19200000>, <133000000>; - - resets = <&gcc GCC_USB30_PRIM_BCR>; - reset-names = "core_reset"; - power-domains = <&gcc USB30_PRIM_GDSC>; - qcom,select-utmi-as-pipe-clk; - - dwc3@10000000 { - compatible = "snps,dwc3"; - reg = <0x10000000 0xcd00>; - interrupts = <0 205 0x4>; - phys = <&hs_phy>, <&ss_phy>; - phy-names = "usb2-phy", "usb3-phy"; - dr_mode = "host"; - }; - }; -
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml new file mode 100644 index 0000000..dac1084 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -0,0 +1,174 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SuperSpeed DWC3 USB SoC controller + +maintainers: + - Manu Gautam <mgautam@codeaurora.org> + +properties: + compatible: + items: + - enum: + - qcom,msm8996-dwc3 + - qcom,msm8998-dwc3 + - qcom,sc7180-dwc3 + - qcom,sdm845-dwc3 + - const: qcom,dwc3 + + reg: + description: Offset and length of register set for QSCRATCH wrapper + maxItems: 1 + + "#address-cells": + enum: [ 1, 2 ] + + "#size-cells": + enum: [ 1, 2 ] + + ranges: true + + power-domains: + description: specifies a phandle to PM domain provider node + maxItems: 1 + + clocks: + description: + A list of phandle and clock-specifier pairs for the clocks + listed in clock-names. + items: + - description: System Config NOC clock. + - description: Master/Core clock, has to be >= 125 MHz + for SS operation and >= 60MHz for HS operation. + - description: System bus AXI clock. + - description: Mock utmi clock needed for ITP/SOF generation + in host mode. Its frequency should be 19.2MHz. + - description: Sleep clock, used for wakeup when + USB3 core goes into low power mode (U3). + + clock-names: + items: + - const: cfg_noc + - const: core + - const: iface + - const: mock_utmi + - const: sleep + + assigned-clocks: + items: + - description: Phandle and clock specifier of MOCK_UTMI_CLK. + - description: Phandle and clock specifoer of MASTER_CLK. + + assigned-clock-rates: + items: + - description: Must be 19.2MHz (19200000). + - description: Must be >= 60 MHz in HS mode, >= 125 MHz in SS mode. + resets: + maxItems: 1 + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: usb-ddr + - const: apps-usb + + interrupts: + items: + - description: The interrupt that is asserted + when a wakeup event is received on USB2 bus. + - description: The interrupt that is asserted + when a wakeup event is received on USB3 bus. + - description: Wakeup event on DM line. + - description: Wakeup event on DP line. + + interrupt-names: + items: + - const: hs_phy_irq + - const: ss_phy_irq + - const: dm_hs_phy_irq + - const: dp_hs_phy_irq + + qcom,select-utmi-as-pipe-clk: + description: + If present, disable USB3 pipe_clk requirement. + Used when dwc3 operates without SSPHY and only + HS/FS/LS modes are supported. + type: boolean + +# Required child node: + +patternProperties: + "^dwc3@[0-9a-f]+$": + type: object + description: + A child node must exist to represent the core DWC3 IP block + The content of the node is defined in dwc3.txt. + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - ranges + - power-domains + - clocks + - clock-names + - interrupts + - interrupt-names + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + soc { + #address-cells = <2>; + #size-cells = <2>; + + usb@a6f8800 { + compatible = "qcom,sdm845-dwc3", "qcom,dwc3"; + reg = <0 0x0a6f8800 0 0x400>; + + #address-cells = <2>; + #size-cells = <2>; + ranges; + clocks = <&gcc GCC_CFG_NOC_USB3_PRIM_AXI_CLK>, + <&gcc GCC_USB30_PRIM_MASTER_CLK>, + <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>, + <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>, + <&gcc GCC_USB30_PRIM_SLEEP_CLK>; + clock-names = "cfg_noc", "core", "iface", "mock_utmi", + "sleep"; + + assigned-clocks = <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>, + <&gcc GCC_USB30_PRIM_MASTER_CLK>; + assigned-clock-rates = <19200000>, <150000000>; + + interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 486 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 488 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 489 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "hs_phy_irq", "ss_phy_irq", + "dm_hs_phy_irq", "dp_hs_phy_irq"; + + power-domains = <&gcc USB30_PRIM_GDSC>; + + resets = <&gcc GCC_USB30_PRIM_BCR>; + + dwc3@a600000 { + compatible = "snps,dwc3"; + reg = <0 0x0a600000 0 0xcd00>; + interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>; + iommus = <&apps_smmu 0x740 0>; + snps,dis_u2_susphy_quirk; + snps,dis_enblslpm_quirk; + phys = <&usb_1_hsphy>, <&usb_1_ssphy>; + phy-names = "usb2-phy", "usb3-phy"; + }; + }; + };
diff --git a/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml b/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml index 92d8631..e3cdeab 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml
@@ -18,6 +18,7 @@ - renesas,r8a774c0-usb3-peri # RZ/G2E - renesas,r8a7795-usb3-peri # R-Car H3 - renesas,r8a7796-usb3-peri # R-Car M3-W + - renesas,r8a77961-usb3-peri # R-Car M3-W+ - renesas,r8a77965-usb3-peri # R-Car M3-N - renesas,r8a77990-usb3-peri # R-Car E3 - const: renesas,rcar-gen3-usb3-peri @@ -72,7 +73,7 @@ usb3_peri0: usb@ee020000 { compatible = "renesas,r8a774c0-usb3-peri", "renesas,rcar-gen3-usb3-peri"; - reg = <0 0xee020000 0 0x400>; + reg = <0xee020000 0x400>; interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 328>; companion = <&xhci0>;
diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml index 469affa8..af4826f 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
@@ -22,6 +22,7 @@ - items: - enum: + - renesas,usbhs-r8a7742 # RZ/G1H - renesas,usbhs-r8a7743 # RZ/G1M - renesas,usbhs-r8a7744 # RZ/G1N - renesas,usbhs-r8a7745 # RZ/G1E @@ -40,6 +41,7 @@ - renesas,usbhs-r8a774c0 # RZ/G2E - renesas,usbhs-r8a7795 # R-Car H3 - renesas,usbhs-r8a7796 # R-Car M3-W + - renesas,usbhs-r8a77961 # R-Car M3-W+ - renesas,usbhs-r8a77965 # R-Car M3-N - renesas,usbhs-r8a77990 # R-Car E3 - renesas,usbhs-r8a77995 # R-Car D3 @@ -120,7 +122,7 @@ usbhs: usb@e6590000 { compatible = "renesas,usbhs-r8a7790", "renesas,rcar-gen2-usbhs"; - reg = <0 0xe6590000 0 0x100>; + reg = <0xe6590000 0x100>; interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cpg CPG_MOD 704>; };
diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml index 5f5264b..9075025 100644 --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
@@ -57,30 +57,36 @@ - | #include <dt-bindings/soc/ti,sci_pm_domain.h> #include <dt-bindings/interrupt-controller/arm-gic.h> - cdns_usb@4104000 { - compatible = "ti,j721e-usb"; - reg = <0x00 0x4104000 0x00 0x100>; - power-domains = <&k3_pds 288 TI_SCI_PD_EXCLUSIVE>; - clocks = <&k3_clks 288 15>, <&k3_clks 288 3>; - clock-names = "ref", "lpm"; - assigned-clocks = <&k3_clks 288 15>; /* USB2_REFCLK */ - assigned-clock-parents = <&k3_clks 288 16>; /* HFOSC0 */ - #address-cells = <2>; - #size-cells = <2>; - usb@6000000 { - compatible = "cdns,usb3"; - reg = <0x00 0x6000000 0x00 0x10000>, - <0x00 0x6010000 0x00 0x10000>, - <0x00 0x6020000 0x00 0x10000>; - reg-names = "otg", "xhci", "dev"; - interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>, /* irq.0 */ - <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>, /* irq.6 */ - <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; /* otgirq.0 */ - interrupt-names = "host", - "peripheral", - "otg"; - maximum-speed = "super-speed"; - dr_mode = "otg"; + bus { + #address-cells = <2>; + #size-cells = <2>; + + cdns_usb@4104000 { + compatible = "ti,j721e-usb"; + reg = <0x00 0x4104000 0x00 0x100>; + power-domains = <&k3_pds 288 TI_SCI_PD_EXCLUSIVE>; + clocks = <&k3_clks 288 15>, <&k3_clks 288 3>; + clock-names = "ref", "lpm"; + assigned-clocks = <&k3_clks 288 15>; /* USB2_REFCLK */ + assigned-clock-parents = <&k3_clks 288 16>; /* HFOSC0 */ + #address-cells = <2>; + #size-cells = <2>; + + usb@6000000 { + compatible = "cdns,usb3"; + reg = <0x00 0x6000000 0x00 0x10000>, + <0x00 0x6010000 0x00 0x10000>, + <0x00 0x6020000 0x00 0x10000>; + reg-names = "otg", "xhci", "dev"; + interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>, /* irq.0 */ + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>, /* irq.6 */ + <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; /* otgirq.0 */ + interrupt-names = "host", + "peripheral", + "otg"; + maximum-speed = "super-speed"; + dr_mode = "otg"; + }; }; };
diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml new file mode 100644 index 0000000..f127535 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml
@@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/ti,keystone-dwc3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI Keystone Soc USB Controller + +maintainers: + - Roger Quadros <rogerq@ti.com> + +properties: + compatible: + oneOf: + - const: "ti,keystone-dwc3" + - const: "ti,am654-dwc3" + + reg: + maxItems: 1 + description: Address and length of the register set for the USB subsystem on + the SOC. + + interrupts: + maxItems: 1 + description: The irq number of this device that is used to interrupt the MPU. + + + clocks: + description: Clock ID for USB functional clock. + + power-domains: + description: Should contain a phandle to a PM domain provider node + and an args specifier containing the USB device id + value. This property is as per the binding, + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + + phys: + description: + PHY specifier for the USB3.0 PHY. Some SoCs need the USB3.0 PHY + to be turned on before the controller. + Documentation/devicetree/bindings/phy/phy-bindings.txt + + phy-names: + items: + - const: "usb3-phy" + + dwc3: + description: This is the node representing the DWC3 controller instance + Documentation/devicetree/bindings/usb/dwc3.txt + +required: + - compatible + - reg + - interrupts + - clocks + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + usb: usb@2680000 { + compatible = "ti,keystone-dwc3"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x2680000 0x10000>; + clocks = <&clkusb>; + clock-names = "usb"; + interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>; + ranges; + + dwc3@2690000 { + compatible = "synopsys,dwc3"; + reg = <0x2690000 0x70000>; + interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>; + usb-phy = <&usb_phy>, <&usb_phy>; + }; + };
diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml new file mode 100644 index 0000000..8eaf4b6 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml
@@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/usb/ti,tps6598x.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Texas Instruments 6598x Type-C Port Switch and Power Delivery controller DT bindings + +maintainers: + - Bryan O'Donoghue <bryan.odonoghue@linaro.org> + +description: | + Texas Instruments 6598x Type-C Port Switch and Power Delivery controller + +properties: + compatible: + enum: + - ti,tps6598x + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-names: + items: + - const: irq + +required: + - compatible + - reg + - interrupts + - interrupt-names + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + tps6598x: tps6598x@38 { + compatible = "ti,tps6598x"; + reg = <0x38>; + + interrupt-parent = <&msmgpio>; + interrupts = <107 IRQ_TYPE_LEVEL_LOW>; + interrupt-names = "irq"; + + pinctrl-names = "default"; + pinctrl-0 = <&typec_pins>; + + typec_con: connector { + compatible = "usb-c-connector"; + label = "USB-C"; + port { + typec_ep: endpoint { + remote-endpoint = <&otg_ep>; + }; + }; + }; + }; + }; +...
diff --git a/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt b/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt deleted file mode 100644 index ec80641..0000000 --- a/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt +++ /dev/null
@@ -1,30 +0,0 @@ -USB GPIO Based Connection Detection - -This is typically used to switch dual role mode from the USB ID pin connected -to an input GPIO, and also used to enable/disable device mode from the USB -Vbus pin connected to an input GPIO. - -Required properties: -- compatible : should include "gpio-usb-b-connector" and "usb-b-connector". -- id-gpios, vbus-gpios : input gpios, either one of them must be present, - and both can be present as well. - see connector/usb-connector.yaml - -Optional properties: -- vbus-supply : can be present if needed when supports dual role mode. - see connector/usb-connector.yaml - -- Sub-nodes: - - port : can be present. - see graph.txt - -Example: - -&mtu3 { - connector { - compatible = "gpio-usb-b-connector", "usb-b-connector"; - type = "micro"; - id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>; - vbus-supply = <&usb_p0_vbus>; - }; -};
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index 3f37895..b120dd6 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -7,6 +7,7 @@ - "marvell,armada3700-xhci" for Armada 37xx SoCs - "marvell,armada-375-xhci" for Armada 375 SoCs - "marvell,armada-380-xhci" for Armada 38x SoCs + - "renesas,xhci-r8a7742" for r8a7742 SoC - "renesas,xhci-r8a7743" for r8a7743 SoC - "renesas,xhci-r8a7744" for r8a7744 SoC - "renesas,xhci-r8a774a1" for r8a774a1 SoC @@ -16,13 +17,15 @@ - "renesas,xhci-r8a7791" for r8a7791 SoC - "renesas,xhci-r8a7793" for r8a7793 SoC - "renesas,xhci-r8a7795" for r8a7795 SoC - - "renesas,xhci-r8a7796" for r8a7796 SoC + - "renesas,xhci-r8a7796" for r8a77960 SoC + - "renesas,xhci-r8a77961" for r8a77961 SoC - "renesas,xhci-r8a77965" for r8a77965 SoC - "renesas,xhci-r8a77990" for r8a77990 SoC - "renesas,rcar-gen2-xhci" for a generic R-Car Gen2 or RZ/G1 compatible device - "renesas,rcar-gen3-xhci" for a generic R-Car Gen3 or RZ/G2 compatible device + - "brcm,bcm7445-xhci" for Broadcom STB SoCs with XHCI - "xhci-platform" (deprecated) When compatible with the generic version, nodes must list the
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index d389138..9aeab66 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -59,6 +59,8 @@ description: Allwinner Technology Co., Ltd. "^alphascale,.*": description: AlphaScale Integrated Circuits Systems, Inc. + "^alps,.*": + description: Alps Electric Co., Ltd. "^altr,.*": description: Altera Corp. "^amarula,.*": @@ -131,6 +133,8 @@ description: Shanghai AVIC Optoelectronics Co., Ltd. "^avnet,.*": description: Avnet, Inc. + "^awinic,.*": + description: Shanghai Awinic Technology Co., Ltd. "^axentia,.*": description: Axentia Technologies AB "^axis,.*": @@ -139,10 +143,14 @@ description: Azoteq (Pty) Ltd "^azw,.*": description: Shenzhen AZW Technology Co., Ltd. + "^baikal,.*": + description: BAIKAL ELECTRONICS, JSC "^bananapi,.*": description: BIPAI KEJI LIMITED "^beacon,.*": description: Compass Electronics Group, LLC + "^beagle,.*": + description: BeagleBoard.org Foundation "^bhf,.*": description: Beckhoff Automation GmbH & Co. KG "^bitmain,.*": @@ -179,14 +187,20 @@ description: Cadence Design Systems Inc. "^cdtech,.*": description: CDTech(H.K.) Electronics Limited + "^cellwise,.*": + description: CellWise Microelectronics Co., Ltd "^ceva,.*": description: Ceva, Inc. + "^checkpoint,.*": + description: Check Point Software Technologies Ltd. "^chipidea,.*": description: Chipidea, Inc "^chipone,.*": description: ChipOne "^chipspark,.*": description: ChipSPARK + "^chrontel,.*": + description: Chrontel, Inc. "^chrp,.*": description: Common Hardware Reference Platform "^chunghwa,.*": @@ -463,6 +477,8 @@ description: Infineon Technologies "^inforce,.*": description: Inforce Computing + "^ivo,.*": + description: InfoVision Optoelectronics Kunshan Co. Ltd. "^ingenic,.*": description: Ingenic Semiconductor "^innolux,.*": @@ -488,7 +504,7 @@ "^issi,.*": description: Integrated Silicon Solutions Inc. "^ite,.*": - description: ITE Tech, Inc. + description: ITE Tech. Inc. "^itead,.*": description: ITEAD Intelligent Systems Co.Ltd "^iwave,.*": @@ -585,6 +601,8 @@ description: LSI Corp. (LSI Logic) "^lwn,.*": description: Liebherr-Werk Nenzing GmbH + "^lxa,.*": + description: Linux Automation GmbH "^macnica,.*": description: Macnica Americas "^mapleboard,.*": @@ -633,6 +651,8 @@ description: Microsoft Corporation "^mikroe,.*": description: MikroElektronika d.o.o. + "^mikrotik,.*": + description: MikroTik "^miniand,.*": description: Miniand Tech "^minix,.*": @@ -808,6 +828,8 @@ description: Primux Trading, S.L. "^probox2,.*": description: PROBOX2 (by W2COMP Co., Ltd.) + "^prt,.*": + description: Protonic Holland "^pulsedlight,.*": description: PulsedLight, Inc "^purism,.*": @@ -900,6 +922,8 @@ description: Sharp Corporation "^shimafuji,.*": description: Shimafuji Electric, Inc. + "^shiratech,.*": + description: Shiratech Solutions "^si-en,.*": description: Si-En Technology Ltd. "^si-linux,.*": @@ -918,6 +942,8 @@ description: Silead Inc. "^silergy,.*": description: Silergy Corp. + "^silex-insight,.*": + description: Silex Insight "^siliconmitus,.*": description: Silicon Mitus, Inc. "^simtek,.*": @@ -936,6 +962,8 @@ description: Sitronix Technology Corporation "^skyworks,.*": description: Skyworks Solutions, Inc. + "^smartlabs,.*": + description: SmartLabs LLC "^smsc,.*": description: Standard Microsystems Corporation "^snps,.*": @@ -1039,12 +1067,16 @@ description: Tronsmart "^truly,.*": description: Truly Semiconductors Limited + "^visionox,.*": + description: Visionox "^tsd,.*": description: Theobroma Systems Design und Consulting GmbH "^tyan,.*": description: Tyan Computer Corporation "^u-blox,.*": description: u-blox + "^u-boot,.*": + description: U-Boot bootloader "^ucrobotics,.*": description: uCRobotics "^ubnt,.*": @@ -1065,6 +1097,8 @@ description: Aigo Digital Technology Co., Ltd. "^v3,.*": description: V3 Semiconductor + "^vaisala,.*": + description: Vaisala "^vamrs,.*": description: Vamrs Ltd. "^variscite,.*": @@ -1093,6 +1127,8 @@ description: Waveshare Electronics "^wd,.*": description: Western Digital Corp. + "^we,.*": + description: Würth Elektronik GmbH. "^wetek,.*": description: WeTek Electronics, limited. "^wexler,.*": @@ -1125,6 +1161,8 @@ description: Shenzhen Xinpeng Technology Co., Ltd "^xlnx,.*": description: Xilinx + "^xnano,.*": + description: Xnano "^xunlong,.*": description: Shenzhen Xunlong Software CO.,Limited "^xylon,.*":
diff --git a/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml b/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml new file mode 100644 index 0000000..8e4c7c6 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
@@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/arm-smc-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Secure Monitor Call based watchdog + +allOf: + - $ref: "watchdog.yaml#" + +maintainers: + - Julius Werner <jwerner@chromium.org> + +properties: + compatible: + enum: + - arm,smc-wdt + arm,smc-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + The ATF smc function id used by the firmware. + Defaults to 0x82003D06 if unset. + +required: + - compatible + +examples: + - | + watchdog { + compatible = "arm,smc-wdt"; + arm,smc-id = <0x82003D06>; + timeout-sec = <15>; + }; + +...
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt deleted file mode 100644 index adc6b76..0000000 --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt +++ /dev/null
@@ -1,24 +0,0 @@ -* Freescale i.MX Watchdog Timer (WDT) Controller - -Required properties: -- compatible : Should be "fsl,<soc>-wdt" -- reg : Should contain WDT registers location and length -- interrupts : Should contain WDT interrupt - -Optional properties: -- big-endian: If present the watchdog device's registers are implemented - in big endian mode, otherwise in native mode(same with CPU), for more - detail please see: Documentation/devicetree/bindings/regmap/regmap.txt. -- fsl,ext-reset-output: If present the watchdog device is configured to - assert its external reset (WDOG_B) instead of issuing a software reset. -- timeout-sec : Contains the watchdog timeout in seconds - -Examples: - -wdt@73f98000 { - compatible = "fsl,imx51-wdt", "fsl,imx21-wdt"; - reg = <0x73f98000 0x4000>; - interrupts = <58>; - big-endian; - timeout-sec = <20>; -};
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml new file mode 100644 index 0000000..d96b93b --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
@@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/fsl-imx-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX Watchdog Timer (WDT) Controller + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +allOf: + - $ref: "watchdog.yaml#" + +properties: + compatible: + enum: + - fsl,imx21-wdt + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + fsl,ext-reset-output: + $ref: /schemas/types.yaml#/definitions/flag + description: | + If present, the watchdog device is configured to assert its + external reset (WDOG_B) instead of issuing a software reset. + +required: + - compatible + - interrupts + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/imx6qdl-clock.h> + + watchdog@20bc000 { + compatible = "fsl,imx21-wdt"; + reg = <0x020bc000 0x4000>; + interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks IMX6QDL_CLK_IPG>; + }; + +...
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt deleted file mode 100644 index f902508..0000000 --- a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.txt +++ /dev/null
@@ -1,22 +0,0 @@ -* Freescale i.MX7ULP Watchdog Timer (WDT) Controller - -Required properties: -- compatible : Should be "fsl,imx7ulp-wdt" -- reg : Should contain WDT registers location and length -- interrupts : Should contain WDT interrupt -- clocks: Should contain a phandle pointing to the gated peripheral clock. - -Optional properties: -- timeout-sec : Contains the watchdog timeout in seconds - -Examples: - -wdog1: watchdog@403d0000 { - compatible = "fsl,imx7ulp-wdt"; - reg = <0x403d0000 0x10000>; - interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&pcc2 IMX7ULP_CLK_WDG1>; - assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>; - assigned-clocks-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>; - timeout-sec = <40>; -};
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml new file mode 100644 index 0000000..51d6d48 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml
@@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/fsl-imx7ulp-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX7ULP Watchdog Timer (WDT) Controller + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +allOf: + - $ref: "watchdog.yaml#" + +properties: + compatible: + enum: + - fsl,imx7ulp-wdt + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + assigned-clocks: + maxItems: 1 + + assigned-clocks-parents: + maxItems: 1 + + timeout-sec: true + +required: + - compatible + - interrupts + - reg + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/imx7ulp-clock.h> + + watchdog@403d0000 { + compatible = "fsl,imx7ulp-wdt"; + reg = <0x403d0000 0x10000>; + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&pcc2 IMX7ULP_CLK_WDG1>; + assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>; + assigned-clocks-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>; + timeout-sec = <40>; + }; + +...
diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt b/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt deleted file mode 100644 index 79b3c62..0000000 --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt +++ /dev/null
@@ -1,50 +0,0 @@ -Renesas Watchdog Timer (WDT) Controller - -Required properties: - - compatible : Must be "renesas,<soctype>-wdt", followed by a generic - fallback compatible string when compatible with the generic - version. - Examples with soctypes are: - - "renesas,r8a7743-wdt" (RZ/G1M) - - "renesas,r8a7744-wdt" (RZ/G1N) - - "renesas,r8a7745-wdt" (RZ/G1E) - - "renesas,r8a77470-wdt" (RZ/G1C) - - "renesas,r8a774a1-wdt" (RZ/G2M) - - "renesas,r8a774b1-wdt" (RZ/G2N) - - "renesas,r8a774c0-wdt" (RZ/G2E) - - "renesas,r8a7790-wdt" (R-Car H2) - - "renesas,r8a7791-wdt" (R-Car M2-W) - - "renesas,r8a7792-wdt" (R-Car V2H) - - "renesas,r8a7793-wdt" (R-Car M2-N) - - "renesas,r8a7794-wdt" (R-Car E2) - - "renesas,r8a7795-wdt" (R-Car H3) - - "renesas,r8a7796-wdt" (R-Car M3-W) - - "renesas,r8a77961-wdt" (R-Car M3-W+) - - "renesas,r8a77965-wdt" (R-Car M3-N) - - "renesas,r8a77970-wdt" (R-Car V3M) - - "renesas,r8a77990-wdt" (R-Car E3) - - "renesas,r8a77995-wdt" (R-Car D3) - - "renesas,r7s72100-wdt" (RZ/A1) - - "renesas,r7s9210-wdt" (RZ/A2) - The generic compatible string must be: - - "renesas,rza-wdt" for RZ/A - - "renesas,rcar-gen2-wdt" for R-Car Gen2 and RZ/G1 - - "renesas,rcar-gen3-wdt" for R-Car Gen3 and RZ/G2 - -- reg : Should contain WDT registers location and length -- clocks : the clock feeding the watchdog timer. - -Optional properties: -- timeout-sec : Contains the watchdog timeout in seconds -- power-domains : the power domain the WDT belongs to -- interrupts: Some WDTs have an interrupt when used in interval timer mode - -Examples: - - wdt0: watchdog@e6020000 { - compatible = "renesas,r8a7795-wdt", "renesas,rcar-gen3-wdt"; - reg = <0 0xe6020000 0 0x0c>; - clocks = <&cpg CPG_MOD 402>; - power-domains = <&cpg>; - timeout-sec = <60>; - };
diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml new file mode 100644 index 0000000..572f4c9 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml
@@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/renesas,wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas Watchdog Timer (WDT) Controller + +maintainers: + - Wolfram Sang <wsa+renesas@sang-engineering.com> + - Geert Uytterhoeven <geert+renesas@glider.be> + +allOf: + - $ref: "watchdog.yaml#" + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,r7s72100-wdt # RZ/A1 + - renesas,r7s9210-wdt # RZ/A2 + - const: renesas,rza-wdt # RZ/A + + - items: + - enum: + - renesas,r8a7742-wdt # RZ/G1H + - renesas,r8a7743-wdt # RZ/G1M + - renesas,r8a7744-wdt # RZ/G1N + - renesas,r8a7745-wdt # RZ/G1E + - renesas,r8a77470-wdt # RZ/G1C + - renesas,r8a7790-wdt # R-Car H2 + - renesas,r8a7791-wdt # R-Car M2-W + - renesas,r8a7792-wdt # R-Car V2H + - renesas,r8a7793-wdt # R-Car M2-N + - renesas,r8a7794-wdt # R-Car E2 + - const: renesas,rcar-gen2-wdt # R-Car Gen2 and RZ/G1 + + - items: + - enum: + - renesas,r8a774a1-wdt # RZ/G2M + - renesas,r8a774b1-wdt # RZ/G2N + - renesas,r8a774c0-wdt # RZ/G2E + - renesas,r8a7795-wdt # R-Car H3 + - renesas,r8a7796-wdt # R-Car M3-W + - renesas,r8a77961-wdt # R-Car M3-W+ + - renesas,r8a77965-wdt # R-Car M3-N + - renesas,r8a77970-wdt # R-Car V3M + - renesas,r8a77980-wdt # R-Car V3H + - renesas,r8a77990-wdt # R-Car E3 + - renesas,r8a77995-wdt # R-Car D3 + - const: renesas,rcar-gen3-wdt # R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + timeout-sec: true + +required: + - compatible + - reg + - clocks + +if: + not: + properties: + compatible: + contains: + enum: + - renesas,rza-wdt +then: + required: + - power-domains + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7795-cpg-mssr.h> + #include <dt-bindings/power/r8a7795-sysc.h> + wdt0: watchdog@e6020000 { + compatible = "renesas,r8a7795-wdt", "renesas,rcar-gen3-wdt"; + reg = <0xe6020000 0x0c>; + clocks = <&cpg CPG_MOD 402>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 402>; + timeout-sec = <60>; + };
diff --git a/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml b/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml new file mode 100644 index 0000000..a059d16 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml
@@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/socionext,uniphier-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier watchdog timer + +maintainers: + - Keiji Hayashibara <hayashibara.keiji@socionext.com> + +allOf: + - $ref: "watchdog.yaml#" + +properties: + compatible: + const: socionext,uniphier-wdt + +required: + - compatible + +additionalProperties: false + +examples: + - | + // The UniPhier watchdog should be a subnode of a "syscon" compatible node. + + sysctrl@61840000 { + compatible = "socionext,uniphier-ld11-sysctrl", + "simple-mfd", "syscon"; + reg = <0x61840000 0x10000>; + + watchdog { + compatible = "socionext,uniphier-wdt"; + }; + };
diff --git a/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml b/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml index e83026f..f045279 100644 --- a/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml
@@ -57,7 +57,7 @@ watchdog0: rti@2200000 { compatible = "ti,rti-wdt"; - reg = <0x0 0x2200000 0x0 0x100>; + reg = <0x2200000 0x100>; clocks = <&k3_clks 252 1>; power-domains = <&k3_pds 252 TI_SCI_PD_EXCLUSIVE>; assigned-clocks = <&k3_clks 252 1>;
diff --git a/Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt b/Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt deleted file mode 100644 index bf63375..0000000 --- a/Documentation/devicetree/bindings/watchdog/uniphier-wdt.txt +++ /dev/null
@@ -1,20 +0,0 @@ -UniPhier watchdog timer controller - -This UniPhier watchdog timer controller must be under sysctrl node. - -Required properties: -- compatible: should be "socionext,uniphier-wdt" - -Example: - - sysctrl@61840000 { - compatible = "socionext,uniphier-ld11-sysctrl", - "simple-mfd", "syscon"; - reg = <0x61840000 0x4000>; - - watchdog { - compatible = "socionext,uniphier-wdt"; - } - - other nodes ... - };
diff --git a/Documentation/devicetree/bindings/writing-bindings.rst b/Documentation/devicetree/bindings/writing-bindings.rst new file mode 100644 index 0000000..45ff426 --- /dev/null +++ b/Documentation/devicetree/bindings/writing-bindings.rst
@@ -0,0 +1,67 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================================ +DOs and DON'Ts for designing and writing Devicetree bindings +============================================================ + +This is a list of common review feedback items focused on binding design. With +every rule, there are exceptions and bindings have many gray areas. + +For guidelines related to patches, see +Documentation/devicetree/bindings/submitting-patches.rst + + +Overall design +============== + +- DO attempt to make bindings complete even if a driver doesn't support some + features. For example, if a device has an interrupt, then include the + 'interrupts' property even if the driver is only polled mode. + +- DON'T refer to Linux or "device driver" in bindings. Bindings should be + based on what the hardware has, not what an OS and driver currently support. + +- DO use node names matching the class of the device. Many standard names are + defined in the DT Spec. If there isn't one, consider adding it. + +- DO check that the example matches the documentation especially after making + review changes. + +- DON'T create nodes just for the sake of instantiating drivers. Multi-function + devices only need child nodes when the child nodes have their own DT + resources. A single node can be multiple providers (e.g. clocks and resets). + +- DON'T use 'syscon' alone without a specific compatible string. A 'syscon' + hardware block should have a compatible string unique enough to infer the + register layout of the entire block (at a minimum). + + +Properties +========== + +- DO make 'compatible' properties specific. DON'T use wildcards in compatible + strings. DO use fallback compatibles when devices are the same as or a subset + 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 + properties could be common among devices of the same class. Check other + existing bindings for similar devices. + +- DON'T redefine common properties. Just reference the definition and define + constraints specific to the device. + +- DO use common property unit suffixes for properties with scientific units. + See property-units.txt. + +- DO define properties in terms of constraints. How many entries? What are + possible values? What is the order? + + +Board/SoC .dts Files +==================== + +- DO put all MMIO devices under a bus node and not at the top-level. + +- DO use non-empty 'ranges' to limit the size of child buses/devices. 64-bit + platforms don't need all devices to have 64-bit address and size.
diff --git a/Documentation/devicetree/bindings/writing-bindings.txt b/Documentation/devicetree/bindings/writing-bindings.txt deleted file mode 100644 index 27dfd2d..0000000 --- a/Documentation/devicetree/bindings/writing-bindings.txt +++ /dev/null
@@ -1,60 +0,0 @@ -DOs and DON'Ts for designing and writing Devicetree bindings - -This is a list of common review feedback items focused on binding design. With -every rule, there are exceptions and bindings have many gray areas. - -For guidelines related to patches, see -Documentation/devicetree/bindings/submitting-patches.txt - - -Overall design - -- DO attempt to make bindings complete even if a driver doesn't support some - features. For example, if a device has an interrupt, then include the - 'interrupts' property even if the driver is only polled mode. - -- DON'T refer to Linux or "device driver" in bindings. Bindings should be - based on what the hardware has, not what an OS and driver currently support. - -- DO use node names matching the class of the device. Many standard names are - defined in the DT Spec. If there isn't one, consider adding it. - -- DO check that the example matches the documentation especially after making - review changes. - -- DON'T create nodes just for the sake of instantiating drivers. Multi-function - devices only need child nodes when the child nodes have their own DT - resources. A single node can be multiple providers (e.g. clocks and resets). - -- DON'T use 'syscon' alone without a specific compatible string. A 'syscon' - hardware block should have a compatible string unique enough to infer the - register layout of the entire block (at a minimum). - - -Properties - -- DO make 'compatible' properties specific. DON'T use wildcards in compatible - strings. DO use fallback compatibles when devices are the same as or a subset - 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 - properties could be common among devices of the same class. Check other - existing bindings for similar devices. - -- DON'T redefine common properties. Just reference the definition and define - constraints specific to the device. - -- DO use common property unit suffixes for properties with scientific units. - See property-units.txt. - -- DO define properties in terms of constraints. How many entries? What are - possible values? What is the order? - - -Board/SoC .dts Files - -- DO put all MMIO devices under a bus node and not at the top-level. - -- DO use non-empty 'ranges' to limit the size of child buses/devices. 64-bit - platforms don't need all devices to have 64-bit address and size.
diff --git a/Documentation/devicetree/bindings/xilinx.txt b/Documentation/devicetree/bindings/xilinx.txt index d058ace..28199b3 100644 --- a/Documentation/devicetree/bindings/xilinx.txt +++ b/Documentation/devicetree/bindings/xilinx.txt
@@ -86,149 +86,6 @@ xlnx,use-parity = <0>; }; - Some IP cores actually implement 2 or more logical devices. In - this case, the device should still describe the whole IP core with - a single node and add a child node for each logical device. The - ranges property can be used to translate from parent IP-core to the - registers of each device. In addition, the parent node should be - compatible with the bus type 'xlnx,compound', and should contain - #address-cells and #size-cells, as with any other bus. (Note: this - makes the assumption that both logical devices have the same bus - binding. If this is not true, then separate nodes should be used - for each logical device). The 'cell-index' property can be used to - enumerate logical devices within an IP core. For example, the - following is the system.mhs entry for the dual ps2 controller found - on the ml403 reference design. - - BEGIN opb_ps2_dual_ref - PARAMETER INSTANCE = opb_ps2_dual_ref_0 - PARAMETER HW_VER = 1.00.a - PARAMETER C_BASEADDR = 0xA9000000 - PARAMETER C_HIGHADDR = 0xA9001FFF - BUS_INTERFACE SOPB = opb_v20_0 - PORT Sys_Intr1 = ps2_1_intr - PORT Sys_Intr2 = ps2_2_intr - PORT Clkin1 = ps2_clk_rx_1 - PORT Clkin2 = ps2_clk_rx_2 - PORT Clkpd1 = ps2_clk_tx_1 - PORT Clkpd2 = ps2_clk_tx_2 - PORT Rx1 = ps2_d_rx_1 - PORT Rx2 = ps2_d_rx_2 - PORT Txpd1 = ps2_d_tx_1 - PORT Txpd2 = ps2_d_tx_2 - END - - It would result in the following device tree nodes: - - opb_ps2_dual_ref_0: opb-ps2-dual-ref@a9000000 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "xlnx,compound"; - ranges = <0 a9000000 2000>; - // If this device had extra parameters, then they would - // go here. - ps2@0 { - compatible = "xlnx,opb-ps2-dual-ref-1.00.a"; - reg = <0 40>; - interrupt-parent = <&opb_intc_0>; - interrupts = <3 0>; - cell-index = <0>; - }; - ps2@1000 { - compatible = "xlnx,opb-ps2-dual-ref-1.00.a"; - reg = <1000 40>; - interrupt-parent = <&opb_intc_0>; - interrupts = <3 0>; - cell-index = <0>; - }; - }; - - Also, the system.mhs file defines bus attachments from the processor - to the devices. The device tree structure should reflect the bus - attachments. Again an example; this system.mhs fragment: - - BEGIN ppc405_virtex4 - PARAMETER INSTANCE = ppc405_0 - PARAMETER HW_VER = 1.01.a - BUS_INTERFACE DPLB = plb_v34_0 - BUS_INTERFACE IPLB = plb_v34_0 - END - - BEGIN opb_intc - PARAMETER INSTANCE = opb_intc_0 - PARAMETER HW_VER = 1.00.c - PARAMETER C_BASEADDR = 0xD1000FC0 - PARAMETER C_HIGHADDR = 0xD1000FDF - BUS_INTERFACE SOPB = opb_v20_0 - END - - BEGIN opb_uart16550 - PARAMETER INSTANCE = opb_uart16550_0 - PARAMETER HW_VER = 1.00.d - PARAMETER C_BASEADDR = 0xa0000000 - PARAMETER C_HIGHADDR = 0xa0001FFF - BUS_INTERFACE SOPB = opb_v20_0 - END - - BEGIN plb_v34 - PARAMETER INSTANCE = plb_v34_0 - PARAMETER HW_VER = 1.02.a - END - - BEGIN plb_bram_if_cntlr - PARAMETER INSTANCE = plb_bram_if_cntlr_0 - PARAMETER HW_VER = 1.00.b - PARAMETER C_BASEADDR = 0xFFFF0000 - PARAMETER C_HIGHADDR = 0xFFFFFFFF - BUS_INTERFACE SPLB = plb_v34_0 - END - - BEGIN plb2opb_bridge - PARAMETER INSTANCE = plb2opb_bridge_0 - PARAMETER HW_VER = 1.01.a - PARAMETER C_RNG0_BASEADDR = 0x20000000 - PARAMETER C_RNG0_HIGHADDR = 0x3FFFFFFF - PARAMETER C_RNG1_BASEADDR = 0x60000000 - PARAMETER C_RNG1_HIGHADDR = 0x7FFFFFFF - PARAMETER C_RNG2_BASEADDR = 0x80000000 - PARAMETER C_RNG2_HIGHADDR = 0xBFFFFFFF - PARAMETER C_RNG3_BASEADDR = 0xC0000000 - PARAMETER C_RNG3_HIGHADDR = 0xDFFFFFFF - BUS_INTERFACE SPLB = plb_v34_0 - BUS_INTERFACE MOPB = opb_v20_0 - END - - Gives this device tree (some properties removed for clarity): - - plb@0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "xlnx,plb-v34-1.02.a"; - device_type = "ibm,plb"; - ranges; // 1:1 translation - - plb_bram_if_cntrl_0: bram@ffff0000 { - reg = <ffff0000 10000>; - } - - opb@20000000 { - #address-cells = <1>; - #size-cells = <1>; - ranges = <20000000 20000000 20000000 - 60000000 60000000 20000000 - 80000000 80000000 40000000 - c0000000 c0000000 20000000>; - - opb_uart16550_0: serial@a0000000 { - reg = <a00000000 2000>; - }; - - opb_intc_0: interrupt-controller@d1000fc0 { - reg = <d1000fc0 20>; - }; - }; - }; - That covers the general approach to binding xilinx IP cores into the device tree. The following are bindings for specific devices:
diff --git a/Documentation/devicetree/changesets.rst b/Documentation/devicetree/changesets.rst new file mode 100644 index 0000000..c7fd8cd --- /dev/null +++ b/Documentation/devicetree/changesets.rst
@@ -0,0 +1,37 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============= +DT Changesets +============= + +A DT changeset is a method which allows one to apply changes +in the live tree in such a way that either the full set of changes +will be applied, or none of them will be. If an error occurs partway +through applying the changeset, then the tree will be rolled back to the +previous state. A changeset can also be removed after it has been +applied. + +When a changeset is applied, all of the changes get applied to the tree +at once before emitting OF_RECONFIG notifiers. This is so that the +receiver sees a complete and consistent state of the tree when it +receives the notifier. + +The sequence of a changeset is as follows. + +1. of_changeset_init() - initializes a changeset + +2. A number of DT tree change calls, of_changeset_attach_node(), + of_changeset_detach_node(), of_changeset_add_property(), + of_changeset_remove_property, of_changeset_update_property() to prepare + a set of changes. No changes to the active tree are made at this point. + All the change operations are recorded in the of_changeset 'entries' + list. + +3. of_changeset_apply() - Apply the changes to the tree. Either the + entire changeset will get applied, or if there is an error the tree will + be restored to the previous state. The core ensures proper serialization + through locking. An unlocked version __of_changeset_apply is available, + if needed. + +If a successfully applied changeset needs to be removed, it can be done +with of_changeset_revert().
diff --git a/Documentation/devicetree/changesets.txt b/Documentation/devicetree/changesets.txt deleted file mode 100644 index cb488ee..0000000 --- a/Documentation/devicetree/changesets.txt +++ /dev/null
@@ -1,31 +0,0 @@ -A DT changeset is a method which allows one to apply changes -in the live tree in such a way that either the full set of changes -will be applied, or none of them will be. If an error occurs partway -through applying the changeset, then the tree will be rolled back to the -previous state. A changeset can also be removed after it has been -applied. - -When a changeset is applied, all of the changes get applied to the tree -at once before emitting OF_RECONFIG notifiers. This is so that the -receiver sees a complete and consistent state of the tree when it -receives the notifier. - -The sequence of a changeset is as follows. - -1. of_changeset_init() - initializes a changeset - -2. A number of DT tree change calls, of_changeset_attach_node(), -of_changeset_detach_node(), of_changeset_add_property(), -of_changeset_remove_property, of_changeset_update_property() to prepare -a set of changes. No changes to the active tree are made at this point. -All the change operations are recorded in the of_changeset 'entries' -list. - -3. of_changeset_apply() - Apply the changes to the tree. Either the -entire changeset will get applied, or if there is an error the tree will -be restored to the previous state. The core ensures proper serialization -through locking. An unlocked version __of_changeset_apply is available, -if needed. - -If a successfully applied changeset needs to be removed, it can be done -with of_changeset_revert().
diff --git a/Documentation/devicetree/dynamic-resolution-notes.rst b/Documentation/devicetree/dynamic-resolution-notes.rst new file mode 100644 index 0000000..570b7e1 --- /dev/null +++ b/Documentation/devicetree/dynamic-resolution-notes.rst
@@ -0,0 +1,27 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================== +Device Tree Dynamic Resolver Notes +================================== + +This document describes the implementation of the in-kernel +Device Tree resolver, residing in drivers/of/resolver.c + +How the resolver works +---------------------- + +The resolver is given as an input an arbitrary tree compiled with the +proper dtc option and having a /plugin/ tag. This generates the +appropriate __fixups__ & __local_fixups__ nodes. + +In sequence the resolver works by the following steps: + +1. Get the maximum device tree phandle value from the live tree + 1. +2. Adjust all the local phandles of the tree to resolve by that amount. +3. Using the __local__fixups__ node information adjust all local references + by the same amount. +4. For each property in the __fixups__ node locate the node it references + in the live tree. This is the label used to tag the node. +5. Retrieve the phandle of the target of the fixup. +6. For each fixup in the property locate the node:property:offset location + and replace it with the phandle value.
diff --git a/Documentation/devicetree/dynamic-resolution-notes.txt b/Documentation/devicetree/dynamic-resolution-notes.txt deleted file mode 100644 index c24ec36..0000000 --- a/Documentation/devicetree/dynamic-resolution-notes.txt +++ /dev/null
@@ -1,24 +0,0 @@ -Device Tree Dynamic Resolver Notes ----------------------------------- - -This document describes the implementation of the in-kernel -Device Tree resolver, residing in drivers/of/resolver.c - -How the resolver works ----------------------- - -The resolver is given as an input an arbitrary tree compiled with the -proper dtc option and having a /plugin/ tag. This generates the -appropriate __fixups__ & __local_fixups__ nodes. - -In sequence the resolver works by the following steps: - -1. Get the maximum device tree phandle value from the live tree + 1. -2. Adjust all the local phandles of the tree to resolve by that amount. -3. Using the __local__fixups__ node information adjust all local references - by the same amount. -4. For each property in the __fixups__ node locate the node it references - in the live tree. This is the label used to tag the node. -5. Retrieve the phandle of the target of the fixup. -6. For each fixup in the property locate the node:property:offset location - and replace it with the phandle value.
diff --git a/Documentation/devicetree/index.rst b/Documentation/devicetree/index.rst new file mode 100644 index 0000000..5402676 --- /dev/null +++ b/Documentation/devicetree/index.rst
@@ -0,0 +1,17 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================= +Open Firmware and Device Tree +============================= + +.. toctree:: + :maxdepth: 1 + + usage-model + writing-schema + changesets + dynamic-resolution-notes + of_unittest + overlay-notes + + bindings/index
diff --git a/Documentation/devicetree/of_unittest.rst b/Documentation/devicetree/of_unittest.rst new file mode 100644 index 0000000..dea0521 --- /dev/null +++ b/Documentation/devicetree/of_unittest.rst
@@ -0,0 +1,205 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================== +Open Firmware Device Tree Unittest +================================== + +Author: Gaurav Minocha <gaurav.minocha.os@gmail.com> + +1. Introduction +=============== + +This document explains how the test data required for executing OF unittest +is attached to the live tree dynamically, independent of the machine's +architecture. + +It is recommended to read the following documents before moving ahead. + +(1) Documentation/devicetree/usage-model.rst +(2) http://www.devicetree.org/Device_Tree_Usage + +OF Selftest has been designed to test the interface (include/linux/of.h) +provided to device driver developers to fetch the device information..etc. +from the unflattened device tree data structure. This interface is used by +most of the device drivers in various use cases. + + +2. Test-data +============ + +The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains +the test data required for executing the unit tests automated in +drivers/of/unittest.c. Currently, following Device Tree Source Include files +(.dtsi) are included in testcases.dts:: + + drivers/of/unittest-data/tests-interrupts.dtsi + drivers/of/unittest-data/tests-platform.dtsi + drivers/of/unittest-data/tests-phandle.dtsi + drivers/of/unittest-data/tests-match.dtsi + +When the kernel is build with OF_SELFTEST enabled, then the following make +rule:: + + $(obj)/%.dtb: $(src)/%.dts FORCE + $(call if_changed_dep, dtc) + +is used to compile the DT source file (testcases.dts) into a binary blob +(testcases.dtb), also referred as flattened DT. + +After that, using the following rule the binary blob above is wrapped as an +assembly file (testcases.dtb.S):: + + $(obj)/%.dtb.S: $(obj)/%.dtb + $(call cmd, dt_S_dtb) + +The assembly file is compiled into an object file (testcases.dtb.o), and is +linked into the kernel image. + + +2.1. Adding the test data +------------------------- + +Un-flattened device tree structure: + +Un-flattened device tree consists of connected device_node(s) in form of a tree +structure described below:: + + // following struct members are used to construct the tree + struct device_node { + ... + struct device_node *parent; + struct device_node *child; + struct device_node *sibling; + ... + }; + +Figure 1, describes a generic structure of machine's un-flattened device tree +considering only child and sibling pointers. There exists another pointer, +``*parent``, that is used to traverse the tree in the reverse direction. So, at +a particular level the child node and all the sibling nodes will have a parent +pointer pointing to a common node (e.g. child1, sibling2, sibling3, sibling4's +parent points to root node):: + + root ('/') + | + child1 -> sibling2 -> sibling3 -> sibling4 -> null + | | | | + | | | null + | | | + | | child31 -> sibling32 -> null + | | | | + | | null null + | | + | child21 -> sibling22 -> sibling23 -> null + | | | | + | null null null + | + child11 -> sibling12 -> sibling13 -> sibling14 -> null + | | | | + | | | null + | | | + null null child131 -> null + | + null + +Figure 1: Generic structure of un-flattened device tree + + +Before executing OF unittest, it is required to attach the test data to +machine's device tree (if present). So, when selftest_data_add() is called, +at first it reads the flattened device tree data linked into the kernel image +via the following kernel symbols:: + + __dtb_testcases_begin - address marking the start of test data blob + __dtb_testcases_end - address marking the end of test data blob + +Secondly, it calls of_fdt_unflatten_tree() to unflatten the flattened +blob. And finally, if the machine's device tree (i.e live tree) is present, +then it attaches the unflattened test data tree to the live tree, else it +attaches itself as a live device tree. + +attach_node_and_children() uses of_attach_node() to attach the nodes into the +live tree as explained below. To explain the same, the test data tree described +in Figure 2 is attached to the live tree described in Figure 1:: + + root ('/') + | + testcase-data + | + test-child0 -> test-sibling1 -> test-sibling2 -> test-sibling3 -> null + | | | | + test-child01 null null null + + +Figure 2: Example test data tree to be attached to live tree. + +According to the scenario above, the live tree is already present so it isn't +required to attach the root('/') node. All other nodes are attached by calling +of_attach_node() on each node. + +In the function of_attach_node(), the new node is attached as the child of the +given parent in live tree. But, if parent already has a child then the new node +replaces the current child and turns it into its sibling. So, when the testcase +data node is attached to the live tree above (Figure 1), the final structure is +as shown in Figure 3:: + + root ('/') + | + testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null + | | | | | + (...) | | | null + | | child31 -> sibling32 -> null + | | | | + | | null null + | | + | child21 -> sibling22 -> sibling23 -> null + | | | | + | null null null + | + child11 -> sibling12 -> sibling13 -> sibling14 -> null + | | | | + null null | null + | + child131 -> null + | + null + ----------------------------------------------------------------------- + + root ('/') + | + testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null + | | | | | + | (...) (...) (...) null + | + test-sibling3 -> test-sibling2 -> test-sibling1 -> test-child0 -> null + | | | | + null null null test-child01 + + +Figure 3: Live device tree structure after attaching the testcase-data. + + +Astute readers would have noticed that test-child0 node becomes the last +sibling compared to the earlier structure (Figure 2). After attaching first +test-child0 the test-sibling1 is attached that pushes the child node +(i.e. test-child0) to become a sibling and makes itself a child node, +as mentioned above. + +If a duplicate node is found (i.e. if a node with same full_name property is +already present in the live tree), then the node isn't attached rather its +properties are updated to the live tree's node by calling the function +update_node_properties(). + + +2.2. Removing the test data +--------------------------- + +Once the test case execution is complete, selftest_data_remove is called in +order to remove the device nodes attached initially (first the leaf nodes are +detached and then moving up the parent nodes are removed, and eventually the +whole tree). selftest_data_remove() calls detach_node_and_children() that uses +of_detach_node() to detach the nodes from the live device tree. + +To detach a node, of_detach_node() either updates the child pointer of given +node's parent to its sibling or attaches the previous sibling to the given +node's sibling, as appropriate. That is it :)
diff --git a/Documentation/devicetree/of_unittest.txt b/Documentation/devicetree/of_unittest.txt deleted file mode 100644 index 3e4e7d4..0000000 --- a/Documentation/devicetree/of_unittest.txt +++ /dev/null
@@ -1,197 +0,0 @@ -Open Firmware Device Tree Unittest ----------------------------------- - -Author: Gaurav Minocha <gaurav.minocha.os@gmail.com> - -1. Introduction - -This document explains how the test data required for executing OF unittest -is attached to the live tree dynamically, independent of the machine's -architecture. - -It is recommended to read the following documents before moving ahead. - -[1] Documentation/devicetree/usage-model.txt -[2] http://www.devicetree.org/Device_Tree_Usage - -OF Selftest has been designed to test the interface (include/linux/of.h) -provided to device driver developers to fetch the device information..etc. -from the unflattened device tree data structure. This interface is used by -most of the device drivers in various use cases. - - -2. Test-data - -The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains -the test data required for executing the unit tests automated in -drivers/of/unittest.c. Currently, following Device Tree Source Include files -(.dtsi) are included in testcases.dts: - -drivers/of/unittest-data/tests-interrupts.dtsi -drivers/of/unittest-data/tests-platform.dtsi -drivers/of/unittest-data/tests-phandle.dtsi -drivers/of/unittest-data/tests-match.dtsi - -When the kernel is build with OF_SELFTEST enabled, then the following make rule - -$(obj)/%.dtb: $(src)/%.dts FORCE - $(call if_changed_dep, dtc) - -is used to compile the DT source file (testcases.dts) into a binary blob -(testcases.dtb), also referred as flattened DT. - -After that, using the following rule the binary blob above is wrapped as an -assembly file (testcases.dtb.S). - -$(obj)/%.dtb.S: $(obj)/%.dtb - $(call cmd, dt_S_dtb) - -The assembly file is compiled into an object file (testcases.dtb.o), and is -linked into the kernel image. - - -2.1. Adding the test data - -Un-flattened device tree structure: - -Un-flattened device tree consists of connected device_node(s) in form of a tree -structure described below. - -// following struct members are used to construct the tree -struct device_node { - ... - struct device_node *parent; - struct device_node *child; - struct device_node *sibling; - ... - }; - -Figure 1, describes a generic structure of machine's un-flattened device tree -considering only child and sibling pointers. There exists another pointer, -*parent, that is used to traverse the tree in the reverse direction. So, at -a particular level the child node and all the sibling nodes will have a parent -pointer pointing to a common node (e.g. child1, sibling2, sibling3, sibling4's -parent points to root node) - -root ('/') - | -child1 -> sibling2 -> sibling3 -> sibling4 -> null - | | | | - | | | null - | | | - | | child31 -> sibling32 -> null - | | | | - | | null null - | | - | child21 -> sibling22 -> sibling23 -> null - | | | | - | null null null - | -child11 -> sibling12 -> sibling13 -> sibling14 -> null - | | | | - | | | null - | | | - null null child131 -> null - | - null - -Figure 1: Generic structure of un-flattened device tree - - -Before executing OF unittest, it is required to attach the test data to -machine's device tree (if present). So, when selftest_data_add() is called, -at first it reads the flattened device tree data linked into the kernel image -via the following kernel symbols: - -__dtb_testcases_begin - address marking the start of test data blob -__dtb_testcases_end - address marking the end of test data blob - -Secondly, it calls of_fdt_unflatten_tree() to unflatten the flattened -blob. And finally, if the machine's device tree (i.e live tree) is present, -then it attaches the unflattened test data tree to the live tree, else it -attaches itself as a live device tree. - -attach_node_and_children() uses of_attach_node() to attach the nodes into the -live tree as explained below. To explain the same, the test data tree described - in Figure 2 is attached to the live tree described in Figure 1. - -root ('/') - | - testcase-data - | - test-child0 -> test-sibling1 -> test-sibling2 -> test-sibling3 -> null - | | | | - test-child01 null null null - - -Figure 2: Example test data tree to be attached to live tree. - -According to the scenario above, the live tree is already present so it isn't -required to attach the root('/') node. All other nodes are attached by calling -of_attach_node() on each node. - -In the function of_attach_node(), the new node is attached as the child of the -given parent in live tree. But, if parent already has a child then the new node -replaces the current child and turns it into its sibling. So, when the testcase -data node is attached to the live tree above (Figure 1), the final structure is - as shown in Figure 3. - -root ('/') - | -testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null - | | | | | - (...) | | | null - | | child31 -> sibling32 -> null - | | | | - | | null null - | | - | child21 -> sibling22 -> sibling23 -> null - | | | | - | null null null - | - child11 -> sibling12 -> sibling13 -> sibling14 -> null - | | | | - null null | null - | - child131 -> null - | - null ------------------------------------------------------------------------ - -root ('/') - | -testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null - | | | | | - | (...) (...) (...) null - | -test-sibling3 -> test-sibling2 -> test-sibling1 -> test-child0 -> null - | | | | - null null null test-child01 - - -Figure 3: Live device tree structure after attaching the testcase-data. - - -Astute readers would have noticed that test-child0 node becomes the last -sibling compared to the earlier structure (Figure 2). After attaching first -test-child0 the test-sibling1 is attached that pushes the child node -(i.e. test-child0) to become a sibling and makes itself a child node, - as mentioned above. - -If a duplicate node is found (i.e. if a node with same full_name property is -already present in the live tree), then the node isn't attached rather its -properties are updated to the live tree's node by calling the function -update_node_properties(). - - -2.2. Removing the test data - -Once the test case execution is complete, selftest_data_remove is called in -order to remove the device nodes attached initially (first the leaf nodes are -detached and then moving up the parent nodes are removed, and eventually the -whole tree). selftest_data_remove() calls detach_node_and_children() that uses -of_detach_node() to detach the nodes from the live device tree. - -To detach a node, of_detach_node() either updates the child pointer of given -node's parent to its sibling or attaches the previous sibling to the given -node's sibling, as appropriate. That is it :)
diff --git a/Documentation/devicetree/overlay-notes.rst b/Documentation/devicetree/overlay-notes.rst new file mode 100644 index 0000000..c67cc67 --- /dev/null +++ b/Documentation/devicetree/overlay-notes.rst
@@ -0,0 +1,128 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +Device Tree Overlay Notes +========================= + +This document describes the implementation of the in-kernel +device tree overlay functionality residing in drivers/of/overlay.c and is a +companion document to Documentation/devicetree/dynamic-resolution-notes.rst[1] + +How overlays work +----------------- + +A Device Tree's overlay purpose is to modify the kernel's live tree, and +have the modification affecting the state of the kernel in a way that +is reflecting the changes. +Since the kernel mainly deals with devices, any new device node that result +in an active device should have it created while if the device node is either +disabled or removed all together, the affected device should be deregistered. + +Lets take an example where we have a foo board with the following base tree:: + + ---- foo.dts --------------------------------------------------------------- + /* FOO platform */ + /dts-v1/; + / { + compatible = "corp,foo"; + + /* shared resources */ + res: res { + }; + + /* On chip peripherals */ + ocp: ocp { + /* peripherals that are always instantiated */ + peripheral1 { ... }; + }; + }; + ---- foo.dts --------------------------------------------------------------- + +The overlay bar.dts, +:: + + ---- bar.dts - overlay target location by label ---------------------------- + /dts-v1/; + /plugin/; + &ocp { + /* bar peripheral */ + bar { + compatible = "corp,bar"; + ... /* various properties and child nodes */ + }; + }; + ---- bar.dts --------------------------------------------------------------- + +when loaded (and resolved as described in [1]) should result in foo+bar.dts:: + + ---- foo+bar.dts ----------------------------------------------------------- + /* FOO platform + bar peripheral */ + / { + compatible = "corp,foo"; + + /* shared resources */ + res: res { + }; + + /* On chip peripherals */ + ocp: ocp { + /* peripherals that are always instantiated */ + peripheral1 { ... }; + + /* bar peripheral */ + bar { + compatible = "corp,bar"; + ... /* various properties and child nodes */ + }; + }; + }; + ---- foo+bar.dts ----------------------------------------------------------- + +As a result of the overlay, a new device node (bar) has been created +so a bar platform device will be registered and if a matching device driver +is loaded the device will be created as expected. + +If the base DT was not compiled with the -@ option then the "&ocp" label +will not be available to resolve the overlay node(s) to the proper location +in the base DT. In this case, the target path can be provided. The target +location by label syntax is preferred because the overlay can be applied to +any base DT containing the label, no matter where the label occurs in the DT. + +The above bar.dts example modified to use target path syntax is:: + + ---- bar.dts - overlay target location by explicit path -------------------- + /dts-v1/; + /plugin/; + &{/ocp} { + /* bar peripheral */ + bar { + compatible = "corp,bar"; + ... /* various properties and child nodes */ + } + }; + ---- bar.dts --------------------------------------------------------------- + + +Overlay in-kernel API +-------------------------------- + +The API is quite easy to use. + +1) Call of_overlay_fdt_apply() to create and apply an overlay changeset. The + return value is an error or a cookie identifying this overlay. + +2) Call of_overlay_remove() to remove and cleanup the overlay changeset + previously created via the call to of_overlay_fdt_apply(). Removal of an + overlay changeset that is stacked by another will not be permitted. + +Finally, if you need to remove all overlays in one-go, just call +of_overlay_remove_all() which will remove every single one in the correct +order. + +In addition, there is the option to register notifiers that get called on +overlay operations. See of_overlay_notifier_register/unregister and +enum of_overlay_notify_action for details. + +Note that a notifier callback is not supposed to store pointers to a device +tree node or its content beyond OF_OVERLAY_POST_REMOVE corresponding to the +respective node it received.
diff --git a/Documentation/devicetree/overlay-notes.txt b/Documentation/devicetree/overlay-notes.txt deleted file mode 100644 index 725fb8d..0000000 --- a/Documentation/devicetree/overlay-notes.txt +++ /dev/null
@@ -1,139 +0,0 @@ -Device Tree Overlay Notes -------------------------- - -This document describes the implementation of the in-kernel -device tree overlay functionality residing in drivers/of/overlay.c and is a -companion document to Documentation/devicetree/dynamic-resolution-notes.txt[1] - -How overlays work ------------------ - -A Device Tree's overlay purpose is to modify the kernel's live tree, and -have the modification affecting the state of the kernel in a way that -is reflecting the changes. -Since the kernel mainly deals with devices, any new device node that result -in an active device should have it created while if the device node is either -disabled or removed all together, the affected device should be deregistered. - -Lets take an example where we have a foo board with the following base tree: - ----- foo.dts ----------------------------------------------------------------- - /* FOO platform */ - / { - compatible = "corp,foo"; - - /* shared resources */ - res: res { - }; - - /* On chip peripherals */ - ocp: ocp { - /* peripherals that are always instantiated */ - peripheral1 { ... }; - } - }; ----- foo.dts ----------------------------------------------------------------- - -The overlay bar.dts, when loaded (and resolved as described in [1]) should - ----- bar.dts ----------------------------------------------------------------- -/plugin/; /* allow undefined label references and record them */ -/ { - .... /* various properties for loader use; i.e. part id etc. */ - fragment@0 { - target = <&ocp>; - __overlay__ { - /* bar peripheral */ - bar { - compatible = "corp,bar"; - ... /* various properties and child nodes */ - } - }; - }; -}; ----- bar.dts ----------------------------------------------------------------- - -result in foo+bar.dts - ----- foo+bar.dts ------------------------------------------------------------- - /* FOO platform + bar peripheral */ - / { - compatible = "corp,foo"; - - /* shared resources */ - res: res { - }; - - /* On chip peripherals */ - ocp: ocp { - /* peripherals that are always instantiated */ - peripheral1 { ... }; - - /* bar peripheral */ - bar { - compatible = "corp,bar"; - ... /* various properties and child nodes */ - } - } - }; ----- foo+bar.dts ------------------------------------------------------------- - -As a result of the overlay, a new device node (bar) has been created -so a bar platform device will be registered and if a matching device driver -is loaded the device will be created as expected. - -Overlay in-kernel API --------------------------------- - -The API is quite easy to use. - -1. Call of_overlay_fdt_apply() to create and apply an overlay changeset. The -return value is an error or a cookie identifying this overlay. - -2. Call of_overlay_remove() to remove and cleanup the overlay changeset -previously created via the call to of_overlay_fdt_apply(). Removal of an -overlay changeset that is stacked by another will not be permitted. - -Finally, if you need to remove all overlays in one-go, just call -of_overlay_remove_all() which will remove every single one in the correct -order. - -In addition, there is the option to register notifiers that get called on -overlay operations. See of_overlay_notifier_register/unregister and -enum of_overlay_notify_action for details. - -Note that a notifier callback is not supposed to store pointers to a device -tree node or its content beyond OF_OVERLAY_POST_REMOVE corresponding to the -respective node it received. - -Overlay DTS Format ------------------- - -The DTS of an overlay should have the following format: - -{ - /* ignored properties by the overlay */ - - fragment@0 { /* first child node */ - - target=<phandle>; /* phandle target of the overlay */ - or - target-path="/path"; /* target path of the overlay */ - - __overlay__ { - property-a; /* add property-a to the target */ - node-a { /* add to an existing, or create a node-a */ - ... - }; - }; - } - fragment@1 { /* second child node */ - ... - }; - /* more fragments follow */ -} - -Using the non-phandle based target method allows one to use a base DT which does -not contain a __symbols__ node, i.e. it was not compiled with the -@ option. -The __symbols__ node is only required for the target=<phandle> method, since it -contains the information required to map from a phandle to a tree location.
diff --git a/Documentation/devicetree/usage-model.rst b/Documentation/devicetree/usage-model.rst new file mode 100644 index 0000000..e1b42dc --- /dev/null +++ b/Documentation/devicetree/usage-model.rst
@@ -0,0 +1,420 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +Linux and the Device Tree +========================= + +The Linux usage model for device tree data + +:Author: Grant Likely <grant.likely@secretlab.ca> + +This article describes how Linux uses the device tree. An overview of +the device tree data format can be found on the device tree usage page +at devicetree.org\ [1]_. + +.. [1] https://elinux.org/Device_Tree_Usage + +The "Open Firmware Device Tree", or simply Device Tree (DT), is a data +structure and language for describing hardware. More specifically, it +is a description of hardware that is readable by an operating system +so that the operating system doesn't need to hard code details of the +machine. + +Structurally, the DT is a tree, or acyclic graph with named nodes, and +nodes may have an arbitrary number of named properties encapsulating +arbitrary data. A mechanism also exists to create arbitrary +links from one node to another outside of the natural tree structure. + +Conceptually, a common set of usage conventions, called 'bindings', +is defined for how data should appear in the tree to describe typical +hardware characteristics including data busses, interrupt lines, GPIO +connections, and peripheral devices. + +As much as possible, hardware is described using existing bindings to +maximize use of existing support code, but since property and node +names are simply text strings, it is easy to extend existing bindings +or create new ones by defining new nodes and properties. Be wary, +however, of creating a new binding without first doing some homework +about what already exists. There are currently two different, +incompatible, bindings for i2c busses that came about because the new +binding was created without first investigating how i2c devices were +already being enumerated in existing systems. + +1. History +---------- +The DT was originally created by Open Firmware as part of the +communication method for passing data from Open Firmware to a client +program (like to an operating system). An operating system used the +Device Tree to discover the topology of the hardware at runtime, and +thereby support a majority of available hardware without hard coded +information (assuming drivers were available for all devices). + +Since Open Firmware is commonly used on PowerPC and SPARC platforms, +the Linux support for those architectures has for a long time used the +Device Tree. + +In 2005, when PowerPC Linux began a major cleanup and to merge 32-bit +and 64-bit support, the decision was made to require DT support on all +powerpc platforms, regardless of whether or not they used Open +Firmware. To do this, a DT representation called the Flattened Device +Tree (FDT) was created which could be passed to the kernel as a binary +blob without requiring a real Open Firmware implementation. U-Boot, +kexec, and other bootloaders were modified to support both passing a +Device Tree Binary (dtb) and to modify a dtb at boot time. DT was +also added to the PowerPC boot wrapper (``arch/powerpc/boot/*``) so that +a dtb could be wrapped up with the kernel image to support booting +existing non-DT aware firmware. + +Some time later, FDT infrastructure was generalized to be usable by +all architectures. At the time of this writing, 6 mainlined +architectures (arm, microblaze, mips, powerpc, sparc, and x86) and 1 +out of mainline (nios) have some level of DT support. + +2. Data Model +------------- +If you haven't already read the Device Tree Usage\ [1]_ page, +then go read it now. It's okay, I'll wait.... + +2.1 High Level View +------------------- +The most important thing to understand is that the DT is simply a data +structure that describes the hardware. There is nothing magical about +it, and it doesn't magically make all hardware configuration problems +go away. What it does do is provide a language for decoupling the +hardware configuration from the board and device driver support in the +Linux kernel (or any other operating system for that matter). Using +it allows board and device support to become data driven; to make +setup decisions based on data passed into the kernel instead of on +per-machine hard coded selections. + +Ideally, data driven platform setup should result in less code +duplication and make it easier to support a wide range of hardware +with a single kernel image. + +Linux uses DT data for three major purposes: + +1) platform identification, +2) runtime configuration, and +3) device population. + +2.2 Platform Identification +--------------------------- +First and foremost, the kernel will use data in the DT to identify the +specific machine. In a perfect world, the specific platform shouldn't +matter to the kernel because all platform details would be described +perfectly by the device tree in a consistent and reliable manner. +Hardware is not perfect though, and so the kernel must identify the +machine during early boot so that it has the opportunity to run +machine-specific fixups. + +In the majority of cases, the machine identity is irrelevant, and the +kernel will instead select setup code based on the machine's core +CPU or SoC. On ARM for example, setup_arch() in +arch/arm/kernel/setup.c will call setup_machine_fdt() in +arch/arm/kernel/devtree.c which searches through the machine_desc +table and selects the machine_desc which best matches the device tree +data. It determines the best match by looking at the 'compatible' +property in the root device tree node, and comparing it with the +dt_compat list in struct machine_desc (which is defined in +arch/arm/include/asm/mach/arch.h if you're curious). + +The 'compatible' property contains a sorted list of strings starting +with the exact name of the machine, followed by an optional list of +boards it is compatible with sorted from most compatible to least. For +example, the root compatible properties for the TI BeagleBoard and its +successor, the BeagleBoard xM board might look like, respectively:: + + compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3"; + compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3"; + +Where "ti,omap3-beagleboard-xm" specifies the exact model, it also +claims that it compatible with the OMAP 3450 SoC, and the omap3 family +of SoCs in general. You'll notice that the list is sorted from most +specific (exact board) to least specific (SoC family). + +Astute readers might point out that the Beagle xM could also claim +compatibility with the original Beagle board. However, one should be +cautioned about doing so at the board level since there is typically a +high level of change from one board to another, even within the same +product line, and it is hard to nail down exactly what is meant when one +board claims to be compatible with another. For the top level, it is +better to err on the side of caution and not claim one board is +compatible with another. The notable exception would be when one +board is a carrier for another, such as a CPU module attached to a +carrier board. + +One more note on compatible values. Any string used in a compatible +property must be documented as to what it indicates. Add +documentation for compatible strings in Documentation/devicetree/bindings. + +Again on ARM, for each machine_desc, the kernel looks to see if +any of the dt_compat list entries appear in the compatible property. +If one does, then that machine_desc is a candidate for driving the +machine. After searching the entire table of machine_descs, +setup_machine_fdt() returns the 'most compatible' machine_desc based +on which entry in the compatible property each machine_desc matches +against. If no matching machine_desc is found, then it returns NULL. + +The reasoning behind this scheme is the observation that in the majority +of cases, a single machine_desc can support a large number of boards +if they all use the same SoC, or same family of SoCs. However, +invariably there will be some exceptions where a specific board will +require special setup code that is not useful in the generic case. +Special cases could be handled by explicitly checking for the +troublesome board(s) in generic setup code, but doing so very quickly +becomes ugly and/or unmaintainable if it is more than just a couple of +cases. + +Instead, the compatible list allows a generic machine_desc to provide +support for a wide common set of boards by specifying "less +compatible" values in the dt_compat list. In the example above, +generic board support can claim compatibility with "ti,omap3" or +"ti,omap3450". If a bug was discovered on the original beagleboard +that required special workaround code during early boot, then a new +machine_desc could be added which implements the workarounds and only +matches on "ti,omap3-beagleboard". + +PowerPC uses a slightly different scheme where it calls the .probe() +hook from each machine_desc, and the first one returning TRUE is used. +However, this approach does not take into account the priority of the +compatible list, and probably should be avoided for new architecture +support. + +2.3 Runtime configuration +------------------------- +In most cases, a DT will be the sole method of communicating data from +firmware to the kernel, so also gets used to pass in runtime and +configuration data like the kernel parameters string and the location +of an initrd image. + +Most of this data is contained in the /chosen node, and when booting +Linux it will look something like this:: + + chosen { + bootargs = "console=ttyS0,115200 loglevel=8"; + initrd-start = <0xc8000000>; + initrd-end = <0xc8200000>; + }; + +The bootargs property contains the kernel arguments, and the initrd-* +properties define the address and size of an initrd blob. Note that +initrd-end is the first address after the initrd image, so this doesn't +match the usual semantic of struct resource. The chosen node may also +optionally contain an arbitrary number of additional properties for +platform-specific configuration data. + +During early boot, the architecture setup code calls of_scan_flat_dt() +several times with different helper callbacks to parse device tree +data before paging is setup. The of_scan_flat_dt() code scans through +the device tree and uses the helpers to extract information required +during early boot. Typically the early_init_dt_scan_chosen() helper +is used to parse the chosen node including kernel parameters, +early_init_dt_scan_root() to initialize the DT address space model, +and early_init_dt_scan_memory() to determine the size and +location of usable RAM. + +On ARM, the function setup_machine_fdt() is responsible for early +scanning of the device tree after selecting the correct machine_desc +that supports the board. + +2.4 Device population +--------------------- +After the board has been identified, and after the early configuration data +has been parsed, then kernel initialization can proceed in the normal +way. At some point in this process, unflatten_device_tree() is called +to convert the data into a more efficient runtime representation. +This is also when machine-specific setup hooks will get called, like +the machine_desc .init_early(), .init_irq() and .init_machine() hooks +on ARM. The remainder of this section uses examples from the ARM +implementation, but all architectures will do pretty much the same +thing when using a DT. + +As can be guessed by the names, .init_early() is used for any machine- +specific setup that needs to be executed early in the boot process, +and .init_irq() is used to set up interrupt handling. Using a DT +doesn't materially change the behaviour of either of these functions. +If a DT is provided, then both .init_early() and .init_irq() are able +to call any of the DT query functions (of_* in include/linux/of*.h) to +get additional data about the platform. + +The most interesting hook in the DT context is .init_machine() which +is primarily responsible for populating the Linux device model with +data about the platform. Historically this has been implemented on +embedded platforms by defining a set of static clock structures, +platform_devices, and other data in the board support .c file, and +registering it en-masse in .init_machine(). When DT is used, then +instead of hard coding static devices for each platform, the list of +devices can be obtained by parsing the DT, and allocating device +structures dynamically. + +The simplest case is when .init_machine() is only responsible for +registering a block of platform_devices. A platform_device is a concept +used by Linux for memory or I/O mapped devices which cannot be detected +by hardware, and for 'composite' or 'virtual' devices (more on those +later). While there is no 'platform device' terminology for the DT, +platform devices roughly correspond to device nodes at the root of the +tree and children of simple memory mapped bus nodes. + +About now is a good time to lay out an example. Here is part of the +device tree for the NVIDIA Tegra board:: + + /{ + compatible = "nvidia,harmony", "nvidia,tegra20"; + #address-cells = <1>; + #size-cells = <1>; + interrupt-parent = <&intc>; + + chosen { }; + aliases { }; + + memory { + device_type = "memory"; + reg = <0x00000000 0x40000000>; + }; + + soc { + compatible = "nvidia,tegra20-soc", "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + intc: interrupt-controller@50041000 { + compatible = "nvidia,tegra20-gic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x50041000 0x1000>, < 0x50040100 0x0100 >; + }; + + serial@70006300 { + compatible = "nvidia,tegra20-uart"; + reg = <0x70006300 0x100>; + interrupts = <122>; + }; + + i2s1: i2s@70002800 { + compatible = "nvidia,tegra20-i2s"; + reg = <0x70002800 0x100>; + interrupts = <77>; + codec = <&wm8903>; + }; + + i2c@7000c000 { + compatible = "nvidia,tegra20-i2c"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x7000c000 0x100>; + interrupts = <70>; + + wm8903: codec@1a { + compatible = "wlf,wm8903"; + reg = <0x1a>; + interrupts = <347>; + }; + }; + }; + + sound { + compatible = "nvidia,harmony-sound"; + i2s-controller = <&i2s1>; + i2s-codec = <&wm8903>; + }; + }; + +At .init_machine() time, Tegra board support code will need to look at +this DT and decide which nodes to create platform_devices for. +However, looking at the tree, it is not immediately obvious what kind +of device each node represents, or even if a node represents a device +at all. The /chosen, /aliases, and /memory nodes are informational +nodes that don't describe devices (although arguably memory could be +considered a device). The children of the /soc node are memory mapped +devices, but the codec@1a is an i2c device, and the sound node +represents not a device, but rather how other devices are connected +together to create the audio subsystem. I know what each device is +because I'm familiar with the board design, but how does the kernel +know what to do with each node? + +The trick is that the kernel starts at the root of the tree and looks +for nodes that have a 'compatible' property. First, it is generally +assumed that any node with a 'compatible' property represents a device +of some kind, and second, it can be assumed that any node at the root +of the tree is either directly attached to the processor bus, or is a +miscellaneous system device that cannot be described any other way. +For each of these nodes, Linux allocates and registers a +platform_device, which in turn may get bound to a platform_driver. + +Why is using a platform_device for these nodes a safe assumption? +Well, for the way that Linux models devices, just about all bus_types +assume that its devices are children of a bus controller. For +example, each i2c_client is a child of an i2c_master. Each spi_device +is a child of an SPI bus. Similarly for USB, PCI, MDIO, etc. The +same hierarchy is also found in the DT, where I2C device nodes only +ever appear as children of an I2C bus node. Ditto for SPI, MDIO, USB, +etc. The only devices which do not require a specific type of parent +device are platform_devices (and amba_devices, but more on that +later), which will happily live at the base of the Linux /sys/devices +tree. Therefore, if a DT node is at the root of the tree, then it +really probably is best registered as a platform_device. + +Linux board support code calls of_platform_populate(NULL, NULL, NULL, NULL) +to kick off discovery of devices at the root of the tree. The +parameters are all NULL because when starting from the root of the +tree, there is no need to provide a starting node (the first NULL), a +parent struct device (the last NULL), and we're not using a match +table (yet). For a board that only needs to register devices, +.init_machine() can be completely empty except for the +of_platform_populate() call. + +In the Tegra example, this accounts for the /soc and /sound nodes, but +what about the children of the SoC node? Shouldn't they be registered +as platform devices too? For Linux DT support, the generic behaviour +is for child devices to be registered by the parent's device driver at +driver .probe() time. So, an i2c bus device driver will register a +i2c_client for each child node, an SPI bus driver will register +its spi_device children, and similarly for other bus_types. +According to that model, a driver could be written that binds to the +SoC node and simply registers platform_devices for each of its +children. The board support code would allocate and register an SoC +device, a (theoretical) SoC device driver could bind to the SoC device, +and register platform_devices for /soc/interrupt-controller, /soc/serial, +/soc/i2s, and /soc/i2c in its .probe() hook. Easy, right? + +Actually, it turns out that registering children of some +platform_devices as more platform_devices is a common pattern, and the +device tree support code reflects that and makes the above example +simpler. The second argument to of_platform_populate() is an +of_device_id table, and any node that matches an entry in that table +will also get its child nodes registered. In the Tegra case, the code +can look something like this:: + + static void __init harmony_init_machine(void) + { + /* ... */ + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); + } + +"simple-bus" is defined in the Devicetree Specification as a property +meaning a simple memory mapped bus, so the of_platform_populate() code +could be written to just assume simple-bus compatible nodes will +always be traversed. However, we pass it in as an argument so that +board support code can always override the default behaviour. + +[Need to add discussion of adding i2c/spi/etc child devices] + +Appendix A: AMBA devices +------------------------ + +ARM Primecells are a certain kind of device attached to the ARM AMBA +bus which include some support for hardware detection and power +management. In Linux, struct amba_device and the amba_bus_type is +used to represent Primecell devices. However, the fiddly bit is that +not all devices on an AMBA bus are Primecells, and for Linux it is +typical for both amba_device and platform_device instances to be +siblings of the same bus segment. + +When using the DT, this creates problems for of_platform_populate() +because it must decide whether to register each node as either a +platform_device or an amba_device. This unfortunately complicates the +device creation model a little bit, but the solution turns out not to +be too invasive. If a node is compatible with "arm,amba-primecell", then +of_platform_populate() will register it as an amba_device instead of a +platform_device.
diff --git a/Documentation/devicetree/usage-model.txt b/Documentation/devicetree/usage-model.txt deleted file mode 100644 index 33a8aaa..0000000 --- a/Documentation/devicetree/usage-model.txt +++ /dev/null
@@ -1,415 +0,0 @@ -Linux and the Device Tree -------------------------- -The Linux usage model for device tree data - -Author: Grant Likely <grant.likely@secretlab.ca> - -This article describes how Linux uses the device tree. An overview of -the device tree data format can be found on the device tree usage page -at devicetree.org[1]. - -[1] http://devicetree.org/Device_Tree_Usage - -The "Open Firmware Device Tree", or simply Device Tree (DT), is a data -structure and language for describing hardware. More specifically, it -is a description of hardware that is readable by an operating system -so that the operating system doesn't need to hard code details of the -machine. - -Structurally, the DT is a tree, or acyclic graph with named nodes, and -nodes may have an arbitrary number of named properties encapsulating -arbitrary data. A mechanism also exists to create arbitrary -links from one node to another outside of the natural tree structure. - -Conceptually, a common set of usage conventions, called 'bindings', -is defined for how data should appear in the tree to describe typical -hardware characteristics including data busses, interrupt lines, GPIO -connections, and peripheral devices. - -As much as possible, hardware is described using existing bindings to -maximize use of existing support code, but since property and node -names are simply text strings, it is easy to extend existing bindings -or create new ones by defining new nodes and properties. Be wary, -however, of creating a new binding without first doing some homework -about what already exists. There are currently two different, -incompatible, bindings for i2c busses that came about because the new -binding was created without first investigating how i2c devices were -already being enumerated in existing systems. - -1. History ----------- -The DT was originally created by Open Firmware as part of the -communication method for passing data from Open Firmware to a client -program (like to an operating system). An operating system used the -Device Tree to discover the topology of the hardware at runtime, and -thereby support a majority of available hardware without hard coded -information (assuming drivers were available for all devices). - -Since Open Firmware is commonly used on PowerPC and SPARC platforms, -the Linux support for those architectures has for a long time used the -Device Tree. - -In 2005, when PowerPC Linux began a major cleanup and to merge 32-bit -and 64-bit support, the decision was made to require DT support on all -powerpc platforms, regardless of whether or not they used Open -Firmware. To do this, a DT representation called the Flattened Device -Tree (FDT) was created which could be passed to the kernel as a binary -blob without requiring a real Open Firmware implementation. U-Boot, -kexec, and other bootloaders were modified to support both passing a -Device Tree Binary (dtb) and to modify a dtb at boot time. DT was -also added to the PowerPC boot wrapper (arch/powerpc/boot/*) so that -a dtb could be wrapped up with the kernel image to support booting -existing non-DT aware firmware. - -Some time later, FDT infrastructure was generalized to be usable by -all architectures. At the time of this writing, 6 mainlined -architectures (arm, microblaze, mips, powerpc, sparc, and x86) and 1 -out of mainline (nios) have some level of DT support. - -2. Data Model -------------- -If you haven't already read the Device Tree Usage[1] page, -then go read it now. It's okay, I'll wait.... - -2.1 High Level View -------------------- -The most important thing to understand is that the DT is simply a data -structure that describes the hardware. There is nothing magical about -it, and it doesn't magically make all hardware configuration problems -go away. What it does do is provide a language for decoupling the -hardware configuration from the board and device driver support in the -Linux kernel (or any other operating system for that matter). Using -it allows board and device support to become data driven; to make -setup decisions based on data passed into the kernel instead of on -per-machine hard coded selections. - -Ideally, data driven platform setup should result in less code -duplication and make it easier to support a wide range of hardware -with a single kernel image. - -Linux uses DT data for three major purposes: -1) platform identification, -2) runtime configuration, and -3) device population. - -2.2 Platform Identification ---------------------------- -First and foremost, the kernel will use data in the DT to identify the -specific machine. In a perfect world, the specific platform shouldn't -matter to the kernel because all platform details would be described -perfectly by the device tree in a consistent and reliable manner. -Hardware is not perfect though, and so the kernel must identify the -machine during early boot so that it has the opportunity to run -machine-specific fixups. - -In the majority of cases, the machine identity is irrelevant, and the -kernel will instead select setup code based on the machine's core -CPU or SoC. On ARM for example, setup_arch() in -arch/arm/kernel/setup.c will call setup_machine_fdt() in -arch/arm/kernel/devtree.c which searches through the machine_desc -table and selects the machine_desc which best matches the device tree -data. It determines the best match by looking at the 'compatible' -property in the root device tree node, and comparing it with the -dt_compat list in struct machine_desc (which is defined in -arch/arm/include/asm/mach/arch.h if you're curious). - -The 'compatible' property contains a sorted list of strings starting -with the exact name of the machine, followed by an optional list of -boards it is compatible with sorted from most compatible to least. For -example, the root compatible properties for the TI BeagleBoard and its -successor, the BeagleBoard xM board might look like, respectively: - - compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3"; - compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3"; - -Where "ti,omap3-beagleboard-xm" specifies the exact model, it also -claims that it compatible with the OMAP 3450 SoC, and the omap3 family -of SoCs in general. You'll notice that the list is sorted from most -specific (exact board) to least specific (SoC family). - -Astute readers might point out that the Beagle xM could also claim -compatibility with the original Beagle board. However, one should be -cautioned about doing so at the board level since there is typically a -high level of change from one board to another, even within the same -product line, and it is hard to nail down exactly what is meant when one -board claims to be compatible with another. For the top level, it is -better to err on the side of caution and not claim one board is -compatible with another. The notable exception would be when one -board is a carrier for another, such as a CPU module attached to a -carrier board. - -One more note on compatible values. Any string used in a compatible -property must be documented as to what it indicates. Add -documentation for compatible strings in Documentation/devicetree/bindings. - -Again on ARM, for each machine_desc, the kernel looks to see if -any of the dt_compat list entries appear in the compatible property. -If one does, then that machine_desc is a candidate for driving the -machine. After searching the entire table of machine_descs, -setup_machine_fdt() returns the 'most compatible' machine_desc based -on which entry in the compatible property each machine_desc matches -against. If no matching machine_desc is found, then it returns NULL. - -The reasoning behind this scheme is the observation that in the majority -of cases, a single machine_desc can support a large number of boards -if they all use the same SoC, or same family of SoCs. However, -invariably there will be some exceptions where a specific board will -require special setup code that is not useful in the generic case. -Special cases could be handled by explicitly checking for the -troublesome board(s) in generic setup code, but doing so very quickly -becomes ugly and/or unmaintainable if it is more than just a couple of -cases. - -Instead, the compatible list allows a generic machine_desc to provide -support for a wide common set of boards by specifying "less -compatible" values in the dt_compat list. In the example above, -generic board support can claim compatibility with "ti,omap3" or -"ti,omap3450". If a bug was discovered on the original beagleboard -that required special workaround code during early boot, then a new -machine_desc could be added which implements the workarounds and only -matches on "ti,omap3-beagleboard". - -PowerPC uses a slightly different scheme where it calls the .probe() -hook from each machine_desc, and the first one returning TRUE is used. -However, this approach does not take into account the priority of the -compatible list, and probably should be avoided for new architecture -support. - -2.3 Runtime configuration -------------------------- -In most cases, a DT will be the sole method of communicating data from -firmware to the kernel, so also gets used to pass in runtime and -configuration data like the kernel parameters string and the location -of an initrd image. - -Most of this data is contained in the /chosen node, and when booting -Linux it will look something like this: - - chosen { - bootargs = "console=ttyS0,115200 loglevel=8"; - initrd-start = <0xc8000000>; - initrd-end = <0xc8200000>; - }; - -The bootargs property contains the kernel arguments, and the initrd-* -properties define the address and size of an initrd blob. Note that -initrd-end is the first address after the initrd image, so this doesn't -match the usual semantic of struct resource. The chosen node may also -optionally contain an arbitrary number of additional properties for -platform-specific configuration data. - -During early boot, the architecture setup code calls of_scan_flat_dt() -several times with different helper callbacks to parse device tree -data before paging is setup. The of_scan_flat_dt() code scans through -the device tree and uses the helpers to extract information required -during early boot. Typically the early_init_dt_scan_chosen() helper -is used to parse the chosen node including kernel parameters, -early_init_dt_scan_root() to initialize the DT address space model, -and early_init_dt_scan_memory() to determine the size and -location of usable RAM. - -On ARM, the function setup_machine_fdt() is responsible for early -scanning of the device tree after selecting the correct machine_desc -that supports the board. - -2.4 Device population ---------------------- -After the board has been identified, and after the early configuration data -has been parsed, then kernel initialization can proceed in the normal -way. At some point in this process, unflatten_device_tree() is called -to convert the data into a more efficient runtime representation. -This is also when machine-specific setup hooks will get called, like -the machine_desc .init_early(), .init_irq() and .init_machine() hooks -on ARM. The remainder of this section uses examples from the ARM -implementation, but all architectures will do pretty much the same -thing when using a DT. - -As can be guessed by the names, .init_early() is used for any machine- -specific setup that needs to be executed early in the boot process, -and .init_irq() is used to set up interrupt handling. Using a DT -doesn't materially change the behaviour of either of these functions. -If a DT is provided, then both .init_early() and .init_irq() are able -to call any of the DT query functions (of_* in include/linux/of*.h) to -get additional data about the platform. - -The most interesting hook in the DT context is .init_machine() which -is primarily responsible for populating the Linux device model with -data about the platform. Historically this has been implemented on -embedded platforms by defining a set of static clock structures, -platform_devices, and other data in the board support .c file, and -registering it en-masse in .init_machine(). When DT is used, then -instead of hard coding static devices for each platform, the list of -devices can be obtained by parsing the DT, and allocating device -structures dynamically. - -The simplest case is when .init_machine() is only responsible for -registering a block of platform_devices. A platform_device is a concept -used by Linux for memory or I/O mapped devices which cannot be detected -by hardware, and for 'composite' or 'virtual' devices (more on those -later). While there is no 'platform device' terminology for the DT, -platform devices roughly correspond to device nodes at the root of the -tree and children of simple memory mapped bus nodes. - -About now is a good time to lay out an example. Here is part of the -device tree for the NVIDIA Tegra board. - -/{ - compatible = "nvidia,harmony", "nvidia,tegra20"; - #address-cells = <1>; - #size-cells = <1>; - interrupt-parent = <&intc>; - - chosen { }; - aliases { }; - - memory { - device_type = "memory"; - reg = <0x00000000 0x40000000>; - }; - - soc { - compatible = "nvidia,tegra20-soc", "simple-bus"; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - intc: interrupt-controller@50041000 { - compatible = "nvidia,tegra20-gic"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0x50041000 0x1000>, < 0x50040100 0x0100 >; - }; - - serial@70006300 { - compatible = "nvidia,tegra20-uart"; - reg = <0x70006300 0x100>; - interrupts = <122>; - }; - - i2s1: i2s@70002800 { - compatible = "nvidia,tegra20-i2s"; - reg = <0x70002800 0x100>; - interrupts = <77>; - codec = <&wm8903>; - }; - - i2c@7000c000 { - compatible = "nvidia,tegra20-i2c"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x7000c000 0x100>; - interrupts = <70>; - - wm8903: codec@1a { - compatible = "wlf,wm8903"; - reg = <0x1a>; - interrupts = <347>; - }; - }; - }; - - sound { - compatible = "nvidia,harmony-sound"; - i2s-controller = <&i2s1>; - i2s-codec = <&wm8903>; - }; -}; - -At .init_machine() time, Tegra board support code will need to look at -this DT and decide which nodes to create platform_devices for. -However, looking at the tree, it is not immediately obvious what kind -of device each node represents, or even if a node represents a device -at all. The /chosen, /aliases, and /memory nodes are informational -nodes that don't describe devices (although arguably memory could be -considered a device). The children of the /soc node are memory mapped -devices, but the codec@1a is an i2c device, and the sound node -represents not a device, but rather how other devices are connected -together to create the audio subsystem. I know what each device is -because I'm familiar with the board design, but how does the kernel -know what to do with each node? - -The trick is that the kernel starts at the root of the tree and looks -for nodes that have a 'compatible' property. First, it is generally -assumed that any node with a 'compatible' property represents a device -of some kind, and second, it can be assumed that any node at the root -of the tree is either directly attached to the processor bus, or is a -miscellaneous system device that cannot be described any other way. -For each of these nodes, Linux allocates and registers a -platform_device, which in turn may get bound to a platform_driver. - -Why is using a platform_device for these nodes a safe assumption? -Well, for the way that Linux models devices, just about all bus_types -assume that its devices are children of a bus controller. For -example, each i2c_client is a child of an i2c_master. Each spi_device -is a child of an SPI bus. Similarly for USB, PCI, MDIO, etc. The -same hierarchy is also found in the DT, where I2C device nodes only -ever appear as children of an I2C bus node. Ditto for SPI, MDIO, USB, -etc. The only devices which do not require a specific type of parent -device are platform_devices (and amba_devices, but more on that -later), which will happily live at the base of the Linux /sys/devices -tree. Therefore, if a DT node is at the root of the tree, then it -really probably is best registered as a platform_device. - -Linux board support code calls of_platform_populate(NULL, NULL, NULL, NULL) -to kick off discovery of devices at the root of the tree. The -parameters are all NULL because when starting from the root of the -tree, there is no need to provide a starting node (the first NULL), a -parent struct device (the last NULL), and we're not using a match -table (yet). For a board that only needs to register devices, -.init_machine() can be completely empty except for the -of_platform_populate() call. - -In the Tegra example, this accounts for the /soc and /sound nodes, but -what about the children of the SoC node? Shouldn't they be registered -as platform devices too? For Linux DT support, the generic behaviour -is for child devices to be registered by the parent's device driver at -driver .probe() time. So, an i2c bus device driver will register a -i2c_client for each child node, an SPI bus driver will register -its spi_device children, and similarly for other bus_types. -According to that model, a driver could be written that binds to the -SoC node and simply registers platform_devices for each of its -children. The board support code would allocate and register an SoC -device, a (theoretical) SoC device driver could bind to the SoC device, -and register platform_devices for /soc/interrupt-controller, /soc/serial, -/soc/i2s, and /soc/i2c in its .probe() hook. Easy, right? - -Actually, it turns out that registering children of some -platform_devices as more platform_devices is a common pattern, and the -device tree support code reflects that and makes the above example -simpler. The second argument to of_platform_populate() is an -of_device_id table, and any node that matches an entry in that table -will also get its child nodes registered. In the Tegra case, the code -can look something like this: - -static void __init harmony_init_machine(void) -{ - /* ... */ - of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); -} - -"simple-bus" is defined in the Devicetree Specification as a property -meaning a simple memory mapped bus, so the of_platform_populate() code -could be written to just assume simple-bus compatible nodes will -always be traversed. However, we pass it in as an argument so that -board support code can always override the default behaviour. - -[Need to add discussion of adding i2c/spi/etc child devices] - -Appendix A: AMBA devices ------------------------- - -ARM Primecells are a certain kind of device attached to the ARM AMBA -bus which include some support for hardware detection and power -management. In Linux, struct amba_device and the amba_bus_type is -used to represent Primecell devices. However, the fiddly bit is that -not all devices on an AMBA bus are Primecells, and for Linux it is -typical for both amba_device and platform_device instances to be -siblings of the same bus segment. - -When using the DT, this creates problems for of_platform_populate() -because it must decide whether to register each node as either a -platform_device or an amba_device. This unfortunately complicates the -device creation model a little bit, but the solution turns out not to -be too invasive. If a node is compatible with "arm,amba-primecell", then -of_platform_populate() will register it as an amba_device instead of a -platform_device.
diff --git a/Documentation/doc-guide/maintainer-profile.rst b/Documentation/doc-guide/maintainer-profile.rst index 5afc0dd..755d39f 100644 --- a/Documentation/doc-guide/maintainer-profile.rst +++ b/Documentation/doc-guide/maintainer-profile.rst
@@ -6,7 +6,7 @@ The documentation "subsystem" is the central coordinating point for the kernel's documentation and associated infrastructure. It covers the hierarchy under Documentation/ (with the exception of -Documentation/device-tree), various utilities under scripts/ and, at least +Documentation/devicetree), various utilities under scripts/ and, at least some of the time, LICENSES/. It's worth noting, though, that the boundaries of this subsystem are rather
diff --git a/Documentation/doc-guide/parse-headers.rst b/Documentation/doc-guide/parse-headers.rst index f7135b0..5da0046f 100644 --- a/Documentation/doc-guide/parse-headers.rst +++ b/Documentation/doc-guide/parse-headers.rst
@@ -186,7 +186,7 @@ Copyright (c) 2016 by Mauro Carvalho Chehab <mchehab+samsung@kernel.org>. -License GPLv2: GNU GPL version 2 <http://gnu.org/licenses/gpl.html>. +License GPLv2: GNU GPL version 2 <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 72fc2e9..ef9519c3 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff
@@ -251,6 +251,7 @@ vmlinux.aout vmlinux.bin.all vmlinux.lds +vmlinux.symvers vmlinuz voffset.h vsyscall.lds
diff --git a/Documentation/driver-api/acpi/linuxized-acpica.rst b/Documentation/driver-api/acpi/linuxized-acpica.rst index 0ca8f15..6bee033 100644 --- a/Documentation/driver-api/acpi/linuxized-acpica.rst +++ b/Documentation/driver-api/acpi/linuxized-acpica.rst
@@ -175,9 +175,9 @@ B. acpica / master - "master" branch of the git repository at <https://github.com/acpica/acpica.git>. C. linux-pm / linux-next - "linux-next" branch of the git repository at - <http://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git>. + <https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git>. D. linux / master - "master" branch of the git repository at - <http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git>. + <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git>. Before the linuxized ACPICA patches are sent to the Linux ACPI community for review, there is a quality assurance build test process to reduce @@ -274,6 +274,6 @@ a diff file indicating the state of the current divergences:: # git clone https://github.com/acpica/acpica - # git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git + # git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git # cd acpica # generate/linux/divergences.sh -s ../linux
diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index c78db28..63dec76 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst
@@ -11,7 +11,7 @@ The three main components of this are: (1) dma-buf, representing a sg_table and exposed to userspace as a file descriptor to allow passing between devices, (2) fence, which provides a mechanism to signal when -one device as finished access, and (3) reservation, which manages the +one device has finished access, and (3) reservation, which manages the shared or exclusive fence(s) associated with the buffer. Shared DMA Buffers @@ -31,7 +31,7 @@ - implements and manages operations in :c:type:`struct dma_buf_ops <dma_buf_ops>` for the buffer, - allows other users to share the buffer by using dma_buf sharing APIs, - - manages the details of buffer allocation, wrapped int a :c:type:`struct + - manages the details of buffer allocation, wrapped in a :c:type:`struct dma_buf <dma_buf>`, - decides about the actual backing storage where this allocation happens, - and takes care of any migration of scatterlist - for all (shared) users of
diff --git a/Documentation/driver-api/driver-model/device.rst b/Documentation/driver-api/driver-model/device.rst index 2b868d4..b9b0223 100644 --- a/Documentation/driver-api/driver-model/device.rst +++ b/Documentation/driver-api/driver-model/device.rst
@@ -50,10 +50,10 @@ Attributes of devices can be exported by a device driver through sysfs. -Please see Documentation/filesystems/sysfs.txt for more information +Please see Documentation/filesystems/sysfs.rst for more information on how sysfs works. -As explained in Documentation/kobject.txt, device attributes must be +As explained in Documentation/core-api/kobject.rst, device attributes must be created before the KOBJ_ADD uevent is generated. The only way to realize that is by defining an attribute group.
diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index 46c1378..e0b58c3 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst
@@ -284,21 +284,13 @@ IIO devm_iio_device_alloc() - devm_iio_device_free() devm_iio_device_register() - devm_iio_device_unregister() devm_iio_kfifo_allocate() - devm_iio_kfifo_free() devm_iio_triggered_buffer_setup() - devm_iio_triggered_buffer_cleanup() devm_iio_trigger_alloc() - devm_iio_trigger_free() devm_iio_trigger_register() - devm_iio_trigger_unregister() devm_iio_channel_get() - devm_iio_channel_release() devm_iio_channel_get_all() - devm_iio_channel_release_all() INPUT devm_input_allocate_device() @@ -322,6 +314,7 @@ devm_platform_ioremap_resource() : calls devm_ioremap_resource() for platform device devm_platform_ioremap_resource_wc() devm_platform_ioremap_resource_byname() + devm_platform_get_and_ioremap_resource() devm_iounmap() pcim_iomap() pcim_iomap_regions() : do request_region() and iomap() on multiple BARs @@ -372,6 +365,11 @@ devm_mux_chip_register() devm_mux_control_get() +NET + devm_alloc_etherdev() + devm_alloc_etherdev_mqs() + devm_register_netdev() + PER-CPU MEM devm_alloc_percpu() devm_free_percpu()
diff --git a/Documentation/driver-api/driver-model/driver.rst b/Documentation/driver-api/driver-model/driver.rst index 63887b8..7d5040f 100644 --- a/Documentation/driver-api/driver-model/driver.rst +++ b/Documentation/driver-api/driver-model/driver.rst
@@ -4,7 +4,6 @@ See the kerneldoc for the struct device_driver. - Allocation ~~~~~~~~~~ @@ -167,9 +166,26 @@ A driver's probe() may return a negative errno value to indicate that the driver did not bind to this device, in which case it should have -released all resources it allocated:: +released all resources it allocated. - void (*sync_state)(struct device *dev); +Optionally, probe() may return -EPROBE_DEFER if the driver depends on +resources that are not yet available (e.g., supplied by a driver that +hasn't initialized yet). The driver core will put the device onto the +deferred probe list and will try to call it again later. If a driver +must defer, it should return -EPROBE_DEFER as early as possible to +reduce the amount of time spent on setup work that will need to be +unwound and reexecuted at a later time. + +.. warning:: + -EPROBE_DEFER must not be returned if probe() has already created + child devices, even if those child devices are removed again + in a cleanup path. If -EPROBE_DEFER is returned after a child + device has been registered, it may result in an infinite loop of + .probe() calls to the same driver. + +:: + + void (*sync_state) (struct device *dev); sync_state is called only once for a device. It's called when all the consumer devices of the device have successfully probed. The list of consumers of the @@ -212,6 +228,8 @@ not restricted to that. Use it whenever it makes sense to take an action after all the consumers of a device have probed:: +:: + int (*remove) (struct device *dev); remove is called to unbind a driver from a device. This may be @@ -224,11 +242,15 @@ device; i.e. anything in the device's driver_data field. If the device is still present, it should quiesce the device and place -it into a supported low-power state:: +it into a supported low-power state. + +:: int (*suspend) (struct device *dev, pm_message_t state); -suspend is called to put the device in a low power state:: +suspend is called to put the device in a low power state. + +:: int (*resume) (struct device *dev);
diff --git a/Documentation/driver-api/driver-model/overview.rst b/Documentation/driver-api/driver-model/overview.rst index d4d1e9b..e98d0ab 100644 --- a/Documentation/driver-api/driver-model/overview.rst +++ b/Documentation/driver-api/driver-model/overview.rst
@@ -121,4 +121,4 @@ More information about the sysfs directory layout can be found in the other documents in this directory and in the file -Documentation/filesystems/sysfs.txt. +Documentation/filesystems/sysfs.rst.
diff --git a/Documentation/driver-api/gpio/board.rst b/Documentation/driver-api/gpio/board.rst index ce91518..191fa86 100644 --- a/Documentation/driver-api/gpio/board.rst +++ b/Documentation/driver-api/gpio/board.rst
@@ -113,13 +113,15 @@ GPIOs are mapped by the means of tables of lookups, containing instances of the gpiod_lookup structure. Two macros are defined to help declaring such mappings:: - GPIO_LOOKUP(chip_label, chip_hwnum, con_id, flags) - GPIO_LOOKUP_IDX(chip_label, chip_hwnum, con_id, idx, flags) + GPIO_LOOKUP(key, chip_hwnum, con_id, flags) + GPIO_LOOKUP_IDX(key, chip_hwnum, con_id, idx, flags) where - - chip_label is the label of the gpiod_chip instance providing the GPIO - - chip_hwnum is the hardware number of the GPIO within the chip + - key is either the label of the gpiod_chip instance providing the GPIO, or + the GPIO line name + - chip_hwnum is the hardware number of the GPIO within the chip, or U16_MAX + to indicate that key is a GPIO line name - con_id is the name of the GPIO function from the device point of view. It can be NULL, in which case it will match any function. - idx is the index of the GPIO within the function. @@ -135,7 +137,10 @@ In the future, these flags might be extended to support more properties. -Note that GPIO_LOOKUP() is just a shortcut to GPIO_LOOKUP_IDX() where idx = 0. +Note that: + 1. GPIO line names are not guaranteed to be globally unique, so the first + match found will be used. + 2. GPIO_LOOKUP() is just a shortcut to GPIO_LOOKUP_IDX() where idx = 0. A lookup table can then be defined as follows, with an empty entry defining its end. The 'dev_id' field of the table is the identifier of the device that will
diff --git a/Documentation/driver-api/iio/triggers.rst b/Documentation/driver-api/iio/triggers.rst index 5c2156d..dfd7ba3 100644 --- a/Documentation/driver-api/iio/triggers.rst +++ b/Documentation/driver-api/iio/triggers.rst
@@ -4,9 +4,7 @@ * struct :c:type:`iio_trigger` — industrial I/O trigger device * :c:func:`devm_iio_trigger_alloc` — Resource-managed iio_trigger_alloc -* :c:func:`devm_iio_trigger_free` — Resource-managed iio_trigger_free * :c:func:`devm_iio_trigger_register` — Resource-managed iio_trigger_register -* :c:func:`devm_iio_trigger_unregister` — Resource-managed iio_trigger_unregister * :c:func:`iio_trigger_validate_own_device` — Check if a trigger and IIO device belong to the same device
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index dcc47c0..6567187 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst
@@ -39,6 +39,7 @@ spi i2c ipmb + ipmi i3c/index interconnect devfreq
diff --git a/Documentation/driver-api/infiniband.rst b/Documentation/driver-api/infiniband.rst index 1a3116f..30e142c 100644 --- a/Documentation/driver-api/infiniband.rst +++ b/Documentation/driver-api/infiniband.rst
@@ -37,9 +37,6 @@ .. kernel-doc:: drivers/infiniband/core/ud_header.c :export: -.. kernel-doc:: drivers/infiniband/core/fmr_pool.c - :export: - .. kernel-doc:: drivers/infiniband/core/umem.c :export:
diff --git a/Documentation/IPMI.txt b/Documentation/driver-api/ipmi.rst similarity index 100% rename from Documentation/IPMI.txt rename to Documentation/driver-api/ipmi.rst
diff --git a/Documentation/driver-api/mtdnand.rst b/Documentation/driver-api/mtdnand.rst index 5544765..0bf8d6e 100644 --- a/Documentation/driver-api/mtdnand.rst +++ b/Documentation/driver-api/mtdnand.rst
@@ -276,8 +276,10 @@ #ifdef MODULE static void __exit board_cleanup (void) { - /* Release resources, unregister device */ - nand_release (mtd_to_nand(board_mtd)); + /* Unregister device */ + WARN_ON(mtd_device_unregister(board_mtd)); + /* Release resources */ + nand_cleanup(mtd_to_nand(board_mtd)); /* unmap physical address */ iounmap(baseaddr);
diff --git a/Documentation/driver-api/nvdimm/nvdimm.rst b/Documentation/driver-api/nvdimm/nvdimm.rst index 08f855c..79c0fd3 100644 --- a/Documentation/driver-api/nvdimm/nvdimm.rst +++ b/Documentation/driver-api/nvdimm/nvdimm.rst
@@ -278,8 +278,8 @@ be contiguous in DPA-space. This bus is provided by the kernel under the device - /sys/devices/platform/nfit_test.0 when CONFIG_NFIT_TEST is enabled and - the nfit_test.ko module is loaded. This not only test LIBNVDIMM but the + /sys/devices/platform/nfit_test.0 when the nfit_test.ko module from + tools/testing/nvdimm is loaded. This not only test LIBNVDIMM but the acpi_nfit.ko driver as well.
diff --git a/Documentation/driver-api/pm/cpuidle.rst b/Documentation/driver-api/pm/cpuidle.rst index 006cf6d..3588bf0 100644 --- a/Documentation/driver-api/pm/cpuidle.rst +++ b/Documentation/driver-api/pm/cpuidle.rst
@@ -68,9 +68,8 @@ governor currently in use, or the name of the new governor was passed to the kernel as the value of the ``cpuidle.governor=`` command line parameter, the new governor will be used from that point on (there can be only one ``CPUIdle`` -governor in use at a time). Also, if ``cpuidle_sysfs_switch`` is passed to the -kernel in the command line, user space can choose the ``CPUIdle`` governor to -use at run time via ``sysfs``. +governor in use at a time). Also, user space can choose the ``CPUIdle`` +governor to use at run time via ``sysfs``. Once registered, ``CPUIdle`` governors cannot be unregistered, so it is not practical to put them into loadable kernel modules.
diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst index f66c7b9..946ad0b 100644 --- a/Documentation/driver-api/pm/devices.rst +++ b/Documentation/driver-api/pm/devices.rst
@@ -349,7 +349,7 @@ PM core will skip the ``suspend``, ``suspend_late`` and ``suspend_noirq`` phases as well as all of the corresponding phases of the subsequent device resume for all of these devices. In that case, - the ``->complete`` callback will be invoked directly after the + the ``->complete`` callback will be the next one invoked after the ``->prepare`` callback and is entirely responsible for putting the device into a consistent state as appropriate. @@ -361,9 +361,9 @@ runtime PM disabled. This feature also can be controlled by device drivers by using the - ``DPM_FLAG_NEVER_SKIP`` and ``DPM_FLAG_SMART_PREPARE`` driver power - management flags. [Typically, they are set at the time the driver is - probed against the device in question by passing them to the + ``DPM_FLAG_NO_DIRECT_COMPLETE`` and ``DPM_FLAG_SMART_PREPARE`` driver + power management flags. [Typically, they are set at the time the driver + is probed against the device in question by passing them to the :c:func:`dev_pm_set_driver_flags` helper function.] If the first of these flags is set, the PM core will not apply the direct-complete procedure described above to the given device and, consequenty, to any @@ -383,11 +383,15 @@ ``->suspend`` methods provided by subsystems (bus types and PM domains in particular) must follow an additional rule regarding what can be done to the devices before their drivers' ``->suspend`` methods are called. - Namely, they can only resume the devices from runtime suspend by - calling :c:func:`pm_runtime_resume` for them, if that is necessary, and + Namely, they may resume the devices from runtime suspend by + calling :c:func:`pm_runtime_resume` for them, if that is necessary, but they must not update the state of the devices in any other way at that time (in case the drivers need to resume the devices from runtime - suspend in their ``->suspend`` methods). + suspend in their ``->suspend`` methods). In fact, the PM core prevents + subsystems or drivers from putting devices into runtime suspend at + these times by calling :c:func:`pm_runtime_get_noresume` before issuing + the ``->prepare`` callback (and calling :c:func:`pm_runtime_put` after + issuing the ``->complete`` callback). 3. For a number of devices it is convenient to split suspend into the "quiesce device" and "save device state" phases, in which cases @@ -459,22 +463,22 @@ Note, however, that new children may be registered below the device as soon as the ``->resume`` callbacks occur; it's not necessary to wait - until the ``complete`` phase with that. + until the ``complete`` phase runs. Moreover, if the preceding ``->prepare`` callback returned a positive number, the device may have been left in runtime suspend throughout the - whole system suspend and resume (the ``suspend``, ``suspend_late``, - ``suspend_noirq`` phases of system suspend and the ``resume_noirq``, - ``resume_early``, ``resume`` phases of system resume may have been - skipped for it). In that case, the ``->complete`` callback is entirely + whole system suspend and resume (its ``->suspend``, ``->suspend_late``, + ``->suspend_noirq``, ``->resume_noirq``, + ``->resume_early``, and ``->resume`` callbacks may have been + skipped). In that case, the ``->complete`` callback is entirely responsible for putting the device into a consistent state after system suspend if necessary. [For example, it may need to queue up a runtime resume request for the device for this purpose.] To check if that is the case, the ``->complete`` callback can consult the device's - ``power.direct_complete`` flag. Namely, if that flag is set when the - ``->complete`` callback is being run, it has been called directly after - the preceding ``->prepare`` and special actions may be required - to make the device work correctly afterward. + ``power.direct_complete`` flag. If that flag is set when the + ``->complete`` callback is being run then the direct-complete mechanism + was used, and special actions may be required to make the device work + correctly afterward. At the end of these phases, drivers should be as functional as they were before suspending: I/O can be performed using DMA and IRQs, and the relevant clocks are @@ -575,10 +579,12 @@ The ``->poweroff``, ``->poweroff_late`` and ``->poweroff_noirq`` callbacks should do essentially the same things as the ``->suspend``, ``->suspend_late`` -and ``->suspend_noirq`` callbacks, respectively. The only notable difference is +and ``->suspend_noirq`` callbacks, respectively. A notable difference is that they need not store the device register values, because the registers should already have been stored during the ``freeze``, ``freeze_late`` or -``freeze_noirq`` phases. +``freeze_noirq`` phases. Also, on many machines the firmware will power-down +the entire system, so it is not necessary for the callback to put the device in +a low-power state. Leaving Hibernation @@ -764,70 +770,119 @@ If it is necessary to resume a device from runtime suspend during a system-wide transition into a sleep state, that can be done by calling -:c:func:`pm_runtime_resume` for it from the ``->suspend`` callback (or its -couterpart for transitions related to hibernation) of either the device's driver -or a subsystem responsible for it (for example, a bus type or a PM domain). -That is guaranteed to work by the requirement that subsystems must not change -the state of devices (possibly except for resuming them from runtime suspend) +:c:func:`pm_runtime_resume` from the ``->suspend`` callback (or the ``->freeze`` +or ``->poweroff`` callback for transitions related to hibernation) of either the +device's driver or its subsystem (for example, a bus type or a PM domain). +However, subsystems must not otherwise change the runtime status of devices from their ``->prepare`` and ``->suspend`` callbacks (or equivalent) *before* invoking device drivers' ``->suspend`` callbacks (or equivalent). +.. _smart_suspend_flag: + +The ``DPM_FLAG_SMART_SUSPEND`` Driver Flag +------------------------------------------ + Some bus types and PM domains have a policy to resume all devices from runtime suspend upfront in their ``->suspend`` callbacks, but that may not be really -necessary if the driver of the device can cope with runtime-suspended devices. -The driver can indicate that by setting ``DPM_FLAG_SMART_SUSPEND`` in -:c:member:`power.driver_flags` at the probe time, by passing it to the -:c:func:`dev_pm_set_driver_flags` helper. That also may cause middle-layer code +necessary if the device's driver can cope with runtime-suspended devices. +The driver can indicate this by setting ``DPM_FLAG_SMART_SUSPEND`` in +:c:member:`power.driver_flags` at probe time, with the assistance of the +:c:func:`dev_pm_set_driver_flags` helper routine. + +Setting that flag causes the PM core and middle-layer code (bus types, PM domains etc.) to skip the ``->suspend_late`` and ``->suspend_noirq`` callbacks provided by the driver if the device remains in -runtime suspend at the beginning of the ``suspend_late`` phase of system-wide -suspend (or in the ``poweroff_late`` phase of hibernation), when runtime PM -has been disabled for it, under the assumption that its state should not change -after that point until the system-wide transition is over (the PM core itself -does that for devices whose "noirq", "late" and "early" system-wide PM callbacks -are executed directly by it). If that happens, the driver's system-wide resume -callbacks, if present, may still be invoked during the subsequent system-wide -resume transition and the device's runtime power management status may be set -to "active" before enabling runtime PM for it, so the driver must be prepared to -cope with the invocation of its system-wide resume callbacks back-to-back with -its ``->runtime_suspend`` one (without the intervening ``->runtime_resume`` and -so on) and the final state of the device must reflect the "active" runtime PM -status in that case. +runtime suspend throughout those phases of the system-wide suspend (and +similarly for the "freeze" and "poweroff" parts of system hibernation). +[Otherwise the same driver +callback might be executed twice in a row for the same device, which would not +be valid in general.] If the middle-layer system-wide PM callbacks are present +for the device then they are responsible for skipping these driver callbacks; +if not then the PM core skips them. The subsystem callback routines can +determine whether they need to skip the driver callbacks by testing the return +value from the :c:func:`dev_pm_skip_suspend` helper function. + +In addition, with ``DPM_FLAG_SMART_SUSPEND`` set, the driver's ``->thaw_noirq`` +and ``->thaw_early`` callbacks are skipped in hibernation if the device remained +in runtime suspend throughout the preceding "freeze" transition. Again, if the +middle-layer callbacks are present for the device, they are responsible for +doing this, otherwise the PM core takes care of it. + + +The ``DPM_FLAG_MAY_SKIP_RESUME`` Driver Flag +-------------------------------------------- During system-wide resume from a sleep state it's easiest to put devices into the full-power state, as explained in :file:`Documentation/power/runtime_pm.rst`. [Refer to that document for more information regarding this particular issue as well as for information on the device runtime power management framework in -general.] - -However, it often is desirable to leave devices in suspend after system -transitions to the working state, especially if those devices had been in +general.] However, it often is desirable to leave devices in suspend after +system transitions to the working state, especially if those devices had been in runtime suspend before the preceding system-wide suspend (or analogous) -transition. Device drivers can use the ``DPM_FLAG_LEAVE_SUSPENDED`` flag to -indicate to the PM core (and middle-layer code) that they prefer the specific -devices handled by them to be left suspended and they have no problems with -skipping their system-wide resume callbacks for this reason. Whether or not the -devices will actually be left in suspend may depend on their state before the -given system suspend-resume cycle and on the type of the system transition under -way. In particular, devices are not left suspended if that transition is a -restore from hibernation, as device states are not guaranteed to be reflected -by the information stored in the hibernation image in that case. +transition. -The middle-layer code involved in the handling of the device is expected to -indicate to the PM core if the device may be left in suspend by setting its -:c:member:`power.may_skip_resume` status bit which is checked by the PM core -during the "noirq" phase of the preceding system-wide suspend (or analogous) -transition. The middle layer is then responsible for handling the device as -appropriate in its "noirq" resume callback, which is executed regardless of -whether or not the device is left suspended, but the other resume callbacks -(except for ``->complete``) will be skipped automatically by the PM core if the -device really can be left in suspend. +To that end, device drivers can use the ``DPM_FLAG_MAY_SKIP_RESUME`` flag to +indicate to the PM core and middle-layer code that they allow their "noirq" and +"early" resume callbacks to be skipped if the device can be left in suspend +after system-wide PM transitions to the working state. Whether or not that is +the case generally depends on the state of the device before the given system +suspend-resume cycle and on the type of the system transition under way. +In particular, the "thaw" and "restore" transitions related to hibernation are +not affected by ``DPM_FLAG_MAY_SKIP_RESUME`` at all. [All callbacks are +issued during the "restore" transition regardless of the flag settings, +and whether or not any driver callbacks +are skipped during the "thaw" transition depends whether or not the +``DPM_FLAG_SMART_SUSPEND`` flag is set (see `above <smart_suspend_flag_>`_). +In addition, a device is not allowed to remain in runtime suspend if any of its +children will be returned to full power.] -For devices whose "noirq", "late" and "early" driver callbacks are invoked -directly by the PM core, all of the system-wide resume callbacks are skipped if -``DPM_FLAG_LEAVE_SUSPENDED`` is set and the device is in runtime suspend during -the ``suspend_noirq`` (or analogous) phase or the transition under way is a -proper system suspend (rather than anything related to hibernation) and the -device's wakeup settings are suitable for runtime PM (that is, it cannot -generate wakeup signals at all or it is allowed to wake up the system from -sleep). +The ``DPM_FLAG_MAY_SKIP_RESUME`` flag is taken into account in combination with +the :c:member:`power.may_skip_resume` status bit set by the PM core during the +"suspend" phase of suspend-type transitions. If the driver or the middle layer +has a reason to prevent the driver's "noirq" and "early" resume callbacks from +being skipped during the subsequent system resume transition, it should +clear :c:member:`power.may_skip_resume` in its ``->suspend``, ``->suspend_late`` +or ``->suspend_noirq`` callback. [Note that the drivers setting +``DPM_FLAG_SMART_SUSPEND`` need to clear :c:member:`power.may_skip_resume` in +their ``->suspend`` callback in case the other two are skipped.] + +Setting the :c:member:`power.may_skip_resume` status bit along with the +``DPM_FLAG_MAY_SKIP_RESUME`` flag is necessary, but generally not sufficient, +for the driver's "noirq" and "early" resume callbacks to be skipped. Whether or +not they should be skipped can be determined by evaluating the +:c:func:`dev_pm_skip_resume` helper function. + +If that function returns ``true``, the driver's "noirq" and "early" resume +callbacks should be skipped and the device's runtime PM status will be set to +"suspended" by the PM core. Otherwise, if the device was runtime-suspended +during the preceding system-wide suspend transition and its +``DPM_FLAG_SMART_SUSPEND`` is set, its runtime PM status will be set to +"active" by the PM core. [Hence, the drivers that do not set +``DPM_FLAG_SMART_SUSPEND`` should not expect the runtime PM status of their +devices to be changed from "suspended" to "active" by the PM core during +system-wide resume-type transitions.] + +If the ``DPM_FLAG_MAY_SKIP_RESUME`` flag is not set for a device, but +``DPM_FLAG_SMART_SUSPEND`` is set and the driver's "late" and "noirq" suspend +callbacks are skipped, its system-wide "noirq" and "early" resume callbacks, if +present, are invoked as usual and the device's runtime PM status is set to +"active" by the PM core before enabling runtime PM for it. In that case, the +driver must be prepared to cope with the invocation of its system-wide resume +callbacks back-to-back with its ``->runtime_suspend`` one (without the +intervening ``->runtime_resume`` and system-wide suspend callbacks) and the +final state of the device must reflect the "active" runtime PM status in that +case. [Note that this is not a problem at all if the driver's +``->suspend_late`` callback pointer points to the same function as its +``->runtime_suspend`` one and its ``->resume_early`` callback pointer points to +the same function as the ``->runtime_resume`` one, while none of the other +system-wide suspend-resume callbacks of the driver are present, for example.] + +Likewise, if ``DPM_FLAG_MAY_SKIP_RESUME`` is set for a device, its driver's +system-wide "noirq" and "early" resume callbacks may be skipped while its "late" +and "noirq" suspend callbacks may have been executed (in principle, regardless +of whether or not ``DPM_FLAG_SMART_SUSPEND`` is set). In that case, the driver +needs to be able to cope with the invocation of its ``->runtime_resume`` +callback back-to-back with its "late" and "noirq" suspend ones. [For instance, +that is not a concern if the driver sets both ``DPM_FLAG_SMART_SUSPEND`` and +``DPM_FLAG_MAY_SKIP_RESUME`` and uses the same pair of suspend/resume callback +functions for runtime PM and system-wide suspend/resume.]
diff --git a/Documentation/driver-api/soundwire/stream.rst b/Documentation/driver-api/soundwire/stream.rst index 8bceece..1b38607 100644 --- a/Documentation/driver-api/soundwire/stream.rst +++ b/Documentation/driver-api/soundwire/stream.rst
@@ -75,8 +75,33 @@ | (Data) | +---------------+ +Example 4: Stereo Stream with L and R channels is rendered by +Master. Both of the L and R channels are received by two different +Slaves. Master and both Slaves are using single port handling +L+R. Each Slave device processes the L + R data locally, typically +based on static configuration or dynamic orientation, and may drive +one or more speakers. :: -Example 4: Stereo Stream with L and R channel is rendered by two different + +---------------+ Clock Signal +---------------+ + | Master +---------+------------------------+ Slave | + | Interface | | | Interface | + | | | | 1 | + | | | Data Signal | | + | L + R +---+------------------------------+ L + R | + | (Data) | | | Data Direction | (Data) | + +---------------+ | | +-------------> +---------------+ + | | + | | + | | +---------------+ + | +----------------------> | Slave | + | | Interface | + | | 2 | + | | | + +----------------------------> | L + R | + | (Data) | + +---------------+ + +Example 5: Stereo Stream with L and R channel is rendered by two different Ports of the Master and is received by only single Port of the Slave interface. :: @@ -101,7 +126,7 @@ +--------------------+ | | +----------------+ -Example 5: Stereo Stream with L and R channel is rendered by 2 Masters, each +Example 6: Stereo Stream with L and R channel is rendered by 2 Masters, each rendering one channel, and is received by two different Slaves, each receiving one channel. Both Masters and both Slaves are using single port. :: @@ -123,12 +148,70 @@ | (Data) | Data Direction | (Data) | +---------------+ +-----------------------> +---------------+ -Note: In multi-link cases like above, to lock, one would acquire a global +Example 7: Stereo Stream with L and R channel is rendered by 2 +Masters, each rendering both channels. Each Slave receives L + R. This +is the same application as Example 4 but with Slaves placed on +separate links. :: + + +---------------+ Clock Signal +---------------+ + | Master +----------------------------------+ Slave | + | Interface | | Interface | + | 1 | | 1 | + | | Data Signal | | + | L + R +----------------------------------+ L + R | + | (Data) | Data Direction | (Data) | + +---------------+ +-----------------------> +---------------+ + + +---------------+ Clock Signal +---------------+ + | Master +----------------------------------+ Slave | + | Interface | | Interface | + | 2 | | 2 | + | | Data Signal | | + | L + R +----------------------------------+ L + R | + | (Data) | Data Direction | (Data) | + +---------------+ +-----------------------> +---------------+ + +Example 8: 4-channel Stream is rendered by 2 Masters, each rendering a +2 channels. Each Slave receives 2 channels. :: + + +---------------+ Clock Signal +---------------+ + | Master +----------------------------------+ Slave | + | Interface | | Interface | + | 1 | | 1 | + | | Data Signal | | + | L1 + R1 +----------------------------------+ L1 + R1 | + | (Data) | Data Direction | (Data) | + +---------------+ +-----------------------> +---------------+ + + +---------------+ Clock Signal +---------------+ + | Master +----------------------------------+ Slave | + | Interface | | Interface | + | 2 | | 2 | + | | Data Signal | | + | L2 + R2 +----------------------------------+ L2 + R2 | + | (Data) | Data Direction | (Data) | + +---------------+ +-----------------------> +---------------+ + +Note1: In multi-link cases like above, to lock, one would acquire a global lock and then go on locking bus instances. But, in this case the caller framework(ASoC DPCM) guarantees that stream operations on a card are always serialized. So, there is no race condition and hence no need for global lock. +Note2: A Slave device may be configured to receive all channels +transmitted on a link for a given Stream (Example 4) or just a subset +of the data (Example 3). The configuration of the Slave device is not +handled by a SoundWire subsystem API, but instead by the +snd_soc_dai_set_tdm_slot() API. The platform or machine driver will +typically configure which of the slots are used. For Example 4, the +same slots would be used by all Devices, while for Example 3 the Slave +Device1 would use e.g. Slot 0 and Slave device2 slot 1. + +Note3: Multiple Sink ports can extract the same information for the +same bitSlots in the SoundWire frame, however multiple Source ports +shall be configured with different bitSlot configurations. This is the +same limitation as with I2S/PCM TDM usages. + SoundWire Stream Management flow ================================
diff --git a/Documentation/driver-api/soundwire/summary.rst b/Documentation/driver-api/soundwire/summary.rst index 8193125..01dcb95 100644 --- a/Documentation/driver-api/soundwire/summary.rst +++ b/Documentation/driver-api/soundwire/summary.rst
@@ -101,10 +101,11 @@ .. code-block:: c - int sdw_add_bus_master(struct sdw_bus *bus) + int sdw_bus_master_add(struct sdw_bus *bus, + struct device *parent, + struct fwnode_handle) { - if (!bus->dev) - return -ENODEV; + sdw_master_device_add(bus, parent, fwnode); mutex_init(&bus->lock); INIT_LIST_HEAD(&bus->slaves);
diff --git a/Documentation/driver-api/thermal/cpu-idle-cooling.rst b/Documentation/driver-api/thermal/cpu-idle-cooling.rst index a1c3ede..b9f34ce 100644 --- a/Documentation/driver-api/thermal/cpu-idle-cooling.rst +++ b/Documentation/driver-api/thermal/cpu-idle-cooling.rst
@@ -1,3 +1,6 @@ +================ +CPU Idle Cooling +================ Situation: ----------
diff --git a/Documentation/driver-api/thermal/index.rst b/Documentation/driver-api/thermal/index.rst index 5ba61d1..4cb0b9b 100644 --- a/Documentation/driver-api/thermal/index.rst +++ b/Documentation/driver-api/thermal/index.rst
@@ -8,6 +8,7 @@ :maxdepth: 1 cpu-cooling-api + cpu-idle-cooling sysfs-api power_allocator
diff --git a/Documentation/driver-api/usb/bulk-streams.rst b/Documentation/driver-api/usb/bulk-streams.rst index 99b515b..eeefe58 100644 --- a/Documentation/driver-api/usb/bulk-streams.rst +++ b/Documentation/driver-api/usb/bulk-streams.rst
@@ -9,9 +9,9 @@ queued at once. Streams are defined in sections 4.4.6.4 and 8.12.1.4 of the Universal Serial Bus -3.0 specification at http://www.usb.org/developers/docs/ The USB Attached SCSI +3.0 specification at https://www.usb.org/developers/docs/ The USB Attached SCSI Protocol, which uses streams to queue multiple SCSI commands, can be found on -the T10 website (http://t10.org/). +the T10 website (https://t10.org/). Device-side implications
diff --git a/Documentation/driver-api/usb/writing_musb_glue_layer.rst b/Documentation/driver-api/usb/writing_musb_glue_layer.rst index 5bf7152..10416cc 100644 --- a/Documentation/driver-api/usb/writing_musb_glue_layer.rst +++ b/Documentation/driver-api/usb/writing_musb_glue_layer.rst
@@ -707,12 +707,12 @@ Resources ========= -USB Home Page: http://www.usb.org +USB Home Page: https://www.usb.org -linux-usb Mailing List Archives: http://marc.info/?l=linux-usb +linux-usb Mailing List Archives: https://marc.info/?l=linux-usb USB On-the-Go Basics: -http://www.maximintegrated.com/app-notes/index.mvp/id/1822 +https://www.maximintegrated.com/app-notes/index.mvp/id/1822 :ref:`Writing USB Device Drivers <writing-usb-driver>`
diff --git a/Documentation/fb/efifb.rst b/Documentation/fb/efifb.rst index 04840331a..6badff6 100644 --- a/Documentation/fb/efifb.rst +++ b/Documentation/fb/efifb.rst
@@ -2,8 +2,10 @@ What is efifb? ============== -This is a generic EFI platform driver for Intel based Apple computers. -efifb is only for EFI booted Intel Macs. +This is a generic EFI platform driver for systems with UEFI firmware. The +system must be booted via the EFI stub for this to be usable. efifb supports +both firmware with Graphics Output Protocol (GOP) displays as well as older +systems with only Universal Graphics Adapter (UGA) displays. Supported Hardware ================== @@ -12,11 +14,14 @@ - Macbook - Macbook Pro 15"/17" - MacMini +- ARM/ARM64/X86 systems with UEFI firmware How to use it? ============== -efifb does not have any kind of autodetection of your machine. +For UGA displays, efifb does not have any kind of autodetection of your +machine. + You have to add the following kernel parameters in your elilo.conf:: Macbook : @@ -28,6 +33,9 @@ Macbook Pro 17", iMac 20" : video=efifb:i20 +For GOP displays, efifb can autodetect the display's resolution and framebuffer +address, so these should work out of the box without any special parameters. + Accepted options: ======= =========================================================== @@ -36,4 +44,28 @@ when large amounts of console data are written. ======= =========================================================== +Options for GOP displays: + +mode=n + The EFI stub will set the mode of the display to mode number n if + possible. + +<xres>x<yres>[-(rgb|bgr|<bpp>)] + The EFI stub will search for a display mode that matches the specified + horizontal and vertical resolution, and optionally bit depth, and set + the mode of the display to it if one is found. The bit depth can either + "rgb" or "bgr" to match specifically those pixel formats, or a number + for a mode with matching bits per pixel. + +auto + The EFI stub will choose the mode with the highest resolution (product + of horizontal and vertical resolution). If there are multiple modes + with the highest resolution, it will choose one with the highest color + depth. + +list + The EFI stub will list out all the display modes that are available. A + specific mode can then be chosen using one of the above options for the + next boot. + Edgar Hucek <gimli@dark-green.com>
diff --git a/Documentation/features/core/eBPF-JIT/arch-support.txt b/Documentation/features/core/eBPF-JIT/arch-support.txt index 9ae6e8d..9ed964f 100644 --- a/Documentation/features/core/eBPF-JIT/arch-support.txt +++ b/Documentation/features/core/eBPF-JIT/arch-support.txt
@@ -23,7 +23,7 @@ | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | ok | | sh: | TODO | | sparc: | ok |
diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt index 304dcd4..6ff3854 100644 --- a/Documentation/features/debug/KASAN/arch-support.txt +++ b/Documentation/features/debug/KASAN/arch-support.txt
@@ -22,9 +22,9 @@ | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | - | powerpc: | TODO | - | riscv: | TODO | - | s390: | TODO | + | powerpc: | ok | + | riscv: | ok | + | s390: | ok | | sh: | TODO | | sparc: | TODO | | um: | TODO |
diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt new file mode 100644 index 0000000..c527d05 --- /dev/null +++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
@@ -0,0 +1,34 @@ +# +# Feature name: debug-vm-pgtable +# Kconfig: ARCH_HAS_DEBUG_VM_PGTABLE +# description: arch supports pgtable tests for semantics compliance +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | ok | + | arm: | TODO | + | arm64: | ok | + | c6x: | TODO | + | csky: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m68k: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | nds32: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | riscv: | TODO | + | s390: | ok | + | sh: | TODO | + | sparc: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + -----------------------
diff --git a/Documentation/features/debug/gcov-profile-all/arch-support.txt b/Documentation/features/debug/gcov-profile-all/arch-support.txt index 6fb2b06..210256f 100644 --- a/Documentation/features/debug/gcov-profile-all/arch-support.txt +++ b/Documentation/features/debug/gcov-profile-all/arch-support.txt
@@ -11,7 +11,7 @@ | arm: | ok | | arm64: | ok | | c6x: | TODO | - | csky: | TODO | + | csky: | ok | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO |
diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt index 32b2972..97cd7aa 100644 --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
@@ -11,7 +11,7 @@ | arm: | TODO | | arm64: | TODO | | c6x: | TODO | - | csky: | TODO | + | csky: | ok | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO |
diff --git a/Documentation/features/debug/kprobes/arch-support.txt b/Documentation/features/debug/kprobes/arch-support.txt index e68239b..8b316c6 100644 --- a/Documentation/features/debug/kprobes/arch-support.txt +++ b/Documentation/features/debug/kprobes/arch-support.txt
@@ -11,7 +11,7 @@ | arm: | ok | | arm64: | ok | | c6x: | TODO | - | csky: | TODO | + | csky: | ok | | h8300: | TODO | | hexagon: | TODO | | ia64: | ok | @@ -23,7 +23,7 @@ | openrisc: | TODO | | parisc: | ok | | powerpc: | ok | - | riscv: | ok | + | riscv: | TODO | | s390: | ok | | sh: | ok | | sparc: | ok |
diff --git a/Documentation/features/debug/kretprobes/arch-support.txt b/Documentation/features/debug/kretprobes/arch-support.txt index f17131b..b805aad 100644 --- a/Documentation/features/debug/kretprobes/arch-support.txt +++ b/Documentation/features/debug/kretprobes/arch-support.txt
@@ -11,7 +11,7 @@ | arm: | ok | | arm64: | ok | | c6x: | TODO | - | csky: | TODO | + | csky: | ok | | h8300: | TODO | | hexagon: | TODO | | ia64: | ok |
diff --git a/Documentation/features/debug/stackprotector/arch-support.txt b/Documentation/features/debug/stackprotector/arch-support.txt index 32bbdfc..12410f6 100644 --- a/Documentation/features/debug/stackprotector/arch-support.txt +++ b/Documentation/features/debug/stackprotector/arch-support.txt
@@ -11,7 +11,7 @@ | arm: | ok | | arm64: | ok | | c6x: | TODO | - | csky: | TODO | + | csky: | ok | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO |
diff --git a/Documentation/features/debug/uprobes/arch-support.txt b/Documentation/features/debug/uprobes/arch-support.txt index 1c577d0..be8acbb 100644 --- a/Documentation/features/debug/uprobes/arch-support.txt +++ b/Documentation/features/debug/uprobes/arch-support.txt
@@ -11,7 +11,7 @@ | arm: | ok | | arm64: | ok | | c6x: | TODO | - | csky: | TODO | + | csky: | ok | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO |
diff --git a/Documentation/features/io/dma-contiguous/arch-support.txt b/Documentation/features/io/dma-contiguous/arch-support.txt index eb28b5c..895c3b0 100644 --- a/Documentation/features/io/dma-contiguous/arch-support.txt +++ b/Documentation/features/io/dma-contiguous/arch-support.txt
@@ -16,7 +16,7 @@ | hexagon: | TODO | | ia64: | TODO | | m68k: | TODO | - | microblaze: | TODO | + | microblaze: | ok | | mips: | ok | | nds32: | TODO | | nios2: | TODO |
diff --git a/Documentation/features/locking/lockdep/arch-support.txt b/Documentation/features/locking/lockdep/arch-support.txt index 941fd5b..98cb9d8 100644 --- a/Documentation/features/locking/lockdep/arch-support.txt +++ b/Documentation/features/locking/lockdep/arch-support.txt
@@ -11,7 +11,7 @@ | arm: | ok | | arm64: | ok | | c6x: | TODO | - | csky: | TODO | + | csky: | ok | | h8300: | TODO | | hexagon: | ok | | ia64: | TODO |
diff --git a/Documentation/features/perf/kprobes-event/arch-support.txt b/Documentation/features/perf/kprobes-event/arch-support.txt index d8278bf..518f352 100644 --- a/Documentation/features/perf/kprobes-event/arch-support.txt +++ b/Documentation/features/perf/kprobes-event/arch-support.txt
@@ -11,7 +11,7 @@ | arm: | ok | | arm64: | ok | | c6x: | TODO | - | csky: | TODO | + | csky: | ok | | h8300: | TODO | | hexagon: | ok | | ia64: | TODO | @@ -21,7 +21,7 @@ | nds32: | ok | | nios2: | TODO | | openrisc: | TODO | - | parisc: | TODO | + | parisc: | ok | | powerpc: | ok | | riscv: | TODO | | s390: | ok |
diff --git a/Documentation/features/perf/perf-regs/arch-support.txt b/Documentation/features/perf/perf-regs/arch-support.txt index 687d049..c22cd6f 100644 --- a/Documentation/features/perf/perf-regs/arch-support.txt +++ b/Documentation/features/perf/perf-regs/arch-support.txt
@@ -11,7 +11,7 @@ | arm: | ok | | arm64: | ok | | c6x: | TODO | - | csky: | TODO | + | csky: | ok | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | @@ -23,7 +23,7 @@ | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | ok | | sh: | TODO | | sparc: | TODO |
diff --git a/Documentation/features/perf/perf-stackdump/arch-support.txt b/Documentation/features/perf/perf-stackdump/arch-support.txt index 90996e3..527fe4d 100644 --- a/Documentation/features/perf/perf-stackdump/arch-support.txt +++ b/Documentation/features/perf/perf-stackdump/arch-support.txt
@@ -11,7 +11,7 @@ | arm: | ok | | arm64: | ok | | c6x: | TODO | - | csky: | TODO | + | csky: | ok | | h8300: | TODO | | hexagon: | TODO | | ia64: | TODO | @@ -23,7 +23,7 @@ | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | ok | | sh: | TODO | | sparc: | TODO |
diff --git a/Documentation/features/seccomp/seccomp-filter/arch-support.txt b/Documentation/features/seccomp/seccomp-filter/arch-support.txt index 4fe6c3c..c7b837f 100644 --- a/Documentation/features/seccomp/seccomp-filter/arch-support.txt +++ b/Documentation/features/seccomp/seccomp-filter/arch-support.txt
@@ -23,7 +23,7 @@ | openrisc: | TODO | | parisc: | ok | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | ok | | sh: | TODO | | sparc: | TODO |
diff --git a/Documentation/features/vm/huge-vmap/arch-support.txt b/Documentation/features/vm/huge-vmap/arch-support.txt index 019131c..8525f19 100644 --- a/Documentation/features/vm/huge-vmap/arch-support.txt +++ b/Documentation/features/vm/huge-vmap/arch-support.txt
@@ -22,7 +22,7 @@ | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | - | powerpc: | TODO | + | powerpc: | ok | | riscv: | TODO | | s390: | TODO | | sh: | TODO |
diff --git a/Documentation/features/vm/numa-memblock/arch-support.txt b/Documentation/features/vm/numa-memblock/arch-support.txt deleted file mode 100644 index 3004beb..0000000 --- a/Documentation/features/vm/numa-memblock/arch-support.txt +++ /dev/null
@@ -1,34 +0,0 @@ -# -# Feature name: numa-memblock -# Kconfig: HAVE_MEMBLOCK_NODE_MAP -# description: arch supports NUMA aware memblocks -# - ----------------------- - | arch |status| - ----------------------- - | alpha: | TODO | - | arc: | .. | - | arm: | .. | - | arm64: | ok | - | c6x: | .. | - | csky: | .. | - | h8300: | .. | - | hexagon: | .. | - | ia64: | ok | - | m68k: | .. | - | microblaze: | ok | - | mips: | ok | - | nds32: | TODO | - | nios2: | .. | - | openrisc: | .. | - | parisc: | .. | - | powerpc: | ok | - | riscv: | ok | - | s390: | ok | - | sh: | ok | - | sparc: | ok | - | um: | .. | - | unicore32: | .. | - | x86: | ok | - | xtensa: | .. | - -----------------------
diff --git a/Documentation/features/vm/pte_special/arch-support.txt b/Documentation/features/vm/pte_special/arch-support.txt index 3d492a3..2e017387 100644 --- a/Documentation/features/vm/pte_special/arch-support.txt +++ b/Documentation/features/vm/pte_special/arch-support.txt
@@ -17,7 +17,7 @@ | ia64: | TODO | | m68k: | TODO | | microblaze: | TODO | - | mips: | TODO | + | mips: | ok | | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO |
diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/9p.rst index 671fef39..2995279 100644 --- a/Documentation/filesystems/9p.rst +++ b/Documentation/filesystems/9p.rst
@@ -192,4 +192,4 @@ http://plan9.bell-labs.com/plan9 For information on Plan 9 from User Space (Plan 9 applications and libraries -ported to Linux/BSD/OSX/etc) check out http://swtch.com/plan9 +ported to Linux/BSD/OSX/etc) check out https://9fans.github.io/plan9port/
diff --git a/Documentation/filesystems/afs.rst b/Documentation/filesystems/afs.rst index c4ec39a5..cada946 100644 --- a/Documentation/filesystems/afs.rst +++ b/Documentation/filesystems/afs.rst
@@ -70,7 +70,7 @@ The first module is the AF_RXRPC network protocol driver. This provides the RxRPC remote operation protocol and may also be accessed from userspace. See: - Documentation/networking/rxrpc.txt + Documentation/networking/rxrpc.rst The second module is the kerberos RxRPC security driver, and the third module is the actual filesystem driver for the AFS filesystem.
diff --git a/Documentation/filesystems/automount-support.rst b/Documentation/filesystems/automount-support.rst new file mode 100644 index 0000000..430f0b4 --- /dev/null +++ b/Documentation/filesystems/automount-support.rst
@@ -0,0 +1,98 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================= +Automount Support +================= + + +Support is available for filesystems that wish to do automounting +support (such as kAFS which can be found in fs/afs/ and NFS in +fs/nfs/). This facility includes allowing in-kernel mounts to be +performed and mountpoint degradation to be requested. The latter can +also be requested by userspace. + + +In-Kernel Automounting +====================== + +See section "Mount Traps" of Documentation/filesystems/autofs.rst + +Then from userspace, you can just do something like:: + + [root@andromeda root]# mount -t afs \#root.afs. /afs + [root@andromeda root]# ls /afs + asd cambridge cambridge.redhat.com grand.central.org + [root@andromeda root]# ls /afs/cambridge + afsdoc + [root@andromeda root]# ls /afs/cambridge/afsdoc/ + ChangeLog html LICENSE pdf RELNOTES-1.2.2 + +And then if you look in the mountpoint catalogue, you'll see something like:: + + [root@andromeda root]# cat /proc/mounts + ... + #root.afs. /afs afs rw 0 0 + #root.cell. /afs/cambridge.redhat.com afs rw 0 0 + #afsdoc. /afs/cambridge.redhat.com/afsdoc afs rw 0 0 + + +Automatic Mountpoint Expiry +=========================== + +Automatic expiration of mountpoints is easy, provided you've mounted the +mountpoint to be expired in the automounting procedure outlined separately. + +To do expiration, you need to follow these steps: + + (1) Create at least one list off which the vfsmounts to be expired can be + hung. + + (2) When a new mountpoint is created in the ->d_automount method, add + the mnt to the list using mnt_set_expiry():: + + mnt_set_expiry(newmnt, &afs_vfsmounts); + + (3) When you want mountpoints to be expired, call mark_mounts_for_expiry() + with a pointer to this list. This will process the list, marking every + vfsmount thereon for potential expiry on the next call. + + If a vfsmount was already flagged for expiry, and if its usage count is 1 + (it's only referenced by its parent vfsmount), then it will be deleted + from the namespace and thrown away (effectively unmounted). + + It may prove simplest to simply call this at regular intervals, using + some sort of timed event to drive it. + +The expiration flag is cleared by calls to mntput. This means that expiration +will only happen on the second expiration request after the last time the +mountpoint was accessed. + +If a mountpoint is moved, it gets removed from the expiration list. If a bind +mount is made on an expirable mount, the new vfsmount will not be on the +expiration list and will not expire. + +If a namespace is copied, all mountpoints contained therein will be copied, +and the copies of those that are on an expiration list will be added to the +same expiration list. + + +Userspace Driven Expiry +======================= + +As an alternative, it is possible for userspace to request expiry of any +mountpoint (though some will be rejected - the current process's idea of the +rootfs for example). It does this by passing the MNT_EXPIRE flag to +umount(). This flag is considered incompatible with MNT_FORCE and MNT_DETACH. + +If the mountpoint in question is in referenced by something other than +umount() or its parent mountpoint, an EBUSY error will be returned and the +mountpoint will not be marked for expiration or unmounted. + +If the mountpoint was not already marked for expiry at that time, an EAGAIN +error will be given and it won't be unmounted. + +Otherwise if it was already marked and it wasn't referenced, unmounting will +take place as usual. + +Again, the expiration flag is cleared every time anything other than umount() +looks at a mountpoint.
diff --git a/Documentation/filesystems/automount-support.txt b/Documentation/filesystems/automount-support.txt deleted file mode 100644 index 7d9f826..0000000 --- a/Documentation/filesystems/automount-support.txt +++ /dev/null
@@ -1,93 +0,0 @@ -Support is available for filesystems that wish to do automounting -support (such as kAFS which can be found in fs/afs/ and NFS in -fs/nfs/). This facility includes allowing in-kernel mounts to be -performed and mountpoint degradation to be requested. The latter can -also be requested by userspace. - - -====================== -IN-KERNEL AUTOMOUNTING -====================== - -See section "Mount Traps" of Documentation/filesystems/autofs.rst - -Then from userspace, you can just do something like: - - [root@andromeda root]# mount -t afs \#root.afs. /afs - [root@andromeda root]# ls /afs - asd cambridge cambridge.redhat.com grand.central.org - [root@andromeda root]# ls /afs/cambridge - afsdoc - [root@andromeda root]# ls /afs/cambridge/afsdoc/ - ChangeLog html LICENSE pdf RELNOTES-1.2.2 - -And then if you look in the mountpoint catalogue, you'll see something like: - - [root@andromeda root]# cat /proc/mounts - ... - #root.afs. /afs afs rw 0 0 - #root.cell. /afs/cambridge.redhat.com afs rw 0 0 - #afsdoc. /afs/cambridge.redhat.com/afsdoc afs rw 0 0 - - -=========================== -AUTOMATIC MOUNTPOINT EXPIRY -=========================== - -Automatic expiration of mountpoints is easy, provided you've mounted the -mountpoint to be expired in the automounting procedure outlined separately. - -To do expiration, you need to follow these steps: - - (1) Create at least one list off which the vfsmounts to be expired can be - hung. - - (2) When a new mountpoint is created in the ->d_automount method, add - the mnt to the list using mnt_set_expiry() - mnt_set_expiry(newmnt, &afs_vfsmounts); - - (3) When you want mountpoints to be expired, call mark_mounts_for_expiry() - with a pointer to this list. This will process the list, marking every - vfsmount thereon for potential expiry on the next call. - - If a vfsmount was already flagged for expiry, and if its usage count is 1 - (it's only referenced by its parent vfsmount), then it will be deleted - from the namespace and thrown away (effectively unmounted). - - It may prove simplest to simply call this at regular intervals, using - some sort of timed event to drive it. - -The expiration flag is cleared by calls to mntput. This means that expiration -will only happen on the second expiration request after the last time the -mountpoint was accessed. - -If a mountpoint is moved, it gets removed from the expiration list. If a bind -mount is made on an expirable mount, the new vfsmount will not be on the -expiration list and will not expire. - -If a namespace is copied, all mountpoints contained therein will be copied, -and the copies of those that are on an expiration list will be added to the -same expiration list. - - -======================= -USERSPACE DRIVEN EXPIRY -======================= - -As an alternative, it is possible for userspace to request expiry of any -mountpoint (though some will be rejected - the current process's idea of the -rootfs for example). It does this by passing the MNT_EXPIRE flag to -umount(). This flag is considered incompatible with MNT_FORCE and MNT_DETACH. - -If the mountpoint in question is in referenced by something other than -umount() or its parent mountpoint, an EBUSY error will be returned and the -mountpoint will not be marked for expiration or unmounted. - -If the mountpoint was not already marked for expiry at that time, an EAGAIN -error will be given and it won't be unmounted. - -Otherwise if it was already marked and it wasn't referenced, unmounting will -take place as usual. - -Again, the expiration flag is cleared every time anything other than umount() -looks at a mountpoint.
diff --git a/Documentation/filesystems/caching/backend-api.rst b/Documentation/filesystems/caching/backend-api.rst new file mode 100644 index 0000000..19fbf6b --- /dev/null +++ b/Documentation/filesystems/caching/backend-api.rst
@@ -0,0 +1,727 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +FS-Cache Cache backend API +========================== + +The FS-Cache system provides an API by which actual caches can be supplied to +FS-Cache for it to then serve out to network filesystems and other interested +parties. + +This API is declared in <linux/fscache-cache.h>. + + +Initialising and Registering a Cache +==================================== + +To start off, a cache definition must be initialised and registered for each +cache the backend wants to make available. For instance, CacheFS does this in +the fill_super() operation on mounting. + +The cache definition (struct fscache_cache) should be initialised by calling:: + + void fscache_init_cache(struct fscache_cache *cache, + struct fscache_cache_ops *ops, + const char *idfmt, + ...); + +Where: + + * "cache" is a pointer to the cache definition; + + * "ops" is a pointer to the table of operations that the backend supports on + this cache; and + + * "idfmt" is a format and printf-style arguments for constructing a label + for the cache. + + +The cache should then be registered with FS-Cache by passing a pointer to the +previously initialised cache definition to:: + + int fscache_add_cache(struct fscache_cache *cache, + struct fscache_object *fsdef, + const char *tagname); + +Two extra arguments should also be supplied: + + * "fsdef" which should point to the object representation for the FS-Cache + master index in this cache. Netfs primary index entries will be created + here. FS-Cache keeps the caller's reference to the index object if + successful and will release it upon withdrawal of the cache. + + * "tagname" which, if given, should be a text string naming this cache. If + this is NULL, the identifier will be used instead. For CacheFS, the + identifier is set to name the underlying block device and the tag can be + supplied by mount. + +This function may return -ENOMEM if it ran out of memory or -EEXIST if the tag +is already in use. 0 will be returned on success. + + +Unregistering a Cache +===================== + +A cache can be withdrawn from the system by calling this function with a +pointer to the cache definition:: + + void fscache_withdraw_cache(struct fscache_cache *cache); + +In CacheFS's case, this is called by put_super(). + + +Security +======== + +The cache methods are executed one of two contexts: + + (1) that of the userspace process that issued the netfs operation that caused + the cache method to be invoked, or + + (2) that of one of the processes in the FS-Cache thread pool. + +In either case, this may not be an appropriate context in which to access the +cache. + +The calling process's fsuid, fsgid and SELinux security identities may need to +be masqueraded for the duration of the cache driver's access to the cache. +This is left to the cache to handle; FS-Cache makes no effort in this regard. + + +Control and Statistics Presentation +=================================== + +The cache may present data to the outside world through FS-Cache's interfaces +in sysfs and procfs - the former for control and the latter for statistics. + +A sysfs directory called /sys/fs/fscache/<cachetag>/ is created if CONFIG_SYSFS +is enabled. This is accessible through the kobject struct fscache_cache::kobj +and is for use by the cache as it sees fit. + + +Relevant Data Structures +======================== + + * Index/Data file FS-Cache representation cookie:: + + struct fscache_cookie { + struct fscache_object_def *def; + struct fscache_netfs *netfs; + void *netfs_data; + ... + }; + + The fields that might be of use to the backend describe the object + definition, the netfs definition and the netfs's data for this cookie. + The object definition contain functions supplied by the netfs for loading + and matching index entries; these are required to provide some of the + cache operations. + + + * In-cache object representation:: + + struct fscache_object { + int debug_id; + enum { + FSCACHE_OBJECT_RECYCLING, + ... + } state; + spinlock_t lock + struct fscache_cache *cache; + struct fscache_cookie *cookie; + ... + }; + + Structures of this type should be allocated by the cache backend and + passed to FS-Cache when requested by the appropriate cache operation. In + the case of CacheFS, they're embedded in CacheFS's internal object + structures. + + The debug_id is a simple integer that can be used in debugging messages + that refer to a particular object. In such a case it should be printed + using "OBJ%x" to be consistent with FS-Cache. + + Each object contains a pointer to the cookie that represents the object it + is backing. An object should retired when put_object() is called if it is + in state FSCACHE_OBJECT_RECYCLING. The fscache_object struct should be + initialised by calling fscache_object_init(object). + + + * FS-Cache operation record:: + + struct fscache_operation { + atomic_t usage; + struct fscache_object *object; + unsigned long flags; + #define FSCACHE_OP_EXCLUSIVE + void (*processor)(struct fscache_operation *op); + void (*release)(struct fscache_operation *op); + ... + }; + + FS-Cache has a pool of threads that it uses to give CPU time to the + various asynchronous operations that need to be done as part of driving + the cache. These are represented by the above structure. The processor + method is called to give the op CPU time, and the release method to get + rid of it when its usage count reaches 0. + + An operation can be made exclusive upon an object by setting the + appropriate flag before enqueuing it with fscache_enqueue_operation(). If + an operation needs more processing time, it should be enqueued again. + + + * FS-Cache retrieval operation record:: + + struct fscache_retrieval { + struct fscache_operation op; + struct address_space *mapping; + struct list_head *to_do; + ... + }; + + A structure of this type is allocated by FS-Cache to record retrieval and + allocation requests made by the netfs. This struct is then passed to the + backend to do the operation. The backend may get extra refs to it by + calling fscache_get_retrieval() and refs may be discarded by calling + fscache_put_retrieval(). + + A retrieval operation can be used by the backend to do retrieval work. To + do this, the retrieval->op.processor method pointer should be set + appropriately by the backend and fscache_enqueue_retrieval() called to + submit it to the thread pool. CacheFiles, for example, uses this to queue + page examination when it detects PG_lock being cleared. + + The to_do field is an empty list available for the cache backend to use as + it sees fit. + + + * FS-Cache storage operation record:: + + struct fscache_storage { + struct fscache_operation op; + pgoff_t store_limit; + ... + }; + + A structure of this type is allocated by FS-Cache to record outstanding + writes to be made. FS-Cache itself enqueues this operation and invokes + the write_page() method on the object at appropriate times to effect + storage. + + +Cache Operations +================ + +The cache backend provides FS-Cache with a table of operations that can be +performed on the denizens of the cache. These are held in a structure of type: + + :: + + struct fscache_cache_ops + + * Name of cache provider [mandatory]:: + + const char *name + + This isn't strictly an operation, but should be pointed at a string naming + the backend. + + + * Allocate a new object [mandatory]:: + + struct fscache_object *(*alloc_object)(struct fscache_cache *cache, + struct fscache_cookie *cookie) + + This method is used to allocate a cache object representation to back a + cookie in a particular cache. fscache_object_init() should be called on + the object to initialise it prior to returning. + + This function may also be used to parse the index key to be used for + multiple lookup calls to turn it into a more convenient form. FS-Cache + will call the lookup_complete() method to allow the cache to release the + form once lookup is complete or aborted. + + + * Look up and create object [mandatory]:: + + void (*lookup_object)(struct fscache_object *object) + + This method is used to look up an object, given that the object is already + allocated and attached to the cookie. This should instantiate that object + in the cache if it can. + + The method should call fscache_object_lookup_negative() as soon as + possible if it determines the object doesn't exist in the cache. If the + object is found to exist and the netfs indicates that it is valid then + fscache_obtained_object() should be called once the object is in a + position to have data stored in it. Similarly, fscache_obtained_object() + should also be called once a non-present object has been created. + + If a lookup error occurs, fscache_object_lookup_error() should be called + to abort the lookup of that object. + + + * Release lookup data [mandatory]:: + + void (*lookup_complete)(struct fscache_object *object) + + This method is called to ask the cache to release any resources it was + using to perform a lookup. + + + * Increment object refcount [mandatory]:: + + struct fscache_object *(*grab_object)(struct fscache_object *object) + + This method is called to increment the reference count on an object. It + may fail (for instance if the cache is being withdrawn) by returning NULL. + It should return the object pointer if successful. + + + * Lock/Unlock object [mandatory]:: + + void (*lock_object)(struct fscache_object *object) + void (*unlock_object)(struct fscache_object *object) + + These methods are used to exclusively lock an object. It must be possible + to schedule with the lock held, so a spinlock isn't sufficient. + + + * Pin/Unpin object [optional]:: + + int (*pin_object)(struct fscache_object *object) + void (*unpin_object)(struct fscache_object *object) + + These methods are used to pin an object into the cache. Once pinned an + object cannot be reclaimed to make space. Return -ENOSPC if there's not + enough space in the cache to permit this. + + + * Check coherency state of an object [mandatory]:: + + int (*check_consistency)(struct fscache_object *object) + + This method is called to have the cache check the saved auxiliary data of + the object against the netfs's idea of the state. 0 should be returned + if they're consistent and -ESTALE otherwise. -ENOMEM and -ERESTARTSYS + may also be returned. + + * Update object [mandatory]:: + + int (*update_object)(struct fscache_object *object) + + This is called to update the index entry for the specified object. The + new information should be in object->cookie->netfs_data. This can be + obtained by calling object->cookie->def->get_aux()/get_attr(). + + + * Invalidate data object [mandatory]:: + + int (*invalidate_object)(struct fscache_operation *op) + + This is called to invalidate a data object (as pointed to by op->object). + All the data stored for this object should be discarded and an + attr_changed operation should be performed. The caller will follow up + with an object update operation. + + fscache_op_complete() must be called on op before returning. + + + * Discard object [mandatory]:: + + void (*drop_object)(struct fscache_object *object) + + This method is called to indicate that an object has been unbound from its + cookie, and that the cache should release the object's resources and + retire it if it's in state FSCACHE_OBJECT_RECYCLING. + + This method should not attempt to release any references held by the + caller. The caller will invoke the put_object() method as appropriate. + + + * Release object reference [mandatory]:: + + void (*put_object)(struct fscache_object *object) + + This method is used to discard a reference to an object. The object may + be freed when all the references to it are released. + + + * Synchronise a cache [mandatory]:: + + void (*sync)(struct fscache_cache *cache) + + This is called to ask the backend to synchronise a cache with its backing + device. + + + * Dissociate a cache [mandatory]:: + + void (*dissociate_pages)(struct fscache_cache *cache) + + This is called to ask a cache to perform any page dissociations as part of + cache withdrawal. + + + * Notification that the attributes on a netfs file changed [mandatory]:: + + int (*attr_changed)(struct fscache_object *object); + + This is called to indicate to the cache that certain attributes on a netfs + file have changed (for example the maximum size a file may reach). The + cache can read these from the netfs by calling the cookie's get_attr() + method. + + The cache may use the file size information to reserve space on the cache. + It should also call fscache_set_store_limit() to indicate to FS-Cache the + highest byte it's willing to store for an object. + + This method may return -ve if an error occurred or the cache object cannot + be expanded. In such a case, the object will be withdrawn from service. + + This operation is run asynchronously from FS-Cache's thread pool, and + storage and retrieval operations from the netfs are excluded during the + execution of this operation. + + + * Reserve cache space for an object's data [optional]:: + + int (*reserve_space)(struct fscache_object *object, loff_t size); + + This is called to request that cache space be reserved to hold the data + for an object and the metadata used to track it. Zero size should be + taken as request to cancel a reservation. + + This should return 0 if successful, -ENOSPC if there isn't enough space + available, or -ENOMEM or -EIO on other errors. + + The reservation may exceed the current size of the object, thus permitting + future expansion. If the amount of space consumed by an object would + exceed the reservation, it's permitted to refuse requests to allocate + pages, but not required. An object may be pruned down to its reservation + size if larger than that already. + + + * Request page be read from cache [mandatory]:: + + int (*read_or_alloc_page)(struct fscache_retrieval *op, + struct page *page, + gfp_t gfp) + + This is called to attempt to read a netfs page from the cache, or to + reserve a backing block if not. FS-Cache will have done as much checking + as it can before calling, but most of the work belongs to the backend. + + If there's no page in the cache, then -ENODATA should be returned if the + backend managed to reserve a backing block; -ENOBUFS or -ENOMEM if it + didn't. + + If there is suitable data in the cache, then a read operation should be + queued and 0 returned. When the read finishes, fscache_end_io() should be + called. + + The fscache_mark_pages_cached() should be called for the page if any cache + metadata is retained. This will indicate to the netfs that the page needs + explicit uncaching. This operation takes a pagevec, thus allowing several + pages to be marked at once. + + The retrieval record pointed to by op should be retained for each page + queued and released when I/O on the page has been formally ended. + fscache_get/put_retrieval() are available for this purpose. + + The retrieval record may be used to get CPU time via the FS-Cache thread + pool. If this is desired, the op->op.processor should be set to point to + the appropriate processing routine, and fscache_enqueue_retrieval() should + be called at an appropriate point to request CPU time. For instance, the + retrieval routine could be enqueued upon the completion of a disk read. + The to_do field in the retrieval record is provided to aid in this. + + If an I/O error occurs, fscache_io_error() should be called and -ENOBUFS + returned if possible or fscache_end_io() called with a suitable error + code. + + fscache_put_retrieval() should be called after a page or pages are dealt + with. This will complete the operation when all pages are dealt with. + + + * Request pages be read from cache [mandatory]:: + + int (*read_or_alloc_pages)(struct fscache_retrieval *op, + struct list_head *pages, + unsigned *nr_pages, + gfp_t gfp) + + This is like the read_or_alloc_page() method, except it is handed a list + of pages instead of one page. Any pages on which a read operation is + started must be added to the page cache for the specified mapping and also + to the LRU. Such pages must also be removed from the pages list and + ``*nr_pages`` decremented per page. + + If there was an error such as -ENOMEM, then that should be returned; else + if one or more pages couldn't be read or allocated, then -ENOBUFS should + be returned; else if one or more pages couldn't be read, then -ENODATA + should be returned. If all the pages are dispatched then 0 should be + returned. + + + * Request page be allocated in the cache [mandatory]:: + + int (*allocate_page)(struct fscache_retrieval *op, + struct page *page, + gfp_t gfp) + + This is like the read_or_alloc_page() method, except that it shouldn't + read from the cache, even if there's data there that could be retrieved. + It should, however, set up any internal metadata required such that + the write_page() method can write to the cache. + + If there's no backing block available, then -ENOBUFS should be returned + (or -ENOMEM if there were other problems). If a block is successfully + allocated, then the netfs page should be marked and 0 returned. + + + * Request pages be allocated in the cache [mandatory]:: + + int (*allocate_pages)(struct fscache_retrieval *op, + struct list_head *pages, + unsigned *nr_pages, + gfp_t gfp) + + This is an multiple page version of the allocate_page() method. pages and + nr_pages should be treated as for the read_or_alloc_pages() method. + + + * Request page be written to cache [mandatory]:: + + int (*write_page)(struct fscache_storage *op, + struct page *page); + + This is called to write from a page on which there was a previously + successful read_or_alloc_page() call or similar. FS-Cache filters out + pages that don't have mappings. + + This method is called asynchronously from the FS-Cache thread pool. It is + not required to actually store anything, provided -ENODATA is then + returned to the next read of this page. + + If an error occurred, then a negative error code should be returned, + otherwise zero should be returned. FS-Cache will take appropriate action + in response to an error, such as withdrawing this object. + + If this method returns success then FS-Cache will inform the netfs + appropriately. + + + * Discard retained per-page metadata [mandatory]:: + + void (*uncache_page)(struct fscache_object *object, struct page *page) + + This is called when a netfs page is being evicted from the pagecache. The + cache backend should tear down any internal representation or tracking it + maintains for this page. + + +FS-Cache Utilities +================== + +FS-Cache provides some utilities that a cache backend may make use of: + + * Note occurrence of an I/O error in a cache:: + + void fscache_io_error(struct fscache_cache *cache) + + This tells FS-Cache that an I/O error occurred in the cache. After this + has been called, only resource dissociation operations (object and page + release) will be passed from the netfs to the cache backend for the + specified cache. + + This does not actually withdraw the cache. That must be done separately. + + + * Invoke the retrieval I/O completion function:: + + void fscache_end_io(struct fscache_retrieval *op, struct page *page, + int error); + + This is called to note the end of an attempt to retrieve a page. The + error value should be 0 if successful and an error otherwise. + + + * Record that one or more pages being retrieved or allocated have been dealt + with:: + + void fscache_retrieval_complete(struct fscache_retrieval *op, + int n_pages); + + This is called to record the fact that one or more pages have been dealt + with and are no longer the concern of this operation. When the number of + pages remaining in the operation reaches 0, the operation will be + completed. + + + * Record operation completion:: + + void fscache_op_complete(struct fscache_operation *op); + + This is called to record the completion of an operation. This deducts + this operation from the parent object's run state, potentially permitting + one or more pending operations to start running. + + + * Set highest store limit:: + + void fscache_set_store_limit(struct fscache_object *object, + loff_t i_size); + + This sets the limit FS-Cache imposes on the highest byte it's willing to + try and store for a netfs. Any page over this limit is automatically + rejected by fscache_read_alloc_page() and co with -ENOBUFS. + + + * Mark pages as being cached:: + + void fscache_mark_pages_cached(struct fscache_retrieval *op, + struct pagevec *pagevec); + + This marks a set of pages as being cached. After this has been called, + the netfs must call fscache_uncache_page() to unmark the pages. + + + * Perform coherency check on an object:: + + enum fscache_checkaux fscache_check_aux(struct fscache_object *object, + const void *data, + uint16_t datalen); + + This asks the netfs to perform a coherency check on an object that has + just been looked up. The cookie attached to the object will determine the + netfs to use. data and datalen should specify where the auxiliary data + retrieved from the cache can be found. + + One of three values will be returned: + + FSCACHE_CHECKAUX_OKAY + The coherency data indicates the object is valid as is. + + FSCACHE_CHECKAUX_NEEDS_UPDATE + The coherency data needs updating, but otherwise the object is + valid. + + FSCACHE_CHECKAUX_OBSOLETE + The coherency data indicates that the object is obsolete and should + be discarded. + + + * Initialise a freshly allocated object:: + + void fscache_object_init(struct fscache_object *object); + + This initialises all the fields in an object representation. + + + * Indicate the destruction of an object:: + + void fscache_object_destroyed(struct fscache_cache *cache); + + This must be called to inform FS-Cache that an object that belonged to a + cache has been destroyed and deallocated. This will allow continuation + of the cache withdrawal process when it is stopped pending destruction of + all the objects. + + + * Indicate negative lookup on an object:: + + void fscache_object_lookup_negative(struct fscache_object *object); + + This is called to indicate to FS-Cache that a lookup process for an object + found a negative result. + + This changes the state of an object to permit reads pending on lookup + completion to go off and start fetching data from the netfs server as it's + known at this point that there can't be any data in the cache. + + This may be called multiple times on an object. Only the first call is + significant - all subsequent calls are ignored. + + + * Indicate an object has been obtained:: + + void fscache_obtained_object(struct fscache_object *object); + + This is called to indicate to FS-Cache that a lookup process for an object + produced a positive result, or that an object was created. This should + only be called once for any particular object. + + This changes the state of an object to indicate: + + (1) if no call to fscache_object_lookup_negative() has been made on + this object, that there may be data available, and that reads can + now go and look for it; and + + (2) that writes may now proceed against this object. + + + * Indicate that object lookup failed:: + + void fscache_object_lookup_error(struct fscache_object *object); + + This marks an object as having encountered a fatal error (usually EIO) + and causes it to move into a state whereby it will be withdrawn as soon + as possible. + + + * Indicate that a stale object was found and discarded:: + + void fscache_object_retrying_stale(struct fscache_object *object); + + This is called to indicate that the lookup procedure found an object in + the cache that the netfs decided was stale. The object has been + discarded from the cache and the lookup will be performed again. + + + * Indicate that the caching backend killed an object:: + + void fscache_object_mark_killed(struct fscache_object *object, + enum fscache_why_object_killed why); + + This is called to indicate that the cache backend preemptively killed an + object. The why parameter should be set to indicate the reason: + + FSCACHE_OBJECT_IS_STALE + - the object was stale and needs discarding. + + FSCACHE_OBJECT_NO_SPACE + - there was insufficient cache space + + FSCACHE_OBJECT_WAS_RETIRED + - the object was retired when relinquished. + + FSCACHE_OBJECT_WAS_CULLED + - the object was culled to make space. + + + * Get and release references on a retrieval record:: + + void fscache_get_retrieval(struct fscache_retrieval *op); + void fscache_put_retrieval(struct fscache_retrieval *op); + + These two functions are used to retain a retrieval record while doing + asynchronous data retrieval and block allocation. + + + * Enqueue a retrieval record for processing:: + + void fscache_enqueue_retrieval(struct fscache_retrieval *op); + + This enqueues a retrieval record for processing by the FS-Cache thread + pool. One of the threads in the pool will invoke the retrieval record's + op->op.processor callback function. This function may be called from + within the callback function. + + + * List of object state names:: + + const char *fscache_object_states[]; + + For debugging purposes, this may be used to turn the state that an object + is in into a text string for display purposes.
diff --git a/Documentation/filesystems/caching/backend-api.txt b/Documentation/filesystems/caching/backend-api.txt deleted file mode 100644 index c418280..0000000 --- a/Documentation/filesystems/caching/backend-api.txt +++ /dev/null
@@ -1,726 +0,0 @@ - ========================== - FS-CACHE CACHE BACKEND API - ========================== - -The FS-Cache system provides an API by which actual caches can be supplied to -FS-Cache for it to then serve out to network filesystems and other interested -parties. - -This API is declared in <linux/fscache-cache.h>. - - -==================================== -INITIALISING AND REGISTERING A CACHE -==================================== - -To start off, a cache definition must be initialised and registered for each -cache the backend wants to make available. For instance, CacheFS does this in -the fill_super() operation on mounting. - -The cache definition (struct fscache_cache) should be initialised by calling: - - void fscache_init_cache(struct fscache_cache *cache, - struct fscache_cache_ops *ops, - const char *idfmt, - ...); - -Where: - - (*) "cache" is a pointer to the cache definition; - - (*) "ops" is a pointer to the table of operations that the backend supports on - this cache; and - - (*) "idfmt" is a format and printf-style arguments for constructing a label - for the cache. - - -The cache should then be registered with FS-Cache by passing a pointer to the -previously initialised cache definition to: - - int fscache_add_cache(struct fscache_cache *cache, - struct fscache_object *fsdef, - const char *tagname); - -Two extra arguments should also be supplied: - - (*) "fsdef" which should point to the object representation for the FS-Cache - master index in this cache. Netfs primary index entries will be created - here. FS-Cache keeps the caller's reference to the index object if - successful and will release it upon withdrawal of the cache. - - (*) "tagname" which, if given, should be a text string naming this cache. If - this is NULL, the identifier will be used instead. For CacheFS, the - identifier is set to name the underlying block device and the tag can be - supplied by mount. - -This function may return -ENOMEM if it ran out of memory or -EEXIST if the tag -is already in use. 0 will be returned on success. - - -===================== -UNREGISTERING A CACHE -===================== - -A cache can be withdrawn from the system by calling this function with a -pointer to the cache definition: - - void fscache_withdraw_cache(struct fscache_cache *cache); - -In CacheFS's case, this is called by put_super(). - - -======== -SECURITY -======== - -The cache methods are executed one of two contexts: - - (1) that of the userspace process that issued the netfs operation that caused - the cache method to be invoked, or - - (2) that of one of the processes in the FS-Cache thread pool. - -In either case, this may not be an appropriate context in which to access the -cache. - -The calling process's fsuid, fsgid and SELinux security identities may need to -be masqueraded for the duration of the cache driver's access to the cache. -This is left to the cache to handle; FS-Cache makes no effort in this regard. - - -=================================== -CONTROL AND STATISTICS PRESENTATION -=================================== - -The cache may present data to the outside world through FS-Cache's interfaces -in sysfs and procfs - the former for control and the latter for statistics. - -A sysfs directory called /sys/fs/fscache/<cachetag>/ is created if CONFIG_SYSFS -is enabled. This is accessible through the kobject struct fscache_cache::kobj -and is for use by the cache as it sees fit. - - -======================== -RELEVANT DATA STRUCTURES -======================== - - (*) Index/Data file FS-Cache representation cookie: - - struct fscache_cookie { - struct fscache_object_def *def; - struct fscache_netfs *netfs; - void *netfs_data; - ... - }; - - The fields that might be of use to the backend describe the object - definition, the netfs definition and the netfs's data for this cookie. - The object definition contain functions supplied by the netfs for loading - and matching index entries; these are required to provide some of the - cache operations. - - - (*) In-cache object representation: - - struct fscache_object { - int debug_id; - enum { - FSCACHE_OBJECT_RECYCLING, - ... - } state; - spinlock_t lock - struct fscache_cache *cache; - struct fscache_cookie *cookie; - ... - }; - - Structures of this type should be allocated by the cache backend and - passed to FS-Cache when requested by the appropriate cache operation. In - the case of CacheFS, they're embedded in CacheFS's internal object - structures. - - The debug_id is a simple integer that can be used in debugging messages - that refer to a particular object. In such a case it should be printed - using "OBJ%x" to be consistent with FS-Cache. - - Each object contains a pointer to the cookie that represents the object it - is backing. An object should retired when put_object() is called if it is - in state FSCACHE_OBJECT_RECYCLING. The fscache_object struct should be - initialised by calling fscache_object_init(object). - - - (*) FS-Cache operation record: - - struct fscache_operation { - atomic_t usage; - struct fscache_object *object; - unsigned long flags; - #define FSCACHE_OP_EXCLUSIVE - void (*processor)(struct fscache_operation *op); - void (*release)(struct fscache_operation *op); - ... - }; - - FS-Cache has a pool of threads that it uses to give CPU time to the - various asynchronous operations that need to be done as part of driving - the cache. These are represented by the above structure. The processor - method is called to give the op CPU time, and the release method to get - rid of it when its usage count reaches 0. - - An operation can be made exclusive upon an object by setting the - appropriate flag before enqueuing it with fscache_enqueue_operation(). If - an operation needs more processing time, it should be enqueued again. - - - (*) FS-Cache retrieval operation record: - - struct fscache_retrieval { - struct fscache_operation op; - struct address_space *mapping; - struct list_head *to_do; - ... - }; - - A structure of this type is allocated by FS-Cache to record retrieval and - allocation requests made by the netfs. This struct is then passed to the - backend to do the operation. The backend may get extra refs to it by - calling fscache_get_retrieval() and refs may be discarded by calling - fscache_put_retrieval(). - - A retrieval operation can be used by the backend to do retrieval work. To - do this, the retrieval->op.processor method pointer should be set - appropriately by the backend and fscache_enqueue_retrieval() called to - submit it to the thread pool. CacheFiles, for example, uses this to queue - page examination when it detects PG_lock being cleared. - - The to_do field is an empty list available for the cache backend to use as - it sees fit. - - - (*) FS-Cache storage operation record: - - struct fscache_storage { - struct fscache_operation op; - pgoff_t store_limit; - ... - }; - - A structure of this type is allocated by FS-Cache to record outstanding - writes to be made. FS-Cache itself enqueues this operation and invokes - the write_page() method on the object at appropriate times to effect - storage. - - -================ -CACHE OPERATIONS -================ - -The cache backend provides FS-Cache with a table of operations that can be -performed on the denizens of the cache. These are held in a structure of type: - - struct fscache_cache_ops - - (*) Name of cache provider [mandatory]: - - const char *name - - This isn't strictly an operation, but should be pointed at a string naming - the backend. - - - (*) Allocate a new object [mandatory]: - - struct fscache_object *(*alloc_object)(struct fscache_cache *cache, - struct fscache_cookie *cookie) - - This method is used to allocate a cache object representation to back a - cookie in a particular cache. fscache_object_init() should be called on - the object to initialise it prior to returning. - - This function may also be used to parse the index key to be used for - multiple lookup calls to turn it into a more convenient form. FS-Cache - will call the lookup_complete() method to allow the cache to release the - form once lookup is complete or aborted. - - - (*) Look up and create object [mandatory]: - - void (*lookup_object)(struct fscache_object *object) - - This method is used to look up an object, given that the object is already - allocated and attached to the cookie. This should instantiate that object - in the cache if it can. - - The method should call fscache_object_lookup_negative() as soon as - possible if it determines the object doesn't exist in the cache. If the - object is found to exist and the netfs indicates that it is valid then - fscache_obtained_object() should be called once the object is in a - position to have data stored in it. Similarly, fscache_obtained_object() - should also be called once a non-present object has been created. - - If a lookup error occurs, fscache_object_lookup_error() should be called - to abort the lookup of that object. - - - (*) Release lookup data [mandatory]: - - void (*lookup_complete)(struct fscache_object *object) - - This method is called to ask the cache to release any resources it was - using to perform a lookup. - - - (*) Increment object refcount [mandatory]: - - struct fscache_object *(*grab_object)(struct fscache_object *object) - - This method is called to increment the reference count on an object. It - may fail (for instance if the cache is being withdrawn) by returning NULL. - It should return the object pointer if successful. - - - (*) Lock/Unlock object [mandatory]: - - void (*lock_object)(struct fscache_object *object) - void (*unlock_object)(struct fscache_object *object) - - These methods are used to exclusively lock an object. It must be possible - to schedule with the lock held, so a spinlock isn't sufficient. - - - (*) Pin/Unpin object [optional]: - - int (*pin_object)(struct fscache_object *object) - void (*unpin_object)(struct fscache_object *object) - - These methods are used to pin an object into the cache. Once pinned an - object cannot be reclaimed to make space. Return -ENOSPC if there's not - enough space in the cache to permit this. - - - (*) Check coherency state of an object [mandatory]: - - int (*check_consistency)(struct fscache_object *object) - - This method is called to have the cache check the saved auxiliary data of - the object against the netfs's idea of the state. 0 should be returned - if they're consistent and -ESTALE otherwise. -ENOMEM and -ERESTARTSYS - may also be returned. - - (*) Update object [mandatory]: - - int (*update_object)(struct fscache_object *object) - - This is called to update the index entry for the specified object. The - new information should be in object->cookie->netfs_data. This can be - obtained by calling object->cookie->def->get_aux()/get_attr(). - - - (*) Invalidate data object [mandatory]: - - int (*invalidate_object)(struct fscache_operation *op) - - This is called to invalidate a data object (as pointed to by op->object). - All the data stored for this object should be discarded and an - attr_changed operation should be performed. The caller will follow up - with an object update operation. - - fscache_op_complete() must be called on op before returning. - - - (*) Discard object [mandatory]: - - void (*drop_object)(struct fscache_object *object) - - This method is called to indicate that an object has been unbound from its - cookie, and that the cache should release the object's resources and - retire it if it's in state FSCACHE_OBJECT_RECYCLING. - - This method should not attempt to release any references held by the - caller. The caller will invoke the put_object() method as appropriate. - - - (*) Release object reference [mandatory]: - - void (*put_object)(struct fscache_object *object) - - This method is used to discard a reference to an object. The object may - be freed when all the references to it are released. - - - (*) Synchronise a cache [mandatory]: - - void (*sync)(struct fscache_cache *cache) - - This is called to ask the backend to synchronise a cache with its backing - device. - - - (*) Dissociate a cache [mandatory]: - - void (*dissociate_pages)(struct fscache_cache *cache) - - This is called to ask a cache to perform any page dissociations as part of - cache withdrawal. - - - (*) Notification that the attributes on a netfs file changed [mandatory]: - - int (*attr_changed)(struct fscache_object *object); - - This is called to indicate to the cache that certain attributes on a netfs - file have changed (for example the maximum size a file may reach). The - cache can read these from the netfs by calling the cookie's get_attr() - method. - - The cache may use the file size information to reserve space on the cache. - It should also call fscache_set_store_limit() to indicate to FS-Cache the - highest byte it's willing to store for an object. - - This method may return -ve if an error occurred or the cache object cannot - be expanded. In such a case, the object will be withdrawn from service. - - This operation is run asynchronously from FS-Cache's thread pool, and - storage and retrieval operations from the netfs are excluded during the - execution of this operation. - - - (*) Reserve cache space for an object's data [optional]: - - int (*reserve_space)(struct fscache_object *object, loff_t size); - - This is called to request that cache space be reserved to hold the data - for an object and the metadata used to track it. Zero size should be - taken as request to cancel a reservation. - - This should return 0 if successful, -ENOSPC if there isn't enough space - available, or -ENOMEM or -EIO on other errors. - - The reservation may exceed the current size of the object, thus permitting - future expansion. If the amount of space consumed by an object would - exceed the reservation, it's permitted to refuse requests to allocate - pages, but not required. An object may be pruned down to its reservation - size if larger than that already. - - - (*) Request page be read from cache [mandatory]: - - int (*read_or_alloc_page)(struct fscache_retrieval *op, - struct page *page, - gfp_t gfp) - - This is called to attempt to read a netfs page from the cache, or to - reserve a backing block if not. FS-Cache will have done as much checking - as it can before calling, but most of the work belongs to the backend. - - If there's no page in the cache, then -ENODATA should be returned if the - backend managed to reserve a backing block; -ENOBUFS or -ENOMEM if it - didn't. - - If there is suitable data in the cache, then a read operation should be - queued and 0 returned. When the read finishes, fscache_end_io() should be - called. - - The fscache_mark_pages_cached() should be called for the page if any cache - metadata is retained. This will indicate to the netfs that the page needs - explicit uncaching. This operation takes a pagevec, thus allowing several - pages to be marked at once. - - The retrieval record pointed to by op should be retained for each page - queued and released when I/O on the page has been formally ended. - fscache_get/put_retrieval() are available for this purpose. - - The retrieval record may be used to get CPU time via the FS-Cache thread - pool. If this is desired, the op->op.processor should be set to point to - the appropriate processing routine, and fscache_enqueue_retrieval() should - be called at an appropriate point to request CPU time. For instance, the - retrieval routine could be enqueued upon the completion of a disk read. - The to_do field in the retrieval record is provided to aid in this. - - If an I/O error occurs, fscache_io_error() should be called and -ENOBUFS - returned if possible or fscache_end_io() called with a suitable error - code. - - fscache_put_retrieval() should be called after a page or pages are dealt - with. This will complete the operation when all pages are dealt with. - - - (*) Request pages be read from cache [mandatory]: - - int (*read_or_alloc_pages)(struct fscache_retrieval *op, - struct list_head *pages, - unsigned *nr_pages, - gfp_t gfp) - - This is like the read_or_alloc_page() method, except it is handed a list - of pages instead of one page. Any pages on which a read operation is - started must be added to the page cache for the specified mapping and also - to the LRU. Such pages must also be removed from the pages list and - *nr_pages decremented per page. - - If there was an error such as -ENOMEM, then that should be returned; else - if one or more pages couldn't be read or allocated, then -ENOBUFS should - be returned; else if one or more pages couldn't be read, then -ENODATA - should be returned. If all the pages are dispatched then 0 should be - returned. - - - (*) Request page be allocated in the cache [mandatory]: - - int (*allocate_page)(struct fscache_retrieval *op, - struct page *page, - gfp_t gfp) - - This is like the read_or_alloc_page() method, except that it shouldn't - read from the cache, even if there's data there that could be retrieved. - It should, however, set up any internal metadata required such that - the write_page() method can write to the cache. - - If there's no backing block available, then -ENOBUFS should be returned - (or -ENOMEM if there were other problems). If a block is successfully - allocated, then the netfs page should be marked and 0 returned. - - - (*) Request pages be allocated in the cache [mandatory]: - - int (*allocate_pages)(struct fscache_retrieval *op, - struct list_head *pages, - unsigned *nr_pages, - gfp_t gfp) - - This is an multiple page version of the allocate_page() method. pages and - nr_pages should be treated as for the read_or_alloc_pages() method. - - - (*) Request page be written to cache [mandatory]: - - int (*write_page)(struct fscache_storage *op, - struct page *page); - - This is called to write from a page on which there was a previously - successful read_or_alloc_page() call or similar. FS-Cache filters out - pages that don't have mappings. - - This method is called asynchronously from the FS-Cache thread pool. It is - not required to actually store anything, provided -ENODATA is then - returned to the next read of this page. - - If an error occurred, then a negative error code should be returned, - otherwise zero should be returned. FS-Cache will take appropriate action - in response to an error, such as withdrawing this object. - - If this method returns success then FS-Cache will inform the netfs - appropriately. - - - (*) Discard retained per-page metadata [mandatory]: - - void (*uncache_page)(struct fscache_object *object, struct page *page) - - This is called when a netfs page is being evicted from the pagecache. The - cache backend should tear down any internal representation or tracking it - maintains for this page. - - -================== -FS-CACHE UTILITIES -================== - -FS-Cache provides some utilities that a cache backend may make use of: - - (*) Note occurrence of an I/O error in a cache: - - void fscache_io_error(struct fscache_cache *cache) - - This tells FS-Cache that an I/O error occurred in the cache. After this - has been called, only resource dissociation operations (object and page - release) will be passed from the netfs to the cache backend for the - specified cache. - - This does not actually withdraw the cache. That must be done separately. - - - (*) Invoke the retrieval I/O completion function: - - void fscache_end_io(struct fscache_retrieval *op, struct page *page, - int error); - - This is called to note the end of an attempt to retrieve a page. The - error value should be 0 if successful and an error otherwise. - - - (*) Record that one or more pages being retrieved or allocated have been dealt - with: - - void fscache_retrieval_complete(struct fscache_retrieval *op, - int n_pages); - - This is called to record the fact that one or more pages have been dealt - with and are no longer the concern of this operation. When the number of - pages remaining in the operation reaches 0, the operation will be - completed. - - - (*) Record operation completion: - - void fscache_op_complete(struct fscache_operation *op); - - This is called to record the completion of an operation. This deducts - this operation from the parent object's run state, potentially permitting - one or more pending operations to start running. - - - (*) Set highest store limit: - - void fscache_set_store_limit(struct fscache_object *object, - loff_t i_size); - - This sets the limit FS-Cache imposes on the highest byte it's willing to - try and store for a netfs. Any page over this limit is automatically - rejected by fscache_read_alloc_page() and co with -ENOBUFS. - - - (*) Mark pages as being cached: - - void fscache_mark_pages_cached(struct fscache_retrieval *op, - struct pagevec *pagevec); - - This marks a set of pages as being cached. After this has been called, - the netfs must call fscache_uncache_page() to unmark the pages. - - - (*) Perform coherency check on an object: - - enum fscache_checkaux fscache_check_aux(struct fscache_object *object, - const void *data, - uint16_t datalen); - - This asks the netfs to perform a coherency check on an object that has - just been looked up. The cookie attached to the object will determine the - netfs to use. data and datalen should specify where the auxiliary data - retrieved from the cache can be found. - - One of three values will be returned: - - (*) FSCACHE_CHECKAUX_OKAY - - The coherency data indicates the object is valid as is. - - (*) FSCACHE_CHECKAUX_NEEDS_UPDATE - - The coherency data needs updating, but otherwise the object is - valid. - - (*) FSCACHE_CHECKAUX_OBSOLETE - - The coherency data indicates that the object is obsolete and should - be discarded. - - - (*) Initialise a freshly allocated object: - - void fscache_object_init(struct fscache_object *object); - - This initialises all the fields in an object representation. - - - (*) Indicate the destruction of an object: - - void fscache_object_destroyed(struct fscache_cache *cache); - - This must be called to inform FS-Cache that an object that belonged to a - cache has been destroyed and deallocated. This will allow continuation - of the cache withdrawal process when it is stopped pending destruction of - all the objects. - - - (*) Indicate negative lookup on an object: - - void fscache_object_lookup_negative(struct fscache_object *object); - - This is called to indicate to FS-Cache that a lookup process for an object - found a negative result. - - This changes the state of an object to permit reads pending on lookup - completion to go off and start fetching data from the netfs server as it's - known at this point that there can't be any data in the cache. - - This may be called multiple times on an object. Only the first call is - significant - all subsequent calls are ignored. - - - (*) Indicate an object has been obtained: - - void fscache_obtained_object(struct fscache_object *object); - - This is called to indicate to FS-Cache that a lookup process for an object - produced a positive result, or that an object was created. This should - only be called once for any particular object. - - This changes the state of an object to indicate: - - (1) if no call to fscache_object_lookup_negative() has been made on - this object, that there may be data available, and that reads can - now go and look for it; and - - (2) that writes may now proceed against this object. - - - (*) Indicate that object lookup failed: - - void fscache_object_lookup_error(struct fscache_object *object); - - This marks an object as having encountered a fatal error (usually EIO) - and causes it to move into a state whereby it will be withdrawn as soon - as possible. - - - (*) Indicate that a stale object was found and discarded: - - void fscache_object_retrying_stale(struct fscache_object *object); - - This is called to indicate that the lookup procedure found an object in - the cache that the netfs decided was stale. The object has been - discarded from the cache and the lookup will be performed again. - - - (*) Indicate that the caching backend killed an object: - - void fscache_object_mark_killed(struct fscache_object *object, - enum fscache_why_object_killed why); - - This is called to indicate that the cache backend preemptively killed an - object. The why parameter should be set to indicate the reason: - - FSCACHE_OBJECT_IS_STALE - the object was stale and needs discarding. - FSCACHE_OBJECT_NO_SPACE - there was insufficient cache space - FSCACHE_OBJECT_WAS_RETIRED - the object was retired when relinquished. - FSCACHE_OBJECT_WAS_CULLED - the object was culled to make space. - - - (*) Get and release references on a retrieval record: - - void fscache_get_retrieval(struct fscache_retrieval *op); - void fscache_put_retrieval(struct fscache_retrieval *op); - - These two functions are used to retain a retrieval record while doing - asynchronous data retrieval and block allocation. - - - (*) Enqueue a retrieval record for processing. - - void fscache_enqueue_retrieval(struct fscache_retrieval *op); - - This enqueues a retrieval record for processing by the FS-Cache thread - pool. One of the threads in the pool will invoke the retrieval record's - op->op.processor callback function. This function may be called from - within the callback function. - - - (*) List of object state names: - - const char *fscache_object_states[]; - - For debugging purposes, this may be used to turn the state that an object - is in into a text string for display purposes.
diff --git a/Documentation/filesystems/caching/cachefiles.rst b/Documentation/filesystems/caching/cachefiles.rst new file mode 100644 index 0000000..65d3db4 --- /dev/null +++ b/Documentation/filesystems/caching/cachefiles.rst
@@ -0,0 +1,484 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============================================== +CacheFiles: CACHE ON ALREADY MOUNTED FILESYSTEM +=============================================== + +.. Contents: + + (*) Overview. + + (*) Requirements. + + (*) Configuration. + + (*) Starting the cache. + + (*) Things to avoid. + + (*) Cache culling. + + (*) Cache structure. + + (*) Security model and SELinux. + + (*) A note on security. + + (*) Statistical information. + + (*) Debugging. + + + +Overview +======== + +CacheFiles is a caching backend that's meant to use as a cache a directory on +an already mounted filesystem of a local type (such as Ext3). + +CacheFiles uses a userspace daemon to do some of the cache management - such as +reaping stale nodes and culling. This is called cachefilesd and lives in +/sbin. + +The filesystem and data integrity of the cache are only as good as those of the +filesystem providing the backing services. Note that CacheFiles does not +attempt to journal anything since the journalling interfaces of the various +filesystems are very specific in nature. + +CacheFiles creates a misc character device - "/dev/cachefiles" - that is used +to communication with the daemon. Only one thing may have this open at once, +and while it is open, a cache is at least partially in existence. The daemon +opens this and sends commands down it to control the cache. + +CacheFiles is currently limited to a single cache. + +CacheFiles attempts to maintain at least a certain percentage of free space on +the filesystem, shrinking the cache by culling the objects it contains to make +space if necessary - see the "Cache Culling" section. This means it can be +placed on the same medium as a live set of data, and will expand to make use of +spare space and automatically contract when the set of data requires more +space. + + + +Requirements +============ + +The use of CacheFiles and its daemon requires the following features to be +available in the system and in the cache filesystem: + + - dnotify. + + - extended attributes (xattrs). + + - openat() and friends. + + - bmap() support on files in the filesystem (FIBMAP ioctl). + + - The use of bmap() to detect a partial page at the end of the file. + +It is strongly recommended that the "dir_index" option is enabled on Ext3 +filesystems being used as a cache. + + +Configuration +============= + +The cache is configured by a script in /etc/cachefilesd.conf. These commands +set up cache ready for use. The following script commands are available: + + brun <N>%, bcull <N>%, bstop <N>%, frun <N>%, fcull <N>%, fstop <N>% + Configure the culling limits. Optional. See the section on culling + The defaults are 7% (run), 5% (cull) and 1% (stop) respectively. + + The commands beginning with a 'b' are file space (block) limits, those + beginning with an 'f' are file count limits. + + dir <path> + Specify the directory containing the root of the cache. Mandatory. + + tag <name> + Specify a tag to FS-Cache to use in distinguishing multiple caches. + Optional. The default is "CacheFiles". + + debug <mask> + Specify a numeric bitmask to control debugging in the kernel module. + Optional. The default is zero (all off). The following values can be + OR'd into the mask to collect various information: + + == ================================================= + 1 Turn on trace of function entry (_enter() macros) + 2 Turn on trace of function exit (_leave() macros) + 4 Turn on trace of internal debug points (_debug()) + == ================================================= + + This mask can also be set through sysfs, eg:: + + echo 5 >/sys/modules/cachefiles/parameters/debug + + +Starting the Cache +================== + +The cache is started by running the daemon. The daemon opens the cache device, +configures the cache and tells it to begin caching. At that point the cache +binds to fscache and the cache becomes live. + +The daemon is run as follows:: + + /sbin/cachefilesd [-d]* [-s] [-n] [-f <configfile>] + +The flags are: + + ``-d`` + Increase the debugging level. This can be specified multiple times and + is cumulative with itself. + + ``-s`` + Send messages to stderr instead of syslog. + + ``-n`` + Don't daemonise and go into background. + + ``-f <configfile>`` + Use an alternative configuration file rather than the default one. + + +Things to Avoid +=============== + +Do not mount other things within the cache as this will cause problems. The +kernel module contains its own very cut-down path walking facility that ignores +mountpoints, but the daemon can't avoid them. + +Do not create, rename or unlink files and directories in the cache while the +cache is active, as this may cause the state to become uncertain. + +Renaming files in the cache might make objects appear to be other objects (the +filename is part of the lookup key). + +Do not change or remove the extended attributes attached to cache files by the +cache as this will cause the cache state management to get confused. + +Do not create files or directories in the cache, lest the cache get confused or +serve incorrect data. + +Do not chmod files in the cache. The module creates things with minimal +permissions to prevent random users being able to access them directly. + + +Cache Culling +============= + +The cache may need culling occasionally to make space. This involves +discarding objects from the cache that have been used less recently than +anything else. Culling is based on the access time of data objects. Empty +directories are culled if not in use. + +Cache culling is done on the basis of the percentage of blocks and the +percentage of files available in the underlying filesystem. There are six +"limits": + + brun, frun + If the amount of free space and the number of available files in the cache + rises above both these limits, then culling is turned off. + + bcull, fcull + If the amount of available space or the number of available files in the + cache falls below either of these limits, then culling is started. + + bstop, fstop + If the amount of available space or the number of available files in the + cache falls below either of these limits, then no further allocation of + disk space or files is permitted until culling has raised things above + these limits again. + +These must be configured thusly:: + + 0 <= bstop < bcull < brun < 100 + 0 <= fstop < fcull < frun < 100 + +Note that these are percentages of available space and available files, and do +_not_ appear as 100 minus the percentage displayed by the "df" program. + +The userspace daemon scans the cache to build up a table of cullable objects. +These are then culled in least recently used order. A new scan of the cache is +started as soon as space is made in the table. Objects will be skipped if +their atimes have changed or if the kernel module says it is still using them. + + +Cache Structure +=============== + +The CacheFiles module will create two directories in the directory it was +given: + + * cache/ + * graveyard/ + +The active cache objects all reside in the first directory. The CacheFiles +kernel module moves any retired or culled objects that it can't simply unlink +to the graveyard from which the daemon will actually delete them. + +The daemon uses dnotify to monitor the graveyard directory, and will delete +anything that appears therein. + + +The module represents index objects as directories with the filename "I..." or +"J...". Note that the "cache/" directory is itself a special index. + +Data objects are represented as files if they have no children, or directories +if they do. Their filenames all begin "D..." or "E...". If represented as a +directory, data objects will have a file in the directory called "data" that +actually holds the data. + +Special objects are similar to data objects, except their filenames begin +"S..." or "T...". + + +If an object has children, then it will be represented as a directory. +Immediately in the representative directory are a collection of directories +named for hash values of the child object keys with an '@' prepended. Into +this directory, if possible, will be placed the representations of the child +objects:: + + /INDEX /INDEX /INDEX /DATA FILES + /=========/==========/=================================/================ + cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400 + cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...DB1ry + cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...N22ry + cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...FP1ry + + +If the key is so long that it exceeds NAME_MAX with the decorations added on to +it, then it will be cut into pieces, the first few of which will be used to +make a nest of directories, and the last one of which will be the objects +inside the last directory. The names of the intermediate directories will have +'+' prepended:: + + J1223/@23/+xy...z/+kl...m/Epqr + + +Note that keys are raw data, and not only may they exceed NAME_MAX in size, +they may also contain things like '/' and NUL characters, and so they may not +be suitable for turning directly into a filename. + +To handle this, CacheFiles will use a suitably printable filename directly and +"base-64" encode ones that aren't directly suitable. The two versions of +object filenames indicate the encoding: + + =============== =============== =============== + OBJECT TYPE PRINTABLE ENCODED + =============== =============== =============== + Index "I..." "J..." + Data "D..." "E..." + Special "S..." "T..." + =============== =============== =============== + +Intermediate directories are always "@" or "+" as appropriate. + + +Each object in the cache has an extended attribute label that holds the object +type ID (required to distinguish special objects) and the auxiliary data from +the netfs. The latter is used to detect stale objects in the cache and update +or retire them. + + +Note that CacheFiles will erase from the cache any file it doesn't recognise or +any file of an incorrect type (such as a FIFO file or a device file). + + +Security Model and SELinux +========================== + +CacheFiles is implemented to deal properly with the LSM security features of +the Linux kernel and the SELinux facility. + +One of the problems that CacheFiles faces is that it is generally acting on +behalf of a process, and running in that process's context, and that includes a +security context that is not appropriate for accessing the cache - either +because the files in the cache are inaccessible to that process, or because if +the process creates a file in the cache, that file may be inaccessible to other +processes. + +The way CacheFiles works is to temporarily change the security context (fsuid, +fsgid and actor security label) that the process acts as - without changing the +security context of the process when it the target of an operation performed by +some other process (so signalling and suchlike still work correctly). + + +When the CacheFiles module is asked to bind to its cache, it: + + (1) Finds the security label attached to the root cache directory and uses + that as the security label with which it will create files. By default, + this is:: + + cachefiles_var_t + + (2) Finds the security label of the process which issued the bind request + (presumed to be the cachefilesd daemon), which by default will be:: + + cachefilesd_t + + and asks LSM to supply a security ID as which it should act given the + daemon's label. By default, this will be:: + + cachefiles_kernel_t + + SELinux transitions the daemon's security ID to the module's security ID + based on a rule of this form in the policy:: + + type_transition <daemon's-ID> kernel_t : process <module's-ID>; + + For instance:: + + type_transition cachefilesd_t kernel_t : process cachefiles_kernel_t; + + +The module's security ID gives it permission to create, move and remove files +and directories in the cache, to find and access directories and files in the +cache, to set and access extended attributes on cache objects, and to read and +write files in the cache. + +The daemon's security ID gives it only a very restricted set of permissions: it +may scan directories, stat files and erase files and directories. It may +not read or write files in the cache, and so it is precluded from accessing the +data cached therein; nor is it permitted to create new files in the cache. + + +There are policy source files available in: + + http://people.redhat.com/~dhowells/fscache/cachefilesd-0.8.tar.bz2 + +and later versions. In that tarball, see the files:: + + cachefilesd.te + cachefilesd.fc + cachefilesd.if + +They are built and installed directly by the RPM. + +If a non-RPM based system is being used, then copy the above files to their own +directory and run:: + + make -f /usr/share/selinux/devel/Makefile + semodule -i cachefilesd.pp + +You will need checkpolicy and selinux-policy-devel installed prior to the +build. + + +By default, the cache is located in /var/fscache, but if it is desirable that +it should be elsewhere, than either the above policy files must be altered, or +an auxiliary policy must be installed to label the alternate location of the +cache. + +For instructions on how to add an auxiliary policy to enable the cache to be +located elsewhere when SELinux is in enforcing mode, please see:: + + /usr/share/doc/cachefilesd-*/move-cache.txt + +When the cachefilesd rpm is installed; alternatively, the document can be found +in the sources. + + +A Note on Security +================== + +CacheFiles makes use of the split security in the task_struct. It allocates +its own task_security structure, and redirects current->cred to point to it +when it acts on behalf of another process, in that process's context. + +The reason it does this is that it calls vfs_mkdir() and suchlike rather than +bypassing security and calling inode ops directly. Therefore the VFS and LSM +may deny the CacheFiles access to the cache data because under some +circumstances the caching code is running in the security context of whatever +process issued the original syscall on the netfs. + +Furthermore, should CacheFiles create a file or directory, the security +parameters with that object is created (UID, GID, security label) would be +derived from that process that issued the system call, thus potentially +preventing other processes from accessing the cache - including CacheFiles's +cache management daemon (cachefilesd). + +What is required is to temporarily override the security of the process that +issued the system call. We can't, however, just do an in-place change of the +security data as that affects the process as an object, not just as a subject. +This means it may lose signals or ptrace events for example, and affects what +the process looks like in /proc. + +So CacheFiles makes use of a logical split in the security between the +objective security (task->real_cred) and the subjective security (task->cred). +The objective security holds the intrinsic security properties of a process and +is never overridden. This is what appears in /proc, and is what is used when a +process is the target of an operation by some other process (SIGKILL for +example). + +The subjective security holds the active security properties of a process, and +may be overridden. This is not seen externally, and is used whan a process +acts upon another object, for example SIGKILLing another process or opening a +file. + +LSM hooks exist that allow SELinux (or Smack or whatever) to reject a request +for CacheFiles to run in a context of a specific security label, or to create +files and directories with another security label. + + +Statistical Information +======================= + +If FS-Cache is compiled with the following option enabled:: + + CONFIG_CACHEFILES_HISTOGRAM=y + +then it will gather certain statistics and display them through a proc file. + + /proc/fs/cachefiles/histogram + + :: + + cat /proc/fs/cachefiles/histogram + JIFS SECS LOOKUPS MKDIRS CREATES + ===== ===== ========= ========= ========= + + This shows the breakdown of the number of times each amount of time + between 0 jiffies and HZ-1 jiffies a variety of tasks took to run. The + columns are as follows: + + ======= ======================================================= + COLUMN TIME MEASUREMENT + ======= ======================================================= + LOOKUPS Length of time to perform a lookup on the backing fs + MKDIRS Length of time to perform a mkdir on the backing fs + CREATES Length of time to perform a create on the backing fs + ======= ======================================================= + + Each row shows the number of events that took a particular range of times. + Each step is 1 jiffy in size. The JIFS column indicates the particular + jiffy range covered, and the SECS field the equivalent number of seconds. + + +Debugging +========= + +If CONFIG_CACHEFILES_DEBUG is enabled, the CacheFiles facility can have runtime +debugging enabled by adjusting the value in:: + + /sys/module/cachefiles/parameters/debug + +This is a bitmask of debugging streams to enable: + + ======= ======= =============================== ======================= + BIT VALUE STREAM POINT + ======= ======= =============================== ======================= + 0 1 General Function entry trace + 1 2 Function exit trace + 2 4 General + ======= ======= =============================== ======================= + +The appropriate set of values should be OR'd together and the result written to +the control file. For example:: + + echo $((1|4|8)) >/sys/module/cachefiles/parameters/debug + +will turn on all function entry debugging.
diff --git a/Documentation/filesystems/caching/cachefiles.txt b/Documentation/filesystems/caching/cachefiles.txt deleted file mode 100644 index 28aefcb..0000000 --- a/Documentation/filesystems/caching/cachefiles.txt +++ /dev/null
@@ -1,501 +0,0 @@ - =============================================== - CacheFiles: CACHE ON ALREADY MOUNTED FILESYSTEM - =============================================== - -Contents: - - (*) Overview. - - (*) Requirements. - - (*) Configuration. - - (*) Starting the cache. - - (*) Things to avoid. - - (*) Cache culling. - - (*) Cache structure. - - (*) Security model and SELinux. - - (*) A note on security. - - (*) Statistical information. - - (*) Debugging. - - -======== -OVERVIEW -======== - -CacheFiles is a caching backend that's meant to use as a cache a directory on -an already mounted filesystem of a local type (such as Ext3). - -CacheFiles uses a userspace daemon to do some of the cache management - such as -reaping stale nodes and culling. This is called cachefilesd and lives in -/sbin. - -The filesystem and data integrity of the cache are only as good as those of the -filesystem providing the backing services. Note that CacheFiles does not -attempt to journal anything since the journalling interfaces of the various -filesystems are very specific in nature. - -CacheFiles creates a misc character device - "/dev/cachefiles" - that is used -to communication with the daemon. Only one thing may have this open at once, -and while it is open, a cache is at least partially in existence. The daemon -opens this and sends commands down it to control the cache. - -CacheFiles is currently limited to a single cache. - -CacheFiles attempts to maintain at least a certain percentage of free space on -the filesystem, shrinking the cache by culling the objects it contains to make -space if necessary - see the "Cache Culling" section. This means it can be -placed on the same medium as a live set of data, and will expand to make use of -spare space and automatically contract when the set of data requires more -space. - - -============ -REQUIREMENTS -============ - -The use of CacheFiles and its daemon requires the following features to be -available in the system and in the cache filesystem: - - - dnotify. - - - extended attributes (xattrs). - - - openat() and friends. - - - bmap() support on files in the filesystem (FIBMAP ioctl). - - - The use of bmap() to detect a partial page at the end of the file. - -It is strongly recommended that the "dir_index" option is enabled on Ext3 -filesystems being used as a cache. - - -============= -CONFIGURATION -============= - -The cache is configured by a script in /etc/cachefilesd.conf. These commands -set up cache ready for use. The following script commands are available: - - (*) brun <N>% - (*) bcull <N>% - (*) bstop <N>% - (*) frun <N>% - (*) fcull <N>% - (*) fstop <N>% - - Configure the culling limits. Optional. See the section on culling - The defaults are 7% (run), 5% (cull) and 1% (stop) respectively. - - The commands beginning with a 'b' are file space (block) limits, those - beginning with an 'f' are file count limits. - - (*) dir <path> - - Specify the directory containing the root of the cache. Mandatory. - - (*) tag <name> - - Specify a tag to FS-Cache to use in distinguishing multiple caches. - Optional. The default is "CacheFiles". - - (*) debug <mask> - - Specify a numeric bitmask to control debugging in the kernel module. - Optional. The default is zero (all off). The following values can be - OR'd into the mask to collect various information: - - 1 Turn on trace of function entry (_enter() macros) - 2 Turn on trace of function exit (_leave() macros) - 4 Turn on trace of internal debug points (_debug()) - - This mask can also be set through sysfs, eg: - - echo 5 >/sys/modules/cachefiles/parameters/debug - - -================== -STARTING THE CACHE -================== - -The cache is started by running the daemon. The daemon opens the cache device, -configures the cache and tells it to begin caching. At that point the cache -binds to fscache and the cache becomes live. - -The daemon is run as follows: - - /sbin/cachefilesd [-d]* [-s] [-n] [-f <configfile>] - -The flags are: - - (*) -d - - Increase the debugging level. This can be specified multiple times and - is cumulative with itself. - - (*) -s - - Send messages to stderr instead of syslog. - - (*) -n - - Don't daemonise and go into background. - - (*) -f <configfile> - - Use an alternative configuration file rather than the default one. - - -=============== -THINGS TO AVOID -=============== - -Do not mount other things within the cache as this will cause problems. The -kernel module contains its own very cut-down path walking facility that ignores -mountpoints, but the daemon can't avoid them. - -Do not create, rename or unlink files and directories in the cache while the -cache is active, as this may cause the state to become uncertain. - -Renaming files in the cache might make objects appear to be other objects (the -filename is part of the lookup key). - -Do not change or remove the extended attributes attached to cache files by the -cache as this will cause the cache state management to get confused. - -Do not create files or directories in the cache, lest the cache get confused or -serve incorrect data. - -Do not chmod files in the cache. The module creates things with minimal -permissions to prevent random users being able to access them directly. - - -============= -CACHE CULLING -============= - -The cache may need culling occasionally to make space. This involves -discarding objects from the cache that have been used less recently than -anything else. Culling is based on the access time of data objects. Empty -directories are culled if not in use. - -Cache culling is done on the basis of the percentage of blocks and the -percentage of files available in the underlying filesystem. There are six -"limits": - - (*) brun - (*) frun - - If the amount of free space and the number of available files in the cache - rises above both these limits, then culling is turned off. - - (*) bcull - (*) fcull - - If the amount of available space or the number of available files in the - cache falls below either of these limits, then culling is started. - - (*) bstop - (*) fstop - - If the amount of available space or the number of available files in the - cache falls below either of these limits, then no further allocation of - disk space or files is permitted until culling has raised things above - these limits again. - -These must be configured thusly: - - 0 <= bstop < bcull < brun < 100 - 0 <= fstop < fcull < frun < 100 - -Note that these are percentages of available space and available files, and do -_not_ appear as 100 minus the percentage displayed by the "df" program. - -The userspace daemon scans the cache to build up a table of cullable objects. -These are then culled in least recently used order. A new scan of the cache is -started as soon as space is made in the table. Objects will be skipped if -their atimes have changed or if the kernel module says it is still using them. - - -=============== -CACHE STRUCTURE -=============== - -The CacheFiles module will create two directories in the directory it was -given: - - (*) cache/ - - (*) graveyard/ - -The active cache objects all reside in the first directory. The CacheFiles -kernel module moves any retired or culled objects that it can't simply unlink -to the graveyard from which the daemon will actually delete them. - -The daemon uses dnotify to monitor the graveyard directory, and will delete -anything that appears therein. - - -The module represents index objects as directories with the filename "I..." or -"J...". Note that the "cache/" directory is itself a special index. - -Data objects are represented as files if they have no children, or directories -if they do. Their filenames all begin "D..." or "E...". If represented as a -directory, data objects will have a file in the directory called "data" that -actually holds the data. - -Special objects are similar to data objects, except their filenames begin -"S..." or "T...". - - -If an object has children, then it will be represented as a directory. -Immediately in the representative directory are a collection of directories -named for hash values of the child object keys with an '@' prepended. Into -this directory, if possible, will be placed the representations of the child -objects: - - INDEX INDEX INDEX DATA FILES - ========= ========== ================================= ================ - cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400 - cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...DB1ry - cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...N22ry - cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...FP1ry - - -If the key is so long that it exceeds NAME_MAX with the decorations added on to -it, then it will be cut into pieces, the first few of which will be used to -make a nest of directories, and the last one of which will be the objects -inside the last directory. The names of the intermediate directories will have -'+' prepended: - - J1223/@23/+xy...z/+kl...m/Epqr - - -Note that keys are raw data, and not only may they exceed NAME_MAX in size, -they may also contain things like '/' and NUL characters, and so they may not -be suitable for turning directly into a filename. - -To handle this, CacheFiles will use a suitably printable filename directly and -"base-64" encode ones that aren't directly suitable. The two versions of -object filenames indicate the encoding: - - OBJECT TYPE PRINTABLE ENCODED - =============== =============== =============== - Index "I..." "J..." - Data "D..." "E..." - Special "S..." "T..." - -Intermediate directories are always "@" or "+" as appropriate. - - -Each object in the cache has an extended attribute label that holds the object -type ID (required to distinguish special objects) and the auxiliary data from -the netfs. The latter is used to detect stale objects in the cache and update -or retire them. - - -Note that CacheFiles will erase from the cache any file it doesn't recognise or -any file of an incorrect type (such as a FIFO file or a device file). - - -========================== -SECURITY MODEL AND SELINUX -========================== - -CacheFiles is implemented to deal properly with the LSM security features of -the Linux kernel and the SELinux facility. - -One of the problems that CacheFiles faces is that it is generally acting on -behalf of a process, and running in that process's context, and that includes a -security context that is not appropriate for accessing the cache - either -because the files in the cache are inaccessible to that process, or because if -the process creates a file in the cache, that file may be inaccessible to other -processes. - -The way CacheFiles works is to temporarily change the security context (fsuid, -fsgid and actor security label) that the process acts as - without changing the -security context of the process when it the target of an operation performed by -some other process (so signalling and suchlike still work correctly). - - -When the CacheFiles module is asked to bind to its cache, it: - - (1) Finds the security label attached to the root cache directory and uses - that as the security label with which it will create files. By default, - this is: - - cachefiles_var_t - - (2) Finds the security label of the process which issued the bind request - (presumed to be the cachefilesd daemon), which by default will be: - - cachefilesd_t - - and asks LSM to supply a security ID as which it should act given the - daemon's label. By default, this will be: - - cachefiles_kernel_t - - SELinux transitions the daemon's security ID to the module's security ID - based on a rule of this form in the policy. - - type_transition <daemon's-ID> kernel_t : process <module's-ID>; - - For instance: - - type_transition cachefilesd_t kernel_t : process cachefiles_kernel_t; - - -The module's security ID gives it permission to create, move and remove files -and directories in the cache, to find and access directories and files in the -cache, to set and access extended attributes on cache objects, and to read and -write files in the cache. - -The daemon's security ID gives it only a very restricted set of permissions: it -may scan directories, stat files and erase files and directories. It may -not read or write files in the cache, and so it is precluded from accessing the -data cached therein; nor is it permitted to create new files in the cache. - - -There are policy source files available in: - - http://people.redhat.com/~dhowells/fscache/cachefilesd-0.8.tar.bz2 - -and later versions. In that tarball, see the files: - - cachefilesd.te - cachefilesd.fc - cachefilesd.if - -They are built and installed directly by the RPM. - -If a non-RPM based system is being used, then copy the above files to their own -directory and run: - - make -f /usr/share/selinux/devel/Makefile - semodule -i cachefilesd.pp - -You will need checkpolicy and selinux-policy-devel installed prior to the -build. - - -By default, the cache is located in /var/fscache, but if it is desirable that -it should be elsewhere, than either the above policy files must be altered, or -an auxiliary policy must be installed to label the alternate location of the -cache. - -For instructions on how to add an auxiliary policy to enable the cache to be -located elsewhere when SELinux is in enforcing mode, please see: - - /usr/share/doc/cachefilesd-*/move-cache.txt - -When the cachefilesd rpm is installed; alternatively, the document can be found -in the sources. - - -================== -A NOTE ON SECURITY -================== - -CacheFiles makes use of the split security in the task_struct. It allocates -its own task_security structure, and redirects current->cred to point to it -when it acts on behalf of another process, in that process's context. - -The reason it does this is that it calls vfs_mkdir() and suchlike rather than -bypassing security and calling inode ops directly. Therefore the VFS and LSM -may deny the CacheFiles access to the cache data because under some -circumstances the caching code is running in the security context of whatever -process issued the original syscall on the netfs. - -Furthermore, should CacheFiles create a file or directory, the security -parameters with that object is created (UID, GID, security label) would be -derived from that process that issued the system call, thus potentially -preventing other processes from accessing the cache - including CacheFiles's -cache management daemon (cachefilesd). - -What is required is to temporarily override the security of the process that -issued the system call. We can't, however, just do an in-place change of the -security data as that affects the process as an object, not just as a subject. -This means it may lose signals or ptrace events for example, and affects what -the process looks like in /proc. - -So CacheFiles makes use of a logical split in the security between the -objective security (task->real_cred) and the subjective security (task->cred). -The objective security holds the intrinsic security properties of a process and -is never overridden. This is what appears in /proc, and is what is used when a -process is the target of an operation by some other process (SIGKILL for -example). - -The subjective security holds the active security properties of a process, and -may be overridden. This is not seen externally, and is used whan a process -acts upon another object, for example SIGKILLing another process or opening a -file. - -LSM hooks exist that allow SELinux (or Smack or whatever) to reject a request -for CacheFiles to run in a context of a specific security label, or to create -files and directories with another security label. - - -======================= -STATISTICAL INFORMATION -======================= - -If FS-Cache is compiled with the following option enabled: - - CONFIG_CACHEFILES_HISTOGRAM=y - -then it will gather certain statistics and display them through a proc file. - - (*) /proc/fs/cachefiles/histogram - - cat /proc/fs/cachefiles/histogram - JIFS SECS LOOKUPS MKDIRS CREATES - ===== ===== ========= ========= ========= - - This shows the breakdown of the number of times each amount of time - between 0 jiffies and HZ-1 jiffies a variety of tasks took to run. The - columns are as follows: - - COLUMN TIME MEASUREMENT - ======= ======================================================= - LOOKUPS Length of time to perform a lookup on the backing fs - MKDIRS Length of time to perform a mkdir on the backing fs - CREATES Length of time to perform a create on the backing fs - - Each row shows the number of events that took a particular range of times. - Each step is 1 jiffy in size. The JIFS column indicates the particular - jiffy range covered, and the SECS field the equivalent number of seconds. - - -========= -DEBUGGING -========= - -If CONFIG_CACHEFILES_DEBUG is enabled, the CacheFiles facility can have runtime -debugging enabled by adjusting the value in: - - /sys/module/cachefiles/parameters/debug - -This is a bitmask of debugging streams to enable: - - BIT VALUE STREAM POINT - ======= ======= =============================== ======================= - 0 1 General Function entry trace - 1 2 Function exit trace - 2 4 General - -The appropriate set of values should be OR'd together and the result written to -the control file. For example: - - echo $((1|4|8)) >/sys/module/cachefiles/parameters/debug - -will turn on all function entry debugging.
diff --git a/Documentation/filesystems/caching/fscache.rst b/Documentation/filesystems/caching/fscache.rst new file mode 100644 index 0000000..70de869 --- /dev/null +++ b/Documentation/filesystems/caching/fscache.rst
@@ -0,0 +1,565 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +General Filesystem Caching +========================== + +Overview +======== + +This facility is a general purpose cache for network filesystems, though it +could be used for caching other things such as ISO9660 filesystems too. + +FS-Cache mediates between cache backends (such as CacheFS) and network +filesystems:: + + +---------+ + | | +--------------+ + | NFS |--+ | | + | | | +-->| CacheFS | + +---------+ | +----------+ | | /dev/hda5 | + | | | | +--------------+ + +---------+ +-->| | | + | | | |--+ + | AFS |----->| FS-Cache | + | | | |--+ + +---------+ +-->| | | + | | | | +--------------+ + +---------+ | +----------+ | | | + | | | +-->| CacheFiles | + | ISOFS |--+ | /var/cache | + | | +--------------+ + +---------+ + +Or to look at it another way, FS-Cache is a module that provides a caching +facility to a network filesystem such that the cache is transparent to the +user:: + + +---------+ + | | + | Server | + | | + +---------+ + | NETWORK + ~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + | + | +----------+ + V | | + +---------+ | | + | | | | + | NFS |----->| FS-Cache | + | | | |--+ + +---------+ | | | +--------------+ +--------------+ + | | | | | | | | + V +----------+ +-->| CacheFiles |-->| Ext3 | + +---------+ | /var/cache | | /dev/sda6 | + | | +--------------+ +--------------+ + | VFS | ^ ^ + | | | | + +---------+ +--------------+ | + | KERNEL SPACE | | + ~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~|~~~~ + | USER SPACE | | + V | | + +---------+ +--------------+ + | | | | + | Process | | cachefilesd | + | | | | + +---------+ +--------------+ + + +FS-Cache does not follow the idea of completely loading every netfs file +opened in its entirety into a cache before permitting it to be accessed and +then serving the pages out of that cache rather than the netfs inode because: + + (1) It must be practical to operate without a cache. + + (2) The size of any accessible file must not be limited to the size of the + cache. + + (3) The combined size of all opened files (this includes mapped libraries) + must not be limited to the size of the cache. + + (4) The user should not be forced to download an entire file just to do a + one-off access of a small portion of it (such as might be done with the + "file" program). + +It instead serves the cache out in PAGE_SIZE chunks as and when requested by +the netfs('s) using it. + + +FS-Cache provides the following facilities: + + (1) More than one cache can be used at once. Caches can be selected + explicitly by use of tags. + + (2) Caches can be added / removed at any time. + + (3) The netfs is provided with an interface that allows either party to + withdraw caching facilities from a file (required for (2)). + + (4) The interface to the netfs returns as few errors as possible, preferring + rather to let the netfs remain oblivious. + + (5) Cookies are used to represent indices, files and other objects to the + netfs. The simplest cookie is just a NULL pointer - indicating nothing + cached there. + + (6) The netfs is allowed to propose - dynamically - any index hierarchy it + desires, though it must be aware that the index search function is + recursive, stack space is limited, and indices can only be children of + indices. + + (7) Data I/O is done direct to and from the netfs's pages. The netfs + indicates that page A is at index B of the data-file represented by cookie + C, and that it should be read or written. The cache backend may or may + not start I/O on that page, but if it does, a netfs callback will be + invoked to indicate completion. The I/O may be either synchronous or + asynchronous. + + (8) Cookies can be "retired" upon release. At this point FS-Cache will mark + them as obsolete and the index hierarchy rooted at that point will get + recycled. + + (9) The netfs provides a "match" function for index searches. In addition to + saying whether a match was made or not, this can also specify that an + entry should be updated or deleted. + +(10) As much as possible is done asynchronously. + + +FS-Cache maintains a virtual indexing tree in which all indices, files, objects +and pages are kept. Bits of this tree may actually reside in one or more +caches:: + + FSDEF + | + +------------------------------------+ + | | + NFS AFS + | | + +--------------------------+ +-----------+ + | | | | + homedir mirror afs.org redhat.com + | | | + +------------+ +---------------+ +----------+ + | | | | | | + 00001 00002 00007 00125 vol00001 vol00002 + | | | | | + +---+---+ +-----+ +---+ +------+------+ +-----+----+ + | | | | | | | | | | | | | + PG0 PG1 PG2 PG0 XATTR PG0 PG1 DIRENT DIRENT DIRENT R/W R/O Bak + | | + PG0 +-------+ + | | + 00001 00003 + | + +---+---+ + | | | + PG0 PG1 PG2 + +In the example above, you can see two netfs's being backed: NFS and AFS. These +have different index hierarchies: + + * The NFS primary index contains per-server indices. Each server index is + indexed by NFS file handles to get data file objects. Each data file + objects can have an array of pages, but may also have further child + objects, such as extended attributes and directory entries. Extended + attribute objects themselves have page-array contents. + + * The AFS primary index contains per-cell indices. Each cell index contains + per-logical-volume indices. Each of volume index contains up to three + indices for the read-write, read-only and backup mirrors of those volumes. + Each of these contains vnode data file objects, each of which contains an + array of pages. + +The very top index is the FS-Cache master index in which individual netfs's +have entries. + +Any index object may reside in more than one cache, provided it only has index +children. Any index with non-index object children will be assumed to only +reside in one cache. + + +The netfs API to FS-Cache can be found in: + + Documentation/filesystems/caching/netfs-api.rst + +The cache backend API to FS-Cache can be found in: + + Documentation/filesystems/caching/backend-api.rst + +A description of the internal representations and object state machine can be +found in: + + Documentation/filesystems/caching/object.rst + + +Statistical Information +======================= + +If FS-Cache is compiled with the following options enabled:: + + CONFIG_FSCACHE_STATS=y + CONFIG_FSCACHE_HISTOGRAM=y + +then it will gather certain statistics and display them through a number of +proc files. + +/proc/fs/fscache/stats +---------------------- + + This shows counts of a number of events that can happen in FS-Cache: + ++--------------+-------+-------------------------------------------------------+ +|CLASS |EVENT |MEANING | ++==============+=======+=======================================================+ +|Cookies |idx=N |Number of index cookies allocated | ++ +-------+-------------------------------------------------------+ +| |dat=N |Number of data storage cookies allocated | ++ +-------+-------------------------------------------------------+ +| |spc=N |Number of special cookies allocated | ++--------------+-------+-------------------------------------------------------+ +|Objects |alc=N |Number of objects allocated | ++ +-------+-------------------------------------------------------+ +| |nal=N |Number of object allocation failures | ++ +-------+-------------------------------------------------------+ +| |avl=N |Number of objects that reached the available state | ++ +-------+-------------------------------------------------------+ +| |ded=N |Number of objects that reached the dead state | ++--------------+-------+-------------------------------------------------------+ +|ChkAux |non=N |Number of objects that didn't have a coherency check | ++ +-------+-------------------------------------------------------+ +| |ok=N |Number of objects that passed a coherency check | ++ +-------+-------------------------------------------------------+ +| |upd=N |Number of objects that needed a coherency data update | ++ +-------+-------------------------------------------------------+ +| |obs=N |Number of objects that were declared obsolete | ++--------------+-------+-------------------------------------------------------+ +|Pages |mrk=N |Number of pages marked as being cached | +| |unc=N |Number of uncache page requests seen | ++--------------+-------+-------------------------------------------------------+ +|Acquire |n=N |Number of acquire cookie requests seen | ++ +-------+-------------------------------------------------------+ +| |nul=N |Number of acq reqs given a NULL parent | ++ +-------+-------------------------------------------------------+ +| |noc=N |Number of acq reqs rejected due to no cache available | ++ +-------+-------------------------------------------------------+ +| |ok=N |Number of acq reqs succeeded | ++ +-------+-------------------------------------------------------+ +| |nbf=N |Number of acq reqs rejected due to error | ++ +-------+-------------------------------------------------------+ +| |oom=N |Number of acq reqs failed on ENOMEM | ++--------------+-------+-------------------------------------------------------+ +|Lookups |n=N |Number of lookup calls made on cache backends | ++ +-------+-------------------------------------------------------+ +| |neg=N |Number of negative lookups made | ++ +-------+-------------------------------------------------------+ +| |pos=N |Number of positive lookups made | ++ +-------+-------------------------------------------------------+ +| |crt=N |Number of objects created by lookup | ++ +-------+-------------------------------------------------------+ +| |tmo=N |Number of lookups timed out and requeued | ++--------------+-------+-------------------------------------------------------+ +|Updates |n=N |Number of update cookie requests seen | ++ +-------+-------------------------------------------------------+ +| |nul=N |Number of upd reqs given a NULL parent | ++ +-------+-------------------------------------------------------+ +| |run=N |Number of upd reqs granted CPU time | ++--------------+-------+-------------------------------------------------------+ +|Relinqs |n=N |Number of relinquish cookie requests seen | ++ +-------+-------------------------------------------------------+ +| |nul=N |Number of rlq reqs given a NULL parent | ++ +-------+-------------------------------------------------------+ +| |wcr=N |Number of rlq reqs waited on completion of creation | ++--------------+-------+-------------------------------------------------------+ +|AttrChg |n=N |Number of attribute changed requests seen | ++ +-------+-------------------------------------------------------+ +| |ok=N |Number of attr changed requests queued | ++ +-------+-------------------------------------------------------+ +| |nbf=N |Number of attr changed rejected -ENOBUFS | ++ +-------+-------------------------------------------------------+ +| |oom=N |Number of attr changed failed -ENOMEM | ++ +-------+-------------------------------------------------------+ +| |run=N |Number of attr changed ops given CPU time | ++--------------+-------+-------------------------------------------------------+ +|Allocs |n=N |Number of allocation requests seen | ++ +-------+-------------------------------------------------------+ +| |ok=N |Number of successful alloc reqs | ++ +-------+-------------------------------------------------------+ +| |wt=N |Number of alloc reqs that waited on lookup completion | ++ +-------+-------------------------------------------------------+ +| |nbf=N |Number of alloc reqs rejected -ENOBUFS | ++ +-------+-------------------------------------------------------+ +| |int=N |Number of alloc reqs aborted -ERESTARTSYS | ++ +-------+-------------------------------------------------------+ +| |ops=N |Number of alloc reqs submitted | ++ +-------+-------------------------------------------------------+ +| |owt=N |Number of alloc reqs waited for CPU time | ++ +-------+-------------------------------------------------------+ +| |abt=N |Number of alloc reqs aborted due to object death | ++--------------+-------+-------------------------------------------------------+ +|Retrvls |n=N |Number of retrieval (read) requests seen | ++ +-------+-------------------------------------------------------+ +| |ok=N |Number of successful retr reqs | ++ +-------+-------------------------------------------------------+ +| |wt=N |Number of retr reqs that waited on lookup completion | ++ +-------+-------------------------------------------------------+ +| |nod=N |Number of retr reqs returned -ENODATA | ++ +-------+-------------------------------------------------------+ +| |nbf=N |Number of retr reqs rejected -ENOBUFS | ++ +-------+-------------------------------------------------------+ +| |int=N |Number of retr reqs aborted -ERESTARTSYS | ++ +-------+-------------------------------------------------------+ +| |oom=N |Number of retr reqs failed -ENOMEM | ++ +-------+-------------------------------------------------------+ +| |ops=N |Number of retr reqs submitted | ++ +-------+-------------------------------------------------------+ +| |owt=N |Number of retr reqs waited for CPU time | ++ +-------+-------------------------------------------------------+ +| |abt=N |Number of retr reqs aborted due to object death | ++--------------+-------+-------------------------------------------------------+ +|Stores |n=N |Number of storage (write) requests seen | ++ +-------+-------------------------------------------------------+ +| |ok=N |Number of successful store reqs | ++ +-------+-------------------------------------------------------+ +| |agn=N |Number of store reqs on a page already pending storage | ++ +-------+-------------------------------------------------------+ +| |nbf=N |Number of store reqs rejected -ENOBUFS | ++ +-------+-------------------------------------------------------+ +| |oom=N |Number of store reqs failed -ENOMEM | ++ +-------+-------------------------------------------------------+ +| |ops=N |Number of store reqs submitted | ++ +-------+-------------------------------------------------------+ +| |run=N |Number of store reqs granted CPU time | ++ +-------+-------------------------------------------------------+ +| |pgs=N |Number of pages given store req processing time | ++ +-------+-------------------------------------------------------+ +| |rxd=N |Number of store reqs deleted from tracking tree | ++ +-------+-------------------------------------------------------+ +| |olm=N |Number of store reqs over store limit | ++--------------+-------+-------------------------------------------------------+ +|VmScan |nos=N |Number of release reqs against pages with no | +| | |pending store | ++ +-------+-------------------------------------------------------+ +| |gon=N |Number of release reqs against pages stored by | +| | |time lock granted | ++ +-------+-------------------------------------------------------+ +| |bsy=N |Number of release reqs ignored due to in-progress store| ++ +-------+-------------------------------------------------------+ +| |can=N |Number of page stores cancelled due to release req | ++--------------+-------+-------------------------------------------------------+ +|Ops |pend=N |Number of times async ops added to pending queues | ++ +-------+-------------------------------------------------------+ +| |run=N |Number of times async ops given CPU time | ++ +-------+-------------------------------------------------------+ +| |enq=N |Number of times async ops queued for processing | ++ +-------+-------------------------------------------------------+ +| |can=N |Number of async ops cancelled | ++ +-------+-------------------------------------------------------+ +| |rej=N |Number of async ops rejected due to object | +| | |lookup/create failure | ++ +-------+-------------------------------------------------------+ +| |ini=N |Number of async ops initialised | ++ +-------+-------------------------------------------------------+ +| |dfr=N |Number of async ops queued for deferred release | ++ +-------+-------------------------------------------------------+ +| |rel=N |Number of async ops released | +| | |(should equal ini=N when idle) | ++ +-------+-------------------------------------------------------+ +| |gc=N |Number of deferred-release async ops garbage collected | ++--------------+-------+-------------------------------------------------------+ +|CacheOp |alo=N |Number of in-progress alloc_object() cache ops | ++ +-------+-------------------------------------------------------+ +| |luo=N |Number of in-progress lookup_object() cache ops | ++ +-------+-------------------------------------------------------+ +| |luc=N |Number of in-progress lookup_complete() cache ops | ++ +-------+-------------------------------------------------------+ +| |gro=N |Number of in-progress grab_object() cache ops | ++ +-------+-------------------------------------------------------+ +| |upo=N |Number of in-progress update_object() cache ops | ++ +-------+-------------------------------------------------------+ +| |dro=N |Number of in-progress drop_object() cache ops | ++ +-------+-------------------------------------------------------+ +| |pto=N |Number of in-progress put_object() cache ops | ++ +-------+-------------------------------------------------------+ +| |syn=N |Number of in-progress sync_cache() cache ops | ++ +-------+-------------------------------------------------------+ +| |atc=N |Number of in-progress attr_changed() cache ops | ++ +-------+-------------------------------------------------------+ +| |rap=N |Number of in-progress read_or_alloc_page() cache ops | ++ +-------+-------------------------------------------------------+ +| |ras=N |Number of in-progress read_or_alloc_pages() cache ops | ++ +-------+-------------------------------------------------------+ +| |alp=N |Number of in-progress allocate_page() cache ops | ++ +-------+-------------------------------------------------------+ +| |als=N |Number of in-progress allocate_pages() cache ops | ++ +-------+-------------------------------------------------------+ +| |wrp=N |Number of in-progress write_page() cache ops | ++ +-------+-------------------------------------------------------+ +| |ucp=N |Number of in-progress uncache_page() cache ops | ++ +-------+-------------------------------------------------------+ +| |dsp=N |Number of in-progress dissociate_pages() cache ops | ++--------------+-------+-------------------------------------------------------+ +|CacheEv |nsp=N |Number of object lookups/creations rejected due to | +| | |lack of space | ++ +-------+-------------------------------------------------------+ +| |stl=N |Number of stale objects deleted | ++ +-------+-------------------------------------------------------+ +| |rtr=N |Number of objects retired when relinquished | ++ +-------+-------------------------------------------------------+ +| |cul=N |Number of objects culled | ++--------------+-------+-------------------------------------------------------+ + + + +/proc/fs/fscache/histogram +-------------------------- + + :: + + cat /proc/fs/fscache/histogram + JIFS SECS OBJ INST OP RUNS OBJ RUNS RETRV DLY RETRIEVLS + ===== ===== ========= ========= ========= ========= ========= + + This shows the breakdown of the number of times each amount of time + between 0 jiffies and HZ-1 jiffies a variety of tasks took to run. The + columns are as follows: + + ========= ======================================================= + COLUMN TIME MEASUREMENT + ========= ======================================================= + OBJ INST Length of time to instantiate an object + OP RUNS Length of time a call to process an operation took + OBJ RUNS Length of time a call to process an object event took + RETRV DLY Time between an requesting a read and lookup completing + RETRIEVLS Time between beginning and end of a retrieval + ========= ======================================================= + + Each row shows the number of events that took a particular range of times. + Each step is 1 jiffy in size. The JIFS column indicates the particular + jiffy range covered, and the SECS field the equivalent number of seconds. + + + +Object List +=========== + +If CONFIG_FSCACHE_OBJECT_LIST is enabled, the FS-Cache facility will maintain a +list of all the objects currently allocated and allow them to be viewed +through:: + + /proc/fs/fscache/objects + +This will look something like:: + + [root@andromeda ~]# head /proc/fs/fscache/objects + OBJECT PARENT STAT CHLDN OPS OOP IPR EX READS EM EV F S | NETFS_COOKIE_DEF TY FL NETFS_DATA OBJECT_KEY, AUX_DATA + ======== ======== ==== ===== === === === == ===== == == = = | ================ == == ================ ================ + 17e4b 2 ACTV 0 0 0 0 0 0 7b 4 0 0 | NFS.fh DT 0 ffff88001dd82820 010006017edcf8bbc93b43298fdfbe71e50b57b13a172c0117f38472, e567634700000000000000000000000063f2404a000000000000000000000000c9030000000000000000000063f2404a + 1693a 2 ACTV 0 0 0 0 0 0 7b 4 0 0 | NFS.fh DT 0 ffff88002db23380 010006017edcf8bbc93b43298fdfbe71e50b57b1e0162c01a2df0ea6, 420ebc4a000000000000000000000000420ebc4a0000000000000000000000000e1801000000000000000000420ebc4a + +where the first set of columns before the '|' describe the object: + + ======= =============================================================== + COLUMN DESCRIPTION + ======= =============================================================== + OBJECT Object debugging ID (appears as OBJ%x in some debug messages) + PARENT Debugging ID of parent object + STAT Object state + CHLDN Number of child objects of this object + OPS Number of outstanding operations on this object + OOP Number of outstanding child object management operations + IPR + EX Number of outstanding exclusive operations + READS Number of outstanding read operations + EM Object's event mask + EV Events raised on this object + F Object flags + S Object work item busy state mask (1:pending 2:running) + ======= =============================================================== + +and the second set of columns describe the object's cookie, if present: + + ================ ====================================================== + COLUMN DESCRIPTION + ================ ====================================================== + NETFS_COOKIE_DEF Name of netfs cookie definition + TY Cookie type (IX - index, DT - data, hex - special) + FL Cookie flags + NETFS_DATA Netfs private data stored in the cookie + OBJECT_KEY Object key } 1 column, with separating comma + AUX_DATA Object aux data } presence may be configured + ================ ====================================================== + +The data shown may be filtered by attaching the a key to an appropriate keyring +before viewing the file. Something like:: + + keyctl add user fscache:objlist <restrictions> @s + +where <restrictions> are a selection of the following letters: + + == ========================================================= + K Show hexdump of object key (don't show if not given) + A Show hexdump of object aux data (don't show if not given) + == ========================================================= + +and the following paired letters: + + == ========================================================= + C Show objects that have a cookie + c Show objects that don't have a cookie + B Show objects that are busy + b Show objects that aren't busy + W Show objects that have pending writes + w Show objects that don't have pending writes + R Show objects that have outstanding reads + r Show objects that don't have outstanding reads + S Show objects that have work queued + s Show objects that don't have work queued + == ========================================================= + +If neither side of a letter pair is given, then both are implied. For example: + + keyctl add user fscache:objlist KB @s + +shows objects that are busy, and lists their object keys, but does not dump +their auxiliary data. It also implies "CcWwRrSs", but as 'B' is given, 'b' is +not implied. + +By default all objects and all fields will be shown. + + +Debugging +========= + +If CONFIG_FSCACHE_DEBUG is enabled, the FS-Cache facility can have runtime +debugging enabled by adjusting the value in:: + + /sys/module/fscache/parameters/debug + +This is a bitmask of debugging streams to enable: + + ======= ======= =============================== ======================= + BIT VALUE STREAM POINT + ======= ======= =============================== ======================= + 0 1 Cache management Function entry trace + 1 2 Function exit trace + 2 4 General + 3 8 Cookie management Function entry trace + 4 16 Function exit trace + 5 32 General + 6 64 Page handling Function entry trace + 7 128 Function exit trace + 8 256 General + 9 512 Operation management Function entry trace + 10 1024 Function exit trace + 11 2048 General + ======= ======= =============================== ======================= + +The appropriate set of values should be OR'd together and the result written to +the control file. For example:: + + echo $((1|8|64)) >/sys/module/fscache/parameters/debug + +will turn on all function entry debugging.
diff --git a/Documentation/filesystems/caching/fscache.txt b/Documentation/filesystems/caching/fscache.txt deleted file mode 100644 index 50f0a57..0000000 --- a/Documentation/filesystems/caching/fscache.txt +++ /dev/null
@@ -1,448 +0,0 @@ - ========================== - General Filesystem Caching - ========================== - -======== -OVERVIEW -======== - -This facility is a general purpose cache for network filesystems, though it -could be used for caching other things such as ISO9660 filesystems too. - -FS-Cache mediates between cache backends (such as CacheFS) and network -filesystems: - - +---------+ - | | +--------------+ - | NFS |--+ | | - | | | +-->| CacheFS | - +---------+ | +----------+ | | /dev/hda5 | - | | | | +--------------+ - +---------+ +-->| | | - | | | |--+ - | AFS |----->| FS-Cache | - | | | |--+ - +---------+ +-->| | | - | | | | +--------------+ - +---------+ | +----------+ | | | - | | | +-->| CacheFiles | - | ISOFS |--+ | /var/cache | - | | +--------------+ - +---------+ - -Or to look at it another way, FS-Cache is a module that provides a caching -facility to a network filesystem such that the cache is transparent to the -user: - - +---------+ - | | - | Server | - | | - +---------+ - | NETWORK - ~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - | - | +----------+ - V | | - +---------+ | | - | | | | - | NFS |----->| FS-Cache | - | | | |--+ - +---------+ | | | +--------------+ +--------------+ - | | | | | | | | - V +----------+ +-->| CacheFiles |-->| Ext3 | - +---------+ | /var/cache | | /dev/sda6 | - | | +--------------+ +--------------+ - | VFS | ^ ^ - | | | | - +---------+ +--------------+ | - | KERNEL SPACE | | - ~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~|~~~~ - | USER SPACE | | - V | | - +---------+ +--------------+ - | | | | - | Process | | cachefilesd | - | | | | - +---------+ +--------------+ - - -FS-Cache does not follow the idea of completely loading every netfs file -opened in its entirety into a cache before permitting it to be accessed and -then serving the pages out of that cache rather than the netfs inode because: - - (1) It must be practical to operate without a cache. - - (2) The size of any accessible file must not be limited to the size of the - cache. - - (3) The combined size of all opened files (this includes mapped libraries) - must not be limited to the size of the cache. - - (4) The user should not be forced to download an entire file just to do a - one-off access of a small portion of it (such as might be done with the - "file" program). - -It instead serves the cache out in PAGE_SIZE chunks as and when requested by -the netfs('s) using it. - - -FS-Cache provides the following facilities: - - (1) More than one cache can be used at once. Caches can be selected - explicitly by use of tags. - - (2) Caches can be added / removed at any time. - - (3) The netfs is provided with an interface that allows either party to - withdraw caching facilities from a file (required for (2)). - - (4) The interface to the netfs returns as few errors as possible, preferring - rather to let the netfs remain oblivious. - - (5) Cookies are used to represent indices, files and other objects to the - netfs. The simplest cookie is just a NULL pointer - indicating nothing - cached there. - - (6) The netfs is allowed to propose - dynamically - any index hierarchy it - desires, though it must be aware that the index search function is - recursive, stack space is limited, and indices can only be children of - indices. - - (7) Data I/O is done direct to and from the netfs's pages. The netfs - indicates that page A is at index B of the data-file represented by cookie - C, and that it should be read or written. The cache backend may or may - not start I/O on that page, but if it does, a netfs callback will be - invoked to indicate completion. The I/O may be either synchronous or - asynchronous. - - (8) Cookies can be "retired" upon release. At this point FS-Cache will mark - them as obsolete and the index hierarchy rooted at that point will get - recycled. - - (9) The netfs provides a "match" function for index searches. In addition to - saying whether a match was made or not, this can also specify that an - entry should be updated or deleted. - -(10) As much as possible is done asynchronously. - - -FS-Cache maintains a virtual indexing tree in which all indices, files, objects -and pages are kept. Bits of this tree may actually reside in one or more -caches. - - FSDEF - | - +------------------------------------+ - | | - NFS AFS - | | - +--------------------------+ +-----------+ - | | | | - homedir mirror afs.org redhat.com - | | | - +------------+ +---------------+ +----------+ - | | | | | | - 00001 00002 00007 00125 vol00001 vol00002 - | | | | | - +---+---+ +-----+ +---+ +------+------+ +-----+----+ - | | | | | | | | | | | | | -PG0 PG1 PG2 PG0 XATTR PG0 PG1 DIRENT DIRENT DIRENT R/W R/O Bak - | | - PG0 +-------+ - | | - 00001 00003 - | - +---+---+ - | | | - PG0 PG1 PG2 - -In the example above, you can see two netfs's being backed: NFS and AFS. These -have different index hierarchies: - - (*) The NFS primary index contains per-server indices. Each server index is - indexed by NFS file handles to get data file objects. Each data file - objects can have an array of pages, but may also have further child - objects, such as extended attributes and directory entries. Extended - attribute objects themselves have page-array contents. - - (*) The AFS primary index contains per-cell indices. Each cell index contains - per-logical-volume indices. Each of volume index contains up to three - indices for the read-write, read-only and backup mirrors of those volumes. - Each of these contains vnode data file objects, each of which contains an - array of pages. - -The very top index is the FS-Cache master index in which individual netfs's -have entries. - -Any index object may reside in more than one cache, provided it only has index -children. Any index with non-index object children will be assumed to only -reside in one cache. - - -The netfs API to FS-Cache can be found in: - - Documentation/filesystems/caching/netfs-api.txt - -The cache backend API to FS-Cache can be found in: - - Documentation/filesystems/caching/backend-api.txt - -A description of the internal representations and object state machine can be -found in: - - Documentation/filesystems/caching/object.txt - - -======================= -STATISTICAL INFORMATION -======================= - -If FS-Cache is compiled with the following options enabled: - - CONFIG_FSCACHE_STATS=y - CONFIG_FSCACHE_HISTOGRAM=y - -then it will gather certain statistics and display them through a number of -proc files. - - (*) /proc/fs/fscache/stats - - This shows counts of a number of events that can happen in FS-Cache: - - CLASS EVENT MEANING - ======= ======= ======================================================= - Cookies idx=N Number of index cookies allocated - dat=N Number of data storage cookies allocated - spc=N Number of special cookies allocated - Objects alc=N Number of objects allocated - nal=N Number of object allocation failures - avl=N Number of objects that reached the available state - ded=N Number of objects that reached the dead state - ChkAux non=N Number of objects that didn't have a coherency check - ok=N Number of objects that passed a coherency check - upd=N Number of objects that needed a coherency data update - obs=N Number of objects that were declared obsolete - Pages mrk=N Number of pages marked as being cached - unc=N Number of uncache page requests seen - Acquire n=N Number of acquire cookie requests seen - nul=N Number of acq reqs given a NULL parent - noc=N Number of acq reqs rejected due to no cache available - ok=N Number of acq reqs succeeded - nbf=N Number of acq reqs rejected due to error - oom=N Number of acq reqs failed on ENOMEM - Lookups n=N Number of lookup calls made on cache backends - neg=N Number of negative lookups made - pos=N Number of positive lookups made - crt=N Number of objects created by lookup - tmo=N Number of lookups timed out and requeued - Updates n=N Number of update cookie requests seen - nul=N Number of upd reqs given a NULL parent - run=N Number of upd reqs granted CPU time - Relinqs n=N Number of relinquish cookie requests seen - nul=N Number of rlq reqs given a NULL parent - wcr=N Number of rlq reqs waited on completion of creation - AttrChg n=N Number of attribute changed requests seen - ok=N Number of attr changed requests queued - nbf=N Number of attr changed rejected -ENOBUFS - oom=N Number of attr changed failed -ENOMEM - run=N Number of attr changed ops given CPU time - Allocs n=N Number of allocation requests seen - ok=N Number of successful alloc reqs - wt=N Number of alloc reqs that waited on lookup completion - nbf=N Number of alloc reqs rejected -ENOBUFS - int=N Number of alloc reqs aborted -ERESTARTSYS - ops=N Number of alloc reqs submitted - owt=N Number of alloc reqs waited for CPU time - abt=N Number of alloc reqs aborted due to object death - Retrvls n=N Number of retrieval (read) requests seen - ok=N Number of successful retr reqs - wt=N Number of retr reqs that waited on lookup completion - nod=N Number of retr reqs returned -ENODATA - nbf=N Number of retr reqs rejected -ENOBUFS - int=N Number of retr reqs aborted -ERESTARTSYS - oom=N Number of retr reqs failed -ENOMEM - ops=N Number of retr reqs submitted - owt=N Number of retr reqs waited for CPU time - abt=N Number of retr reqs aborted due to object death - Stores n=N Number of storage (write) requests seen - ok=N Number of successful store reqs - agn=N Number of store reqs on a page already pending storage - nbf=N Number of store reqs rejected -ENOBUFS - oom=N Number of store reqs failed -ENOMEM - ops=N Number of store reqs submitted - run=N Number of store reqs granted CPU time - pgs=N Number of pages given store req processing time - rxd=N Number of store reqs deleted from tracking tree - olm=N Number of store reqs over store limit - VmScan nos=N Number of release reqs against pages with no pending store - gon=N Number of release reqs against pages stored by time lock granted - bsy=N Number of release reqs ignored due to in-progress store - can=N Number of page stores cancelled due to release req - Ops pend=N Number of times async ops added to pending queues - run=N Number of times async ops given CPU time - enq=N Number of times async ops queued for processing - can=N Number of async ops cancelled - rej=N Number of async ops rejected due to object lookup/create failure - ini=N Number of async ops initialised - dfr=N Number of async ops queued for deferred release - rel=N Number of async ops released (should equal ini=N when idle) - gc=N Number of deferred-release async ops garbage collected - CacheOp alo=N Number of in-progress alloc_object() cache ops - luo=N Number of in-progress lookup_object() cache ops - luc=N Number of in-progress lookup_complete() cache ops - gro=N Number of in-progress grab_object() cache ops - upo=N Number of in-progress update_object() cache ops - dro=N Number of in-progress drop_object() cache ops - pto=N Number of in-progress put_object() cache ops - syn=N Number of in-progress sync_cache() cache ops - atc=N Number of in-progress attr_changed() cache ops - rap=N Number of in-progress read_or_alloc_page() cache ops - ras=N Number of in-progress read_or_alloc_pages() cache ops - alp=N Number of in-progress allocate_page() cache ops - als=N Number of in-progress allocate_pages() cache ops - wrp=N Number of in-progress write_page() cache ops - ucp=N Number of in-progress uncache_page() cache ops - dsp=N Number of in-progress dissociate_pages() cache ops - CacheEv nsp=N Number of object lookups/creations rejected due to lack of space - stl=N Number of stale objects deleted - rtr=N Number of objects retired when relinquished - cul=N Number of objects culled - - - (*) /proc/fs/fscache/histogram - - cat /proc/fs/fscache/histogram - JIFS SECS OBJ INST OP RUNS OBJ RUNS RETRV DLY RETRIEVLS - ===== ===== ========= ========= ========= ========= ========= - - This shows the breakdown of the number of times each amount of time - between 0 jiffies and HZ-1 jiffies a variety of tasks took to run. The - columns are as follows: - - COLUMN TIME MEASUREMENT - ======= ======================================================= - OBJ INST Length of time to instantiate an object - OP RUNS Length of time a call to process an operation took - OBJ RUNS Length of time a call to process an object event took - RETRV DLY Time between an requesting a read and lookup completing - RETRIEVLS Time between beginning and end of a retrieval - - Each row shows the number of events that took a particular range of times. - Each step is 1 jiffy in size. The JIFS column indicates the particular - jiffy range covered, and the SECS field the equivalent number of seconds. - - -=========== -OBJECT LIST -=========== - -If CONFIG_FSCACHE_OBJECT_LIST is enabled, the FS-Cache facility will maintain a -list of all the objects currently allocated and allow them to be viewed -through: - - /proc/fs/fscache/objects - -This will look something like: - - [root@andromeda ~]# head /proc/fs/fscache/objects - OBJECT PARENT STAT CHLDN OPS OOP IPR EX READS EM EV F S | NETFS_COOKIE_DEF TY FL NETFS_DATA OBJECT_KEY, AUX_DATA - ======== ======== ==== ===== === === === == ===== == == = = | ================ == == ================ ================ - 17e4b 2 ACTV 0 0 0 0 0 0 7b 4 0 0 | NFS.fh DT 0 ffff88001dd82820 010006017edcf8bbc93b43298fdfbe71e50b57b13a172c0117f38472, e567634700000000000000000000000063f2404a000000000000000000000000c9030000000000000000000063f2404a - 1693a 2 ACTV 0 0 0 0 0 0 7b 4 0 0 | NFS.fh DT 0 ffff88002db23380 010006017edcf8bbc93b43298fdfbe71e50b57b1e0162c01a2df0ea6, 420ebc4a000000000000000000000000420ebc4a0000000000000000000000000e1801000000000000000000420ebc4a - -where the first set of columns before the '|' describe the object: - - COLUMN DESCRIPTION - ======= =============================================================== - OBJECT Object debugging ID (appears as OBJ%x in some debug messages) - PARENT Debugging ID of parent object - STAT Object state - CHLDN Number of child objects of this object - OPS Number of outstanding operations on this object - OOP Number of outstanding child object management operations - IPR - EX Number of outstanding exclusive operations - READS Number of outstanding read operations - EM Object's event mask - EV Events raised on this object - F Object flags - S Object work item busy state mask (1:pending 2:running) - -and the second set of columns describe the object's cookie, if present: - - COLUMN DESCRIPTION - =============== ======================================================= - NETFS_COOKIE_DEF Name of netfs cookie definition - TY Cookie type (IX - index, DT - data, hex - special) - FL Cookie flags - NETFS_DATA Netfs private data stored in the cookie - OBJECT_KEY Object key } 1 column, with separating comma - AUX_DATA Object aux data } presence may be configured - -The data shown may be filtered by attaching the a key to an appropriate keyring -before viewing the file. Something like: - - keyctl add user fscache:objlist <restrictions> @s - -where <restrictions> are a selection of the following letters: - - K Show hexdump of object key (don't show if not given) - A Show hexdump of object aux data (don't show if not given) - -and the following paired letters: - - C Show objects that have a cookie - c Show objects that don't have a cookie - B Show objects that are busy - b Show objects that aren't busy - W Show objects that have pending writes - w Show objects that don't have pending writes - R Show objects that have outstanding reads - r Show objects that don't have outstanding reads - S Show objects that have work queued - s Show objects that don't have work queued - -If neither side of a letter pair is given, then both are implied. For example: - - keyctl add user fscache:objlist KB @s - -shows objects that are busy, and lists their object keys, but does not dump -their auxiliary data. It also implies "CcWwRrSs", but as 'B' is given, 'b' is -not implied. - -By default all objects and all fields will be shown. - - -========= -DEBUGGING -========= - -If CONFIG_FSCACHE_DEBUG is enabled, the FS-Cache facility can have runtime -debugging enabled by adjusting the value in: - - /sys/module/fscache/parameters/debug - -This is a bitmask of debugging streams to enable: - - BIT VALUE STREAM POINT - ======= ======= =============================== ======================= - 0 1 Cache management Function entry trace - 1 2 Function exit trace - 2 4 General - 3 8 Cookie management Function entry trace - 4 16 Function exit trace - 5 32 General - 6 64 Page handling Function entry trace - 7 128 Function exit trace - 8 256 General - 9 512 Operation management Function entry trace - 10 1024 Function exit trace - 11 2048 General - -The appropriate set of values should be OR'd together and the result written to -the control file. For example: - - echo $((1|8|64)) >/sys/module/fscache/parameters/debug - -will turn on all function entry debugging.
diff --git a/Documentation/filesystems/caching/index.rst b/Documentation/filesystems/caching/index.rst new file mode 100644 index 0000000..033da7a --- /dev/null +++ b/Documentation/filesystems/caching/index.rst
@@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Filesystem Caching +================== + +.. toctree:: + :maxdepth: 2 + + fscache + object + backend-api + cachefiles + netfs-api + operations
diff --git a/Documentation/filesystems/caching/netfs-api.rst b/Documentation/filesystems/caching/netfs-api.rst new file mode 100644 index 0000000..d9f14b8 --- /dev/null +++ b/Documentation/filesystems/caching/netfs-api.rst
@@ -0,0 +1,896 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============================== +FS-Cache Network Filesystem API +=============================== + +There's an API by which a network filesystem can make use of the FS-Cache +facilities. This is based around a number of principles: + + (1) Caches can store a number of different object types. There are two main + object types: indices and files. The first is a special type used by + FS-Cache to make finding objects faster and to make retiring of groups of + objects easier. + + (2) Every index, file or other object is represented by a cookie. This cookie + may or may not have anything associated with it, but the netfs doesn't + need to care. + + (3) Barring the top-level index (one entry per cached netfs), the index + hierarchy for each netfs is structured according the whim of the netfs. + +This API is declared in <linux/fscache.h>. + +.. This document contains the following sections: + + (1) Network filesystem definition + (2) Index definition + (3) Object definition + (4) Network filesystem (un)registration + (5) Cache tag lookup + (6) Index registration + (7) Data file registration + (8) Miscellaneous object registration + (9) Setting the data file size + (10) Page alloc/read/write + (11) Page uncaching + (12) Index and data file consistency + (13) Cookie enablement + (14) Miscellaneous cookie operations + (15) Cookie unregistration + (16) Index invalidation + (17) Data file invalidation + (18) FS-Cache specific page flags. + + +Network Filesystem Definition +============================= + +FS-Cache needs a description of the network filesystem. This is specified +using a record of the following structure:: + + struct fscache_netfs { + uint32_t version; + const char *name; + struct fscache_cookie *primary_index; + ... + }; + +This first two fields should be filled in before registration, and the third +will be filled in by the registration function; any other fields should just be +ignored and are for internal use only. + +The fields are: + + (1) The name of the netfs (used as the key in the toplevel index). + + (2) The version of the netfs (if the name matches but the version doesn't, the + entire in-cache hierarchy for this netfs will be scrapped and begun + afresh). + + (3) The cookie representing the primary index will be allocated according to + another parameter passed into the registration function. + +For example, kAFS (linux/fs/afs/) uses the following definitions to describe +itself:: + + struct fscache_netfs afs_cache_netfs = { + .version = 0, + .name = "afs", + }; + + +Index Definition +================ + +Indices are used for two purposes: + + (1) To aid the finding of a file based on a series of keys (such as AFS's + "cell", "volume ID", "vnode ID"). + + (2) To make it easier to discard a subset of all the files cached based around + a particular key - for instance to mirror the removal of an AFS volume. + +However, since it's unlikely that any two netfs's are going to want to define +their index hierarchies in quite the same way, FS-Cache tries to impose as few +restraints as possible on how an index is structured and where it is placed in +the tree. The netfs can even mix indices and data files at the same level, but +it's not recommended. + +Each index entry consists of a key of indeterminate length plus some auxiliary +data, also of indeterminate length. + +There are some limits on indices: + + (1) Any index containing non-index objects should be restricted to a single + cache. Any such objects created within an index will be created in the + first cache only. The cache in which an index is created can be + controlled by cache tags (see below). + + (2) The entry data must be atomically journallable, so it is limited to about + 400 bytes at present. At least 400 bytes will be available. + + (3) The depth of the index tree should be judged with care as the search + function is recursive. Too many layers will run the kernel out of stack. + + +Object Definition +================= + +To define an object, a structure of the following type should be filled out:: + + struct fscache_cookie_def + { + uint8_t name[16]; + uint8_t type; + + struct fscache_cache_tag *(*select_cache)( + const void *parent_netfs_data, + const void *cookie_netfs_data); + + enum fscache_checkaux (*check_aux)(void *cookie_netfs_data, + const void *data, + uint16_t datalen, + loff_t object_size); + + void (*get_context)(void *cookie_netfs_data, void *context); + + void (*put_context)(void *cookie_netfs_data, void *context); + + void (*mark_pages_cached)(void *cookie_netfs_data, + struct address_space *mapping, + struct pagevec *cached_pvec); + }; + +This has the following fields: + + (1) The type of the object [mandatory]. + + This is one of the following values: + + FSCACHE_COOKIE_TYPE_INDEX + This defines an index, which is a special FS-Cache type. + + FSCACHE_COOKIE_TYPE_DATAFILE + This defines an ordinary data file. + + Any other value between 2 and 255 + This defines an extraordinary object such as an XATTR. + + (2) The name of the object type (NUL terminated unless all 16 chars are used) + [optional]. + + (3) A function to select the cache in which to store an index [optional]. + + This function is invoked when an index needs to be instantiated in a cache + during the instantiation of a non-index object. Only the immediate index + parent for the non-index object will be queried. Any indices above that + in the hierarchy may be stored in multiple caches. This function does not + need to be supplied for any non-index object or any index that will only + have index children. + + If this function is not supplied or if it returns NULL then the first + cache in the parent's list will be chosen, or failing that, the first + cache in the master list. + + (4) A function to check the auxiliary data [optional]. + + This function will be called to check that a match found in the cache for + this object is valid. For instance with AFS it could check the auxiliary + data against the data version number returned by the server to determine + whether the index entry in a cache is still valid. + + If this function is absent, it will be assumed that matching objects in a + cache are always valid. + + The function is also passed the cache's idea of the object size and may + use this to manage coherency also. + + If present, the function should return one of the following values: + + FSCACHE_CHECKAUX_OKAY + - the entry is okay as is + + FSCACHE_CHECKAUX_NEEDS_UPDATE + - the entry requires update + + FSCACHE_CHECKAUX_OBSOLETE + - the entry should be deleted + + This function can also be used to extract data from the auxiliary data in + the cache and copy it into the netfs's structures. + + (5) A pair of functions to manage contexts for the completion callback + [optional]. + + The cache read/write functions are passed a context which is then passed + to the I/O completion callback function. To ensure this context remains + valid until after the I/O completion is called, two functions may be + provided: one to get an extra reference on the context, and one to drop a + reference to it. + + If the context is not used or is a type of object that won't go out of + scope, then these functions are not required. These functions are not + required for indices as indices may not contain data. These functions may + be called in interrupt context and so may not sleep. + + (6) A function to mark a page as retaining cache metadata [optional]. + + This is called by the cache to indicate that it is retaining in-memory + information for this page and that the netfs should uncache the page when + it has finished. This does not indicate whether there's data on the disk + or not. Note that several pages at once may be presented for marking. + + The PG_fscache bit is set on the pages before this function would be + called, so the function need not be provided if this is sufficient. + + This function is not required for indices as they're not permitted data. + + (7) A function to unmark all the pages retaining cache metadata [mandatory]. + + This is called by FS-Cache to indicate that a backing store is being + unbound from a cookie and that all the marks on the pages should be + cleared to prevent confusion. Note that the cache will have torn down all + its tracking information so that the pages don't need to be explicitly + uncached. + + This function is not required for indices as they're not permitted data. + + +Network Filesystem (Un)registration +=================================== + +The first step is to declare the network filesystem to the cache. This also +involves specifying the layout of the primary index (for AFS, this would be the +"cell" level). + +The registration function is:: + + int fscache_register_netfs(struct fscache_netfs *netfs); + +It just takes a pointer to the netfs definition. It returns 0 or an error as +appropriate. + +For kAFS, registration is done as follows:: + + ret = fscache_register_netfs(&afs_cache_netfs); + +The last step is, of course, unregistration:: + + void fscache_unregister_netfs(struct fscache_netfs *netfs); + + +Cache Tag Lookup +================ + +FS-Cache permits the use of more than one cache. To permit particular index +subtrees to be bound to particular caches, the second step is to look up cache +representation tags. This step is optional; it can be left entirely up to +FS-Cache as to which cache should be used. The problem with doing that is that +FS-Cache will always pick the first cache that was registered. + +To get the representation for a named tag:: + + struct fscache_cache_tag *fscache_lookup_cache_tag(const char *name); + +This takes a text string as the name and returns a representation of a tag. It +will never return an error. It may return a dummy tag, however, if it runs out +of memory; this will inhibit caching with this tag. + +Any representation so obtained must be released by passing it to this function:: + + void fscache_release_cache_tag(struct fscache_cache_tag *tag); + +The tag will be retrieved by FS-Cache when it calls the object definition +operation select_cache(). + + +Index Registration +================== + +The third step is to inform FS-Cache about part of an index hierarchy that can +be used to locate files. This is done by requesting a cookie for each index in +the path to the file:: + + struct fscache_cookie * + fscache_acquire_cookie(struct fscache_cookie *parent, + const struct fscache_object_def *def, + const void *index_key, + size_t index_key_len, + const void *aux_data, + size_t aux_data_len, + void *netfs_data, + loff_t object_size, + bool enable); + +This function creates an index entry in the index represented by parent, +filling in the index entry by calling the operations pointed to by def. + +A unique key that represents the object within the parent must be pointed to by +index_key and is of length index_key_len. + +An optional blob of auxiliary data that is to be stored within the cache can be +pointed to with aux_data and should be of length aux_data_len. This would +typically be used for storing coherency data. + +The netfs may pass an arbitrary value in netfs_data and this will be presented +to it in the event of any calling back. This may also be used in tracing or +logging of messages. + +The cache tracks the size of the data attached to an object and this set to be +object_size. For indices, this should be 0. This value will be passed to the +->check_aux() callback. + +Note that this function never returns an error - all errors are handled +internally. It may, however, return NULL to indicate no cookie. It is quite +acceptable to pass this token back to this function as the parent to another +acquisition (or even to the relinquish cookie, read page and write page +functions - see below). + +Note also that no indices are actually created in a cache until a non-index +object needs to be created somewhere down the hierarchy. Furthermore, an index +may be created in several different caches independently at different times. +This is all handled transparently, and the netfs doesn't see any of it. + +A cookie will be created in the disabled state if enabled is false. A cookie +must be enabled to do anything with it. A disabled cookie can be enabled by +calling fscache_enable_cookie() (see below). + +For example, with AFS, a cell would be added to the primary index. This index +entry would have a dependent inode containing volume mappings within this cell:: + + cell->cache = + fscache_acquire_cookie(afs_cache_netfs.primary_index, + &afs_cell_cache_index_def, + cell->name, strlen(cell->name), + NULL, 0, + cell, 0, true); + +And then a particular volume could be added to that index by ID, creating +another index for vnodes (AFS inode equivalents):: + + volume->cache = + fscache_acquire_cookie(volume->cell->cache, + &afs_volume_cache_index_def, + &volume->vid, sizeof(volume->vid), + NULL, 0, + volume, 0, true); + + +Data File Registration +====================== + +The fourth step is to request a data file be created in the cache. This is +identical to index cookie acquisition. The only difference is that the type in +the object definition should be something other than index type:: + + vnode->cache = + fscache_acquire_cookie(volume->cache, + &afs_vnode_cache_object_def, + &key, sizeof(key), + &aux, sizeof(aux), + vnode, vnode->status.size, true); + + +Miscellaneous Object Registration +================================= + +An optional step is to request an object of miscellaneous type be created in +the cache. This is almost identical to index cookie acquisition. The only +difference is that the type in the object definition should be something other +than index type. While the parent object could be an index, it's more likely +it would be some other type of object such as a data file:: + + xattr->cache = + fscache_acquire_cookie(vnode->cache, + &afs_xattr_cache_object_def, + &xattr->name, strlen(xattr->name), + NULL, 0, + xattr, strlen(xattr->val), true); + +Miscellaneous objects might be used to store extended attributes or directory +entries for example. + + +Setting the Data File Size +========================== + +The fifth step is to set the physical attributes of the file, such as its size. +This doesn't automatically reserve any space in the cache, but permits the +cache to adjust its metadata for data tracking appropriately:: + + int fscache_attr_changed(struct fscache_cookie *cookie); + +The cache will return -ENOBUFS if there is no backing cache or if there is no +space to allocate any extra metadata required in the cache. + +Note that attempts to read or write data pages in the cache over this size may +be rebuffed with -ENOBUFS. + +This operation schedules an attribute adjustment to happen asynchronously at +some point in the future, and as such, it may happen after the function returns +to the caller. The attribute adjustment excludes read and write operations. + + +Page alloc/read/write +===================== + +And the sixth step is to store and retrieve pages in the cache. There are +three functions that are used to do this. + +Note: + + (1) A page should not be re-read or re-allocated without uncaching it first. + + (2) A read or allocated page must be uncached when the netfs page is released + from the pagecache. + + (3) A page should only be written to the cache if previous read or allocated. + +This permits the cache to maintain its page tracking in proper order. + + +PAGE READ +--------- + +Firstly, the netfs should ask FS-Cache to examine the caches and read the +contents cached for a particular page of a particular file if present, or else +allocate space to store the contents if not:: + + typedef + void (*fscache_rw_complete_t)(struct page *page, + void *context, + int error); + + int fscache_read_or_alloc_page(struct fscache_cookie *cookie, + struct page *page, + fscache_rw_complete_t end_io_func, + void *context, + gfp_t gfp); + +The cookie argument must specify a cookie for an object that isn't an index, +the page specified will have the data loaded into it (and is also used to +specify the page number), and the gfp argument is used to control how any +memory allocations made are satisfied. + +If the cookie indicates the inode is not cached: + + (1) The function will return -ENOBUFS. + +Else if there's a copy of the page resident in the cache: + + (1) The mark_pages_cached() cookie operation will be called on that page. + + (2) The function will submit a request to read the data from the cache's + backing device directly into the page specified. + + (3) The function will return 0. + + (4) When the read is complete, end_io_func() will be invoked with: + + * The netfs data supplied when the cookie was created. + + * The page descriptor. + + * The context argument passed to the above function. This will be + maintained with the get_context/put_context functions mentioned above. + + * An argument that's 0 on success or negative for an error code. + + If an error occurs, it should be assumed that the page contains no usable + data. fscache_readpages_cancel() may need to be called. + + end_io_func() will be called in process context if the read is results in + an error, but it might be called in interrupt context if the read is + successful. + +Otherwise, if there's not a copy available in cache, but the cache may be able +to store the page: + + (1) The mark_pages_cached() cookie operation will be called on that page. + + (2) A block may be reserved in the cache and attached to the object at the + appropriate place. + + (3) The function will return -ENODATA. + +This function may also return -ENOMEM or -EINTR, in which case it won't have +read any data from the cache. + + +Page Allocate +------------- + +Alternatively, if there's not expected to be any data in the cache for a page +because the file has been extended, a block can simply be allocated instead:: + + int fscache_alloc_page(struct fscache_cookie *cookie, + struct page *page, + gfp_t gfp); + +This is similar to the fscache_read_or_alloc_page() function, except that it +never reads from the cache. It will return 0 if a block has been allocated, +rather than -ENODATA as the other would. One or the other must be performed +before writing to the cache. + +The mark_pages_cached() cookie operation will be called on the page if +successful. + + +Page Write +---------- + +Secondly, if the netfs changes the contents of the page (either due to an +initial download or if a user performs a write), then the page should be +written back to the cache:: + + int fscache_write_page(struct fscache_cookie *cookie, + struct page *page, + loff_t object_size, + gfp_t gfp); + +The cookie argument must specify a data file cookie, the page specified should +contain the data to be written (and is also used to specify the page number), +object_size is the revised size of the object and the gfp argument is used to +control how any memory allocations made are satisfied. + +The page must have first been read or allocated successfully and must not have +been uncached before writing is performed. + +If the cookie indicates the inode is not cached then: + + (1) The function will return -ENOBUFS. + +Else if space can be allocated in the cache to hold this page: + + (1) PG_fscache_write will be set on the page. + + (2) The function will submit a request to write the data to cache's backing + device directly from the page specified. + + (3) The function will return 0. + + (4) When the write is complete PG_fscache_write is cleared on the page and + anyone waiting for that bit will be woken up. + +Else if there's no space available in the cache, -ENOBUFS will be returned. It +is also possible for the PG_fscache_write bit to be cleared when no write took +place if unforeseen circumstances arose (such as a disk error). + +Writing takes place asynchronously. + + +Multiple Page Read +------------------ + +A facility is provided to read several pages at once, as requested by the +readpages() address space operation:: + + int fscache_read_or_alloc_pages(struct fscache_cookie *cookie, + struct address_space *mapping, + struct list_head *pages, + int *nr_pages, + fscache_rw_complete_t end_io_func, + void *context, + gfp_t gfp); + +This works in a similar way to fscache_read_or_alloc_page(), except: + + (1) Any page it can retrieve data for is removed from pages and nr_pages and + dispatched for reading to the disk. Reads of adjacent pages on disk may + be merged for greater efficiency. + + (2) The mark_pages_cached() cookie operation will be called on several pages + at once if they're being read or allocated. + + (3) If there was an general error, then that error will be returned. + + Else if some pages couldn't be allocated or read, then -ENOBUFS will be + returned. + + Else if some pages couldn't be read but were allocated, then -ENODATA will + be returned. + + Otherwise, if all pages had reads dispatched, then 0 will be returned, the + list will be empty and ``*nr_pages`` will be 0. + + (4) end_io_func will be called once for each page being read as the reads + complete. It will be called in process context if error != 0, but it may + be called in interrupt context if there is no error. + +Note that a return of -ENODATA, -ENOBUFS or any other error does not preclude +some of the pages being read and some being allocated. Those pages will have +been marked appropriately and will need uncaching. + + +Cancellation of Unread Pages +---------------------------- + +If one or more pages are passed to fscache_read_or_alloc_pages() but not then +read from the cache and also not read from the underlying filesystem then +those pages will need to have any marks and reservations removed. This can be +done by calling:: + + void fscache_readpages_cancel(struct fscache_cookie *cookie, + struct list_head *pages); + +prior to returning to the caller. The cookie argument should be as passed to +fscache_read_or_alloc_pages(). Every page in the pages list will be examined +and any that have PG_fscache set will be uncached. + + +Page Uncaching +============== + +To uncache a page, this function should be called:: + + void fscache_uncache_page(struct fscache_cookie *cookie, + struct page *page); + +This function permits the cache to release any in-memory representation it +might be holding for this netfs page. This function must be called once for +each page on which the read or write page functions above have been called to +make sure the cache's in-memory tracking information gets torn down. + +Note that pages can't be explicitly deleted from the a data file. The whole +data file must be retired (see the relinquish cookie function below). + +Furthermore, note that this does not cancel the asynchronous read or write +operation started by the read/alloc and write functions, so the page +invalidation functions must use:: + + bool fscache_check_page_write(struct fscache_cookie *cookie, + struct page *page); + +to see if a page is being written to the cache, and:: + + void fscache_wait_on_page_write(struct fscache_cookie *cookie, + struct page *page); + +to wait for it to finish if it is. + + +When releasepage() is being implemented, a special FS-Cache function exists to +manage the heuristics of coping with vmscan trying to eject pages, which may +conflict with the cache trying to write pages to the cache (which may itself +need to allocate memory):: + + bool fscache_maybe_release_page(struct fscache_cookie *cookie, + struct page *page, + gfp_t gfp); + +This takes the netfs cookie, and the page and gfp arguments as supplied to +releasepage(). It will return false if the page cannot be released yet for +some reason and if it returns true, the page has been uncached and can now be +released. + +To make a page available for release, this function may wait for an outstanding +storage request to complete, or it may attempt to cancel the storage request - +in which case the page will not be stored in the cache this time. + + +Bulk Image Page Uncache +----------------------- + +A convenience routine is provided to perform an uncache on all the pages +attached to an inode. This assumes that the pages on the inode correspond on a +1:1 basis with the pages in the cache:: + + void fscache_uncache_all_inode_pages(struct fscache_cookie *cookie, + struct inode *inode); + +This takes the netfs cookie that the pages were cached with and the inode that +the pages are attached to. This function will wait for pages to finish being +written to the cache and for the cache to finish with the page generally. No +error is returned. + + +Index and Data File consistency +=============================== + +To find out whether auxiliary data for an object is up to data within the +cache, the following function can be called:: + + int fscache_check_consistency(struct fscache_cookie *cookie, + const void *aux_data); + +This will call back to the netfs to check whether the auxiliary data associated +with a cookie is correct; if aux_data is non-NULL, it will update the auxiliary +data buffer first. It returns 0 if it is and -ESTALE if it isn't; it may also +return -ENOMEM and -ERESTARTSYS. + +To request an update of the index data for an index or other object, the +following function should be called:: + + void fscache_update_cookie(struct fscache_cookie *cookie, + const void *aux_data); + +This function will update the cookie's auxiliary data buffer from aux_data if +that is non-NULL and then schedule this to be stored on disk. The update +method in the parent index definition will be called to transfer the data. + +Note that partial updates may happen automatically at other times, such as when +data blocks are added to a data file object. + + +Cookie Enablement +================= + +Cookies exist in one of two states: enabled and disabled. If a cookie is +disabled, it ignores all attempts to acquire child cookies; check, update or +invalidate its state; allocate, read or write backing pages - though it is +still possible to uncache pages and relinquish the cookie. + +The initial enablement state is set by fscache_acquire_cookie(), but the cookie +can be enabled or disabled later. To disable a cookie, call:: + + void fscache_disable_cookie(struct fscache_cookie *cookie, + const void *aux_data, + bool invalidate); + +If the cookie is not already disabled, this locks the cookie against other +enable and disable ops, marks the cookie as being disabled, discards or +invalidates any backing objects and waits for cessation of activity on any +associated object before unlocking the cookie. + +All possible failures are handled internally. The caller should consider +calling fscache_uncache_all_inode_pages() afterwards to make sure all page +markings are cleared up. + +Cookies can be enabled or reenabled with:: + + void fscache_enable_cookie(struct fscache_cookie *cookie, + const void *aux_data, + loff_t object_size, + bool (*can_enable)(void *data), + void *data) + +If the cookie is not already enabled, this locks the cookie against other +enable and disable ops, invokes can_enable() and, if the cookie is not an index +cookie, will begin the procedure of acquiring backing objects. + +The optional can_enable() function is passed the data argument and returns a +ruling as to whether or not enablement should actually be permitted to begin. + +All possible failures are handled internally. The cookie will only be marked +as enabled if provisional backing objects are allocated. + +The object's data size is updated from object_size and is passed to the +->check_aux() function. + +In both cases, the cookie's auxiliary data buffer is updated from aux_data if +that is non-NULL inside the enablement lock before proceeding. + + +Miscellaneous Cookie operations +=============================== + +There are a number of operations that can be used to control cookies: + + * Cookie pinning:: + + int fscache_pin_cookie(struct fscache_cookie *cookie); + void fscache_unpin_cookie(struct fscache_cookie *cookie); + + These operations permit data cookies to be pinned into the cache and to + have the pinning removed. They are not permitted on index cookies. + + The pinning function will return 0 if successful, -ENOBUFS in the cookie + isn't backed by a cache, -EOPNOTSUPP if the cache doesn't support pinning, + -ENOSPC if there isn't enough space to honour the operation, -ENOMEM or + -EIO if there's any other problem. + + * Data space reservation:: + + int fscache_reserve_space(struct fscache_cookie *cookie, loff_t size); + + This permits a netfs to request cache space be reserved to store up to the + given amount of a file. It is permitted to ask for more than the current + size of the file to allow for future file expansion. + + If size is given as zero then the reservation will be cancelled. + + The function will return 0 if successful, -ENOBUFS in the cookie isn't + backed by a cache, -EOPNOTSUPP if the cache doesn't support reservations, + -ENOSPC if there isn't enough space to honour the operation, -ENOMEM or + -EIO if there's any other problem. + + Note that this doesn't pin an object in a cache; it can still be culled to + make space if it's not in use. + + +Cookie Unregistration +===================== + +To get rid of a cookie, this function should be called:: + + void fscache_relinquish_cookie(struct fscache_cookie *cookie, + const void *aux_data, + bool retire); + +If retire is non-zero, then the object will be marked for recycling, and all +copies of it will be removed from all active caches in which it is present. +Not only that but all child objects will also be retired. + +If retire is zero, then the object may be available again when next the +acquisition function is called. Retirement here will overrule the pinning on a +cookie. + +The cookie's auxiliary data will be updated from aux_data if that is non-NULL +so that the cache can lazily update it on disk. + +One very important note - relinquish must NOT be called for a cookie unless all +the cookies for "child" indices, objects and pages have been relinquished +first. + + +Index Invalidation +================== + +There is no direct way to invalidate an index subtree. To do this, the caller +should relinquish and retire the cookie they have, and then acquire a new one. + + +Data File Invalidation +====================== + +Sometimes it will be necessary to invalidate an object that contains data. +Typically this will be necessary when the server tells the netfs of a foreign +change - at which point the netfs has to throw away all the state it had for an +inode and reload from the server. + +To indicate that a cache object should be invalidated, the following function +can be called:: + + void fscache_invalidate(struct fscache_cookie *cookie); + +This can be called with spinlocks held as it defers the work to a thread pool. +All extant storage, retrieval and attribute change ops at this point are +cancelled and discarded. Some future operations will be rejected until the +cache has had a chance to insert a barrier in the operations queue. After +that, operations will be queued again behind the invalidation operation. + +The invalidation operation will perform an attribute change operation and an +auxiliary data update operation as it is very likely these will have changed. + +Using the following function, the netfs can wait for the invalidation operation +to have reached a point at which it can start submitting ordinary operations +once again:: + + void fscache_wait_on_invalidate(struct fscache_cookie *cookie); + + +FS-cache Specific Page Flag +=========================== + +FS-Cache makes use of a page flag, PG_private_2, for its own purpose. This is +given the alternative name PG_fscache. + +PG_fscache is used to indicate that the page is known by the cache, and that +the cache must be informed if the page is going to go away. It's an indication +to the netfs that the cache has an interest in this page, where an interest may +be a pointer to it, resources allocated or reserved for it, or I/O in progress +upon it. + +The netfs can use this information in methods such as releasepage() to +determine whether it needs to uncache a page or update it. + +Furthermore, if this bit is set, releasepage() and invalidatepage() operations +will be called on a page to get rid of it, even if PG_private is not set. This +allows caching to attempted on a page before read_cache_pages() to be called +after fscache_read_or_alloc_pages() as the former will try and release pages it +was given under certain circumstances. + +This bit does not overlap with such as PG_private. This means that FS-Cache +can be used with a filesystem that uses the block buffering code. + +There are a number of operations defined on this flag:: + + int PageFsCache(struct page *page); + void SetPageFsCache(struct page *page) + void ClearPageFsCache(struct page *page) + int TestSetPageFsCache(struct page *page) + int TestClearPageFsCache(struct page *page) + +These functions are bit test, bit set, bit clear, bit test and set and bit +test and clear operations on PG_fscache.
diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt deleted file mode 100644 index ba968e8..0000000 --- a/Documentation/filesystems/caching/netfs-api.txt +++ /dev/null
@@ -1,910 +0,0 @@ - =============================== - FS-CACHE NETWORK FILESYSTEM API - =============================== - -There's an API by which a network filesystem can make use of the FS-Cache -facilities. This is based around a number of principles: - - (1) Caches can store a number of different object types. There are two main - object types: indices and files. The first is a special type used by - FS-Cache to make finding objects faster and to make retiring of groups of - objects easier. - - (2) Every index, file or other object is represented by a cookie. This cookie - may or may not have anything associated with it, but the netfs doesn't - need to care. - - (3) Barring the top-level index (one entry per cached netfs), the index - hierarchy for each netfs is structured according the whim of the netfs. - -This API is declared in <linux/fscache.h>. - -This document contains the following sections: - - (1) Network filesystem definition - (2) Index definition - (3) Object definition - (4) Network filesystem (un)registration - (5) Cache tag lookup - (6) Index registration - (7) Data file registration - (8) Miscellaneous object registration - (9) Setting the data file size - (10) Page alloc/read/write - (11) Page uncaching - (12) Index and data file consistency - (13) Cookie enablement - (14) Miscellaneous cookie operations - (15) Cookie unregistration - (16) Index invalidation - (17) Data file invalidation - (18) FS-Cache specific page flags. - - -============================= -NETWORK FILESYSTEM DEFINITION -============================= - -FS-Cache needs a description of the network filesystem. This is specified -using a record of the following structure: - - struct fscache_netfs { - uint32_t version; - const char *name; - struct fscache_cookie *primary_index; - ... - }; - -This first two fields should be filled in before registration, and the third -will be filled in by the registration function; any other fields should just be -ignored and are for internal use only. - -The fields are: - - (1) The name of the netfs (used as the key in the toplevel index). - - (2) The version of the netfs (if the name matches but the version doesn't, the - entire in-cache hierarchy for this netfs will be scrapped and begun - afresh). - - (3) The cookie representing the primary index will be allocated according to - another parameter passed into the registration function. - -For example, kAFS (linux/fs/afs/) uses the following definitions to describe -itself: - - struct fscache_netfs afs_cache_netfs = { - .version = 0, - .name = "afs", - }; - - -================ -INDEX DEFINITION -================ - -Indices are used for two purposes: - - (1) To aid the finding of a file based on a series of keys (such as AFS's - "cell", "volume ID", "vnode ID"). - - (2) To make it easier to discard a subset of all the files cached based around - a particular key - for instance to mirror the removal of an AFS volume. - -However, since it's unlikely that any two netfs's are going to want to define -their index hierarchies in quite the same way, FS-Cache tries to impose as few -restraints as possible on how an index is structured and where it is placed in -the tree. The netfs can even mix indices and data files at the same level, but -it's not recommended. - -Each index entry consists of a key of indeterminate length plus some auxiliary -data, also of indeterminate length. - -There are some limits on indices: - - (1) Any index containing non-index objects should be restricted to a single - cache. Any such objects created within an index will be created in the - first cache only. The cache in which an index is created can be - controlled by cache tags (see below). - - (2) The entry data must be atomically journallable, so it is limited to about - 400 bytes at present. At least 400 bytes will be available. - - (3) The depth of the index tree should be judged with care as the search - function is recursive. Too many layers will run the kernel out of stack. - - -================= -OBJECT DEFINITION -================= - -To define an object, a structure of the following type should be filled out: - - struct fscache_cookie_def - { - uint8_t name[16]; - uint8_t type; - - struct fscache_cache_tag *(*select_cache)( - const void *parent_netfs_data, - const void *cookie_netfs_data); - - enum fscache_checkaux (*check_aux)(void *cookie_netfs_data, - const void *data, - uint16_t datalen, - loff_t object_size); - - void (*get_context)(void *cookie_netfs_data, void *context); - - void (*put_context)(void *cookie_netfs_data, void *context); - - void (*mark_pages_cached)(void *cookie_netfs_data, - struct address_space *mapping, - struct pagevec *cached_pvec); - }; - -This has the following fields: - - (1) The type of the object [mandatory]. - - This is one of the following values: - - (*) FSCACHE_COOKIE_TYPE_INDEX - - This defines an index, which is a special FS-Cache type. - - (*) FSCACHE_COOKIE_TYPE_DATAFILE - - This defines an ordinary data file. - - (*) Any other value between 2 and 255 - - This defines an extraordinary object such as an XATTR. - - (2) The name of the object type (NUL terminated unless all 16 chars are used) - [optional]. - - (3) A function to select the cache in which to store an index [optional]. - - This function is invoked when an index needs to be instantiated in a cache - during the instantiation of a non-index object. Only the immediate index - parent for the non-index object will be queried. Any indices above that - in the hierarchy may be stored in multiple caches. This function does not - need to be supplied for any non-index object or any index that will only - have index children. - - If this function is not supplied or if it returns NULL then the first - cache in the parent's list will be chosen, or failing that, the first - cache in the master list. - - (4) A function to check the auxiliary data [optional]. - - This function will be called to check that a match found in the cache for - this object is valid. For instance with AFS it could check the auxiliary - data against the data version number returned by the server to determine - whether the index entry in a cache is still valid. - - If this function is absent, it will be assumed that matching objects in a - cache are always valid. - - The function is also passed the cache's idea of the object size and may - use this to manage coherency also. - - If present, the function should return one of the following values: - - (*) FSCACHE_CHECKAUX_OKAY - the entry is okay as is - (*) FSCACHE_CHECKAUX_NEEDS_UPDATE - the entry requires update - (*) FSCACHE_CHECKAUX_OBSOLETE - the entry should be deleted - - This function can also be used to extract data from the auxiliary data in - the cache and copy it into the netfs's structures. - - (5) A pair of functions to manage contexts for the completion callback - [optional]. - - The cache read/write functions are passed a context which is then passed - to the I/O completion callback function. To ensure this context remains - valid until after the I/O completion is called, two functions may be - provided: one to get an extra reference on the context, and one to drop a - reference to it. - - If the context is not used or is a type of object that won't go out of - scope, then these functions are not required. These functions are not - required for indices as indices may not contain data. These functions may - be called in interrupt context and so may not sleep. - - (6) A function to mark a page as retaining cache metadata [optional]. - - This is called by the cache to indicate that it is retaining in-memory - information for this page and that the netfs should uncache the page when - it has finished. This does not indicate whether there's data on the disk - or not. Note that several pages at once may be presented for marking. - - The PG_fscache bit is set on the pages before this function would be - called, so the function need not be provided if this is sufficient. - - This function is not required for indices as they're not permitted data. - - (7) A function to unmark all the pages retaining cache metadata [mandatory]. - - This is called by FS-Cache to indicate that a backing store is being - unbound from a cookie and that all the marks on the pages should be - cleared to prevent confusion. Note that the cache will have torn down all - its tracking information so that the pages don't need to be explicitly - uncached. - - This function is not required for indices as they're not permitted data. - - -=================================== -NETWORK FILESYSTEM (UN)REGISTRATION -=================================== - -The first step is to declare the network filesystem to the cache. This also -involves specifying the layout of the primary index (for AFS, this would be the -"cell" level). - -The registration function is: - - int fscache_register_netfs(struct fscache_netfs *netfs); - -It just takes a pointer to the netfs definition. It returns 0 or an error as -appropriate. - -For kAFS, registration is done as follows: - - ret = fscache_register_netfs(&afs_cache_netfs); - -The last step is, of course, unregistration: - - void fscache_unregister_netfs(struct fscache_netfs *netfs); - - -================ -CACHE TAG LOOKUP -================ - -FS-Cache permits the use of more than one cache. To permit particular index -subtrees to be bound to particular caches, the second step is to look up cache -representation tags. This step is optional; it can be left entirely up to -FS-Cache as to which cache should be used. The problem with doing that is that -FS-Cache will always pick the first cache that was registered. - -To get the representation for a named tag: - - struct fscache_cache_tag *fscache_lookup_cache_tag(const char *name); - -This takes a text string as the name and returns a representation of a tag. It -will never return an error. It may return a dummy tag, however, if it runs out -of memory; this will inhibit caching with this tag. - -Any representation so obtained must be released by passing it to this function: - - void fscache_release_cache_tag(struct fscache_cache_tag *tag); - -The tag will be retrieved by FS-Cache when it calls the object definition -operation select_cache(). - - -================== -INDEX REGISTRATION -================== - -The third step is to inform FS-Cache about part of an index hierarchy that can -be used to locate files. This is done by requesting a cookie for each index in -the path to the file: - - struct fscache_cookie * - fscache_acquire_cookie(struct fscache_cookie *parent, - const struct fscache_object_def *def, - const void *index_key, - size_t index_key_len, - const void *aux_data, - size_t aux_data_len, - void *netfs_data, - loff_t object_size, - bool enable); - -This function creates an index entry in the index represented by parent, -filling in the index entry by calling the operations pointed to by def. - -A unique key that represents the object within the parent must be pointed to by -index_key and is of length index_key_len. - -An optional blob of auxiliary data that is to be stored within the cache can be -pointed to with aux_data and should be of length aux_data_len. This would -typically be used for storing coherency data. - -The netfs may pass an arbitrary value in netfs_data and this will be presented -to it in the event of any calling back. This may also be used in tracing or -logging of messages. - -The cache tracks the size of the data attached to an object and this set to be -object_size. For indices, this should be 0. This value will be passed to the -->check_aux() callback. - -Note that this function never returns an error - all errors are handled -internally. It may, however, return NULL to indicate no cookie. It is quite -acceptable to pass this token back to this function as the parent to another -acquisition (or even to the relinquish cookie, read page and write page -functions - see below). - -Note also that no indices are actually created in a cache until a non-index -object needs to be created somewhere down the hierarchy. Furthermore, an index -may be created in several different caches independently at different times. -This is all handled transparently, and the netfs doesn't see any of it. - -A cookie will be created in the disabled state if enabled is false. A cookie -must be enabled to do anything with it. A disabled cookie can be enabled by -calling fscache_enable_cookie() (see below). - -For example, with AFS, a cell would be added to the primary index. This index -entry would have a dependent inode containing volume mappings within this cell: - - cell->cache = - fscache_acquire_cookie(afs_cache_netfs.primary_index, - &afs_cell_cache_index_def, - cell->name, strlen(cell->name), - NULL, 0, - cell, 0, true); - -And then a particular volume could be added to that index by ID, creating -another index for vnodes (AFS inode equivalents): - - volume->cache = - fscache_acquire_cookie(volume->cell->cache, - &afs_volume_cache_index_def, - &volume->vid, sizeof(volume->vid), - NULL, 0, - volume, 0, true); - - -====================== -DATA FILE REGISTRATION -====================== - -The fourth step is to request a data file be created in the cache. This is -identical to index cookie acquisition. The only difference is that the type in -the object definition should be something other than index type. - - vnode->cache = - fscache_acquire_cookie(volume->cache, - &afs_vnode_cache_object_def, - &key, sizeof(key), - &aux, sizeof(aux), - vnode, vnode->status.size, true); - - -================================= -MISCELLANEOUS OBJECT REGISTRATION -================================= - -An optional step is to request an object of miscellaneous type be created in -the cache. This is almost identical to index cookie acquisition. The only -difference is that the type in the object definition should be something other -than index type. While the parent object could be an index, it's more likely -it would be some other type of object such as a data file. - - xattr->cache = - fscache_acquire_cookie(vnode->cache, - &afs_xattr_cache_object_def, - &xattr->name, strlen(xattr->name), - NULL, 0, - xattr, strlen(xattr->val), true); - -Miscellaneous objects might be used to store extended attributes or directory -entries for example. - - -========================== -SETTING THE DATA FILE SIZE -========================== - -The fifth step is to set the physical attributes of the file, such as its size. -This doesn't automatically reserve any space in the cache, but permits the -cache to adjust its metadata for data tracking appropriately: - - int fscache_attr_changed(struct fscache_cookie *cookie); - -The cache will return -ENOBUFS if there is no backing cache or if there is no -space to allocate any extra metadata required in the cache. - -Note that attempts to read or write data pages in the cache over this size may -be rebuffed with -ENOBUFS. - -This operation schedules an attribute adjustment to happen asynchronously at -some point in the future, and as such, it may happen after the function returns -to the caller. The attribute adjustment excludes read and write operations. - - -===================== -PAGE ALLOC/READ/WRITE -===================== - -And the sixth step is to store and retrieve pages in the cache. There are -three functions that are used to do this. - -Note: - - (1) A page should not be re-read or re-allocated without uncaching it first. - - (2) A read or allocated page must be uncached when the netfs page is released - from the pagecache. - - (3) A page should only be written to the cache if previous read or allocated. - -This permits the cache to maintain its page tracking in proper order. - - -PAGE READ ---------- - -Firstly, the netfs should ask FS-Cache to examine the caches and read the -contents cached for a particular page of a particular file if present, or else -allocate space to store the contents if not: - - typedef - void (*fscache_rw_complete_t)(struct page *page, - void *context, - int error); - - int fscache_read_or_alloc_page(struct fscache_cookie *cookie, - struct page *page, - fscache_rw_complete_t end_io_func, - void *context, - gfp_t gfp); - -The cookie argument must specify a cookie for an object that isn't an index, -the page specified will have the data loaded into it (and is also used to -specify the page number), and the gfp argument is used to control how any -memory allocations made are satisfied. - -If the cookie indicates the inode is not cached: - - (1) The function will return -ENOBUFS. - -Else if there's a copy of the page resident in the cache: - - (1) The mark_pages_cached() cookie operation will be called on that page. - - (2) The function will submit a request to read the data from the cache's - backing device directly into the page specified. - - (3) The function will return 0. - - (4) When the read is complete, end_io_func() will be invoked with: - - (*) The netfs data supplied when the cookie was created. - - (*) The page descriptor. - - (*) The context argument passed to the above function. This will be - maintained with the get_context/put_context functions mentioned above. - - (*) An argument that's 0 on success or negative for an error code. - - If an error occurs, it should be assumed that the page contains no usable - data. fscache_readpages_cancel() may need to be called. - - end_io_func() will be called in process context if the read is results in - an error, but it might be called in interrupt context if the read is - successful. - -Otherwise, if there's not a copy available in cache, but the cache may be able -to store the page: - - (1) The mark_pages_cached() cookie operation will be called on that page. - - (2) A block may be reserved in the cache and attached to the object at the - appropriate place. - - (3) The function will return -ENODATA. - -This function may also return -ENOMEM or -EINTR, in which case it won't have -read any data from the cache. - - -PAGE ALLOCATE -------------- - -Alternatively, if there's not expected to be any data in the cache for a page -because the file has been extended, a block can simply be allocated instead: - - int fscache_alloc_page(struct fscache_cookie *cookie, - struct page *page, - gfp_t gfp); - -This is similar to the fscache_read_or_alloc_page() function, except that it -never reads from the cache. It will return 0 if a block has been allocated, -rather than -ENODATA as the other would. One or the other must be performed -before writing to the cache. - -The mark_pages_cached() cookie operation will be called on the page if -successful. - - -PAGE WRITE ----------- - -Secondly, if the netfs changes the contents of the page (either due to an -initial download or if a user performs a write), then the page should be -written back to the cache: - - int fscache_write_page(struct fscache_cookie *cookie, - struct page *page, - loff_t object_size, - gfp_t gfp); - -The cookie argument must specify a data file cookie, the page specified should -contain the data to be written (and is also used to specify the page number), -object_size is the revised size of the object and the gfp argument is used to -control how any memory allocations made are satisfied. - -The page must have first been read or allocated successfully and must not have -been uncached before writing is performed. - -If the cookie indicates the inode is not cached then: - - (1) The function will return -ENOBUFS. - -Else if space can be allocated in the cache to hold this page: - - (1) PG_fscache_write will be set on the page. - - (2) The function will submit a request to write the data to cache's backing - device directly from the page specified. - - (3) The function will return 0. - - (4) When the write is complete PG_fscache_write is cleared on the page and - anyone waiting for that bit will be woken up. - -Else if there's no space available in the cache, -ENOBUFS will be returned. It -is also possible for the PG_fscache_write bit to be cleared when no write took -place if unforeseen circumstances arose (such as a disk error). - -Writing takes place asynchronously. - - -MULTIPLE PAGE READ ------------------- - -A facility is provided to read several pages at once, as requested by the -readpages() address space operation: - - int fscache_read_or_alloc_pages(struct fscache_cookie *cookie, - struct address_space *mapping, - struct list_head *pages, - int *nr_pages, - fscache_rw_complete_t end_io_func, - void *context, - gfp_t gfp); - -This works in a similar way to fscache_read_or_alloc_page(), except: - - (1) Any page it can retrieve data for is removed from pages and nr_pages and - dispatched for reading to the disk. Reads of adjacent pages on disk may - be merged for greater efficiency. - - (2) The mark_pages_cached() cookie operation will be called on several pages - at once if they're being read or allocated. - - (3) If there was an general error, then that error will be returned. - - Else if some pages couldn't be allocated or read, then -ENOBUFS will be - returned. - - Else if some pages couldn't be read but were allocated, then -ENODATA will - be returned. - - Otherwise, if all pages had reads dispatched, then 0 will be returned, the - list will be empty and *nr_pages will be 0. - - (4) end_io_func will be called once for each page being read as the reads - complete. It will be called in process context if error != 0, but it may - be called in interrupt context if there is no error. - -Note that a return of -ENODATA, -ENOBUFS or any other error does not preclude -some of the pages being read and some being allocated. Those pages will have -been marked appropriately and will need uncaching. - - -CANCELLATION OF UNREAD PAGES ----------------------------- - -If one or more pages are passed to fscache_read_or_alloc_pages() but not then -read from the cache and also not read from the underlying filesystem then -those pages will need to have any marks and reservations removed. This can be -done by calling: - - void fscache_readpages_cancel(struct fscache_cookie *cookie, - struct list_head *pages); - -prior to returning to the caller. The cookie argument should be as passed to -fscache_read_or_alloc_pages(). Every page in the pages list will be examined -and any that have PG_fscache set will be uncached. - - -============== -PAGE UNCACHING -============== - -To uncache a page, this function should be called: - - void fscache_uncache_page(struct fscache_cookie *cookie, - struct page *page); - -This function permits the cache to release any in-memory representation it -might be holding for this netfs page. This function must be called once for -each page on which the read or write page functions above have been called to -make sure the cache's in-memory tracking information gets torn down. - -Note that pages can't be explicitly deleted from the a data file. The whole -data file must be retired (see the relinquish cookie function below). - -Furthermore, note that this does not cancel the asynchronous read or write -operation started by the read/alloc and write functions, so the page -invalidation functions must use: - - bool fscache_check_page_write(struct fscache_cookie *cookie, - struct page *page); - -to see if a page is being written to the cache, and: - - void fscache_wait_on_page_write(struct fscache_cookie *cookie, - struct page *page); - -to wait for it to finish if it is. - - -When releasepage() is being implemented, a special FS-Cache function exists to -manage the heuristics of coping with vmscan trying to eject pages, which may -conflict with the cache trying to write pages to the cache (which may itself -need to allocate memory): - - bool fscache_maybe_release_page(struct fscache_cookie *cookie, - struct page *page, - gfp_t gfp); - -This takes the netfs cookie, and the page and gfp arguments as supplied to -releasepage(). It will return false if the page cannot be released yet for -some reason and if it returns true, the page has been uncached and can now be -released. - -To make a page available for release, this function may wait for an outstanding -storage request to complete, or it may attempt to cancel the storage request - -in which case the page will not be stored in the cache this time. - - -BULK INODE PAGE UNCACHE ------------------------ - -A convenience routine is provided to perform an uncache on all the pages -attached to an inode. This assumes that the pages on the inode correspond on a -1:1 basis with the pages in the cache. - - void fscache_uncache_all_inode_pages(struct fscache_cookie *cookie, - struct inode *inode); - -This takes the netfs cookie that the pages were cached with and the inode that -the pages are attached to. This function will wait for pages to finish being -written to the cache and for the cache to finish with the page generally. No -error is returned. - - -=============================== -INDEX AND DATA FILE CONSISTENCY -=============================== - -To find out whether auxiliary data for an object is up to data within the -cache, the following function can be called: - - int fscache_check_consistency(struct fscache_cookie *cookie, - const void *aux_data); - -This will call back to the netfs to check whether the auxiliary data associated -with a cookie is correct; if aux_data is non-NULL, it will update the auxiliary -data buffer first. It returns 0 if it is and -ESTALE if it isn't; it may also -return -ENOMEM and -ERESTARTSYS. - -To request an update of the index data for an index or other object, the -following function should be called: - - void fscache_update_cookie(struct fscache_cookie *cookie, - const void *aux_data); - -This function will update the cookie's auxiliary data buffer from aux_data if -that is non-NULL and then schedule this to be stored on disk. The update -method in the parent index definition will be called to transfer the data. - -Note that partial updates may happen automatically at other times, such as when -data blocks are added to a data file object. - - -================= -COOKIE ENABLEMENT -================= - -Cookies exist in one of two states: enabled and disabled. If a cookie is -disabled, it ignores all attempts to acquire child cookies; check, update or -invalidate its state; allocate, read or write backing pages - though it is -still possible to uncache pages and relinquish the cookie. - -The initial enablement state is set by fscache_acquire_cookie(), but the cookie -can be enabled or disabled later. To disable a cookie, call: - - void fscache_disable_cookie(struct fscache_cookie *cookie, - const void *aux_data, - bool invalidate); - -If the cookie is not already disabled, this locks the cookie against other -enable and disable ops, marks the cookie as being disabled, discards or -invalidates any backing objects and waits for cessation of activity on any -associated object before unlocking the cookie. - -All possible failures are handled internally. The caller should consider -calling fscache_uncache_all_inode_pages() afterwards to make sure all page -markings are cleared up. - -Cookies can be enabled or reenabled with: - - void fscache_enable_cookie(struct fscache_cookie *cookie, - const void *aux_data, - loff_t object_size, - bool (*can_enable)(void *data), - void *data) - -If the cookie is not already enabled, this locks the cookie against other -enable and disable ops, invokes can_enable() and, if the cookie is not an index -cookie, will begin the procedure of acquiring backing objects. - -The optional can_enable() function is passed the data argument and returns a -ruling as to whether or not enablement should actually be permitted to begin. - -All possible failures are handled internally. The cookie will only be marked -as enabled if provisional backing objects are allocated. - -The object's data size is updated from object_size and is passed to the -->check_aux() function. - -In both cases, the cookie's auxiliary data buffer is updated from aux_data if -that is non-NULL inside the enablement lock before proceeding. - - -=============================== -MISCELLANEOUS COOKIE OPERATIONS -=============================== - -There are a number of operations that can be used to control cookies: - - (*) Cookie pinning: - - int fscache_pin_cookie(struct fscache_cookie *cookie); - void fscache_unpin_cookie(struct fscache_cookie *cookie); - - These operations permit data cookies to be pinned into the cache and to - have the pinning removed. They are not permitted on index cookies. - - The pinning function will return 0 if successful, -ENOBUFS in the cookie - isn't backed by a cache, -EOPNOTSUPP if the cache doesn't support pinning, - -ENOSPC if there isn't enough space to honour the operation, -ENOMEM or - -EIO if there's any other problem. - - (*) Data space reservation: - - int fscache_reserve_space(struct fscache_cookie *cookie, loff_t size); - - This permits a netfs to request cache space be reserved to store up to the - given amount of a file. It is permitted to ask for more than the current - size of the file to allow for future file expansion. - - If size is given as zero then the reservation will be cancelled. - - The function will return 0 if successful, -ENOBUFS in the cookie isn't - backed by a cache, -EOPNOTSUPP if the cache doesn't support reservations, - -ENOSPC if there isn't enough space to honour the operation, -ENOMEM or - -EIO if there's any other problem. - - Note that this doesn't pin an object in a cache; it can still be culled to - make space if it's not in use. - - -===================== -COOKIE UNREGISTRATION -===================== - -To get rid of a cookie, this function should be called. - - void fscache_relinquish_cookie(struct fscache_cookie *cookie, - const void *aux_data, - bool retire); - -If retire is non-zero, then the object will be marked for recycling, and all -copies of it will be removed from all active caches in which it is present. -Not only that but all child objects will also be retired. - -If retire is zero, then the object may be available again when next the -acquisition function is called. Retirement here will overrule the pinning on a -cookie. - -The cookie's auxiliary data will be updated from aux_data if that is non-NULL -so that the cache can lazily update it on disk. - -One very important note - relinquish must NOT be called for a cookie unless all -the cookies for "child" indices, objects and pages have been relinquished -first. - - -================== -INDEX INVALIDATION -================== - -There is no direct way to invalidate an index subtree. To do this, the caller -should relinquish and retire the cookie they have, and then acquire a new one. - - -====================== -DATA FILE INVALIDATION -====================== - -Sometimes it will be necessary to invalidate an object that contains data. -Typically this will be necessary when the server tells the netfs of a foreign -change - at which point the netfs has to throw away all the state it had for an -inode and reload from the server. - -To indicate that a cache object should be invalidated, the following function -can be called: - - void fscache_invalidate(struct fscache_cookie *cookie); - -This can be called with spinlocks held as it defers the work to a thread pool. -All extant storage, retrieval and attribute change ops at this point are -cancelled and discarded. Some future operations will be rejected until the -cache has had a chance to insert a barrier in the operations queue. After -that, operations will be queued again behind the invalidation operation. - -The invalidation operation will perform an attribute change operation and an -auxiliary data update operation as it is very likely these will have changed. - -Using the following function, the netfs can wait for the invalidation operation -to have reached a point at which it can start submitting ordinary operations -once again: - - void fscache_wait_on_invalidate(struct fscache_cookie *cookie); - - -=========================== -FS-CACHE SPECIFIC PAGE FLAG -=========================== - -FS-Cache makes use of a page flag, PG_private_2, for its own purpose. This is -given the alternative name PG_fscache. - -PG_fscache is used to indicate that the page is known by the cache, and that -the cache must be informed if the page is going to go away. It's an indication -to the netfs that the cache has an interest in this page, where an interest may -be a pointer to it, resources allocated or reserved for it, or I/O in progress -upon it. - -The netfs can use this information in methods such as releasepage() to -determine whether it needs to uncache a page or update it. - -Furthermore, if this bit is set, releasepage() and invalidatepage() operations -will be called on a page to get rid of it, even if PG_private is not set. This -allows caching to attempted on a page before read_cache_pages() to be called -after fscache_read_or_alloc_pages() as the former will try and release pages it -was given under certain circumstances. - -This bit does not overlap with such as PG_private. This means that FS-Cache -can be used with a filesystem that uses the block buffering code. - -There are a number of operations defined on this flag: - - int PageFsCache(struct page *page); - void SetPageFsCache(struct page *page) - void ClearPageFsCache(struct page *page) - int TestSetPageFsCache(struct page *page) - int TestClearPageFsCache(struct page *page) - -These functions are bit test, bit set, bit clear, bit test and set and bit -test and clear operations on PG_fscache.
diff --git a/Documentation/filesystems/caching/object.rst b/Documentation/filesystems/caching/object.rst new file mode 100644 index 0000000..ce0e043 --- /dev/null +++ b/Documentation/filesystems/caching/object.rst
@@ -0,0 +1,313 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================================================== +In-Kernel Cache Object Representation and Management +==================================================== + +By: David Howells <dhowells@redhat.com> + +.. Contents: + + (*) Representation + + (*) Object management state machine. + + - Provision of cpu time. + - Locking simplification. + + (*) The set of states. + + (*) The set of events. + + +Representation +============== + +FS-Cache maintains an in-kernel representation of each object that a netfs is +currently interested in. Such objects are represented by the fscache_cookie +struct and are referred to as cookies. + +FS-Cache also maintains a separate in-kernel representation of the objects that +a cache backend is currently actively caching. Such objects are represented by +the fscache_object struct. The cache backends allocate these upon request, and +are expected to embed them in their own representations. These are referred to +as objects. + +There is a 1:N relationship between cookies and objects. A cookie may be +represented by multiple objects - an index may exist in more than one cache - +or even by no objects (it may not be cached). + +Furthermore, both cookies and objects are hierarchical. The two hierarchies +correspond, but the cookies tree is a superset of the union of the object trees +of multiple caches:: + + NETFS INDEX TREE : CACHE 1 : CACHE 2 + : : + : +-----------+ : + +----------->| IObject | : + +-----------+ | : +-----------+ : + | ICookie |-------+ : | : + +-----------+ | : | : +-----------+ + | +------------------------------>| IObject | + | : | : +-----------+ + | : V : | + | : +-----------+ : | + V +----------->| IObject | : | + +-----------+ | : +-----------+ : | + | ICookie |-------+ : | : V + +-----------+ | : | : +-----------+ + | +------------------------------>| IObject | + +-----+-----+ : | : +-----------+ + | | : | : | + V | : V : | + +-----------+ | : +-----------+ : | + | ICookie |------------------------->| IObject | : | + +-----------+ | : +-----------+ : | + | V : | : V + | +-----------+ : | : +-----------+ + | | ICookie |-------------------------------->| IObject | + | +-----------+ : | : +-----------+ + V | : V : | + +-----------+ | : +-----------+ : | + | DCookie |------------------------->| DObject | : | + +-----------+ | : +-----------+ : | + | : : | + +-------+-------+ : : | + | | : : | + V V : : V + +-----------+ +-----------+ : : +-----------+ + | DCookie | | DCookie |------------------------>| DObject | + +-----------+ +-----------+ : : +-----------+ + : : + +In the above illustration, ICookie and IObject represent indices and DCookie +and DObject represent data storage objects. Indices may have representation in +multiple caches, but currently, non-index objects may not. Objects of any type +may also be entirely unrepresented. + +As far as the netfs API goes, the netfs is only actually permitted to see +pointers to the cookies. The cookies themselves and any objects attached to +those cookies are hidden from it. + + +Object Management State Machine +=============================== + +Within FS-Cache, each active object is managed by its own individual state +machine. The state for an object is kept in the fscache_object struct, in +object->state. A cookie may point to a set of objects that are in different +states. + +Each state has an action associated with it that is invoked when the machine +wakes up in that state. There are four logical sets of states: + + (1) Preparation: states that wait for the parent objects to become ready. The + representations are hierarchical, and it is expected that an object must + be created or accessed with respect to its parent object. + + (2) Initialisation: states that perform lookups in the cache and validate + what's found and that create on disk any missing metadata. + + (3) Normal running: states that allow netfs operations on objects to proceed + and that update the state of objects. + + (4) Termination: states that detach objects from their netfs cookies, that + delete objects from disk, that handle disk and system errors and that free + up in-memory resources. + + +In most cases, transitioning between states is in response to signalled events. +When a state has finished processing, it will usually set the mask of events in +which it is interested (object->event_mask) and relinquish the worker thread. +Then when an event is raised (by calling fscache_raise_event()), if the event +is not masked, the object will be queued for processing (by calling +fscache_enqueue_object()). + + +Provision of CPU Time +--------------------- + +The work to be done by the various states was given CPU time by the threads of +the slow work facility. This was used in preference to the workqueue facility +because: + + (1) Threads may be completely occupied for very long periods of time by a + particular work item. These state actions may be doing sequences of + synchronous, journalled disk accesses (lookup, mkdir, create, setxattr, + getxattr, truncate, unlink, rmdir, rename). + + (2) Threads may do little actual work, but may rather spend a lot of time + sleeping on I/O. This means that single-threaded and 1-per-CPU-threaded + workqueues don't necessarily have the right numbers of threads. + + +Locking Simplification +---------------------- + +Because only one worker thread may be operating on any particular object's +state machine at once, this simplifies the locking, particularly with respect +to disconnecting the netfs's representation of a cache object (fscache_cookie) +from the cache backend's representation (fscache_object) - which may be +requested from either end. + + +The Set of States +================= + +The object state machine has a set of states that it can be in. There are +preparation states in which the object sets itself up and waits for its parent +object to transit to a state that allows access to its children: + + (1) State FSCACHE_OBJECT_INIT. + + Initialise the object and wait for the parent object to become active. In + the cache, it is expected that it will not be possible to look an object + up from the parent object, until that parent object itself has been looked + up. + +There are initialisation states in which the object sets itself up and accesses +disk for the object metadata: + + (2) State FSCACHE_OBJECT_LOOKING_UP. + + Look up the object on disk, using the parent as a starting point. + FS-Cache expects the cache backend to probe the cache to see whether this + object is represented there, and if it is, to see if it's valid (coherency + management). + + The cache should call fscache_object_lookup_negative() to indicate lookup + failure for whatever reason, and should call fscache_obtained_object() to + indicate success. + + At the completion of lookup, FS-Cache will let the netfs go ahead with + read operations, no matter whether the file is yet cached. If not yet + cached, read operations will be immediately rejected with ENODATA until + the first known page is uncached - as to that point there can be no data + to be read out of the cache for that file that isn't currently also held + in the pagecache. + + (3) State FSCACHE_OBJECT_CREATING. + + Create an object on disk, using the parent as a starting point. This + happens if the lookup failed to find the object, or if the object's + coherency data indicated what's on disk is out of date. In this state, + FS-Cache expects the cache to create + + The cache should call fscache_obtained_object() if creation completes + successfully, fscache_object_lookup_negative() otherwise. + + At the completion of creation, FS-Cache will start processing write + operations the netfs has queued for an object. If creation failed, the + write ops will be transparently discarded, and nothing recorded in the + cache. + +There are some normal running states in which the object spends its time +servicing netfs requests: + + (4) State FSCACHE_OBJECT_AVAILABLE. + + A transient state in which pending operations are started, child objects + are permitted to advance from FSCACHE_OBJECT_INIT state, and temporary + lookup data is freed. + + (5) State FSCACHE_OBJECT_ACTIVE. + + The normal running state. In this state, requests the netfs makes will be + passed on to the cache. + + (6) State FSCACHE_OBJECT_INVALIDATING. + + The object is undergoing invalidation. When the state comes here, it + discards all pending read, write and attribute change operations as it is + going to clear out the cache entirely and reinitialise it. It will then + continue to the FSCACHE_OBJECT_UPDATING state. + + (7) State FSCACHE_OBJECT_UPDATING. + + The state machine comes here to update the object in the cache from the + netfs's records. This involves updating the auxiliary data that is used + to maintain coherency. + +And there are terminal states in which an object cleans itself up, deallocates +memory and potentially deletes stuff from disk: + + (8) State FSCACHE_OBJECT_LC_DYING. + + The object comes here if it is dying because of a lookup or creation + error. This would be due to a disk error or system error of some sort. + Temporary data is cleaned up, and the parent is released. + + (9) State FSCACHE_OBJECT_DYING. + + The object comes here if it is dying due to an error, because its parent + cookie has been relinquished by the netfs or because the cache is being + withdrawn. + + Any child objects waiting on this one are given CPU time so that they too + can destroy themselves. This object waits for all its children to go away + before advancing to the next state. + +(10) State FSCACHE_OBJECT_ABORT_INIT. + + The object comes to this state if it was waiting on its parent in + FSCACHE_OBJECT_INIT, but its parent died. The object will destroy itself + so that the parent may proceed from the FSCACHE_OBJECT_DYING state. + +(11) State FSCACHE_OBJECT_RELEASING. +(12) State FSCACHE_OBJECT_RECYCLING. + + The object comes to one of these two states when dying once it is rid of + all its children, if it is dying because the netfs relinquished its + cookie. In the first state, the cached data is expected to persist, and + in the second it will be deleted. + +(13) State FSCACHE_OBJECT_WITHDRAWING. + + The object transits to this state if the cache decides it wants to + withdraw the object from service, perhaps to make space, but also due to + error or just because the whole cache is being withdrawn. + +(14) State FSCACHE_OBJECT_DEAD. + + The object transits to this state when the in-memory object record is + ready to be deleted. The object processor shouldn't ever see an object in + this state. + + +The Set of Events +----------------- + +There are a number of events that can be raised to an object state machine: + + FSCACHE_OBJECT_EV_UPDATE + The netfs requested that an object be updated. The state machine will ask + the cache backend to update the object, and the cache backend will ask the + netfs for details of the change through its cookie definition ops. + + FSCACHE_OBJECT_EV_CLEARED + This is signalled in two circumstances: + + (a) when an object's last child object is dropped and + + (b) when the last operation outstanding on an object is completed. + + This is used to proceed from the dying state. + + FSCACHE_OBJECT_EV_ERROR + This is signalled when an I/O error occurs during the processing of some + object. + + FSCACHE_OBJECT_EV_RELEASE, FSCACHE_OBJECT_EV_RETIRE + These are signalled when the netfs relinquishes a cookie it was using. + The event selected depends on whether the netfs asks for the backing + object to be retired (deleted) or retained. + + FSCACHE_OBJECT_EV_WITHDRAW + This is signalled when the cache backend wants to withdraw an object. + This means that the object will have to be detached from the netfs's + cookie. + +Because the withdrawing releasing/retiring events are all handled by the object +state machine, it doesn't matter if there's a collision with both ends trying +to sever the connection at the same time. The state machine can just pick +which one it wants to honour, and that effects the other.
diff --git a/Documentation/filesystems/caching/object.txt b/Documentation/filesystems/caching/object.txt deleted file mode 100644 index 100ff41..0000000 --- a/Documentation/filesystems/caching/object.txt +++ /dev/null
@@ -1,320 +0,0 @@ - ==================================================== - IN-KERNEL CACHE OBJECT REPRESENTATION AND MANAGEMENT - ==================================================== - -By: David Howells <dhowells@redhat.com> - -Contents: - - (*) Representation - - (*) Object management state machine. - - - Provision of cpu time. - - Locking simplification. - - (*) The set of states. - - (*) The set of events. - - -============== -REPRESENTATION -============== - -FS-Cache maintains an in-kernel representation of each object that a netfs is -currently interested in. Such objects are represented by the fscache_cookie -struct and are referred to as cookies. - -FS-Cache also maintains a separate in-kernel representation of the objects that -a cache backend is currently actively caching. Such objects are represented by -the fscache_object struct. The cache backends allocate these upon request, and -are expected to embed them in their own representations. These are referred to -as objects. - -There is a 1:N relationship between cookies and objects. A cookie may be -represented by multiple objects - an index may exist in more than one cache - -or even by no objects (it may not be cached). - -Furthermore, both cookies and objects are hierarchical. The two hierarchies -correspond, but the cookies tree is a superset of the union of the object trees -of multiple caches: - - NETFS INDEX TREE : CACHE 1 : CACHE 2 - : : - : +-----------+ : - +----------->| IObject | : - +-----------+ | : +-----------+ : - | ICookie |-------+ : | : - +-----------+ | : | : +-----------+ - | +------------------------------>| IObject | - | : | : +-----------+ - | : V : | - | : +-----------+ : | - V +----------->| IObject | : | - +-----------+ | : +-----------+ : | - | ICookie |-------+ : | : V - +-----------+ | : | : +-----------+ - | +------------------------------>| IObject | - +-----+-----+ : | : +-----------+ - | | : | : | - V | : V : | - +-----------+ | : +-----------+ : | - | ICookie |------------------------->| IObject | : | - +-----------+ | : +-----------+ : | - | V : | : V - | +-----------+ : | : +-----------+ - | | ICookie |-------------------------------->| IObject | - | +-----------+ : | : +-----------+ - V | : V : | - +-----------+ | : +-----------+ : | - | DCookie |------------------------->| DObject | : | - +-----------+ | : +-----------+ : | - | : : | - +-------+-------+ : : | - | | : : | - V V : : V - +-----------+ +-----------+ : : +-----------+ - | DCookie | | DCookie |------------------------>| DObject | - +-----------+ +-----------+ : : +-----------+ - : : - -In the above illustration, ICookie and IObject represent indices and DCookie -and DObject represent data storage objects. Indices may have representation in -multiple caches, but currently, non-index objects may not. Objects of any type -may also be entirely unrepresented. - -As far as the netfs API goes, the netfs is only actually permitted to see -pointers to the cookies. The cookies themselves and any objects attached to -those cookies are hidden from it. - - -=============================== -OBJECT MANAGEMENT STATE MACHINE -=============================== - -Within FS-Cache, each active object is managed by its own individual state -machine. The state for an object is kept in the fscache_object struct, in -object->state. A cookie may point to a set of objects that are in different -states. - -Each state has an action associated with it that is invoked when the machine -wakes up in that state. There are four logical sets of states: - - (1) Preparation: states that wait for the parent objects to become ready. The - representations are hierarchical, and it is expected that an object must - be created or accessed with respect to its parent object. - - (2) Initialisation: states that perform lookups in the cache and validate - what's found and that create on disk any missing metadata. - - (3) Normal running: states that allow netfs operations on objects to proceed - and that update the state of objects. - - (4) Termination: states that detach objects from their netfs cookies, that - delete objects from disk, that handle disk and system errors and that free - up in-memory resources. - - -In most cases, transitioning between states is in response to signalled events. -When a state has finished processing, it will usually set the mask of events in -which it is interested (object->event_mask) and relinquish the worker thread. -Then when an event is raised (by calling fscache_raise_event()), if the event -is not masked, the object will be queued for processing (by calling -fscache_enqueue_object()). - - -PROVISION OF CPU TIME ---------------------- - -The work to be done by the various states was given CPU time by the threads of -the slow work facility. This was used in preference to the workqueue facility -because: - - (1) Threads may be completely occupied for very long periods of time by a - particular work item. These state actions may be doing sequences of - synchronous, journalled disk accesses (lookup, mkdir, create, setxattr, - getxattr, truncate, unlink, rmdir, rename). - - (2) Threads may do little actual work, but may rather spend a lot of time - sleeping on I/O. This means that single-threaded and 1-per-CPU-threaded - workqueues don't necessarily have the right numbers of threads. - - -LOCKING SIMPLIFICATION ----------------------- - -Because only one worker thread may be operating on any particular object's -state machine at once, this simplifies the locking, particularly with respect -to disconnecting the netfs's representation of a cache object (fscache_cookie) -from the cache backend's representation (fscache_object) - which may be -requested from either end. - - -================= -THE SET OF STATES -================= - -The object state machine has a set of states that it can be in. There are -preparation states in which the object sets itself up and waits for its parent -object to transit to a state that allows access to its children: - - (1) State FSCACHE_OBJECT_INIT. - - Initialise the object and wait for the parent object to become active. In - the cache, it is expected that it will not be possible to look an object - up from the parent object, until that parent object itself has been looked - up. - -There are initialisation states in which the object sets itself up and accesses -disk for the object metadata: - - (2) State FSCACHE_OBJECT_LOOKING_UP. - - Look up the object on disk, using the parent as a starting point. - FS-Cache expects the cache backend to probe the cache to see whether this - object is represented there, and if it is, to see if it's valid (coherency - management). - - The cache should call fscache_object_lookup_negative() to indicate lookup - failure for whatever reason, and should call fscache_obtained_object() to - indicate success. - - At the completion of lookup, FS-Cache will let the netfs go ahead with - read operations, no matter whether the file is yet cached. If not yet - cached, read operations will be immediately rejected with ENODATA until - the first known page is uncached - as to that point there can be no data - to be read out of the cache for that file that isn't currently also held - in the pagecache. - - (3) State FSCACHE_OBJECT_CREATING. - - Create an object on disk, using the parent as a starting point. This - happens if the lookup failed to find the object, or if the object's - coherency data indicated what's on disk is out of date. In this state, - FS-Cache expects the cache to create - - The cache should call fscache_obtained_object() if creation completes - successfully, fscache_object_lookup_negative() otherwise. - - At the completion of creation, FS-Cache will start processing write - operations the netfs has queued for an object. If creation failed, the - write ops will be transparently discarded, and nothing recorded in the - cache. - -There are some normal running states in which the object spends its time -servicing netfs requests: - - (4) State FSCACHE_OBJECT_AVAILABLE. - - A transient state in which pending operations are started, child objects - are permitted to advance from FSCACHE_OBJECT_INIT state, and temporary - lookup data is freed. - - (5) State FSCACHE_OBJECT_ACTIVE. - - The normal running state. In this state, requests the netfs makes will be - passed on to the cache. - - (6) State FSCACHE_OBJECT_INVALIDATING. - - The object is undergoing invalidation. When the state comes here, it - discards all pending read, write and attribute change operations as it is - going to clear out the cache entirely and reinitialise it. It will then - continue to the FSCACHE_OBJECT_UPDATING state. - - (7) State FSCACHE_OBJECT_UPDATING. - - The state machine comes here to update the object in the cache from the - netfs's records. This involves updating the auxiliary data that is used - to maintain coherency. - -And there are terminal states in which an object cleans itself up, deallocates -memory and potentially deletes stuff from disk: - - (8) State FSCACHE_OBJECT_LC_DYING. - - The object comes here if it is dying because of a lookup or creation - error. This would be due to a disk error or system error of some sort. - Temporary data is cleaned up, and the parent is released. - - (9) State FSCACHE_OBJECT_DYING. - - The object comes here if it is dying due to an error, because its parent - cookie has been relinquished by the netfs or because the cache is being - withdrawn. - - Any child objects waiting on this one are given CPU time so that they too - can destroy themselves. This object waits for all its children to go away - before advancing to the next state. - -(10) State FSCACHE_OBJECT_ABORT_INIT. - - The object comes to this state if it was waiting on its parent in - FSCACHE_OBJECT_INIT, but its parent died. The object will destroy itself - so that the parent may proceed from the FSCACHE_OBJECT_DYING state. - -(11) State FSCACHE_OBJECT_RELEASING. -(12) State FSCACHE_OBJECT_RECYCLING. - - The object comes to one of these two states when dying once it is rid of - all its children, if it is dying because the netfs relinquished its - cookie. In the first state, the cached data is expected to persist, and - in the second it will be deleted. - -(13) State FSCACHE_OBJECT_WITHDRAWING. - - The object transits to this state if the cache decides it wants to - withdraw the object from service, perhaps to make space, but also due to - error or just because the whole cache is being withdrawn. - -(14) State FSCACHE_OBJECT_DEAD. - - The object transits to this state when the in-memory object record is - ready to be deleted. The object processor shouldn't ever see an object in - this state. - - -THE SET OF EVENTS ------------------ - -There are a number of events that can be raised to an object state machine: - - (*) FSCACHE_OBJECT_EV_UPDATE - - The netfs requested that an object be updated. The state machine will ask - the cache backend to update the object, and the cache backend will ask the - netfs for details of the change through its cookie definition ops. - - (*) FSCACHE_OBJECT_EV_CLEARED - - This is signalled in two circumstances: - - (a) when an object's last child object is dropped and - - (b) when the last operation outstanding on an object is completed. - - This is used to proceed from the dying state. - - (*) FSCACHE_OBJECT_EV_ERROR - - This is signalled when an I/O error occurs during the processing of some - object. - - (*) FSCACHE_OBJECT_EV_RELEASE - (*) FSCACHE_OBJECT_EV_RETIRE - - These are signalled when the netfs relinquishes a cookie it was using. - The event selected depends on whether the netfs asks for the backing - object to be retired (deleted) or retained. - - (*) FSCACHE_OBJECT_EV_WITHDRAW - - This is signalled when the cache backend wants to withdraw an object. - This means that the object will have to be detached from the netfs's - cookie. - -Because the withdrawing releasing/retiring events are all handled by the object -state machine, it doesn't matter if there's a collision with both ends trying -to sever the connection at the same time. The state machine can just pick -which one it wants to honour, and that effects the other.
diff --git a/Documentation/filesystems/caching/operations.rst b/Documentation/filesystems/caching/operations.rst new file mode 100644 index 0000000..f7ddcc0 --- /dev/null +++ b/Documentation/filesystems/caching/operations.rst
@@ -0,0 +1,210 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================ +Asynchronous Operations Handling +================================ + +By: David Howells <dhowells@redhat.com> + +.. Contents: + + (*) Overview. + + (*) Operation record initialisation. + + (*) Parameters. + + (*) Procedure. + + (*) Asynchronous callback. + + +Overview +======== + +FS-Cache has an asynchronous operations handling facility that it uses for its +data storage and retrieval routines. Its operations are represented by +fscache_operation structs, though these are usually embedded into some other +structure. + +This facility is available to and expected to be be used by the cache backends, +and FS-Cache will create operations and pass them off to the appropriate cache +backend for completion. + +To make use of this facility, <linux/fscache-cache.h> should be #included. + + +Operation Record Initialisation +=============================== + +An operation is recorded in an fscache_operation struct:: + + struct fscache_operation { + union { + struct work_struct fast_work; + struct slow_work slow_work; + }; + unsigned long flags; + fscache_operation_processor_t processor; + ... + }; + +Someone wanting to issue an operation should allocate something with this +struct embedded in it. They should initialise it by calling:: + + void fscache_operation_init(struct fscache_operation *op, + fscache_operation_release_t release); + +with the operation to be initialised and the release function to use. + +The op->flags parameter should be set to indicate the CPU time provision and +the exclusivity (see the Parameters section). + +The op->fast_work, op->slow_work and op->processor flags should be set as +appropriate for the CPU time provision (see the Parameters section). + +FSCACHE_OP_WAITING may be set in op->flags prior to each submission of the +operation and waited for afterwards. + + +Parameters +========== + +There are a number of parameters that can be set in the operation record's flag +parameter. There are three options for the provision of CPU time in these +operations: + + (1) The operation may be done synchronously (FSCACHE_OP_MYTHREAD). A thread + may decide it wants to handle an operation itself without deferring it to + another thread. + + This is, for example, used in read operations for calling readpages() on + the backing filesystem in CacheFiles. Although readpages() does an + asynchronous data fetch, the determination of whether pages exist is done + synchronously - and the netfs does not proceed until this has been + determined. + + If this option is to be used, FSCACHE_OP_WAITING must be set in op->flags + before submitting the operation, and the operating thread must wait for it + to be cleared before proceeding:: + + wait_on_bit(&op->flags, FSCACHE_OP_WAITING, + TASK_UNINTERRUPTIBLE); + + + (2) The operation may be fast asynchronous (FSCACHE_OP_FAST), in which case it + will be given to keventd to process. Such an operation is not permitted + to sleep on I/O. + + This is, for example, used by CacheFiles to copy data from a backing fs + page to a netfs page after the backing fs has read the page in. + + If this option is used, op->fast_work and op->processor must be + initialised before submitting the operation:: + + INIT_WORK(&op->fast_work, do_some_work); + + + (3) The operation may be slow asynchronous (FSCACHE_OP_SLOW), in which case it + will be given to the slow work facility to process. Such an operation is + permitted to sleep on I/O. + + This is, for example, used by FS-Cache to handle background writes of + pages that have just been fetched from a remote server. + + If this option is used, op->slow_work and op->processor must be + initialised before submitting the operation:: + + fscache_operation_init_slow(op, processor) + + +Furthermore, operations may be one of two types: + + (1) Exclusive (FSCACHE_OP_EXCLUSIVE). Operations of this type may not run in + conjunction with any other operation on the object being operated upon. + + An example of this is the attribute change operation, in which the file + being written to may need truncation. + + (2) Shareable. Operations of this type may be running simultaneously. It's + up to the operation implementation to prevent interference between other + operations running at the same time. + + +Procedure +========= + +Operations are used through the following procedure: + + (1) The submitting thread must allocate the operation and initialise it + itself. Normally this would be part of a more specific structure with the + generic op embedded within. + + (2) The submitting thread must then submit the operation for processing using + one of the following two functions:: + + int fscache_submit_op(struct fscache_object *object, + struct fscache_operation *op); + + int fscache_submit_exclusive_op(struct fscache_object *object, + struct fscache_operation *op); + + The first function should be used to submit non-exclusive ops and the + second to submit exclusive ones. The caller must still set the + FSCACHE_OP_EXCLUSIVE flag. + + If successful, both functions will assign the operation to the specified + object and return 0. -ENOBUFS will be returned if the object specified is + permanently unavailable. + + The operation manager will defer operations on an object that is still + undergoing lookup or creation. The operation will also be deferred if an + operation of conflicting exclusivity is in progress on the object. + + If the operation is asynchronous, the manager will retain a reference to + it, so the caller should put their reference to it by passing it to:: + + void fscache_put_operation(struct fscache_operation *op); + + (3) If the submitting thread wants to do the work itself, and has marked the + operation with FSCACHE_OP_MYTHREAD, then it should monitor + FSCACHE_OP_WAITING as described above and check the state of the object if + necessary (the object might have died while the thread was waiting). + + When it has finished doing its processing, it should call + fscache_op_complete() and fscache_put_operation() on it. + + (4) The operation holds an effective lock upon the object, preventing other + exclusive ops conflicting until it is released. The operation can be + enqueued for further immediate asynchronous processing by adjusting the + CPU time provisioning option if necessary, eg:: + + op->flags &= ~FSCACHE_OP_TYPE; + op->flags |= ~FSCACHE_OP_FAST; + + and calling:: + + void fscache_enqueue_operation(struct fscache_operation *op) + + This can be used to allow other things to have use of the worker thread + pools. + + +Asynchronous Callback +===================== + +When used in asynchronous mode, the worker thread pool will invoke the +processor method with a pointer to the operation. This should then get at the +container struct by using container_of():: + + static void fscache_write_op(struct fscache_operation *_op) + { + struct fscache_storage *op = + container_of(_op, struct fscache_storage, op); + ... + } + +The caller holds a reference on the operation, and will invoke +fscache_put_operation() when the processor function returns. The processor +function is at liberty to call fscache_enqueue_operation() or to take extra +references.
diff --git a/Documentation/filesystems/caching/operations.txt b/Documentation/filesystems/caching/operations.txt deleted file mode 100644 index d8976c4..0000000 --- a/Documentation/filesystems/caching/operations.txt +++ /dev/null
@@ -1,213 +0,0 @@ - ================================ - ASYNCHRONOUS OPERATIONS HANDLING - ================================ - -By: David Howells <dhowells@redhat.com> - -Contents: - - (*) Overview. - - (*) Operation record initialisation. - - (*) Parameters. - - (*) Procedure. - - (*) Asynchronous callback. - - -======== -OVERVIEW -======== - -FS-Cache has an asynchronous operations handling facility that it uses for its -data storage and retrieval routines. Its operations are represented by -fscache_operation structs, though these are usually embedded into some other -structure. - -This facility is available to and expected to be be used by the cache backends, -and FS-Cache will create operations and pass them off to the appropriate cache -backend for completion. - -To make use of this facility, <linux/fscache-cache.h> should be #included. - - -=============================== -OPERATION RECORD INITIALISATION -=============================== - -An operation is recorded in an fscache_operation struct: - - struct fscache_operation { - union { - struct work_struct fast_work; - struct slow_work slow_work; - }; - unsigned long flags; - fscache_operation_processor_t processor; - ... - }; - -Someone wanting to issue an operation should allocate something with this -struct embedded in it. They should initialise it by calling: - - void fscache_operation_init(struct fscache_operation *op, - fscache_operation_release_t release); - -with the operation to be initialised and the release function to use. - -The op->flags parameter should be set to indicate the CPU time provision and -the exclusivity (see the Parameters section). - -The op->fast_work, op->slow_work and op->processor flags should be set as -appropriate for the CPU time provision (see the Parameters section). - -FSCACHE_OP_WAITING may be set in op->flags prior to each submission of the -operation and waited for afterwards. - - -========== -PARAMETERS -========== - -There are a number of parameters that can be set in the operation record's flag -parameter. There are three options for the provision of CPU time in these -operations: - - (1) The operation may be done synchronously (FSCACHE_OP_MYTHREAD). A thread - may decide it wants to handle an operation itself without deferring it to - another thread. - - This is, for example, used in read operations for calling readpages() on - the backing filesystem in CacheFiles. Although readpages() does an - asynchronous data fetch, the determination of whether pages exist is done - synchronously - and the netfs does not proceed until this has been - determined. - - If this option is to be used, FSCACHE_OP_WAITING must be set in op->flags - before submitting the operation, and the operating thread must wait for it - to be cleared before proceeding: - - wait_on_bit(&op->flags, FSCACHE_OP_WAITING, - TASK_UNINTERRUPTIBLE); - - - (2) The operation may be fast asynchronous (FSCACHE_OP_FAST), in which case it - will be given to keventd to process. Such an operation is not permitted - to sleep on I/O. - - This is, for example, used by CacheFiles to copy data from a backing fs - page to a netfs page after the backing fs has read the page in. - - If this option is used, op->fast_work and op->processor must be - initialised before submitting the operation: - - INIT_WORK(&op->fast_work, do_some_work); - - - (3) The operation may be slow asynchronous (FSCACHE_OP_SLOW), in which case it - will be given to the slow work facility to process. Such an operation is - permitted to sleep on I/O. - - This is, for example, used by FS-Cache to handle background writes of - pages that have just been fetched from a remote server. - - If this option is used, op->slow_work and op->processor must be - initialised before submitting the operation: - - fscache_operation_init_slow(op, processor) - - -Furthermore, operations may be one of two types: - - (1) Exclusive (FSCACHE_OP_EXCLUSIVE). Operations of this type may not run in - conjunction with any other operation on the object being operated upon. - - An example of this is the attribute change operation, in which the file - being written to may need truncation. - - (2) Shareable. Operations of this type may be running simultaneously. It's - up to the operation implementation to prevent interference between other - operations running at the same time. - - -========= -PROCEDURE -========= - -Operations are used through the following procedure: - - (1) The submitting thread must allocate the operation and initialise it - itself. Normally this would be part of a more specific structure with the - generic op embedded within. - - (2) The submitting thread must then submit the operation for processing using - one of the following two functions: - - int fscache_submit_op(struct fscache_object *object, - struct fscache_operation *op); - - int fscache_submit_exclusive_op(struct fscache_object *object, - struct fscache_operation *op); - - The first function should be used to submit non-exclusive ops and the - second to submit exclusive ones. The caller must still set the - FSCACHE_OP_EXCLUSIVE flag. - - If successful, both functions will assign the operation to the specified - object and return 0. -ENOBUFS will be returned if the object specified is - permanently unavailable. - - The operation manager will defer operations on an object that is still - undergoing lookup or creation. The operation will also be deferred if an - operation of conflicting exclusivity is in progress on the object. - - If the operation is asynchronous, the manager will retain a reference to - it, so the caller should put their reference to it by passing it to: - - void fscache_put_operation(struct fscache_operation *op); - - (3) If the submitting thread wants to do the work itself, and has marked the - operation with FSCACHE_OP_MYTHREAD, then it should monitor - FSCACHE_OP_WAITING as described above and check the state of the object if - necessary (the object might have died while the thread was waiting). - - When it has finished doing its processing, it should call - fscache_op_complete() and fscache_put_operation() on it. - - (4) The operation holds an effective lock upon the object, preventing other - exclusive ops conflicting until it is released. The operation can be - enqueued for further immediate asynchronous processing by adjusting the - CPU time provisioning option if necessary, eg: - - op->flags &= ~FSCACHE_OP_TYPE; - op->flags |= ~FSCACHE_OP_FAST; - - and calling: - - void fscache_enqueue_operation(struct fscache_operation *op) - - This can be used to allow other things to have use of the worker thread - pools. - - -===================== -ASYNCHRONOUS CALLBACK -===================== - -When used in asynchronous mode, the worker thread pool will invoke the -processor method with a pointer to the operation. This should then get at the -container struct by using container_of(): - - static void fscache_write_op(struct fscache_operation *_op) - { - struct fscache_storage *op = - container_of(_op, struct fscache_storage, op); - ... - } - -The caller holds a reference on the operation, and will invoke -fscache_put_operation() when the processor function returns. The processor -function is at liberty to call fscache_enqueue_operation() or to take extra -references.
diff --git a/Documentation/filesystems/cifs/cifsroot.rst b/Documentation/filesystems/cifs/cifsroot.rst new file mode 100644 index 0000000..4930bb4 --- /dev/null +++ b/Documentation/filesystems/cifs/cifsroot.rst
@@ -0,0 +1,105 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================================== +Mounting root file system via SMB (cifs.ko) +=========================================== + +Written 2019 by Paulo Alcantara <palcantara@suse.de> + +Written 2019 by Aurelien Aptel <aaptel@suse.com> + +The CONFIG_CIFS_ROOT option enables experimental root file system +support over the SMB protocol via cifs.ko. + +It introduces a new kernel command-line option called 'cifsroot=' +which will tell the kernel to mount the root file system over the +network by utilizing SMB or CIFS protocol. + +In order to mount, the network stack will also need to be set up by +using 'ip=' config option. For more details, see +Documentation/admin-guide/nfs/nfsroot.rst. + +A CIFS root mount currently requires the use of SMB1+UNIX Extensions +which is only supported by the Samba server. SMB1 is the older +deprecated version of the protocol but it has been extended to support +POSIX features (See [1]). The equivalent extensions for the newer +recommended version of the protocol (SMB3) have not been fully +implemented yet which means SMB3 doesn't support some required POSIX +file system objects (e.g. block devices, pipes, sockets). + +As a result, a CIFS root will default to SMB1 for now but the version +to use can nonetheless be changed via the 'vers=' mount option. This +default will change once the SMB3 POSIX extensions are fully +implemented. + +Server configuration +==================== + +To enable SMB1+UNIX extensions you will need to set these global +settings in Samba smb.conf:: + + [global] + server min protocol = NT1 + unix extension = yes # default + +Kernel command line +=================== + +:: + + root=/dev/cifs + +This is just a virtual device that basically tells the kernel to mount +the root file system via SMB protocol. + +:: + + cifsroot=//<server-ip>/<share>[,options] + +Enables the kernel to mount the root file system via SMB that are +located in the <server-ip> and <share> specified in this option. + +The default mount options are set in fs/cifs/cifsroot.c. + +server-ip + IPv4 address of the server. + +share + Path to SMB share (rootfs). + +options + Optional mount options. For more information, see mount.cifs(8). + +Examples +======== + +Export root file system as a Samba share in smb.conf file:: + + ... + [linux] + path = /path/to/rootfs + read only = no + guest ok = yes + force user = root + force group = root + browseable = yes + writeable = yes + admin users = root + public = yes + create mask = 0777 + directory mask = 0777 + ... + +Restart smb service:: + + # systemctl restart smb + +Test it under QEMU on a kernel built with CONFIG_CIFS_ROOT and +CONFIG_IP_PNP options enabled:: + + # qemu-system-x86_64 -enable-kvm -cpu host -m 1024 \ + -kernel /path/to/linux/arch/x86/boot/bzImage -nographic \ + -append "root=/dev/cifs rw ip=dhcp cifsroot=//10.0.2.2/linux,username=foo,password=bar console=ttyS0 3" + + +1: https://wiki.samba.org/index.php/UNIX_Extensions
diff --git a/Documentation/filesystems/cifs/cifsroot.txt b/Documentation/filesystems/cifs/cifsroot.txt deleted file mode 100644 index 947b7ec..0000000 --- a/Documentation/filesystems/cifs/cifsroot.txt +++ /dev/null
@@ -1,97 +0,0 @@ -Mounting root file system via SMB (cifs.ko) -=========================================== - -Written 2019 by Paulo Alcantara <palcantara@suse.de> -Written 2019 by Aurelien Aptel <aaptel@suse.com> - -The CONFIG_CIFS_ROOT option enables experimental root file system -support over the SMB protocol via cifs.ko. - -It introduces a new kernel command-line option called 'cifsroot=' -which will tell the kernel to mount the root file system over the -network by utilizing SMB or CIFS protocol. - -In order to mount, the network stack will also need to be set up by -using 'ip=' config option. For more details, see -Documentation/admin-guide/nfs/nfsroot.rst. - -A CIFS root mount currently requires the use of SMB1+UNIX Extensions -which is only supported by the Samba server. SMB1 is the older -deprecated version of the protocol but it has been extended to support -POSIX features (See [1]). The equivalent extensions for the newer -recommended version of the protocol (SMB3) have not been fully -implemented yet which means SMB3 doesn't support some required POSIX -file system objects (e.g. block devices, pipes, sockets). - -As a result, a CIFS root will default to SMB1 for now but the version -to use can nonetheless be changed via the 'vers=' mount option. This -default will change once the SMB3 POSIX extensions are fully -implemented. - -Server configuration -==================== - -To enable SMB1+UNIX extensions you will need to set these global -settings in Samba smb.conf: - - [global] - server min protocol = NT1 - unix extension = yes # default - -Kernel command line -=================== - -root=/dev/cifs - -This is just a virtual device that basically tells the kernel to mount -the root file system via SMB protocol. - -cifsroot=//<server-ip>/<share>[,options] - -Enables the kernel to mount the root file system via SMB that are -located in the <server-ip> and <share> specified in this option. - -The default mount options are set in fs/cifs/cifsroot.c. - -server-ip - IPv4 address of the server. - -share - Path to SMB share (rootfs). - -options - Optional mount options. For more information, see mount.cifs(8). - -Examples -======== - -Export root file system as a Samba share in smb.conf file. - -... -[linux] - path = /path/to/rootfs - read only = no - guest ok = yes - force user = root - force group = root - browseable = yes - writeable = yes - admin users = root - public = yes - create mask = 0777 - directory mask = 0777 -... - -Restart smb service. - -# systemctl restart smb - -Test it under QEMU on a kernel built with CONFIG_CIFS_ROOT and -CONFIG_IP_PNP options enabled. - -# qemu-system-x86_64 -enable-kvm -cpu host -m 1024 \ - -kernel /path/to/linux/arch/x86/boot/bzImage -nographic \ - -append "root=/dev/cifs rw ip=dhcp cifsroot=//10.0.2.2/linux,username=foo,password=bar console=ttyS0 3" - - -1: https://wiki.samba.org/index.php/UNIX_Extensions
diff --git a/Documentation/filesystems/coda.rst b/Documentation/filesystems/coda.rst new file mode 100644 index 0000000..84c860c --- /dev/null +++ b/Documentation/filesystems/coda.rst
@@ -0,0 +1,1670 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================== +Coda Kernel-Venus Interface +=========================== + +.. Note:: + + This is one of the technical documents describing a component of + Coda -- this document describes the client kernel-Venus interface. + +For more information: + + http://www.coda.cs.cmu.edu + +For user level software needed to run Coda: + + ftp://ftp.coda.cs.cmu.edu + +To run Coda you need to get a user level cache manager for the client, +named Venus, as well as tools to manipulate ACLs, to log in, etc. The +client needs to have the Coda filesystem selected in the kernel +configuration. + +The server needs a user level server and at present does not depend on +kernel support. + + The Venus kernel interface + + Peter J. Braam + + v1.0, Nov 9, 1997 + + This document describes the communication between Venus and kernel + level filesystem code needed for the operation of the Coda file sys- + tem. This document version is meant to describe the current interface + (version 1.0) as well as improvements we envisage. + +.. Table of Contents + + 1. Introduction + + 2. Servicing Coda filesystem calls + + 3. The message layer + + 3.1 Implementation details + + 4. The interface at the call level + + 4.1 Data structures shared by the kernel and Venus + 4.2 The pioctl interface + 4.3 root + 4.4 lookup + 4.5 getattr + 4.6 setattr + 4.7 access + 4.8 create + 4.9 mkdir + 4.10 link + 4.11 symlink + 4.12 remove + 4.13 rmdir + 4.14 readlink + 4.15 open + 4.16 close + 4.17 ioctl + 4.18 rename + 4.19 readdir + 4.20 vget + 4.21 fsync + 4.22 inactive + 4.23 rdwr + 4.24 odymount + 4.25 ody_lookup + 4.26 ody_expand + 4.27 prefetch + 4.28 signal + + 5. The minicache and downcalls + + 5.1 INVALIDATE + 5.2 FLUSH + 5.3 PURGEUSER + 5.4 ZAPFILE + 5.5 ZAPDIR + 5.6 ZAPVNODE + 5.7 PURGEFID + 5.8 REPLACE + + 6. Initialization and cleanup + + 6.1 Requirements + +1. Introduction +=============== + + A key component in the Coda Distributed File System is the cache + manager, Venus. + + When processes on a Coda enabled system access files in the Coda + filesystem, requests are directed at the filesystem layer in the + operating system. The operating system will communicate with Venus to + service the request for the process. Venus manages a persistent + client cache and makes remote procedure calls to Coda file servers and + related servers (such as authentication servers) to service these + requests it receives from the operating system. When Venus has + serviced a request it replies to the operating system with appropriate + return codes, and other data related to the request. Optionally the + kernel support for Coda may maintain a minicache of recently processed + requests to limit the number of interactions with Venus. Venus + possesses the facility to inform the kernel when elements from its + minicache are no longer valid. + + This document describes precisely this communication between the + kernel and Venus. The definitions of so called upcalls and downcalls + will be given with the format of the data they handle. We shall also + describe the semantic invariants resulting from the calls. + + Historically Coda was implemented in a BSD file system in Mach 2.6. + The interface between the kernel and Venus is very similar to the BSD + VFS interface. Similar functionality is provided, and the format of + the parameters and returned data is very similar to the BSD VFS. This + leads to an almost natural environment for implementing a kernel-level + filesystem driver for Coda in a BSD system. However, other operating + systems such as Linux and Windows 95 and NT have virtual filesystem + with different interfaces. + + To implement Coda on these systems some reverse engineering of the + Venus/Kernel protocol is necessary. Also it came to light that other + systems could profit significantly from certain small optimizations + and modifications to the protocol. To facilitate this work as well as + to make future ports easier, communication between Venus and the + kernel should be documented in great detail. This is the aim of this + document. + +2. Servicing Coda filesystem calls +=================================== + + The service of a request for a Coda file system service originates in + a process P which accessing a Coda file. It makes a system call which + traps to the OS kernel. Examples of such calls trapping to the kernel + are ``read``, ``write``, ``open``, ``close``, ``create``, ``mkdir``, + ``rmdir``, ``chmod`` in a Unix ontext. Similar calls exist in the Win32 + environment, and are named ``CreateFile``. + + Generally the operating system handles the request in a virtual + filesystem (VFS) layer, which is named I/O Manager in NT and IFS + manager in Windows 95. The VFS is responsible for partial processing + of the request and for locating the specific filesystem(s) which will + service parts of the request. Usually the information in the path + assists in locating the correct FS drivers. Sometimes after extensive + pre-processing, the VFS starts invoking exported routines in the FS + driver. This is the point where the FS specific processing of the + request starts, and here the Coda specific kernel code comes into + play. + + The FS layer for Coda must expose and implement several interfaces. + First and foremost the VFS must be able to make all necessary calls to + the Coda FS layer, so the Coda FS driver must expose the VFS interface + as applicable in the operating system. These differ very significantly + among operating systems, but share features such as facilities to + read/write and create and remove objects. The Coda FS layer services + such VFS requests by invoking one or more well defined services + offered by the cache manager Venus. When the replies from Venus have + come back to the FS driver, servicing of the VFS call continues and + finishes with a reply to the kernel's VFS. Finally the VFS layer + returns to the process. + + As a result of this design a basic interface exposed by the FS driver + must allow Venus to manage message traffic. In particular Venus must + be able to retrieve and place messages and to be notified of the + arrival of a new message. The notification must be through a mechanism + which does not block Venus since Venus must attend to other tasks even + when no messages are waiting or being processed. + + **Interfaces of the Coda FS Driver** + + Furthermore the FS layer provides for a special path of communication + between a user process and Venus, called the pioctl interface. The + pioctl interface is used for Coda specific services, such as + requesting detailed information about the persistent cache managed by + Venus. Here the involvement of the kernel is minimal. It identifies + the calling process and passes the information on to Venus. When + Venus replies the response is passed back to the caller in unmodified + form. + + Finally Venus allows the kernel FS driver to cache the results from + certain services. This is done to avoid excessive context switches + and results in an efficient system. However, Venus may acquire + information, for example from the network which implies that cached + information must be flushed or replaced. Venus then makes a downcall + to the Coda FS layer to request flushes or updates in the cache. The + kernel FS driver handles such requests synchronously. + + Among these interfaces the VFS interface and the facility to place, + receive and be notified of messages are platform specific. We will + not go into the calls exported to the VFS layer but we will state the + requirements of the message exchange mechanism. + + +3. The message layer +===================== + + At the lowest level the communication between Venus and the FS driver + proceeds through messages. The synchronization between processes + requesting Coda file service and Venus relies on blocking and waking + up processes. The Coda FS driver processes VFS- and pioctl-requests + on behalf of a process P, creates messages for Venus, awaits replies + and finally returns to the caller. The implementation of the exchange + of messages is platform specific, but the semantics have (so far) + appeared to be generally applicable. Data buffers are created by the + FS Driver in kernel memory on behalf of P and copied to user memory in + Venus. + + The FS Driver while servicing P makes upcalls to Venus. Such an + upcall is dispatched to Venus by creating a message structure. The + structure contains the identification of P, the message sequence + number, the size of the request and a pointer to the data in kernel + memory for the request. Since the data buffer is re-used to hold the + reply from Venus, there is a field for the size of the reply. A flags + field is used in the message to precisely record the status of the + message. Additional platform dependent structures involve pointers to + determine the position of the message on queues and pointers to + synchronization objects. In the upcall routine the message structure + is filled in, flags are set to 0, and it is placed on the *pending* + queue. The routine calling upcall is responsible for allocating the + data buffer; its structure will be described in the next section. + + A facility must exist to notify Venus that the message has been + created, and implemented using available synchronization objects in + the OS. This notification is done in the upcall context of the process + P. When the message is on the pending queue, process P cannot proceed + in upcall. The (kernel mode) processing of P in the filesystem + request routine must be suspended until Venus has replied. Therefore + the calling thread in P is blocked in upcall. A pointer in the + message structure will locate the synchronization object on which P is + sleeping. + + Venus detects the notification that a message has arrived, and the FS + driver allow Venus to retrieve the message with a getmsg_from_kernel + call. This action finishes in the kernel by putting the message on the + queue of processing messages and setting flags to READ. Venus is + passed the contents of the data buffer. The getmsg_from_kernel call + now returns and Venus processes the request. + + At some later point the FS driver receives a message from Venus, + namely when Venus calls sendmsg_to_kernel. At this moment the Coda FS + driver looks at the contents of the message and decides if: + + + * the message is a reply for a suspended thread P. If so it removes + the message from the processing queue and marks the message as + WRITTEN. Finally, the FS driver unblocks P (still in the kernel + mode context of Venus) and the sendmsg_to_kernel call returns to + Venus. The process P will be scheduled at some point and continues + processing its upcall with the data buffer replaced with the reply + from Venus. + + * The message is a ``downcall``. A downcall is a request from Venus to + the FS Driver. The FS driver processes the request immediately + (usually a cache eviction or replacement) and when it finishes + sendmsg_to_kernel returns. + + Now P awakes and continues processing upcall. There are some + subtleties to take account of. First P will determine if it was woken + up in upcall by a signal from some other source (for example an + attempt to terminate P) or as is normally the case by Venus in its + sendmsg_to_kernel call. In the normal case, the upcall routine will + deallocate the message structure and return. The FS routine can proceed + with its processing. + + + **Sleeping and IPC arrangements** + + In case P is woken up by a signal and not by Venus, it will first look + at the flags field. If the message is not yet READ, the process P can + handle its signal without notifying Venus. If Venus has READ, and + the request should not be processed, P can send Venus a signal message + to indicate that it should disregard the previous message. Such + signals are put in the queue at the head, and read first by Venus. If + the message is already marked as WRITTEN it is too late to stop the + processing. The VFS routine will now continue. (-- If a VFS request + involves more than one upcall, this can lead to complicated state, an + extra field "handle_signals" could be added in the message structure + to indicate points of no return have been passed.--) + + + +3.1. Implementation details +---------------------------- + + The Unix implementation of this mechanism has been through the + implementation of a character device associated with Coda. Venus + retrieves messages by doing a read on the device, replies are sent + with a write and notification is through the select system call on the + file descriptor for the device. The process P is kept waiting on an + interruptible wait queue object. + + In Windows NT and the DPMI Windows 95 implementation a DeviceIoControl + call is used. The DeviceIoControl call is designed to copy buffers + from user memory to kernel memory with OPCODES. The sendmsg_to_kernel + is issued as a synchronous call, while the getmsg_from_kernel call is + asynchronous. Windows EventObjects are used for notification of + message arrival. The process P is kept waiting on a KernelEvent + object in NT and a semaphore in Windows 95. + + +4. The interface at the call level +=================================== + + + This section describes the upcalls a Coda FS driver can make to Venus. + Each of these upcalls make use of two structures: inputArgs and + outputArgs. In pseudo BNF form the structures take the following + form:: + + + struct inputArgs { + u_long opcode; + u_long unique; /* Keep multiple outstanding msgs distinct */ + u_short pid; /* Common to all */ + u_short pgid; /* Common to all */ + struct CodaCred cred; /* Common to all */ + + <union "in" of call dependent parts of inputArgs> + }; + + struct outputArgs { + u_long opcode; + u_long unique; /* Keep multiple outstanding msgs distinct */ + u_long result; + + <union "out" of call dependent parts of inputArgs> + }; + + + + Before going on let us elucidate the role of the various fields. The + inputArgs start with the opcode which defines the type of service + requested from Venus. There are approximately 30 upcalls at present + which we will discuss. The unique field labels the inputArg with a + unique number which will identify the message uniquely. A process and + process group id are passed. Finally the credentials of the caller + are included. + + Before delving into the specific calls we need to discuss a variety of + data structures shared by the kernel and Venus. + + + + +4.1. Data structures shared by the kernel and Venus +---------------------------------------------------- + + + The CodaCred structure defines a variety of user and group ids as + they are set for the calling process. The vuid_t and vgid_t are 32 bit + unsigned integers. It also defines group membership in an array. On + Unix the CodaCred has proven sufficient to implement good security + semantics for Coda but the structure may have to undergo modification + for the Windows environment when these mature:: + + struct CodaCred { + vuid_t cr_uid, cr_euid, cr_suid, cr_fsuid; /* Real, effective, set, fs uid */ + vgid_t cr_gid, cr_egid, cr_sgid, cr_fsgid; /* same for groups */ + vgid_t cr_groups[NGROUPS]; /* Group membership for caller */ + }; + + + .. Note:: + + It is questionable if we need CodaCreds in Venus. Finally Venus + doesn't know about groups, although it does create files with the + default uid/gid. Perhaps the list of group membership is superfluous. + + + The next item is the fundamental identifier used to identify Coda + files, the ViceFid. A fid of a file uniquely defines a file or + directory in the Coda filesystem within a cell [1]_:: + + typedef struct ViceFid { + VolumeId Volume; + VnodeId Vnode; + Unique_t Unique; + } ViceFid; + + .. [1] A cell is agroup of Coda servers acting under the aegis of a single + system control machine or SCM. See the Coda Administration manual + for a detailed description of the role of the SCM. + + Each of the constituent fields: VolumeId, VnodeId and Unique_t are + unsigned 32 bit integers. We envisage that a further field will need + to be prefixed to identify the Coda cell; this will probably take the + form of a Ipv6 size IP address naming the Coda cell through DNS. + + The next important structure shared between Venus and the kernel is + the attributes of the file. The following structure is used to + exchange information. It has room for future extensions such as + support for device files (currently not present in Coda):: + + + struct coda_timespec { + int64_t tv_sec; /* seconds */ + long tv_nsec; /* nanoseconds */ + }; + + struct coda_vattr { + enum coda_vtype va_type; /* vnode type (for create) */ + u_short va_mode; /* files access mode and type */ + short va_nlink; /* number of references to file */ + vuid_t va_uid; /* owner user id */ + vgid_t va_gid; /* owner group id */ + long va_fsid; /* file system id (dev for now) */ + long va_fileid; /* file id */ + u_quad_t va_size; /* file size in bytes */ + long va_blocksize; /* blocksize preferred for i/o */ + struct coda_timespec va_atime; /* time of last access */ + struct coda_timespec va_mtime; /* time of last modification */ + struct coda_timespec va_ctime; /* time file changed */ + u_long va_gen; /* generation number of file */ + u_long va_flags; /* flags defined for file */ + dev_t va_rdev; /* device special file represents */ + u_quad_t va_bytes; /* bytes of disk space held by file */ + u_quad_t va_filerev; /* file modification number */ + u_int va_vaflags; /* operations flags, see below */ + long va_spare; /* remain quad aligned */ + }; + + +4.2. The pioctl interface +-------------------------- + + + Coda specific requests can be made by application through the pioctl + interface. The pioctl is implemented as an ordinary ioctl on a + fictitious file /coda/.CONTROL. The pioctl call opens this file, gets + a file handle and makes the ioctl call. Finally it closes the file. + + The kernel involvement in this is limited to providing the facility to + open and close and pass the ioctl message and to verify that a path in + the pioctl data buffers is a file in a Coda filesystem. + + The kernel is handed a data packet of the form:: + + struct { + const char *path; + struct ViceIoctl vidata; + int follow; + } data; + + + + where:: + + + struct ViceIoctl { + caddr_t in, out; /* Data to be transferred in, or out */ + short in_size; /* Size of input buffer <= 2K */ + short out_size; /* Maximum size of output buffer, <= 2K */ + }; + + + + The path must be a Coda file, otherwise the ioctl upcall will not be + made. + + .. Note:: The data structures and code are a mess. We need to clean this up. + + +**We now proceed to document the individual calls**: + + +4.3. root +---------- + + + Arguments + in + + empty + + out:: + + struct cfs_root_out { + ViceFid VFid; + } cfs_root; + + + + Description + This call is made to Venus during the initialization of + the Coda filesystem. If the result is zero, the cfs_root structure + contains the ViceFid of the root of the Coda filesystem. If a non-zero + result is generated, its value is a platform dependent error code + indicating the difficulty Venus encountered in locating the root of + the Coda filesystem. + +4.4. lookup +------------ + + + Summary + Find the ViceFid and type of an object in a directory if it exists. + + Arguments + in:: + + struct cfs_lookup_in { + ViceFid VFid; + char *name; /* Place holder for data. */ + } cfs_lookup; + + + + out:: + + struct cfs_lookup_out { + ViceFid VFid; + int vtype; + } cfs_lookup; + + + + Description + This call is made to determine the ViceFid and filetype of + a directory entry. The directory entry requested carries name name + and Venus will search the directory identified by cfs_lookup_in.VFid. + The result may indicate that the name does not exist, or that + difficulty was encountered in finding it (e.g. due to disconnection). + If the result is zero, the field cfs_lookup_out.VFid contains the + targets ViceFid and cfs_lookup_out.vtype the coda_vtype giving the + type of object the name designates. + + The name of the object is an 8 bit character string of maximum length + CFS_MAXNAMLEN, currently set to 256 (including a 0 terminator.) + + It is extremely important to realize that Venus bitwise ors the field + cfs_lookup.vtype with CFS_NOCACHE to indicate that the object should + not be put in the kernel name cache. + + .. Note:: + + The type of the vtype is currently wrong. It should be + coda_vtype. Linux does not take note of CFS_NOCACHE. It should. + + +4.5. getattr +------------- + + + Summary Get the attributes of a file. + + Arguments + in:: + + struct cfs_getattr_in { + ViceFid VFid; + struct coda_vattr attr; /* XXXXX */ + } cfs_getattr; + + + + out:: + + struct cfs_getattr_out { + struct coda_vattr attr; + } cfs_getattr; + + + + Description + This call returns the attributes of the file identified by fid. + + Errors + Errors can occur if the object with fid does not exist, is + unaccessible or if the caller does not have permission to fetch + attributes. + + .. Note:: + + Many kernel FS drivers (Linux, NT and Windows 95) need to acquire + the attributes as well as the Fid for the instantiation of an internal + "inode" or "FileHandle". A significant improvement in performance on + such systems could be made by combining the lookup and getattr calls + both at the Venus/kernel interaction level and at the RPC level. + + The vattr structure included in the input arguments is superfluous and + should be removed. + + +4.6. setattr +------------- + + + Summary + Set the attributes of a file. + + Arguments + in:: + + struct cfs_setattr_in { + ViceFid VFid; + struct coda_vattr attr; + } cfs_setattr; + + + + + out + + empty + + Description + The structure attr is filled with attributes to be changed + in BSD style. Attributes not to be changed are set to -1, apart from + vtype which is set to VNON. Other are set to the value to be assigned. + The only attributes which the FS driver may request to change are the + mode, owner, groupid, atime, mtime and ctime. The return value + indicates success or failure. + + Errors + A variety of errors can occur. The object may not exist, may + be inaccessible, or permission may not be granted by Venus. + + +4.7. access +------------ + + + Arguments + in:: + + struct cfs_access_in { + ViceFid VFid; + int flags; + } cfs_access; + + + + out + + empty + + Description + Verify if access to the object identified by VFid for + operations described by flags is permitted. The result indicates if + access will be granted. It is important to remember that Coda uses + ACLs to enforce protection and that ultimately the servers, not the + clients enforce the security of the system. The result of this call + will depend on whether a token is held by the user. + + Errors + The object may not exist, or the ACL describing the protection + may not be accessible. + + +4.8. create +------------ + + + Summary + Invoked to create a file + + Arguments + in:: + + struct cfs_create_in { + ViceFid VFid; + struct coda_vattr attr; + int excl; + int mode; + char *name; /* Place holder for data. */ + } cfs_create; + + + + + out:: + + struct cfs_create_out { + ViceFid VFid; + struct coda_vattr attr; + } cfs_create; + + + + Description + This upcall is invoked to request creation of a file. + The file will be created in the directory identified by VFid, its name + will be name, and the mode will be mode. If excl is set an error will + be returned if the file already exists. If the size field in attr is + set to zero the file will be truncated. The uid and gid of the file + are set by converting the CodaCred to a uid using a macro CRTOUID + (this macro is platform dependent). Upon success the VFid and + attributes of the file are returned. The Coda FS Driver will normally + instantiate a vnode, inode or file handle at kernel level for the new + object. + + + Errors + A variety of errors can occur. Permissions may be insufficient. + If the object exists and is not a file the error EISDIR is returned + under Unix. + + .. Note:: + + The packing of parameters is very inefficient and appears to + indicate confusion between the system call creat and the VFS operation + create. The VFS operation create is only called to create new objects. + This create call differs from the Unix one in that it is not invoked + to return a file descriptor. The truncate and exclusive options, + together with the mode, could simply be part of the mode as it is + under Unix. There should be no flags argument; this is used in open + (2) to return a file descriptor for READ or WRITE mode. + + The attributes of the directory should be returned too, since the size + and mtime changed. + + +4.9. mkdir +----------- + + + Summary + Create a new directory. + + Arguments + in:: + + struct cfs_mkdir_in { + ViceFid VFid; + struct coda_vattr attr; + char *name; /* Place holder for data. */ + } cfs_mkdir; + + + + out:: + + struct cfs_mkdir_out { + ViceFid VFid; + struct coda_vattr attr; + } cfs_mkdir; + + + + + Description + This call is similar to create but creates a directory. + Only the mode field in the input parameters is used for creation. + Upon successful creation, the attr returned contains the attributes of + the new directory. + + Errors + As for create. + + .. Note:: + + The input parameter should be changed to mode instead of + attributes. + + The attributes of the parent should be returned since the size and + mtime changes. + + +4.10. link +----------- + + + Summary + Create a link to an existing file. + + Arguments + in:: + + struct cfs_link_in { + ViceFid sourceFid; /* cnode to link *to* */ + ViceFid destFid; /* Directory in which to place link */ + char *tname; /* Place holder for data. */ + } cfs_link; + + + + out + + empty + + Description + This call creates a link to the sourceFid in the directory + identified by destFid with name tname. The source must reside in the + target's parent, i.e. the source must be have parent destFid, i.e. Coda + does not support cross directory hard links. Only the return value is + relevant. It indicates success or the type of failure. + + Errors + The usual errors can occur. + + +4.11. symlink +-------------- + + + Summary + create a symbolic link + + Arguments + in:: + + struct cfs_symlink_in { + ViceFid VFid; /* Directory to put symlink in */ + char *srcname; + struct coda_vattr attr; + char *tname; + } cfs_symlink; + + + + out + + none + + Description + Create a symbolic link. The link is to be placed in the + directory identified by VFid and named tname. It should point to the + pathname srcname. The attributes of the newly created object are to + be set to attr. + + .. Note:: + + The attributes of the target directory should be returned since + its size changed. + + +4.12. remove +------------- + + + Summary + Remove a file + + Arguments + in:: + + struct cfs_remove_in { + ViceFid VFid; + char *name; /* Place holder for data. */ + } cfs_remove; + + + + out + + none + + Description + Remove file named cfs_remove_in.name in directory + identified by VFid. + + + .. Note:: + + The attributes of the directory should be returned since its + mtime and size may change. + + +4.13. rmdir +------------ + + + Summary + Remove a directory + + Arguments + in:: + + struct cfs_rmdir_in { + ViceFid VFid; + char *name; /* Place holder for data. */ + } cfs_rmdir; + + + + out + + none + + Description + Remove the directory with name name from the directory + identified by VFid. + + .. Note:: The attributes of the parent directory should be returned since + its mtime and size may change. + + +4.14. readlink +--------------- + + + Summary + Read the value of a symbolic link. + + Arguments + in:: + + struct cfs_readlink_in { + ViceFid VFid; + } cfs_readlink; + + + + out:: + + struct cfs_readlink_out { + int count; + caddr_t data; /* Place holder for data. */ + } cfs_readlink; + + + + Description + This routine reads the contents of symbolic link + identified by VFid into the buffer data. The buffer data must be able + to hold any name up to CFS_MAXNAMLEN (PATH or NAM??). + + Errors + No unusual errors. + + +4.15. open +----------- + + + Summary + Open a file. + + Arguments + in:: + + struct cfs_open_in { + ViceFid VFid; + int flags; + } cfs_open; + + + + out:: + + struct cfs_open_out { + dev_t dev; + ino_t inode; + } cfs_open; + + + + Description + This request asks Venus to place the file identified by + VFid in its cache and to note that the calling process wishes to open + it with flags as in open(2). The return value to the kernel differs + for Unix and Windows systems. For Unix systems the Coda FS Driver is + informed of the device and inode number of the container file in the + fields dev and inode. For Windows the path of the container file is + returned to the kernel. + + + .. Note:: + + Currently the cfs_open_out structure is not properly adapted to + deal with the Windows case. It might be best to implement two + upcalls, one to open aiming at a container file name, the other at a + container file inode. + + +4.16. close +------------ + + + Summary + Close a file, update it on the servers. + + Arguments + in:: + + struct cfs_close_in { + ViceFid VFid; + int flags; + } cfs_close; + + + + out + + none + + Description + Close the file identified by VFid. + + .. Note:: + + The flags argument is bogus and not used. However, Venus' code + has room to deal with an execp input field, probably this field should + be used to inform Venus that the file was closed but is still memory + mapped for execution. There are comments about fetching versus not + fetching the data in Venus vproc_vfscalls. This seems silly. If a + file is being closed, the data in the container file is to be the new + data. Here again the execp flag might be in play to create confusion: + currently Venus might think a file can be flushed from the cache when + it is still memory mapped. This needs to be understood. + + +4.17. ioctl +------------ + + + Summary + Do an ioctl on a file. This includes the pioctl interface. + + Arguments + in:: + + struct cfs_ioctl_in { + ViceFid VFid; + int cmd; + int len; + int rwflag; + char *data; /* Place holder for data. */ + } cfs_ioctl; + + + + out:: + + + struct cfs_ioctl_out { + int len; + caddr_t data; /* Place holder for data. */ + } cfs_ioctl; + + + + Description + Do an ioctl operation on a file. The command, len and + data arguments are filled as usual. flags is not used by Venus. + + .. Note:: + + Another bogus parameter. flags is not used. What is the + business about PREFETCHING in the Venus code? + + + +4.18. rename +------------- + + + Summary + Rename a fid. + + Arguments + in:: + + struct cfs_rename_in { + ViceFid sourceFid; + char *srcname; + ViceFid destFid; + char *destname; + } cfs_rename; + + + + out + + none + + Description + Rename the object with name srcname in directory + sourceFid to destname in destFid. It is important that the names + srcname and destname are 0 terminated strings. Strings in Unix + kernels are not always null terminated. + + +4.19. readdir +-------------- + + + Summary + Read directory entries. + + Arguments + in:: + + struct cfs_readdir_in { + ViceFid VFid; + int count; + int offset; + } cfs_readdir; + + + + + out:: + + struct cfs_readdir_out { + int size; + caddr_t data; /* Place holder for data. */ + } cfs_readdir; + + + + Description + Read directory entries from VFid starting at offset and + read at most count bytes. Returns the data in data and returns + the size in size. + + + .. Note:: + + This call is not used. Readdir operations exploit container + files. We will re-evaluate this during the directory revamp which is + about to take place. + + +4.20. vget +----------- + + + Summary + instructs Venus to do an FSDB->Get. + + Arguments + in:: + + struct cfs_vget_in { + ViceFid VFid; + } cfs_vget; + + + + out:: + + struct cfs_vget_out { + ViceFid VFid; + int vtype; + } cfs_vget; + + + + Description + This upcall asks Venus to do a get operation on an fsobj + labelled by VFid. + + .. Note:: + + This operation is not used. However, it is extremely useful + since it can be used to deal with read/write memory mapped files. + These can be "pinned" in the Venus cache using vget and released with + inactive. + + +4.21. fsync +------------ + + + Summary + Tell Venus to update the RVM attributes of a file. + + Arguments + in:: + + struct cfs_fsync_in { + ViceFid VFid; + } cfs_fsync; + + + + out + + none + + Description + Ask Venus to update RVM attributes of object VFid. This + should be called as part of kernel level fsync type calls. The + result indicates if the syncing was successful. + + .. Note:: Linux does not implement this call. It should. + + +4.22. inactive +--------------- + + + Summary + Tell Venus a vnode is no longer in use. + + Arguments + in:: + + struct cfs_inactive_in { + ViceFid VFid; + } cfs_inactive; + + + + out + + none + + Description + This operation returns EOPNOTSUPP. + + .. Note:: This should perhaps be removed. + + +4.23. rdwr +----------- + + + Summary + Read or write from a file + + Arguments + in:: + + struct cfs_rdwr_in { + ViceFid VFid; + int rwflag; + int count; + int offset; + int ioflag; + caddr_t data; /* Place holder for data. */ + } cfs_rdwr; + + + + + out:: + + struct cfs_rdwr_out { + int rwflag; + int count; + caddr_t data; /* Place holder for data. */ + } cfs_rdwr; + + + + Description + This upcall asks Venus to read or write from a file. + + + .. Note:: + + It should be removed since it is against the Coda philosophy that + read/write operations never reach Venus. I have been told the + operation does not work. It is not currently used. + + + +4.24. odymount +--------------- + + + Summary + Allows mounting multiple Coda "filesystems" on one Unix mount point. + + Arguments + in:: + + struct ody_mount_in { + char *name; /* Place holder for data. */ + } ody_mount; + + + + out:: + + struct ody_mount_out { + ViceFid VFid; + } ody_mount; + + + + Description + Asks Venus to return the rootfid of a Coda system named + name. The fid is returned in VFid. + + .. Note:: + + This call was used by David for dynamic sets. It should be + removed since it causes a jungle of pointers in the VFS mounting area. + It is not used by Coda proper. Call is not implemented by Venus. + + +4.25. ody_lookup +----------------- + + + Summary + Looks up something. + + Arguments + in + + irrelevant + + + out + + irrelevant + + + .. Note:: Gut it. Call is not implemented by Venus. + + +4.26. ody_expand +----------------- + + + Summary + expands something in a dynamic set. + + Arguments + in + + irrelevant + + out + + irrelevant + + .. Note:: Gut it. Call is not implemented by Venus. + + +4.27. prefetch +--------------- + + + Summary + Prefetch a dynamic set. + + Arguments + + in + + Not documented. + + out + + Not documented. + + Description + Venus worker.cc has support for this call, although it is + noted that it doesn't work. Not surprising, since the kernel does not + have support for it. (ODY_PREFETCH is not a defined operation). + + + .. Note:: Gut it. It isn't working and isn't used by Coda. + + + +4.28. signal +------------- + + + Summary + Send Venus a signal about an upcall. + + Arguments + in + + none + + out + + not applicable. + + Description + This is an out-of-band upcall to Venus to inform Venus + that the calling process received a signal after Venus read the + message from the input queue. Venus is supposed to clean up the + operation. + + Errors + No reply is given. + + .. Note:: + + We need to better understand what Venus needs to clean up and if + it is doing this correctly. Also we need to handle multiple upcall + per system call situations correctly. It would be important to know + what state changes in Venus take place after an upcall for which the + kernel is responsible for notifying Venus to clean up (e.g. open + definitely is such a state change, but many others are maybe not). + + +5. The minicache and downcalls +=============================== + + + The Coda FS Driver can cache results of lookup and access upcalls, to + limit the frequency of upcalls. Upcalls carry a price since a process + context switch needs to take place. The counterpart of caching the + information is that Venus will notify the FS Driver that cached + entries must be flushed or renamed. + + The kernel code generally has to maintain a structure which links the + internal file handles (called vnodes in BSD, inodes in Linux and + FileHandles in Windows) with the ViceFid's which Venus maintains. The + reason is that frequent translations back and forth are needed in + order to make upcalls and use the results of upcalls. Such linking + objects are called cnodes. + + The current minicache implementations have cache entries which record + the following: + + 1. the name of the file + + 2. the cnode of the directory containing the object + + 3. a list of CodaCred's for which the lookup is permitted. + + 4. the cnode of the object + + The lookup call in the Coda FS Driver may request the cnode of the + desired object from the cache, by passing its name, directory and the + CodaCred's of the caller. The cache will return the cnode or indicate + that it cannot be found. The Coda FS Driver must be careful to + invalidate cache entries when it modifies or removes objects. + + When Venus obtains information that indicates that cache entries are + no longer valid, it will make a downcall to the kernel. Downcalls are + intercepted by the Coda FS Driver and lead to cache invalidations of + the kind described below. The Coda FS Driver does not return an error + unless the downcall data could not be read into kernel memory. + + +5.1. INVALIDATE +---------------- + + + No information is available on this call. + + +5.2. FLUSH +----------- + + + + Arguments + None + + Summary + Flush the name cache entirely. + + Description + Venus issues this call upon startup and when it dies. This + is to prevent stale cache information being held. Some operating + systems allow the kernel name cache to be switched off dynamically. + When this is done, this downcall is made. + + +5.3. PURGEUSER +--------------- + + + Arguments + :: + + struct cfs_purgeuser_out {/* CFS_PURGEUSER is a venus->kernel call */ + struct CodaCred cred; + } cfs_purgeuser; + + + + Description + Remove all entries in the cache carrying the Cred. This + call is issued when tokens for a user expire or are flushed. + + +5.4. ZAPFILE +------------- + + + Arguments + :: + + struct cfs_zapfile_out { /* CFS_ZAPFILE is a venus->kernel call */ + ViceFid CodaFid; + } cfs_zapfile; + + + + Description + Remove all entries which have the (dir vnode, name) pair. + This is issued as a result of an invalidation of cached attributes of + a vnode. + + .. Note:: + + Call is not named correctly in NetBSD and Mach. The minicache + zapfile routine takes different arguments. Linux does not implement + the invalidation of attributes correctly. + + + +5.5. ZAPDIR +------------ + + + Arguments + :: + + struct cfs_zapdir_out { /* CFS_ZAPDIR is a venus->kernel call */ + ViceFid CodaFid; + } cfs_zapdir; + + + + Description + Remove all entries in the cache lying in a directory + CodaFid, and all children of this directory. This call is issued when + Venus receives a callback on the directory. + + +5.6. ZAPVNODE +-------------- + + + + Arguments + :: + + struct cfs_zapvnode_out { /* CFS_ZAPVNODE is a venus->kernel call */ + struct CodaCred cred; + ViceFid VFid; + } cfs_zapvnode; + + + + Description + Remove all entries in the cache carrying the cred and VFid + as in the arguments. This downcall is probably never issued. + + +5.7. PURGEFID +-------------- + + + Arguments + :: + + struct cfs_purgefid_out { /* CFS_PURGEFID is a venus->kernel call */ + ViceFid CodaFid; + } cfs_purgefid; + + + + Description + Flush the attribute for the file. If it is a dir (odd + vnode), purge its children from the namecache and remove the file from the + namecache. + + + +5.8. REPLACE +------------- + + + Summary + Replace the Fid's for a collection of names. + + Arguments + :: + + struct cfs_replace_out { /* cfs_replace is a venus->kernel call */ + ViceFid NewFid; + ViceFid OldFid; + } cfs_replace; + + + + Description + This routine replaces a ViceFid in the name cache with + another. It is added to allow Venus during reintegration to replace + locally allocated temp fids while disconnected with global fids even + when the reference counts on those fids are not zero. + + +6. Initialization and cleanup +============================== + + + This section gives brief hints as to desirable features for the Coda + FS Driver at startup and upon shutdown or Venus failures. Before + entering the discussion it is useful to repeat that the Coda FS Driver + maintains the following data: + + + 1. message queues + + 2. cnodes + + 3. name cache entries + + The name cache entries are entirely private to the driver, so they + can easily be manipulated. The message queues will generally have + clear points of initialization and destruction. The cnodes are + much more delicate. User processes hold reference counts in Coda + filesystems and it can be difficult to clean up the cnodes. + + It can expect requests through: + + 1. the message subsystem + + 2. the VFS layer + + 3. pioctl interface + + Currently the pioctl passes through the VFS for Coda so we can + treat these similarly. + + +6.1. Requirements +------------------ + + + The following requirements should be accommodated: + + 1. The message queues should have open and close routines. On Unix + the opening of the character devices are such routines. + + - Before opening, no messages can be placed. + + - Opening will remove any old messages still pending. + + - Close will notify any sleeping processes that their upcall cannot + be completed. + + - Close will free all memory allocated by the message queues. + + + 2. At open the namecache shall be initialized to empty state. + + 3. Before the message queues are open, all VFS operations will fail. + Fortunately this can be achieved by making sure than mounting the + Coda filesystem cannot succeed before opening. + + 4. After closing of the queues, no VFS operations can succeed. Here + one needs to be careful, since a few operations (lookup, + read/write, readdir) can proceed without upcalls. These must be + explicitly blocked. + + 5. Upon closing the namecache shall be flushed and disabled. + + 6. All memory held by cnodes can be freed without relying on upcalls. + + 7. Unmounting the file system can be done without relying on upcalls. + + 8. Mounting the Coda filesystem should fail gracefully if Venus cannot + get the rootfid or the attributes of the rootfid. The latter is + best implemented by Venus fetching these objects before attempting + to mount. + + .. Note:: + + NetBSD in particular but also Linux have not implemented the + above requirements fully. For smooth operation this needs to be + corrected. + + +
diff --git a/Documentation/filesystems/coda.txt b/Documentation/filesystems/coda.txt deleted file mode 100644 index 1711ad4..0000000 --- a/Documentation/filesystems/coda.txt +++ /dev/null
@@ -1,1676 +0,0 @@ -NOTE: -This is one of the technical documents describing a component of -Coda -- this document describes the client kernel-Venus interface. - -For more information: - http://www.coda.cs.cmu.edu -For user level software needed to run Coda: - ftp://ftp.coda.cs.cmu.edu - -To run Coda you need to get a user level cache manager for the client, -named Venus, as well as tools to manipulate ACLs, to log in, etc. The -client needs to have the Coda filesystem selected in the kernel -configuration. - -The server needs a user level server and at present does not depend on -kernel support. - - - - - - - - The Venus kernel interface - Peter J. Braam - v1.0, Nov 9, 1997 - - This document describes the communication between Venus and kernel - level filesystem code needed for the operation of the Coda file sys- - tem. This document version is meant to describe the current interface - (version 1.0) as well as improvements we envisage. - ______________________________________________________________________ - - Table of Contents - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1. Introduction - - 2. Servicing Coda filesystem calls - - 3. The message layer - - 3.1 Implementation details - - 4. The interface at the call level - - 4.1 Data structures shared by the kernel and Venus - 4.2 The pioctl interface - 4.3 root - 4.4 lookup - 4.5 getattr - 4.6 setattr - 4.7 access - 4.8 create - 4.9 mkdir - 4.10 link - 4.11 symlink - 4.12 remove - 4.13 rmdir - 4.14 readlink - 4.15 open - 4.16 close - 4.17 ioctl - 4.18 rename - 4.19 readdir - 4.20 vget - 4.21 fsync - 4.22 inactive - 4.23 rdwr - 4.24 odymount - 4.25 ody_lookup - 4.26 ody_expand - 4.27 prefetch - 4.28 signal - - 5. The minicache and downcalls - - 5.1 INVALIDATE - 5.2 FLUSH - 5.3 PURGEUSER - 5.4 ZAPFILE - 5.5 ZAPDIR - 5.6 ZAPVNODE - 5.7 PURGEFID - 5.8 REPLACE - - 6. Initialization and cleanup - - 6.1 Requirements - - - ______________________________________________________________________ - 0wpage - - 11.. IInnttrroodduuccttiioonn - - - - A key component in the Coda Distributed File System is the cache - manager, _V_e_n_u_s. - - - When processes on a Coda enabled system access files in the Coda - filesystem, requests are directed at the filesystem layer in the - operating system. The operating system will communicate with Venus to - service the request for the process. Venus manages a persistent - client cache and makes remote procedure calls to Coda file servers and - related servers (such as authentication servers) to service these - requests it receives from the operating system. When Venus has - serviced a request it replies to the operating system with appropriate - return codes, and other data related to the request. Optionally the - kernel support for Coda may maintain a minicache of recently processed - requests to limit the number of interactions with Venus. Venus - possesses the facility to inform the kernel when elements from its - minicache are no longer valid. - - This document describes precisely this communication between the - kernel and Venus. The definitions of so called upcalls and downcalls - will be given with the format of the data they handle. We shall also - describe the semantic invariants resulting from the calls. - - Historically Coda was implemented in a BSD file system in Mach 2.6. - The interface between the kernel and Venus is very similar to the BSD - VFS interface. Similar functionality is provided, and the format of - the parameters and returned data is very similar to the BSD VFS. This - leads to an almost natural environment for implementing a kernel-level - filesystem driver for Coda in a BSD system. However, other operating - systems such as Linux and Windows 95 and NT have virtual filesystem - with different interfaces. - - To implement Coda on these systems some reverse engineering of the - Venus/Kernel protocol is necessary. Also it came to light that other - systems could profit significantly from certain small optimizations - and modifications to the protocol. To facilitate this work as well as - to make future ports easier, communication between Venus and the - kernel should be documented in great detail. This is the aim of this - document. - - 0wpage - - 22.. SSeerrvviicciinngg CCooddaa ffiilleessyysstteemm ccaallllss - - The service of a request for a Coda file system service originates in - a process PP which accessing a Coda file. It makes a system call which - traps to the OS kernel. Examples of such calls trapping to the kernel - are _r_e_a_d_, _w_r_i_t_e_, _o_p_e_n_, _c_l_o_s_e_, _c_r_e_a_t_e_, _m_k_d_i_r_, _r_m_d_i_r_, _c_h_m_o_d in a Unix - context. Similar calls exist in the Win32 environment, and are named - _C_r_e_a_t_e_F_i_l_e_, . - - Generally the operating system handles the request in a virtual - filesystem (VFS) layer, which is named I/O Manager in NT and IFS - manager in Windows 95. The VFS is responsible for partial processing - of the request and for locating the specific filesystem(s) which will - service parts of the request. Usually the information in the path - assists in locating the correct FS drivers. Sometimes after extensive - pre-processing, the VFS starts invoking exported routines in the FS - driver. This is the point where the FS specific processing of the - request starts, and here the Coda specific kernel code comes into - play. - - The FS layer for Coda must expose and implement several interfaces. - First and foremost the VFS must be able to make all necessary calls to - the Coda FS layer, so the Coda FS driver must expose the VFS interface - as applicable in the operating system. These differ very significantly - among operating systems, but share features such as facilities to - read/write and create and remove objects. The Coda FS layer services - such VFS requests by invoking one or more well defined services - offered by the cache manager Venus. When the replies from Venus have - come back to the FS driver, servicing of the VFS call continues and - finishes with a reply to the kernel's VFS. Finally the VFS layer - returns to the process. - - As a result of this design a basic interface exposed by the FS driver - must allow Venus to manage message traffic. In particular Venus must - be able to retrieve and place messages and to be notified of the - arrival of a new message. The notification must be through a mechanism - which does not block Venus since Venus must attend to other tasks even - when no messages are waiting or being processed. - - - - - - - Interfaces of the Coda FS Driver - - Furthermore the FS layer provides for a special path of communication - between a user process and Venus, called the pioctl interface. The - pioctl interface is used for Coda specific services, such as - requesting detailed information about the persistent cache managed by - Venus. Here the involvement of the kernel is minimal. It identifies - the calling process and passes the information on to Venus. When - Venus replies the response is passed back to the caller in unmodified - form. - - Finally Venus allows the kernel FS driver to cache the results from - certain services. This is done to avoid excessive context switches - and results in an efficient system. However, Venus may acquire - information, for example from the network which implies that cached - information must be flushed or replaced. Venus then makes a downcall - to the Coda FS layer to request flushes or updates in the cache. The - kernel FS driver handles such requests synchronously. - - Among these interfaces the VFS interface and the facility to place, - receive and be notified of messages are platform specific. We will - not go into the calls exported to the VFS layer but we will state the - requirements of the message exchange mechanism. - - 0wpage - - 33.. TThhee mmeessssaaggee llaayyeerr - - - - At the lowest level the communication between Venus and the FS driver - proceeds through messages. The synchronization between processes - requesting Coda file service and Venus relies on blocking and waking - up processes. The Coda FS driver processes VFS- and pioctl-requests - on behalf of a process P, creates messages for Venus, awaits replies - and finally returns to the caller. The implementation of the exchange - of messages is platform specific, but the semantics have (so far) - appeared to be generally applicable. Data buffers are created by the - FS Driver in kernel memory on behalf of P and copied to user memory in - Venus. - - The FS Driver while servicing P makes upcalls to Venus. Such an - upcall is dispatched to Venus by creating a message structure. The - structure contains the identification of P, the message sequence - number, the size of the request and a pointer to the data in kernel - memory for the request. Since the data buffer is re-used to hold the - reply from Venus, there is a field for the size of the reply. A flags - field is used in the message to precisely record the status of the - message. Additional platform dependent structures involve pointers to - determine the position of the message on queues and pointers to - synchronization objects. In the upcall routine the message structure - is filled in, flags are set to 0, and it is placed on the _p_e_n_d_i_n_g - queue. The routine calling upcall is responsible for allocating the - data buffer; its structure will be described in the next section. - - A facility must exist to notify Venus that the message has been - created, and implemented using available synchronization objects in - the OS. This notification is done in the upcall context of the process - P. When the message is on the pending queue, process P cannot proceed - in upcall. The (kernel mode) processing of P in the filesystem - request routine must be suspended until Venus has replied. Therefore - the calling thread in P is blocked in upcall. A pointer in the - message structure will locate the synchronization object on which P is - sleeping. - - Venus detects the notification that a message has arrived, and the FS - driver allow Venus to retrieve the message with a getmsg_from_kernel - call. This action finishes in the kernel by putting the message on the - queue of processing messages and setting flags to READ. Venus is - passed the contents of the data buffer. The getmsg_from_kernel call - now returns and Venus processes the request. - - At some later point the FS driver receives a message from Venus, - namely when Venus calls sendmsg_to_kernel. At this moment the Coda FS - driver looks at the contents of the message and decides if: - - - +o the message is a reply for a suspended thread P. If so it removes - the message from the processing queue and marks the message as - WRITTEN. Finally, the FS driver unblocks P (still in the kernel - mode context of Venus) and the sendmsg_to_kernel call returns to - Venus. The process P will be scheduled at some point and continues - processing its upcall with the data buffer replaced with the reply - from Venus. - - +o The message is a _d_o_w_n_c_a_l_l. A downcall is a request from Venus to - the FS Driver. The FS driver processes the request immediately - (usually a cache eviction or replacement) and when it finishes - sendmsg_to_kernel returns. - - Now P awakes and continues processing upcall. There are some - subtleties to take account of. First P will determine if it was woken - up in upcall by a signal from some other source (for example an - attempt to terminate P) or as is normally the case by Venus in its - sendmsg_to_kernel call. In the normal case, the upcall routine will - deallocate the message structure and return. The FS routine can proceed - with its processing. - - - - - - - - Sleeping and IPC arrangements - - In case P is woken up by a signal and not by Venus, it will first look - at the flags field. If the message is not yet READ, the process P can - handle its signal without notifying Venus. If Venus has READ, and - the request should not be processed, P can send Venus a signal message - to indicate that it should disregard the previous message. Such - signals are put in the queue at the head, and read first by Venus. If - the message is already marked as WRITTEN it is too late to stop the - processing. The VFS routine will now continue. (-- If a VFS request - involves more than one upcall, this can lead to complicated state, an - extra field "handle_signals" could be added in the message structure - to indicate points of no return have been passed.--) - - - - 33..11.. IImmpplleemmeennttaattiioonn ddeettaaiillss - - The Unix implementation of this mechanism has been through the - implementation of a character device associated with Coda. Venus - retrieves messages by doing a read on the device, replies are sent - with a write and notification is through the select system call on the - file descriptor for the device. The process P is kept waiting on an - interruptible wait queue object. - - In Windows NT and the DPMI Windows 95 implementation a DeviceIoControl - call is used. The DeviceIoControl call is designed to copy buffers - from user memory to kernel memory with OPCODES. The sendmsg_to_kernel - is issued as a synchronous call, while the getmsg_from_kernel call is - asynchronous. Windows EventObjects are used for notification of - message arrival. The process P is kept waiting on a KernelEvent - object in NT and a semaphore in Windows 95. - - 0wpage - - 44.. TThhee iinntteerrffaaccee aatt tthhee ccaallll lleevveell - - - This section describes the upcalls a Coda FS driver can make to Venus. - Each of these upcalls make use of two structures: inputArgs and - outputArgs. In pseudo BNF form the structures take the following - form: - - - struct inputArgs { - u_long opcode; - u_long unique; /* Keep multiple outstanding msgs distinct */ - u_short pid; /* Common to all */ - u_short pgid; /* Common to all */ - struct CodaCred cred; /* Common to all */ - - <union "in" of call dependent parts of inputArgs> - }; - - struct outputArgs { - u_long opcode; - u_long unique; /* Keep multiple outstanding msgs distinct */ - u_long result; - - <union "out" of call dependent parts of inputArgs> - }; - - - - Before going on let us elucidate the role of the various fields. The - inputArgs start with the opcode which defines the type of service - requested from Venus. There are approximately 30 upcalls at present - which we will discuss. The unique field labels the inputArg with a - unique number which will identify the message uniquely. A process and - process group id are passed. Finally the credentials of the caller - are included. - - Before delving into the specific calls we need to discuss a variety of - data structures shared by the kernel and Venus. - - - - - 44..11.. DDaattaa ssttrruuccttuurreess sshhaarreedd bbyy tthhee kkeerrnneell aanndd VVeennuuss - - - The CodaCred structure defines a variety of user and group ids as - they are set for the calling process. The vuid_t and vgid_t are 32 bit - unsigned integers. It also defines group membership in an array. On - Unix the CodaCred has proven sufficient to implement good security - semantics for Coda but the structure may have to undergo modification - for the Windows environment when these mature. - - struct CodaCred { - vuid_t cr_uid, cr_euid, cr_suid, cr_fsuid; /* Real, effective, set, fs uid */ - vgid_t cr_gid, cr_egid, cr_sgid, cr_fsgid; /* same for groups */ - vgid_t cr_groups[NGROUPS]; /* Group membership for caller */ - }; - - - - NNOOTTEE It is questionable if we need CodaCreds in Venus. Finally Venus - doesn't know about groups, although it does create files with the - default uid/gid. Perhaps the list of group membership is superfluous. - - - The next item is the fundamental identifier used to identify Coda - files, the ViceFid. A fid of a file uniquely defines a file or - directory in the Coda filesystem within a _c_e_l_l. (-- A _c_e_l_l is a - group of Coda servers acting under the aegis of a single system - control machine or SCM. See the Coda Administration manual for a - detailed description of the role of the SCM.--) - - - typedef struct ViceFid { - VolumeId Volume; - VnodeId Vnode; - Unique_t Unique; - } ViceFid; - - - - Each of the constituent fields: VolumeId, VnodeId and Unique_t are - unsigned 32 bit integers. We envisage that a further field will need - to be prefixed to identify the Coda cell; this will probably take the - form of a Ipv6 size IP address naming the Coda cell through DNS. - - The next important structure shared between Venus and the kernel is - the attributes of the file. The following structure is used to - exchange information. It has room for future extensions such as - support for device files (currently not present in Coda). - - - - - - - - - - - - - - - - - struct coda_timespec { - int64_t tv_sec; /* seconds */ - long tv_nsec; /* nanoseconds */ - }; - - struct coda_vattr { - enum coda_vtype va_type; /* vnode type (for create) */ - u_short va_mode; /* files access mode and type */ - short va_nlink; /* number of references to file */ - vuid_t va_uid; /* owner user id */ - vgid_t va_gid; /* owner group id */ - long va_fsid; /* file system id (dev for now) */ - long va_fileid; /* file id */ - u_quad_t va_size; /* file size in bytes */ - long va_blocksize; /* blocksize preferred for i/o */ - struct coda_timespec va_atime; /* time of last access */ - struct coda_timespec va_mtime; /* time of last modification */ - struct coda_timespec va_ctime; /* time file changed */ - u_long va_gen; /* generation number of file */ - u_long va_flags; /* flags defined for file */ - dev_t va_rdev; /* device special file represents */ - u_quad_t va_bytes; /* bytes of disk space held by file */ - u_quad_t va_filerev; /* file modification number */ - u_int va_vaflags; /* operations flags, see below */ - long va_spare; /* remain quad aligned */ - }; - - - - - 44..22.. TThhee ppiiooccttll iinntteerrffaaccee - - - Coda specific requests can be made by application through the pioctl - interface. The pioctl is implemented as an ordinary ioctl on a - fictitious file /coda/.CONTROL. The pioctl call opens this file, gets - a file handle and makes the ioctl call. Finally it closes the file. - - The kernel involvement in this is limited to providing the facility to - open and close and pass the ioctl message _a_n_d to verify that a path in - the pioctl data buffers is a file in a Coda filesystem. - - The kernel is handed a data packet of the form: - - struct { - const char *path; - struct ViceIoctl vidata; - int follow; - } data; - - - - where - - - struct ViceIoctl { - caddr_t in, out; /* Data to be transferred in, or out */ - short in_size; /* Size of input buffer <= 2K */ - short out_size; /* Maximum size of output buffer, <= 2K */ - }; - - - - The path must be a Coda file, otherwise the ioctl upcall will not be - made. - - NNOOTTEE The data structures and code are a mess. We need to clean this - up. - - We now proceed to document the individual calls: - - 0wpage - - 44..33.. rroooott - - - AArrgguummeennttss - - iinn empty - - oouutt - - struct cfs_root_out { - ViceFid VFid; - } cfs_root; - - - - DDeessccrriippttiioonn This call is made to Venus during the initialization of - the Coda filesystem. If the result is zero, the cfs_root structure - contains the ViceFid of the root of the Coda filesystem. If a non-zero - result is generated, its value is a platform dependent error code - indicating the difficulty Venus encountered in locating the root of - the Coda filesystem. - - 0wpage - - 44..44.. llooookkuupp - - - SSuummmmaarryy Find the ViceFid and type of an object in a directory if it - exists. - - AArrgguummeennttss - - iinn - - struct cfs_lookup_in { - ViceFid VFid; - char *name; /* Place holder for data. */ - } cfs_lookup; - - - - oouutt - - struct cfs_lookup_out { - ViceFid VFid; - int vtype; - } cfs_lookup; - - - - DDeessccrriippttiioonn This call is made to determine the ViceFid and filetype of - a directory entry. The directory entry requested carries name name - and Venus will search the directory identified by cfs_lookup_in.VFid. - The result may indicate that the name does not exist, or that - difficulty was encountered in finding it (e.g. due to disconnection). - If the result is zero, the field cfs_lookup_out.VFid contains the - targets ViceFid and cfs_lookup_out.vtype the coda_vtype giving the - type of object the name designates. - - The name of the object is an 8 bit character string of maximum length - CFS_MAXNAMLEN, currently set to 256 (including a 0 terminator.) - - It is extremely important to realize that Venus bitwise ors the field - cfs_lookup.vtype with CFS_NOCACHE to indicate that the object should - not be put in the kernel name cache. - - NNOOTTEE The type of the vtype is currently wrong. It should be - coda_vtype. Linux does not take note of CFS_NOCACHE. It should. - - 0wpage - - 44..55.. ggeettaattttrr - - - SSuummmmaarryy Get the attributes of a file. - - AArrgguummeennttss - - iinn - - struct cfs_getattr_in { - ViceFid VFid; - struct coda_vattr attr; /* XXXXX */ - } cfs_getattr; - - - - oouutt - - struct cfs_getattr_out { - struct coda_vattr attr; - } cfs_getattr; - - - - DDeessccrriippttiioonn This call returns the attributes of the file identified by - fid. - - EErrrroorrss Errors can occur if the object with fid does not exist, is - unaccessible or if the caller does not have permission to fetch - attributes. - - NNoottee Many kernel FS drivers (Linux, NT and Windows 95) need to acquire - the attributes as well as the Fid for the instantiation of an internal - "inode" or "FileHandle". A significant improvement in performance on - such systems could be made by combining the _l_o_o_k_u_p and _g_e_t_a_t_t_r calls - both at the Venus/kernel interaction level and at the RPC level. - - The vattr structure included in the input arguments is superfluous and - should be removed. - - 0wpage - - 44..66.. sseettaattttrr - - - SSuummmmaarryy Set the attributes of a file. - - AArrgguummeennttss - - iinn - - struct cfs_setattr_in { - ViceFid VFid; - struct coda_vattr attr; - } cfs_setattr; - - - - - oouutt - empty - - DDeessccrriippttiioonn The structure attr is filled with attributes to be changed - in BSD style. Attributes not to be changed are set to -1, apart from - vtype which is set to VNON. Other are set to the value to be assigned. - The only attributes which the FS driver may request to change are the - mode, owner, groupid, atime, mtime and ctime. The return value - indicates success or failure. - - EErrrroorrss A variety of errors can occur. The object may not exist, may - be inaccessible, or permission may not be granted by Venus. - - 0wpage - - 44..77.. aacccceessss - - - SSuummmmaarryy - - AArrgguummeennttss - - iinn - - struct cfs_access_in { - ViceFid VFid; - int flags; - } cfs_access; - - - - oouutt - empty - - DDeessccrriippttiioonn Verify if access to the object identified by VFid for - operations described by flags is permitted. The result indicates if - access will be granted. It is important to remember that Coda uses - ACLs to enforce protection and that ultimately the servers, not the - clients enforce the security of the system. The result of this call - will depend on whether a _t_o_k_e_n is held by the user. - - EErrrroorrss The object may not exist, or the ACL describing the protection - may not be accessible. - - 0wpage - - 44..88.. ccrreeaattee - - - SSuummmmaarryy Invoked to create a file - - AArrgguummeennttss - - iinn - - struct cfs_create_in { - ViceFid VFid; - struct coda_vattr attr; - int excl; - int mode; - char *name; /* Place holder for data. */ - } cfs_create; - - - - - oouutt - - struct cfs_create_out { - ViceFid VFid; - struct coda_vattr attr; - } cfs_create; - - - - DDeessccrriippttiioonn This upcall is invoked to request creation of a file. - The file will be created in the directory identified by VFid, its name - will be name, and the mode will be mode. If excl is set an error will - be returned if the file already exists. If the size field in attr is - set to zero the file will be truncated. The uid and gid of the file - are set by converting the CodaCred to a uid using a macro CRTOUID - (this macro is platform dependent). Upon success the VFid and - attributes of the file are returned. The Coda FS Driver will normally - instantiate a vnode, inode or file handle at kernel level for the new - object. - - - EErrrroorrss A variety of errors can occur. Permissions may be insufficient. - If the object exists and is not a file the error EISDIR is returned - under Unix. - - NNOOTTEE The packing of parameters is very inefficient and appears to - indicate confusion between the system call creat and the VFS operation - create. The VFS operation create is only called to create new objects. - This create call differs from the Unix one in that it is not invoked - to return a file descriptor. The truncate and exclusive options, - together with the mode, could simply be part of the mode as it is - under Unix. There should be no flags argument; this is used in open - (2) to return a file descriptor for READ or WRITE mode. - - The attributes of the directory should be returned too, since the size - and mtime changed. - - 0wpage - - 44..99.. mmkkddiirr - - - SSuummmmaarryy Create a new directory. - - AArrgguummeennttss - - iinn - - struct cfs_mkdir_in { - ViceFid VFid; - struct coda_vattr attr; - char *name; /* Place holder for data. */ - } cfs_mkdir; - - - - oouutt - - struct cfs_mkdir_out { - ViceFid VFid; - struct coda_vattr attr; - } cfs_mkdir; - - - - - DDeessccrriippttiioonn This call is similar to create but creates a directory. - Only the mode field in the input parameters is used for creation. - Upon successful creation, the attr returned contains the attributes of - the new directory. - - EErrrroorrss As for create. - - NNOOTTEE The input parameter should be changed to mode instead of - attributes. - - The attributes of the parent should be returned since the size and - mtime changes. - - 0wpage - - 44..1100.. lliinnkk - - - SSuummmmaarryy Create a link to an existing file. - - AArrgguummeennttss - - iinn - - struct cfs_link_in { - ViceFid sourceFid; /* cnode to link *to* */ - ViceFid destFid; /* Directory in which to place link */ - char *tname; /* Place holder for data. */ - } cfs_link; - - - - oouutt - empty - - DDeessccrriippttiioonn This call creates a link to the sourceFid in the directory - identified by destFid with name tname. The source must reside in the - target's parent, i.e. the source must be have parent destFid, i.e. Coda - does not support cross directory hard links. Only the return value is - relevant. It indicates success or the type of failure. - - EErrrroorrss The usual errors can occur.0wpage - - 44..1111.. ssyymmlliinnkk - - - SSuummmmaarryy create a symbolic link - - AArrgguummeennttss - - iinn - - struct cfs_symlink_in { - ViceFid VFid; /* Directory to put symlink in */ - char *srcname; - struct coda_vattr attr; - char *tname; - } cfs_symlink; - - - - oouutt - none - - DDeessccrriippttiioonn Create a symbolic link. The link is to be placed in the - directory identified by VFid and named tname. It should point to the - pathname srcname. The attributes of the newly created object are to - be set to attr. - - EErrrroorrss - - NNOOTTEE The attributes of the target directory should be returned since - its size changed. - - 0wpage - - 44..1122.. rreemmoovvee - - - SSuummmmaarryy Remove a file - - AArrgguummeennttss - - iinn - - struct cfs_remove_in { - ViceFid VFid; - char *name; /* Place holder for data. */ - } cfs_remove; - - - - oouutt - none - - DDeessccrriippttiioonn Remove file named cfs_remove_in.name in directory - identified by VFid. - - EErrrroorrss - - NNOOTTEE The attributes of the directory should be returned since its - mtime and size may change. - - 0wpage - - 44..1133.. rrmmddiirr - - - SSuummmmaarryy Remove a directory - - AArrgguummeennttss - - iinn - - struct cfs_rmdir_in { - ViceFid VFid; - char *name; /* Place holder for data. */ - } cfs_rmdir; - - - - oouutt - none - - DDeessccrriippttiioonn Remove the directory with name name from the directory - identified by VFid. - - EErrrroorrss - - NNOOTTEE The attributes of the parent directory should be returned since - its mtime and size may change. - - 0wpage - - 44..1144.. rreeaaddlliinnkk - - - SSuummmmaarryy Read the value of a symbolic link. - - AArrgguummeennttss - - iinn - - struct cfs_readlink_in { - ViceFid VFid; - } cfs_readlink; - - - - oouutt - - struct cfs_readlink_out { - int count; - caddr_t data; /* Place holder for data. */ - } cfs_readlink; - - - - DDeessccrriippttiioonn This routine reads the contents of symbolic link - identified by VFid into the buffer data. The buffer data must be able - to hold any name up to CFS_MAXNAMLEN (PATH or NAM??). - - EErrrroorrss No unusual errors. - - 0wpage - - 44..1155.. ooppeenn - - - SSuummmmaarryy Open a file. - - AArrgguummeennttss - - iinn - - struct cfs_open_in { - ViceFid VFid; - int flags; - } cfs_open; - - - - oouutt - - struct cfs_open_out { - dev_t dev; - ino_t inode; - } cfs_open; - - - - DDeessccrriippttiioonn This request asks Venus to place the file identified by - VFid in its cache and to note that the calling process wishes to open - it with flags as in open(2). The return value to the kernel differs - for Unix and Windows systems. For Unix systems the Coda FS Driver is - informed of the device and inode number of the container file in the - fields dev and inode. For Windows the path of the container file is - returned to the kernel. - EErrrroorrss - - NNOOTTEE Currently the cfs_open_out structure is not properly adapted to - deal with the Windows case. It might be best to implement two - upcalls, one to open aiming at a container file name, the other at a - container file inode. - - 0wpage - - 44..1166.. cclloossee - - - SSuummmmaarryy Close a file, update it on the servers. - - AArrgguummeennttss - - iinn - - struct cfs_close_in { - ViceFid VFid; - int flags; - } cfs_close; - - - - oouutt - none - - DDeessccrriippttiioonn Close the file identified by VFid. - - EErrrroorrss - - NNOOTTEE The flags argument is bogus and not used. However, Venus' code - has room to deal with an execp input field, probably this field should - be used to inform Venus that the file was closed but is still memory - mapped for execution. There are comments about fetching versus not - fetching the data in Venus vproc_vfscalls. This seems silly. If a - file is being closed, the data in the container file is to be the new - data. Here again the execp flag might be in play to create confusion: - currently Venus might think a file can be flushed from the cache when - it is still memory mapped. This needs to be understood. - - 0wpage - - 44..1177.. iiooccttll - - - SSuummmmaarryy Do an ioctl on a file. This includes the pioctl interface. - - AArrgguummeennttss - - iinn - - struct cfs_ioctl_in { - ViceFid VFid; - int cmd; - int len; - int rwflag; - char *data; /* Place holder for data. */ - } cfs_ioctl; - - - - oouutt - - - struct cfs_ioctl_out { - int len; - caddr_t data; /* Place holder for data. */ - } cfs_ioctl; - - - - DDeessccrriippttiioonn Do an ioctl operation on a file. The command, len and - data arguments are filled as usual. flags is not used by Venus. - - EErrrroorrss - - NNOOTTEE Another bogus parameter. flags is not used. What is the - business about PREFETCHING in the Venus code? - - - 0wpage - - 44..1188.. rreennaammee - - - SSuummmmaarryy Rename a fid. - - AArrgguummeennttss - - iinn - - struct cfs_rename_in { - ViceFid sourceFid; - char *srcname; - ViceFid destFid; - char *destname; - } cfs_rename; - - - - oouutt - none - - DDeessccrriippttiioonn Rename the object with name srcname in directory - sourceFid to destname in destFid. It is important that the names - srcname and destname are 0 terminated strings. Strings in Unix - kernels are not always null terminated. - - EErrrroorrss - - 0wpage - - 44..1199.. rreeaaddddiirr - - - SSuummmmaarryy Read directory entries. - - AArrgguummeennttss - - iinn - - struct cfs_readdir_in { - ViceFid VFid; - int count; - int offset; - } cfs_readdir; - - - - - oouutt - - struct cfs_readdir_out { - int size; - caddr_t data; /* Place holder for data. */ - } cfs_readdir; - - - - DDeessccrriippttiioonn Read directory entries from VFid starting at offset and - read at most count bytes. Returns the data in data and returns - the size in size. - - EErrrroorrss - - NNOOTTEE This call is not used. Readdir operations exploit container - files. We will re-evaluate this during the directory revamp which is - about to take place. - - 0wpage - - 44..2200.. vvggeett - - - SSuummmmaarryy instructs Venus to do an FSDB->Get. - - AArrgguummeennttss - - iinn - - struct cfs_vget_in { - ViceFid VFid; - } cfs_vget; - - - - oouutt - - struct cfs_vget_out { - ViceFid VFid; - int vtype; - } cfs_vget; - - - - DDeessccrriippttiioonn This upcall asks Venus to do a get operation on an fsobj - labelled by VFid. - - EErrrroorrss - - NNOOTTEE This operation is not used. However, it is extremely useful - since it can be used to deal with read/write memory mapped files. - These can be "pinned" in the Venus cache using vget and released with - inactive. - - 0wpage - - 44..2211.. ffssyynncc - - - SSuummmmaarryy Tell Venus to update the RVM attributes of a file. - - AArrgguummeennttss - - iinn - - struct cfs_fsync_in { - ViceFid VFid; - } cfs_fsync; - - - - oouutt - none - - DDeessccrriippttiioonn Ask Venus to update RVM attributes of object VFid. This - should be called as part of kernel level fsync type calls. The - result indicates if the syncing was successful. - - EErrrroorrss - - NNOOTTEE Linux does not implement this call. It should. - - 0wpage - - 44..2222.. iinnaaccttiivvee - - - SSuummmmaarryy Tell Venus a vnode is no longer in use. - - AArrgguummeennttss - - iinn - - struct cfs_inactive_in { - ViceFid VFid; - } cfs_inactive; - - - - oouutt - none - - DDeessccrriippttiioonn This operation returns EOPNOTSUPP. - - EErrrroorrss - - NNOOTTEE This should perhaps be removed. - - 0wpage - - 44..2233.. rrddwwrr - - - SSuummmmaarryy Read or write from a file - - AArrgguummeennttss - - iinn - - struct cfs_rdwr_in { - ViceFid VFid; - int rwflag; - int count; - int offset; - int ioflag; - caddr_t data; /* Place holder for data. */ - } cfs_rdwr; - - - - - oouutt - - struct cfs_rdwr_out { - int rwflag; - int count; - caddr_t data; /* Place holder for data. */ - } cfs_rdwr; - - - - DDeessccrriippttiioonn This upcall asks Venus to read or write from a file. - - EErrrroorrss - - NNOOTTEE It should be removed since it is against the Coda philosophy that - read/write operations never reach Venus. I have been told the - operation does not work. It is not currently used. - - - 0wpage - - 44..2244.. ooddyymmoouunntt - - - SSuummmmaarryy Allows mounting multiple Coda "filesystems" on one Unix mount - point. - - AArrgguummeennttss - - iinn - - struct ody_mount_in { - char *name; /* Place holder for data. */ - } ody_mount; - - - - oouutt - - struct ody_mount_out { - ViceFid VFid; - } ody_mount; - - - - DDeessccrriippttiioonn Asks Venus to return the rootfid of a Coda system named - name. The fid is returned in VFid. - - EErrrroorrss - - NNOOTTEE This call was used by David for dynamic sets. It should be - removed since it causes a jungle of pointers in the VFS mounting area. - It is not used by Coda proper. Call is not implemented by Venus. - - 0wpage - - 44..2255.. ooddyy__llooookkuupp - - - SSuummmmaarryy Looks up something. - - AArrgguummeennttss - - iinn irrelevant - - - oouutt - irrelevant - - DDeessccrriippttiioonn - - EErrrroorrss - - NNOOTTEE Gut it. Call is not implemented by Venus. - - 0wpage - - 44..2266.. ooddyy__eexxppaanndd - - - SSuummmmaarryy expands something in a dynamic set. - - AArrgguummeennttss - - iinn irrelevant - - oouutt - irrelevant - - DDeessccrriippttiioonn - - EErrrroorrss - - NNOOTTEE Gut it. Call is not implemented by Venus. - - 0wpage - - 44..2277.. pprreeffeettcchh - - - SSuummmmaarryy Prefetch a dynamic set. - - AArrgguummeennttss - - iinn Not documented. - - oouutt - Not documented. - - DDeessccrriippttiioonn Venus worker.cc has support for this call, although it is - noted that it doesn't work. Not surprising, since the kernel does not - have support for it. (ODY_PREFETCH is not a defined operation). - - EErrrroorrss - - NNOOTTEE Gut it. It isn't working and isn't used by Coda. - - - 0wpage - - 44..2288.. ssiiggnnaall - - - SSuummmmaarryy Send Venus a signal about an upcall. - - AArrgguummeennttss - - iinn none - - oouutt - not applicable. - - DDeessccrriippttiioonn This is an out-of-band upcall to Venus to inform Venus - that the calling process received a signal after Venus read the - message from the input queue. Venus is supposed to clean up the - operation. - - EErrrroorrss No reply is given. - - NNOOTTEE We need to better understand what Venus needs to clean up and if - it is doing this correctly. Also we need to handle multiple upcall - per system call situations correctly. It would be important to know - what state changes in Venus take place after an upcall for which the - kernel is responsible for notifying Venus to clean up (e.g. open - definitely is such a state change, but many others are maybe not). - - 0wpage - - 55.. TThhee mmiinniiccaacchhee aanndd ddoowwnnccaallllss - - - The Coda FS Driver can cache results of lookup and access upcalls, to - limit the frequency of upcalls. Upcalls carry a price since a process - context switch needs to take place. The counterpart of caching the - information is that Venus will notify the FS Driver that cached - entries must be flushed or renamed. - - The kernel code generally has to maintain a structure which links the - internal file handles (called vnodes in BSD, inodes in Linux and - FileHandles in Windows) with the ViceFid's which Venus maintains. The - reason is that frequent translations back and forth are needed in - order to make upcalls and use the results of upcalls. Such linking - objects are called ccnnooddeess. - - The current minicache implementations have cache entries which record - the following: - - 1. the name of the file - - 2. the cnode of the directory containing the object - - 3. a list of CodaCred's for which the lookup is permitted. - - 4. the cnode of the object - - The lookup call in the Coda FS Driver may request the cnode of the - desired object from the cache, by passing its name, directory and the - CodaCred's of the caller. The cache will return the cnode or indicate - that it cannot be found. The Coda FS Driver must be careful to - invalidate cache entries when it modifies or removes objects. - - When Venus obtains information that indicates that cache entries are - no longer valid, it will make a downcall to the kernel. Downcalls are - intercepted by the Coda FS Driver and lead to cache invalidations of - the kind described below. The Coda FS Driver does not return an error - unless the downcall data could not be read into kernel memory. - - - 55..11.. IINNVVAALLIIDDAATTEE - - - No information is available on this call. - - - 55..22.. FFLLUUSSHH - - - - AArrgguummeennttss None - - SSuummmmaarryy Flush the name cache entirely. - - DDeessccrriippttiioonn Venus issues this call upon startup and when it dies. This - is to prevent stale cache information being held. Some operating - systems allow the kernel name cache to be switched off dynamically. - When this is done, this downcall is made. - - - 55..33.. PPUURRGGEEUUSSEERR - - - AArrgguummeennttss - - struct cfs_purgeuser_out {/* CFS_PURGEUSER is a venus->kernel call */ - struct CodaCred cred; - } cfs_purgeuser; - - - - DDeessccrriippttiioonn Remove all entries in the cache carrying the Cred. This - call is issued when tokens for a user expire or are flushed. - - - 55..44.. ZZAAPPFFIILLEE - - - AArrgguummeennttss - - struct cfs_zapfile_out { /* CFS_ZAPFILE is a venus->kernel call */ - ViceFid CodaFid; - } cfs_zapfile; - - - - DDeessccrriippttiioonn Remove all entries which have the (dir vnode, name) pair. - This is issued as a result of an invalidation of cached attributes of - a vnode. - - NNOOTTEE Call is not named correctly in NetBSD and Mach. The minicache - zapfile routine takes different arguments. Linux does not implement - the invalidation of attributes correctly. - - - - 55..55.. ZZAAPPDDIIRR - - - AArrgguummeennttss - - struct cfs_zapdir_out { /* CFS_ZAPDIR is a venus->kernel call */ - ViceFid CodaFid; - } cfs_zapdir; - - - - DDeessccrriippttiioonn Remove all entries in the cache lying in a directory - CodaFid, and all children of this directory. This call is issued when - Venus receives a callback on the directory. - - - 55..66.. ZZAAPPVVNNOODDEE - - - - AArrgguummeennttss - - struct cfs_zapvnode_out { /* CFS_ZAPVNODE is a venus->kernel call */ - struct CodaCred cred; - ViceFid VFid; - } cfs_zapvnode; - - - - DDeessccrriippttiioonn Remove all entries in the cache carrying the cred and VFid - as in the arguments. This downcall is probably never issued. - - - 55..77.. PPUURRGGEEFFIIDD - - - SSuummmmaarryy - - AArrgguummeennttss - - struct cfs_purgefid_out { /* CFS_PURGEFID is a venus->kernel call */ - ViceFid CodaFid; - } cfs_purgefid; - - - - DDeessccrriippttiioonn Flush the attribute for the file. If it is a dir (odd - vnode), purge its children from the namecache and remove the file from the - namecache. - - - - 55..88.. RREEPPLLAACCEE - - - SSuummmmaarryy Replace the Fid's for a collection of names. - - AArrgguummeennttss - - struct cfs_replace_out { /* cfs_replace is a venus->kernel call */ - ViceFid NewFid; - ViceFid OldFid; - } cfs_replace; - - - - DDeessccrriippttiioonn This routine replaces a ViceFid in the name cache with - another. It is added to allow Venus during reintegration to replace - locally allocated temp fids while disconnected with global fids even - when the reference counts on those fids are not zero. - - 0wpage - - 66.. IInniittiiaalliizzaattiioonn aanndd cclleeaannuupp - - - This section gives brief hints as to desirable features for the Coda - FS Driver at startup and upon shutdown or Venus failures. Before - entering the discussion it is useful to repeat that the Coda FS Driver - maintains the following data: - - - 1. message queues - - 2. cnodes - - 3. name cache entries - - The name cache entries are entirely private to the driver, so they - can easily be manipulated. The message queues will generally have - clear points of initialization and destruction. The cnodes are - much more delicate. User processes hold reference counts in Coda - filesystems and it can be difficult to clean up the cnodes. - - It can expect requests through: - - 1. the message subsystem - - 2. the VFS layer - - 3. pioctl interface - - Currently the _p_i_o_c_t_l passes through the VFS for Coda so we can - treat these similarly. - - - 66..11.. RReeqquuiirreemmeennttss - - - The following requirements should be accommodated: - - 1. The message queues should have open and close routines. On Unix - the opening of the character devices are such routines. - - +o Before opening, no messages can be placed. - - +o Opening will remove any old messages still pending. - - +o Close will notify any sleeping processes that their upcall cannot - be completed. - - +o Close will free all memory allocated by the message queues. - - - 2. At open the namecache shall be initialized to empty state. - - 3. Before the message queues are open, all VFS operations will fail. - Fortunately this can be achieved by making sure than mounting the - Coda filesystem cannot succeed before opening. - - 4. After closing of the queues, no VFS operations can succeed. Here - one needs to be careful, since a few operations (lookup, - read/write, readdir) can proceed without upcalls. These must be - explicitly blocked. - - 5. Upon closing the namecache shall be flushed and disabled. - - 6. All memory held by cnodes can be freed without relying on upcalls. - - 7. Unmounting the file system can be done without relying on upcalls. - - 8. Mounting the Coda filesystem should fail gracefully if Venus cannot - get the rootfid or the attributes of the rootfid. The latter is - best implemented by Venus fetching these objects before attempting - to mount. - - NNOOTTEE NetBSD in particular but also Linux have not implemented the - above requirements fully. For smooth operation this needs to be - corrected. - - -
diff --git a/Documentation/filesystems/configfs.rst b/Documentation/filesystems/configfs.rst new file mode 100644 index 0000000..f894195 --- /dev/null +++ b/Documentation/filesystems/configfs.rst
@@ -0,0 +1,535 @@ +======================================================= +Configfs - Userspace-driven Kernel Object Configuration +======================================================= + +Joel Becker <joel.becker@oracle.com> + +Updated: 31 March 2005 + +Copyright (c) 2005 Oracle Corporation, + Joel Becker <joel.becker@oracle.com> + + +What is configfs? +================= + +configfs is a ram-based filesystem that provides the converse of +sysfs's functionality. Where sysfs is a filesystem-based view of +kernel objects, configfs is a filesystem-based manager of kernel +objects, or config_items. + +With sysfs, an object is created in kernel (for example, when a device +is discovered) and it is registered with sysfs. Its attributes then +appear in sysfs, allowing userspace to read the attributes via +readdir(3)/read(2). It may allow some attributes to be modified via +write(2). The important point is that the object is created and +destroyed in kernel, the kernel controls the lifecycle of the sysfs +representation, and sysfs is merely a window on all this. + +A configfs config_item is created via an explicit userspace operation: +mkdir(2). It is destroyed via rmdir(2). The attributes appear at +mkdir(2) time, and can be read or modified via read(2) and write(2). +As with sysfs, readdir(3) queries the list of items and/or attributes. +symlink(2) can be used to group items together. Unlike sysfs, the +lifetime of the representation is completely driven by userspace. The +kernel modules backing the items must respond to this. + +Both sysfs and configfs can and should exist together on the same +system. One is not a replacement for the other. + +Using configfs +============== + +configfs can be compiled as a module or into the kernel. You can access +it by doing:: + + mount -t configfs none /config + +The configfs tree will be empty unless client modules are also loaded. +These are modules that register their item types with configfs as +subsystems. Once a client subsystem is loaded, it will appear as a +subdirectory (or more than one) under /config. Like sysfs, the +configfs tree is always there, whether mounted on /config or not. + +An item is created via mkdir(2). The item's attributes will also +appear at this time. readdir(3) can determine what the attributes are, +read(2) can query their default values, and write(2) can store new +values. Don't mix more than one attribute in one attribute file. + +There are two types of configfs attributes: + +* Normal attributes, which similar to sysfs attributes, are small ASCII text + files, with a maximum size of one page (PAGE_SIZE, 4096 on i386). Preferably + only one value per file should be used, and the same caveats from sysfs apply. + Configfs expects write(2) to store the entire buffer at once. When writing to + normal configfs attributes, userspace processes should first read the entire + file, modify the portions they wish to change, and then write the entire + buffer back. + +* Binary attributes, which are somewhat similar to sysfs binary attributes, + but with a few slight changes to semantics. The PAGE_SIZE limitation does not + apply, but the whole binary item must fit in single kernel vmalloc'ed buffer. + The write(2) calls from user space are buffered, and the attributes' + write_bin_attribute method will be invoked on the final close, therefore it is + imperative for user-space to check the return code of close(2) in order to + verify that the operation finished successfully. + To avoid a malicious user OOMing the kernel, there's a per-binary attribute + maximum buffer value. + +When an item needs to be destroyed, remove it with rmdir(2). An +item cannot be destroyed if any other item has a link to it (via +symlink(2)). Links can be removed via unlink(2). + +Configuring FakeNBD: an Example +=============================== + +Imagine there's a Network Block Device (NBD) driver that allows you to +access remote block devices. Call it FakeNBD. FakeNBD uses configfs +for its configuration. Obviously, there will be a nice program that +sysadmins use to configure FakeNBD, but somehow that program has to tell +the driver about it. Here's where configfs comes in. + +When the FakeNBD driver is loaded, it registers itself with configfs. +readdir(3) sees this just fine:: + + # ls /config + fakenbd + +A fakenbd connection can be created with mkdir(2). The name is +arbitrary, but likely the tool will make some use of the name. Perhaps +it is a uuid or a disk name:: + + # mkdir /config/fakenbd/disk1 + # ls /config/fakenbd/disk1 + target device rw + +The target attribute contains the IP address of the server FakeNBD will +connect to. The device attribute is the device on the server. +Predictably, the rw attribute determines whether the connection is +read-only or read-write:: + + # echo 10.0.0.1 > /config/fakenbd/disk1/target + # echo /dev/sda1 > /config/fakenbd/disk1/device + # echo 1 > /config/fakenbd/disk1/rw + +That's it. That's all there is. Now the device is configured, via the +shell no less. + +Coding With configfs +==================== + +Every object in configfs is a config_item. A config_item reflects an +object in the subsystem. It has attributes that match values on that +object. configfs handles the filesystem representation of that object +and its attributes, allowing the subsystem to ignore all but the +basic show/store interaction. + +Items are created and destroyed inside a config_group. A group is a +collection of items that share the same attributes and operations. +Items are created by mkdir(2) and removed by rmdir(2), but configfs +handles that. The group has a set of operations to perform these tasks + +A subsystem is the top level of a client module. During initialization, +the client module registers the subsystem with configfs, the subsystem +appears as a directory at the top of the configfs filesystem. A +subsystem is also a config_group, and can do everything a config_group +can. + +struct config_item +================== + +:: + + struct config_item { + char *ci_name; + char ci_namebuf[UOBJ_NAME_LEN]; + struct kref ci_kref; + struct list_head ci_entry; + struct config_item *ci_parent; + struct config_group *ci_group; + struct config_item_type *ci_type; + struct dentry *ci_dentry; + }; + + void config_item_init(struct config_item *); + void config_item_init_type_name(struct config_item *, + const char *name, + struct config_item_type *type); + struct config_item *config_item_get(struct config_item *); + void config_item_put(struct config_item *); + +Generally, struct config_item is embedded in a container structure, a +structure that actually represents what the subsystem is doing. The +config_item portion of that structure is how the object interacts with +configfs. + +Whether statically defined in a source file or created by a parent +config_group, a config_item must have one of the _init() functions +called on it. This initializes the reference count and sets up the +appropriate fields. + +All users of a config_item should have a reference on it via +config_item_get(), and drop the reference when they are done via +config_item_put(). + +By itself, a config_item cannot do much more than appear in configfs. +Usually a subsystem wants the item to display and/or store attributes, +among other things. For that, it needs a type. + +struct config_item_type +======================= + +:: + + struct configfs_item_operations { + void (*release)(struct config_item *); + int (*allow_link)(struct config_item *src, + struct config_item *target); + void (*drop_link)(struct config_item *src, + struct config_item *target); + }; + + struct config_item_type { + struct module *ct_owner; + struct configfs_item_operations *ct_item_ops; + struct configfs_group_operations *ct_group_ops; + struct configfs_attribute **ct_attrs; + struct configfs_bin_attribute **ct_bin_attrs; + }; + +The most basic function of a config_item_type is to define what +operations can be performed on a config_item. All items that have been +allocated dynamically will need to provide the ct_item_ops->release() +method. This method is called when the config_item's reference count +reaches zero. + +struct configfs_attribute +========================= + +:: + + struct configfs_attribute { + char *ca_name; + struct module *ca_owner; + umode_t ca_mode; + ssize_t (*show)(struct config_item *, char *); + ssize_t (*store)(struct config_item *, const char *, size_t); + }; + +When a config_item wants an attribute to appear as a file in the item's +configfs directory, it must define a configfs_attribute describing it. +It then adds the attribute to the NULL-terminated array +config_item_type->ct_attrs. When the item appears in configfs, the +attribute file will appear with the configfs_attribute->ca_name +filename. configfs_attribute->ca_mode specifies the file permissions. + +If an attribute is readable and provides a ->show method, that method will +be called whenever userspace asks for a read(2) on the attribute. If an +attribute is writable and provides a ->store method, that method will be +be called whenever userspace asks for a write(2) on the attribute. + +struct configfs_bin_attribute +============================= + +:: + + struct configfs_bin_attribute { + struct configfs_attribute cb_attr; + void *cb_private; + size_t cb_max_size; + }; + +The binary attribute is used when the one needs to use binary blob to +appear as the contents of a file in the item's configfs directory. +To do so add the binary attribute to the NULL-terminated array +config_item_type->ct_bin_attrs, and the item appears in configfs, the +attribute file will appear with the configfs_bin_attribute->cb_attr.ca_name +filename. configfs_bin_attribute->cb_attr.ca_mode specifies the file +permissions. +The cb_private member is provided for use by the driver, while the +cb_max_size member specifies the maximum amount of vmalloc buffer +to be used. + +If binary attribute is readable and the config_item provides a +ct_item_ops->read_bin_attribute() method, that method will be called +whenever userspace asks for a read(2) on the attribute. The converse +will happen for write(2). The reads/writes are bufferred so only a +single read/write will occur; the attributes' need not concern itself +with it. + +struct config_group +=================== + +A config_item cannot live in a vacuum. The only way one can be created +is via mkdir(2) on a config_group. This will trigger creation of a +child item:: + + struct config_group { + struct config_item cg_item; + struct list_head cg_children; + struct configfs_subsystem *cg_subsys; + struct list_head default_groups; + struct list_head group_entry; + }; + + void config_group_init(struct config_group *group); + void config_group_init_type_name(struct config_group *group, + const char *name, + struct config_item_type *type); + + +The config_group structure contains a config_item. Properly configuring +that item means that a group can behave as an item in its own right. +However, it can do more: it can create child items or groups. This is +accomplished via the group operations specified on the group's +config_item_type:: + + struct configfs_group_operations { + struct config_item *(*make_item)(struct config_group *group, + const char *name); + struct config_group *(*make_group)(struct config_group *group, + const char *name); + int (*commit_item)(struct config_item *item); + void (*disconnect_notify)(struct config_group *group, + struct config_item *item); + void (*drop_item)(struct config_group *group, + struct config_item *item); + }; + +A group creates child items by providing the +ct_group_ops->make_item() method. If provided, this method is called from +mkdir(2) in the group's directory. The subsystem allocates a new +config_item (or more likely, its container structure), initializes it, +and returns it to configfs. Configfs will then populate the filesystem +tree to reflect the new item. + +If the subsystem wants the child to be a group itself, the subsystem +provides ct_group_ops->make_group(). Everything else behaves the same, +using the group _init() functions on the group. + +Finally, when userspace calls rmdir(2) on the item or group, +ct_group_ops->drop_item() is called. As a config_group is also a +config_item, it is not necessary for a separate drop_group() method. +The subsystem must config_item_put() the reference that was initialized +upon item allocation. If a subsystem has no work to do, it may omit +the ct_group_ops->drop_item() method, and configfs will call +config_item_put() on the item on behalf of the subsystem. + +Important: + drop_item() is void, and as such cannot fail. When rmdir(2) + is called, configfs WILL remove the item from the filesystem tree + (assuming that it has no children to keep it busy). The subsystem is + responsible for responding to this. If the subsystem has references to + the item in other threads, the memory is safe. It may take some time + for the item to actually disappear from the subsystem's usage. But it + is gone from configfs. + +When drop_item() is called, the item's linkage has already been torn +down. It no longer has a reference on its parent and has no place in +the item hierarchy. If a client needs to do some cleanup before this +teardown happens, the subsystem can implement the +ct_group_ops->disconnect_notify() method. The method is called after +configfs has removed the item from the filesystem view but before the +item is removed from its parent group. Like drop_item(), +disconnect_notify() is void and cannot fail. Client subsystems should +not drop any references here, as they still must do it in drop_item(). + +A config_group cannot be removed while it still has child items. This +is implemented in the configfs rmdir(2) code. ->drop_item() will not be +called, as the item has not been dropped. rmdir(2) will fail, as the +directory is not empty. + +struct configfs_subsystem +========================= + +A subsystem must register itself, usually at module_init time. This +tells configfs to make the subsystem appear in the file tree:: + + struct configfs_subsystem { + struct config_group su_group; + struct mutex su_mutex; + }; + + int configfs_register_subsystem(struct configfs_subsystem *subsys); + void configfs_unregister_subsystem(struct configfs_subsystem *subsys); + +A subsystem consists of a toplevel config_group and a mutex. +The group is where child config_items are created. For a subsystem, +this group is usually defined statically. Before calling +configfs_register_subsystem(), the subsystem must have initialized the +group via the usual group _init() functions, and it must also have +initialized the mutex. + +When the register call returns, the subsystem is live, and it +will be visible via configfs. At that point, mkdir(2) can be called and +the subsystem must be ready for it. + +An Example +========== + +The best example of these basic concepts is the simple_children +subsystem/group and the simple_child item in +samples/configfs/configfs_sample.c. It shows a trivial object displaying +and storing an attribute, and a simple group creating and destroying +these children. + +Hierarchy Navigation and the Subsystem Mutex +============================================ + +There is an extra bonus that configfs provides. The config_groups and +config_items are arranged in a hierarchy due to the fact that they +appear in a filesystem. A subsystem is NEVER to touch the filesystem +parts, but the subsystem might be interested in this hierarchy. For +this reason, the hierarchy is mirrored via the config_group->cg_children +and config_item->ci_parent structure members. + +A subsystem can navigate the cg_children list and the ci_parent pointer +to see the tree created by the subsystem. This can race with configfs' +management of the hierarchy, so configfs uses the subsystem mutex to +protect modifications. Whenever a subsystem wants to navigate the +hierarchy, it must do so under the protection of the subsystem +mutex. + +A subsystem will be prevented from acquiring the mutex while a newly +allocated item has not been linked into this hierarchy. Similarly, it +will not be able to acquire the mutex while a dropping item has not +yet been unlinked. This means that an item's ci_parent pointer will +never be NULL while the item is in configfs, and that an item will only +be in its parent's cg_children list for the same duration. This allows +a subsystem to trust ci_parent and cg_children while they hold the +mutex. + +Item Aggregation Via symlink(2) +=============================== + +configfs provides a simple group via the group->item parent/child +relationship. Often, however, a larger environment requires aggregation +outside of the parent/child connection. This is implemented via +symlink(2). + +A config_item may provide the ct_item_ops->allow_link() and +ct_item_ops->drop_link() methods. If the ->allow_link() method exists, +symlink(2) may be called with the config_item as the source of the link. +These links are only allowed between configfs config_items. Any +symlink(2) attempt outside the configfs filesystem will be denied. + +When symlink(2) is called, the source config_item's ->allow_link() +method is called with itself and a target item. If the source item +allows linking to target item, it returns 0. A source item may wish to +reject a link if it only wants links to a certain type of object (say, +in its own subsystem). + +When unlink(2) is called on the symbolic link, the source item is +notified via the ->drop_link() method. Like the ->drop_item() method, +this is a void function and cannot return failure. The subsystem is +responsible for responding to the change. + +A config_item cannot be removed while it links to any other item, nor +can it be removed while an item links to it. Dangling symlinks are not +allowed in configfs. + +Automatically Created Subgroups +=============================== + +A new config_group may want to have two types of child config_items. +While this could be codified by magic names in ->make_item(), it is much +more explicit to have a method whereby userspace sees this divergence. + +Rather than have a group where some items behave differently than +others, configfs provides a method whereby one or many subgroups are +automatically created inside the parent at its creation. Thus, +mkdir("parent") results in "parent", "parent/subgroup1", up through +"parent/subgroupN". Items of type 1 can now be created in +"parent/subgroup1", and items of type N can be created in +"parent/subgroupN". + +These automatic subgroups, or default groups, do not preclude other +children of the parent group. If ct_group_ops->make_group() exists, +other child groups can be created on the parent group directly. + +A configfs subsystem specifies default groups by adding them using the +configfs_add_default_group() function to the parent config_group +structure. Each added group is populated in the configfs tree at the same +time as the parent group. Similarly, they are removed at the same time +as the parent. No extra notification is provided. When a ->drop_item() +method call notifies the subsystem the parent group is going away, it +also means every default group child associated with that parent group. + +As a consequence of this, default groups cannot be removed directly via +rmdir(2). They also are not considered when rmdir(2) on the parent +group is checking for children. + +Dependent Subsystems +==================== + +Sometimes other drivers depend on particular configfs items. For +example, ocfs2 mounts depend on a heartbeat region item. If that +region item is removed with rmdir(2), the ocfs2 mount must BUG or go +readonly. Not happy. + +configfs provides two additional API calls: configfs_depend_item() and +configfs_undepend_item(). A client driver can call +configfs_depend_item() on an existing item to tell configfs that it is +depended on. configfs will then return -EBUSY from rmdir(2) for that +item. When the item is no longer depended on, the client driver calls +configfs_undepend_item() on it. + +These API cannot be called underneath any configfs callbacks, as +they will conflict. They can block and allocate. A client driver +probably shouldn't calling them of its own gumption. Rather it should +be providing an API that external subsystems call. + +How does this work? Imagine the ocfs2 mount process. When it mounts, +it asks for a heartbeat region item. This is done via a call into the +heartbeat code. Inside the heartbeat code, the region item is looked +up. Here, the heartbeat code calls configfs_depend_item(). If it +succeeds, then heartbeat knows the region is safe to give to ocfs2. +If it fails, it was being torn down anyway, and heartbeat can gracefully +pass up an error. + +Committable Items +================= + +Note: + Committable items are currently unimplemented. + +Some config_items cannot have a valid initial state. That is, no +default values can be specified for the item's attributes such that the +item can do its work. Userspace must configure one or more attributes, +after which the subsystem can start whatever entity this item +represents. + +Consider the FakeNBD device from above. Without a target address *and* +a target device, the subsystem has no idea what block device to import. +The simple example assumes that the subsystem merely waits until all the +appropriate attributes are configured, and then connects. This will, +indeed, work, but now every attribute store must check if the attributes +are initialized. Every attribute store must fire off the connection if +that condition is met. + +Far better would be an explicit action notifying the subsystem that the +config_item is ready to go. More importantly, an explicit action allows +the subsystem to provide feedback as to whether the attributes are +initialized in a way that makes sense. configfs provides this as +committable items. + +configfs still uses only normal filesystem operations. An item is +committed via rename(2). The item is moved from a directory where it +can be modified to a directory where it cannot. + +Any group that provides the ct_group_ops->commit_item() method has +committable items. When this group appears in configfs, mkdir(2) will +not work directly in the group. Instead, the group will have two +subdirectories: "live" and "pending". The "live" directory does not +support mkdir(2) or rmdir(2) either. It only allows rename(2). The +"pending" directory does allow mkdir(2) and rmdir(2). An item is +created in the "pending" directory. Its attributes can be modified at +will. Userspace commits the item by renaming it into the "live" +directory. At this point, the subsystem receives the ->commit_item() +callback. If all required attributes are filled to satisfaction, the +method returns zero and the item is moved to the "live" directory. + +As rmdir(2) does not work in the "live" directory, an item must be +shutdown, or "uncommitted". Again, this is done via rename(2), this +time from the "live" directory back to the "pending" one. The subsystem +is notified by the ct_group_ops->uncommit_object() method.
diff --git a/Documentation/filesystems/configfs/configfs.txt b/Documentation/filesystems/configfs/configfs.txt deleted file mode 100644 index 16e606c..0000000 --- a/Documentation/filesystems/configfs/configfs.txt +++ /dev/null
@@ -1,508 +0,0 @@ - -configfs - Userspace-driven kernel object configuration. - -Joel Becker <joel.becker@oracle.com> - -Updated: 31 March 2005 - -Copyright (c) 2005 Oracle Corporation, - Joel Becker <joel.becker@oracle.com> - - -[What is configfs?] - -configfs is a ram-based filesystem that provides the converse of -sysfs's functionality. Where sysfs is a filesystem-based view of -kernel objects, configfs is a filesystem-based manager of kernel -objects, or config_items. - -With sysfs, an object is created in kernel (for example, when a device -is discovered) and it is registered with sysfs. Its attributes then -appear in sysfs, allowing userspace to read the attributes via -readdir(3)/read(2). It may allow some attributes to be modified via -write(2). The important point is that the object is created and -destroyed in kernel, the kernel controls the lifecycle of the sysfs -representation, and sysfs is merely a window on all this. - -A configfs config_item is created via an explicit userspace operation: -mkdir(2). It is destroyed via rmdir(2). The attributes appear at -mkdir(2) time, and can be read or modified via read(2) and write(2). -As with sysfs, readdir(3) queries the list of items and/or attributes. -symlink(2) can be used to group items together. Unlike sysfs, the -lifetime of the representation is completely driven by userspace. The -kernel modules backing the items must respond to this. - -Both sysfs and configfs can and should exist together on the same -system. One is not a replacement for the other. - -[Using configfs] - -configfs can be compiled as a module or into the kernel. You can access -it by doing - - mount -t configfs none /config - -The configfs tree will be empty unless client modules are also loaded. -These are modules that register their item types with configfs as -subsystems. Once a client subsystem is loaded, it will appear as a -subdirectory (or more than one) under /config. Like sysfs, the -configfs tree is always there, whether mounted on /config or not. - -An item is created via mkdir(2). The item's attributes will also -appear at this time. readdir(3) can determine what the attributes are, -read(2) can query their default values, and write(2) can store new -values. Don't mix more than one attribute in one attribute file. - -There are two types of configfs attributes: - -* Normal attributes, which similar to sysfs attributes, are small ASCII text -files, with a maximum size of one page (PAGE_SIZE, 4096 on i386). Preferably -only one value per file should be used, and the same caveats from sysfs apply. -Configfs expects write(2) to store the entire buffer at once. When writing to -normal configfs attributes, userspace processes should first read the entire -file, modify the portions they wish to change, and then write the entire -buffer back. - -* Binary attributes, which are somewhat similar to sysfs binary attributes, -but with a few slight changes to semantics. The PAGE_SIZE limitation does not -apply, but the whole binary item must fit in single kernel vmalloc'ed buffer. -The write(2) calls from user space are buffered, and the attributes' -write_bin_attribute method will be invoked on the final close, therefore it is -imperative for user-space to check the return code of close(2) in order to -verify that the operation finished successfully. -To avoid a malicious user OOMing the kernel, there's a per-binary attribute -maximum buffer value. - -When an item needs to be destroyed, remove it with rmdir(2). An -item cannot be destroyed if any other item has a link to it (via -symlink(2)). Links can be removed via unlink(2). - -[Configuring FakeNBD: an Example] - -Imagine there's a Network Block Device (NBD) driver that allows you to -access remote block devices. Call it FakeNBD. FakeNBD uses configfs -for its configuration. Obviously, there will be a nice program that -sysadmins use to configure FakeNBD, but somehow that program has to tell -the driver about it. Here's where configfs comes in. - -When the FakeNBD driver is loaded, it registers itself with configfs. -readdir(3) sees this just fine: - - # ls /config - fakenbd - -A fakenbd connection can be created with mkdir(2). The name is -arbitrary, but likely the tool will make some use of the name. Perhaps -it is a uuid or a disk name: - - # mkdir /config/fakenbd/disk1 - # ls /config/fakenbd/disk1 - target device rw - -The target attribute contains the IP address of the server FakeNBD will -connect to. The device attribute is the device on the server. -Predictably, the rw attribute determines whether the connection is -read-only or read-write. - - # echo 10.0.0.1 > /config/fakenbd/disk1/target - # echo /dev/sda1 > /config/fakenbd/disk1/device - # echo 1 > /config/fakenbd/disk1/rw - -That's it. That's all there is. Now the device is configured, via the -shell no less. - -[Coding With configfs] - -Every object in configfs is a config_item. A config_item reflects an -object in the subsystem. It has attributes that match values on that -object. configfs handles the filesystem representation of that object -and its attributes, allowing the subsystem to ignore all but the -basic show/store interaction. - -Items are created and destroyed inside a config_group. A group is a -collection of items that share the same attributes and operations. -Items are created by mkdir(2) and removed by rmdir(2), but configfs -handles that. The group has a set of operations to perform these tasks - -A subsystem is the top level of a client module. During initialization, -the client module registers the subsystem with configfs, the subsystem -appears as a directory at the top of the configfs filesystem. A -subsystem is also a config_group, and can do everything a config_group -can. - -[struct config_item] - - struct config_item { - char *ci_name; - char ci_namebuf[UOBJ_NAME_LEN]; - struct kref ci_kref; - struct list_head ci_entry; - struct config_item *ci_parent; - struct config_group *ci_group; - struct config_item_type *ci_type; - struct dentry *ci_dentry; - }; - - void config_item_init(struct config_item *); - void config_item_init_type_name(struct config_item *, - const char *name, - struct config_item_type *type); - struct config_item *config_item_get(struct config_item *); - void config_item_put(struct config_item *); - -Generally, struct config_item is embedded in a container structure, a -structure that actually represents what the subsystem is doing. The -config_item portion of that structure is how the object interacts with -configfs. - -Whether statically defined in a source file or created by a parent -config_group, a config_item must have one of the _init() functions -called on it. This initializes the reference count and sets up the -appropriate fields. - -All users of a config_item should have a reference on it via -config_item_get(), and drop the reference when they are done via -config_item_put(). - -By itself, a config_item cannot do much more than appear in configfs. -Usually a subsystem wants the item to display and/or store attributes, -among other things. For that, it needs a type. - -[struct config_item_type] - - struct configfs_item_operations { - void (*release)(struct config_item *); - int (*allow_link)(struct config_item *src, - struct config_item *target); - void (*drop_link)(struct config_item *src, - struct config_item *target); - }; - - struct config_item_type { - struct module *ct_owner; - struct configfs_item_operations *ct_item_ops; - struct configfs_group_operations *ct_group_ops; - struct configfs_attribute **ct_attrs; - struct configfs_bin_attribute **ct_bin_attrs; - }; - -The most basic function of a config_item_type is to define what -operations can be performed on a config_item. All items that have been -allocated dynamically will need to provide the ct_item_ops->release() -method. This method is called when the config_item's reference count -reaches zero. - -[struct configfs_attribute] - - struct configfs_attribute { - char *ca_name; - struct module *ca_owner; - umode_t ca_mode; - ssize_t (*show)(struct config_item *, char *); - ssize_t (*store)(struct config_item *, const char *, size_t); - }; - -When a config_item wants an attribute to appear as a file in the item's -configfs directory, it must define a configfs_attribute describing it. -It then adds the attribute to the NULL-terminated array -config_item_type->ct_attrs. When the item appears in configfs, the -attribute file will appear with the configfs_attribute->ca_name -filename. configfs_attribute->ca_mode specifies the file permissions. - -If an attribute is readable and provides a ->show method, that method will -be called whenever userspace asks for a read(2) on the attribute. If an -attribute is writable and provides a ->store method, that method will be -be called whenever userspace asks for a write(2) on the attribute. - -[struct configfs_bin_attribute] - - struct configfs_bin_attribute { - struct configfs_attribute cb_attr; - void *cb_private; - size_t cb_max_size; - }; - -The binary attribute is used when the one needs to use binary blob to -appear as the contents of a file in the item's configfs directory. -To do so add the binary attribute to the NULL-terminated array -config_item_type->ct_bin_attrs, and the item appears in configfs, the -attribute file will appear with the configfs_bin_attribute->cb_attr.ca_name -filename. configfs_bin_attribute->cb_attr.ca_mode specifies the file -permissions. -The cb_private member is provided for use by the driver, while the -cb_max_size member specifies the maximum amount of vmalloc buffer -to be used. - -If binary attribute is readable and the config_item provides a -ct_item_ops->read_bin_attribute() method, that method will be called -whenever userspace asks for a read(2) on the attribute. The converse -will happen for write(2). The reads/writes are bufferred so only a -single read/write will occur; the attributes' need not concern itself -with it. - -[struct config_group] - -A config_item cannot live in a vacuum. The only way one can be created -is via mkdir(2) on a config_group. This will trigger creation of a -child item. - - struct config_group { - struct config_item cg_item; - struct list_head cg_children; - struct configfs_subsystem *cg_subsys; - struct list_head default_groups; - struct list_head group_entry; - }; - - void config_group_init(struct config_group *group); - void config_group_init_type_name(struct config_group *group, - const char *name, - struct config_item_type *type); - - -The config_group structure contains a config_item. Properly configuring -that item means that a group can behave as an item in its own right. -However, it can do more: it can create child items or groups. This is -accomplished via the group operations specified on the group's -config_item_type. - - struct configfs_group_operations { - struct config_item *(*make_item)(struct config_group *group, - const char *name); - struct config_group *(*make_group)(struct config_group *group, - const char *name); - int (*commit_item)(struct config_item *item); - void (*disconnect_notify)(struct config_group *group, - struct config_item *item); - void (*drop_item)(struct config_group *group, - struct config_item *item); - }; - -A group creates child items by providing the -ct_group_ops->make_item() method. If provided, this method is called from mkdir(2) in the group's directory. The subsystem allocates a new -config_item (or more likely, its container structure), initializes it, -and returns it to configfs. Configfs will then populate the filesystem -tree to reflect the new item. - -If the subsystem wants the child to be a group itself, the subsystem -provides ct_group_ops->make_group(). Everything else behaves the same, -using the group _init() functions on the group. - -Finally, when userspace calls rmdir(2) on the item or group, -ct_group_ops->drop_item() is called. As a config_group is also a -config_item, it is not necessary for a separate drop_group() method. -The subsystem must config_item_put() the reference that was initialized -upon item allocation. If a subsystem has no work to do, it may omit -the ct_group_ops->drop_item() method, and configfs will call -config_item_put() on the item on behalf of the subsystem. - -IMPORTANT: drop_item() is void, and as such cannot fail. When rmdir(2) -is called, configfs WILL remove the item from the filesystem tree -(assuming that it has no children to keep it busy). The subsystem is -responsible for responding to this. If the subsystem has references to -the item in other threads, the memory is safe. It may take some time -for the item to actually disappear from the subsystem's usage. But it -is gone from configfs. - -When drop_item() is called, the item's linkage has already been torn -down. It no longer has a reference on its parent and has no place in -the item hierarchy. If a client needs to do some cleanup before this -teardown happens, the subsystem can implement the -ct_group_ops->disconnect_notify() method. The method is called after -configfs has removed the item from the filesystem view but before the -item is removed from its parent group. Like drop_item(), -disconnect_notify() is void and cannot fail. Client subsystems should -not drop any references here, as they still must do it in drop_item(). - -A config_group cannot be removed while it still has child items. This -is implemented in the configfs rmdir(2) code. ->drop_item() will not be -called, as the item has not been dropped. rmdir(2) will fail, as the -directory is not empty. - -[struct configfs_subsystem] - -A subsystem must register itself, usually at module_init time. This -tells configfs to make the subsystem appear in the file tree. - - struct configfs_subsystem { - struct config_group su_group; - struct mutex su_mutex; - }; - - int configfs_register_subsystem(struct configfs_subsystem *subsys); - void configfs_unregister_subsystem(struct configfs_subsystem *subsys); - - A subsystem consists of a toplevel config_group and a mutex. -The group is where child config_items are created. For a subsystem, -this group is usually defined statically. Before calling -configfs_register_subsystem(), the subsystem must have initialized the -group via the usual group _init() functions, and it must also have -initialized the mutex. - When the register call returns, the subsystem is live, and it -will be visible via configfs. At that point, mkdir(2) can be called and -the subsystem must be ready for it. - -[An Example] - -The best example of these basic concepts is the simple_children -subsystem/group and the simple_child item in -samples/configfs/configfs_sample.c. It shows a trivial object displaying -and storing an attribute, and a simple group creating and destroying -these children. - -[Hierarchy Navigation and the Subsystem Mutex] - -There is an extra bonus that configfs provides. The config_groups and -config_items are arranged in a hierarchy due to the fact that they -appear in a filesystem. A subsystem is NEVER to touch the filesystem -parts, but the subsystem might be interested in this hierarchy. For -this reason, the hierarchy is mirrored via the config_group->cg_children -and config_item->ci_parent structure members. - -A subsystem can navigate the cg_children list and the ci_parent pointer -to see the tree created by the subsystem. This can race with configfs' -management of the hierarchy, so configfs uses the subsystem mutex to -protect modifications. Whenever a subsystem wants to navigate the -hierarchy, it must do so under the protection of the subsystem -mutex. - -A subsystem will be prevented from acquiring the mutex while a newly -allocated item has not been linked into this hierarchy. Similarly, it -will not be able to acquire the mutex while a dropping item has not -yet been unlinked. This means that an item's ci_parent pointer will -never be NULL while the item is in configfs, and that an item will only -be in its parent's cg_children list for the same duration. This allows -a subsystem to trust ci_parent and cg_children while they hold the -mutex. - -[Item Aggregation Via symlink(2)] - -configfs provides a simple group via the group->item parent/child -relationship. Often, however, a larger environment requires aggregation -outside of the parent/child connection. This is implemented via -symlink(2). - -A config_item may provide the ct_item_ops->allow_link() and -ct_item_ops->drop_link() methods. If the ->allow_link() method exists, -symlink(2) may be called with the config_item as the source of the link. -These links are only allowed between configfs config_items. Any -symlink(2) attempt outside the configfs filesystem will be denied. - -When symlink(2) is called, the source config_item's ->allow_link() -method is called with itself and a target item. If the source item -allows linking to target item, it returns 0. A source item may wish to -reject a link if it only wants links to a certain type of object (say, -in its own subsystem). - -When unlink(2) is called on the symbolic link, the source item is -notified via the ->drop_link() method. Like the ->drop_item() method, -this is a void function and cannot return failure. The subsystem is -responsible for responding to the change. - -A config_item cannot be removed while it links to any other item, nor -can it be removed while an item links to it. Dangling symlinks are not -allowed in configfs. - -[Automatically Created Subgroups] - -A new config_group may want to have two types of child config_items. -While this could be codified by magic names in ->make_item(), it is much -more explicit to have a method whereby userspace sees this divergence. - -Rather than have a group where some items behave differently than -others, configfs provides a method whereby one or many subgroups are -automatically created inside the parent at its creation. Thus, -mkdir("parent") results in "parent", "parent/subgroup1", up through -"parent/subgroupN". Items of type 1 can now be created in -"parent/subgroup1", and items of type N can be created in -"parent/subgroupN". - -These automatic subgroups, or default groups, do not preclude other -children of the parent group. If ct_group_ops->make_group() exists, -other child groups can be created on the parent group directly. - -A configfs subsystem specifies default groups by adding them using the -configfs_add_default_group() function to the parent config_group -structure. Each added group is populated in the configfs tree at the same -time as the parent group. Similarly, they are removed at the same time -as the parent. No extra notification is provided. When a ->drop_item() -method call notifies the subsystem the parent group is going away, it -also means every default group child associated with that parent group. - -As a consequence of this, default groups cannot be removed directly via -rmdir(2). They also are not considered when rmdir(2) on the parent -group is checking for children. - -[Dependent Subsystems] - -Sometimes other drivers depend on particular configfs items. For -example, ocfs2 mounts depend on a heartbeat region item. If that -region item is removed with rmdir(2), the ocfs2 mount must BUG or go -readonly. Not happy. - -configfs provides two additional API calls: configfs_depend_item() and -configfs_undepend_item(). A client driver can call -configfs_depend_item() on an existing item to tell configfs that it is -depended on. configfs will then return -EBUSY from rmdir(2) for that -item. When the item is no longer depended on, the client driver calls -configfs_undepend_item() on it. - -These API cannot be called underneath any configfs callbacks, as -they will conflict. They can block and allocate. A client driver -probably shouldn't calling them of its own gumption. Rather it should -be providing an API that external subsystems call. - -How does this work? Imagine the ocfs2 mount process. When it mounts, -it asks for a heartbeat region item. This is done via a call into the -heartbeat code. Inside the heartbeat code, the region item is looked -up. Here, the heartbeat code calls configfs_depend_item(). If it -succeeds, then heartbeat knows the region is safe to give to ocfs2. -If it fails, it was being torn down anyway, and heartbeat can gracefully -pass up an error. - -[Committable Items] - -NOTE: Committable items are currently unimplemented. - -Some config_items cannot have a valid initial state. That is, no -default values can be specified for the item's attributes such that the -item can do its work. Userspace must configure one or more attributes, -after which the subsystem can start whatever entity this item -represents. - -Consider the FakeNBD device from above. Without a target address *and* -a target device, the subsystem has no idea what block device to import. -The simple example assumes that the subsystem merely waits until all the -appropriate attributes are configured, and then connects. This will, -indeed, work, but now every attribute store must check if the attributes -are initialized. Every attribute store must fire off the connection if -that condition is met. - -Far better would be an explicit action notifying the subsystem that the -config_item is ready to go. More importantly, an explicit action allows -the subsystem to provide feedback as to whether the attributes are -initialized in a way that makes sense. configfs provides this as -committable items. - -configfs still uses only normal filesystem operations. An item is -committed via rename(2). The item is moved from a directory where it -can be modified to a directory where it cannot. - -Any group that provides the ct_group_ops->commit_item() method has -committable items. When this group appears in configfs, mkdir(2) will -not work directly in the group. Instead, the group will have two -subdirectories: "live" and "pending". The "live" directory does not -support mkdir(2) or rmdir(2) either. It only allows rename(2). The -"pending" directory does allow mkdir(2) and rmdir(2). An item is -created in the "pending" directory. Its attributes can be modified at -will. Userspace commits the item by renaming it into the "live" -directory. At this point, the subsystem receives the ->commit_item() -callback. If all required attributes are filled to satisfaction, the -method returns zero and the item is moved to the "live" directory. - -As rmdir(2) does not work in the "live" directory, an item must be -shutdown, or "uncommitted". Again, this is done via rename(2), this -time from the "live" directory back to the "pending" one. The subsystem -is notified by the ct_group_ops->uncommit_object() method. - -
diff --git a/Documentation/filesystems/dax.txt b/Documentation/filesystems/dax.txt index 6797294..8e26707 100644 --- a/Documentation/filesystems/dax.txt +++ b/Documentation/filesystems/dax.txt
@@ -20,8 +20,144 @@ If you have a block device which supports DAX, you can make a filesystem on it as usual. The DAX code currently only supports files with a block size equal to your kernel's PAGE_SIZE, so you may need to specify a block -size when creating the filesystem. When mounting it, use the "-o dax" -option on the command line or add 'dax' to the options in /etc/fstab. +size when creating the filesystem. + +Currently 3 filesystems support DAX: ext2, ext4 and xfs. Enabling DAX on them +is different. + +Enabling DAX on ext4 and ext2 +----------------------------- + +When mounting the filesystem, use the "-o dax" option on the command line or +add 'dax' to the options in /etc/fstab. This works to enable DAX on all files +within the filesystem. It is equivalent to the '-o dax=always' behavior below. + + +Enabling DAX on xfs +------------------- + +Summary +------- + + 1. There exists an in-kernel file access mode flag S_DAX that corresponds to + the statx flag STATX_ATTR_DAX. See the manpage for statx(2) for details + about this access mode. + + 2. There exists a persistent flag FS_XFLAG_DAX that can be applied to regular + files and directories. This advisory flag can be set or cleared at any + time, but doing so does not immediately affect the S_DAX state. + + 3. If the persistent FS_XFLAG_DAX flag is set on a directory, this flag will + be inherited by all regular files and subdirectories that are subsequently + created in this directory. Files and subdirectories that exist at the time + this flag is set or cleared on the parent directory are not modified by + this modification of the parent directory. + + 4. There exist dax mount options which can override FS_XFLAG_DAX in the + setting of the S_DAX flag. Given underlying storage which supports DAX the + following hold: + + "-o dax=inode" means "follow FS_XFLAG_DAX" and is the default. + + "-o dax=never" means "never set S_DAX, ignore FS_XFLAG_DAX." + + "-o dax=always" means "always set S_DAX ignore FS_XFLAG_DAX." + + "-o dax" is a legacy option which is an alias for "dax=always". + This may be removed in the future so "-o dax=always" is + the preferred method for specifying this behavior. + + NOTE: Modifications to and the inheritance behavior of FS_XFLAG_DAX remain + the same even when the filesystem is mounted with a dax option. However, + in-core inode state (S_DAX) will be overridden until the filesystem is + remounted with dax=inode and the inode is evicted from kernel memory. + + 5. The S_DAX policy can be changed via: + + a) Setting the parent directory FS_XFLAG_DAX as needed before files are + created + + b) Setting the appropriate dax="foo" mount option + + c) Changing the FS_XFLAG_DAX flag on existing regular files and + directories. This has runtime constraints and limitations that are + described in 6) below. + + 6. When changing the S_DAX policy via toggling the persistent FS_XFLAG_DAX flag, + the change in behaviour for existing regular files may not occur + immediately. If the change must take effect immediately, the administrator + needs to: + + a) stop the application so there are no active references to the data set + the policy change will affect + + b) evict the data set from kernel caches so it will be re-instantiated when + the application is restarted. This can be achieved by: + + i. drop-caches + ii. a filesystem unmount and mount cycle + iii. a system reboot + + +Details +------- + +There are 2 per-file dax flags. One is a persistent inode setting (FS_XFLAG_DAX) +and the other is a volatile flag indicating the active state of the feature +(S_DAX). + +FS_XFLAG_DAX is preserved within the filesystem. This persistent config +setting can be set, cleared and/or queried using the FS_IOC_FS[GS]ETXATTR ioctl +(see ioctl_xfs_fsgetxattr(2)) or an utility such as 'xfs_io'. + +New files and directories automatically inherit FS_XFLAG_DAX from +their parent directory _when_ _created_. Therefore, setting FS_XFLAG_DAX at +directory creation time can be used to set a default behavior for an entire +sub-tree. + +To clarify inheritance, here are 3 examples: + +Example A: + +mkdir -p a/b/c +xfs_io -c 'chattr +x' a +mkdir a/b/c/d +mkdir a/e + + dax: a,e + no dax: b,c,d + +Example B: + +mkdir a +xfs_io -c 'chattr +x' a +mkdir -p a/b/c/d + + dax: a,b,c,d + no dax: + +Example C: + +mkdir -p a/b/c +xfs_io -c 'chattr +x' c +mkdir a/b/c/d + + dax: c,d + no dax: a,b + + +The current enabled state (S_DAX) is set when a file inode is instantiated in +memory by the kernel. It is set based on the underlying media support, the +value of FS_XFLAG_DAX and the filesystem's dax mount option. + +statx can be used to query S_DAX. NOTE that only regular files will ever have +S_DAX set and therefore statx will never indicate that S_DAX is set on +directories. + +Setting the FS_XFLAG_DAX flag (specifically or through inheritance) occurs even +if the underlying media does not support dax and/or the filesystem is +overridden with a mount option. + Implementation Tips for Block Driver Writers @@ -74,7 +210,7 @@ exposure of uninitialized data through mmap. These filesystems may be used for inspiration: -- ext2: see Documentation/filesystems/ext2.txt +- ext2: see Documentation/filesystems/ext2.rst - ext4: see Documentation/filesystems/ext4/ - xfs: see Documentation/admin-guide/xfs.rst @@ -94,7 +230,7 @@ redundancy in the following ways: 1. Delete the affected file, and restore from a backup (sysadmin route): - This will free the file system blocks that were being used by the file, + This will free the filesystem blocks that were being used by the file, and the next time they're allocated, they will be zeroed first, which happens through the driver, and will clear bad sectors.
diff --git a/Documentation/filesystems/debugfs.rst b/Documentation/filesystems/debugfs.rst index db9ea08..1da7a4b 100644 --- a/Documentation/filesystems/debugfs.rst +++ b/Documentation/filesystems/debugfs.rst
@@ -79,8 +79,8 @@ struct dentry *parent, u8 *value); void debugfs_create_u16(const char *name, umode_t mode, struct dentry *parent, u16 *value); - struct dentry *debugfs_create_u32(const char *name, umode_t mode, - struct dentry *parent, u32 *value); + void debugfs_create_u32(const char *name, umode_t mode, + struct dentry *parent, u32 *value); void debugfs_create_u64(const char *name, umode_t mode, struct dentry *parent, u64 *value); @@ -166,16 +166,17 @@ }; struct debugfs_regset32 { - struct debugfs_reg32 *regs; + const struct debugfs_reg32 *regs; int nregs; void __iomem *base; + struct device *dev; /* Optional device for Runtime PM */ }; debugfs_create_regset32(const char *name, umode_t mode, struct dentry *parent, struct debugfs_regset32 *regset); - void debugfs_print_regs32(struct seq_file *s, struct debugfs_reg32 *regs, + void debugfs_print_regs32(struct seq_file *s, const struct debugfs_reg32 *regs, int nregs, void __iomem *base, char *prefix); The "base" argument may be 0, but you may want to build the reg32 array
diff --git a/Documentation/filesystems/devpts.rst b/Documentation/filesystems/devpts.rst new file mode 100644 index 0000000..a03248d --- /dev/null +++ b/Documentation/filesystems/devpts.rst
@@ -0,0 +1,36 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +The Devpts Filesystem +===================== + +Each mount of the devpts filesystem is now distinct such that ptys +and their indicies allocated in one mount are independent from ptys +and their indicies in all other mounts. + +All mounts of the devpts filesystem now create a ``/dev/pts/ptmx`` node +with permissions ``0000``. + +To retain backwards compatibility the a ptmx device node (aka any node +created with ``mknod name c 5 2``) when opened will look for an instance +of devpts under the name ``pts`` in the same directory as the ptmx device +node. + +As an option instead of placing a ``/dev/ptmx`` device node at ``/dev/ptmx`` +it is possible to place a symlink to ``/dev/pts/ptmx`` at ``/dev/ptmx`` or +to bind mount ``/dev/ptx/ptmx`` to ``/dev/ptmx``. If you opt for using +the devpts filesystem in this manner devpts should be mounted with +the ``ptmxmode=0666``, or ``chmod 0666 /dev/pts/ptmx`` should be called. + +Total count of pty pairs in all instances is limited by sysctls:: + + kernel.pty.max = 4096 - global limit + kernel.pty.reserve = 1024 - reserved for filesystems mounted from the initial mount namespace + kernel.pty.nr - current count of ptys + +Per-instance limit could be set by adding mount option ``max=<count>``. + +This feature was added in kernel 3.4 together with +``sysctl kernel.pty.reserve``. + +In kernels older than 3.4 sysctl ``kernel.pty.max`` works as per-instance limit.
diff --git a/Documentation/filesystems/devpts.txt b/Documentation/filesystems/devpts.txt deleted file mode 100644 index 9f94fe27..0000000 --- a/Documentation/filesystems/devpts.txt +++ /dev/null
@@ -1,26 +0,0 @@ -Each mount of the devpts filesystem is now distinct such that ptys -and their indicies allocated in one mount are independent from ptys -and their indicies in all other mounts. - -All mounts of the devpts filesystem now create a /dev/pts/ptmx node -with permissions 0000. - -To retain backwards compatibility the a ptmx device node (aka any node -created with "mknod name c 5 2") when opened will look for an instance -of devpts under the name "pts" in the same directory as the ptmx device -node. - -As an option instead of placing a /dev/ptmx device node at /dev/ptmx -it is possible to place a symlink to /dev/pts/ptmx at /dev/ptmx or -to bind mount /dev/ptx/ptmx to /dev/ptmx. If you opt for using -the devpts filesystem in this manner devpts should be mounted with -the ptmxmode=0666, or chmod 0666 /dev/pts/ptmx should be called. - -Total count of pty pairs in all instances is limited by sysctls: -kernel.pty.max = 4096 - global limit -kernel.pty.reserve = 1024 - reserved for filesystems mounted from the initial mount namespace -kernel.pty.nr - current count of ptys - -Per-instance limit could be set by adding mount option "max=<count>". -This feature was added in kernel 3.4 together with sysctl kernel.pty.reserve. -In kernels older than 3.4 sysctl kernel.pty.max works as per-instance limit.
diff --git a/Documentation/filesystems/dnotify.rst b/Documentation/filesystems/dnotify.rst new file mode 100644 index 0000000..a28a1f9e --- /dev/null +++ b/Documentation/filesystems/dnotify.rst
@@ -0,0 +1,75 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================ +Linux Directory Notification +============================ + + Stephen Rothwell <sfr@canb.auug.org.au> + +The intention of directory notification is to allow user applications +to be notified when a directory, or any of the files in it, are changed. +The basic mechanism involves the application registering for notification +on a directory using a fcntl(2) call and the notifications themselves +being delivered using signals. + +The application decides which "events" it wants to be notified about. +The currently defined events are: + + ========= ===================================================== + DN_ACCESS A file in the directory was accessed (read) + DN_MODIFY A file in the directory was modified (write,truncate) + DN_CREATE A file was created in the directory + DN_DELETE A file was unlinked from directory + DN_RENAME A file in the directory was renamed + DN_ATTRIB A file in the directory had its attributes + changed (chmod,chown) + ========= ===================================================== + +Usually, the application must reregister after each notification, but +if DN_MULTISHOT is or'ed with the event mask, then the registration will +remain until explicitly removed (by registering for no events). + +By default, SIGIO will be delivered to the process and no other useful +information. However, if the F_SETSIG fcntl(2) call is used to let the +kernel know which signal to deliver, a siginfo structure will be passed to +the signal handler and the si_fd member of that structure will contain the +file descriptor associated with the directory in which the event occurred. + +Preferably the application will choose one of the real time signals +(SIGRTMIN + <n>) so that the notifications may be queued. This is +especially important if DN_MULTISHOT is specified. Note that SIGRTMIN +is often blocked, so it is better to use (at least) SIGRTMIN + 1. + +Implementation expectations (features and bugs :-)) +--------------------------------------------------- + +The notification should work for any local access to files even if the +actual file system is on a remote server. This implies that remote +access to files served by local user mode servers should be notified. +Also, remote accesses to files served by a local kernel NFS server should +be notified. + +In order to make the impact on the file system code as small as possible, +the problem of hard links to files has been ignored. So if a file (x) +exists in two directories (a and b) then a change to the file using the +name "a/x" should be notified to a program expecting notifications on +directory "a", but will not be notified to one expecting notifications on +directory "b". + +Also, files that are unlinked, will still cause notifications in the +last directory that they were linked to. + +Configuration +------------- + +Dnotify is controlled via the CONFIG_DNOTIFY configuration option. When +disabled, fcntl(fd, F_NOTIFY, ...) will return -EINVAL. + +Example +------- +See tools/testing/selftests/filesystems/dnotify_test.c for an example. + +NOTE +---- +Beginning with Linux 2.6.13, dnotify has been replaced by inotify. +See Documentation/filesystems/inotify.rst for more information on it.
diff --git a/Documentation/filesystems/dnotify.txt b/Documentation/filesystems/dnotify.txt deleted file mode 100644 index 1515688..0000000 --- a/Documentation/filesystems/dnotify.txt +++ /dev/null
@@ -1,70 +0,0 @@ - Linux Directory Notification - ============================ - - Stephen Rothwell <sfr@canb.auug.org.au> - -The intention of directory notification is to allow user applications -to be notified when a directory, or any of the files in it, are changed. -The basic mechanism involves the application registering for notification -on a directory using a fcntl(2) call and the notifications themselves -being delivered using signals. - -The application decides which "events" it wants to be notified about. -The currently defined events are: - - DN_ACCESS A file in the directory was accessed (read) - DN_MODIFY A file in the directory was modified (write,truncate) - DN_CREATE A file was created in the directory - DN_DELETE A file was unlinked from directory - DN_RENAME A file in the directory was renamed - DN_ATTRIB A file in the directory had its attributes - changed (chmod,chown) - -Usually, the application must reregister after each notification, but -if DN_MULTISHOT is or'ed with the event mask, then the registration will -remain until explicitly removed (by registering for no events). - -By default, SIGIO will be delivered to the process and no other useful -information. However, if the F_SETSIG fcntl(2) call is used to let the -kernel know which signal to deliver, a siginfo structure will be passed to -the signal handler and the si_fd member of that structure will contain the -file descriptor associated with the directory in which the event occurred. - -Preferably the application will choose one of the real time signals -(SIGRTMIN + <n>) so that the notifications may be queued. This is -especially important if DN_MULTISHOT is specified. Note that SIGRTMIN -is often blocked, so it is better to use (at least) SIGRTMIN + 1. - -Implementation expectations (features and bugs :-)) ---------------------------- - -The notification should work for any local access to files even if the -actual file system is on a remote server. This implies that remote -access to files served by local user mode servers should be notified. -Also, remote accesses to files served by a local kernel NFS server should -be notified. - -In order to make the impact on the file system code as small as possible, -the problem of hard links to files has been ignored. So if a file (x) -exists in two directories (a and b) then a change to the file using the -name "a/x" should be notified to a program expecting notifications on -directory "a", but will not be notified to one expecting notifications on -directory "b". - -Also, files that are unlinked, will still cause notifications in the -last directory that they were linked to. - -Configuration -------------- - -Dnotify is controlled via the CONFIG_DNOTIFY configuration option. When -disabled, fcntl(fd, F_NOTIFY, ...) will return -EINVAL. - -Example -------- -See tools/testing/selftests/filesystems/dnotify_test.c for an example. - -NOTE ----- -Beginning with Linux 2.6.13, dnotify has been replaced by inotify. -See Documentation/filesystems/inotify.txt for more information on it.
diff --git a/Documentation/filesystems/efivarfs.rst b/Documentation/filesystems/efivarfs.rst index 90ac656..0551985 100644 --- a/Documentation/filesystems/efivarfs.rst +++ b/Documentation/filesystems/efivarfs.rst
@@ -24,3 +24,20 @@ as immutable files. This doesn't prevent removal - "chattr -i" will work - but it does prevent this kind of failure from being accomplished accidentally. + +.. warning :: + When a content of an UEFI variable in /sys/firmware/efi/efivars is + displayed, for example using "hexdump", pay attention that the first + 4 bytes of the output represent the UEFI variable attributes, + in little-endian format. + + Practically the output of each efivar is composed of: + + +-----------------------------------+ + |4_bytes_of_attributes + efivar_data| + +-----------------------------------+ + +*See also:* + +- Documentation/admin-guide/acpi/ssdt-overlays.rst +- Documentation/ABI/stable/sysfs-firmware-efi-vars
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index 87d794b..099d45a 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst
@@ -225,8 +225,12 @@ pass, but the performance will regress. "nobarrier" is based on "posix", but doesn't issue flush command for non-atomic files likewise "nobarrier" mount option. -test_dummy_encryption Enable dummy encryption, which provides a fake fscrypt +test_dummy_encryption +test_dummy_encryption=%s + Enable dummy encryption, which provides a fake fscrypt context. The fake fscrypt context is used by xfstests. + The argument may be either "v1" or "v2", in order to + select the corresponding fscrypt policy version. checkpoint=%s[:%u[%]] Set to "disable" to turn off checkpointing. Set to "enable" to reenable checkpointing. Is enabled by default. While disabled, any unmounting or unexpected shutdowns will cause @@ -244,7 +248,7 @@ would be unusable can be viewed at /sys/fs/f2fs/<disk>/unusable This space is reclaimed once checkpoint=enable. compress_algorithm=%s Control compress algorithm, currently f2fs supports "lzo", - "lz4" and "zstd" algorithm. + "lz4", "zstd" and "lzo-rle" algorithm. compress_log_size=%u Support configuring compress cluster size, the size will be 4KB * (1 << %u), 16KB is minimum size, also it's default size.
diff --git a/Documentation/filesystems/fiemap.rst b/Documentation/filesystems/fiemap.rst new file mode 100644 index 0000000..93fc96f --- /dev/null +++ b/Documentation/filesystems/fiemap.rst
@@ -0,0 +1,236 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============ +Fiemap Ioctl +============ + +The fiemap ioctl is an efficient method for userspace to get file +extent mappings. Instead of block-by-block mapping (such as bmap), fiemap +returns a list of extents. + + +Request Basics +-------------- + +A fiemap request is encoded within struct fiemap:: + + struct fiemap { + __u64 fm_start; /* logical offset (inclusive) at + * which to start mapping (in) */ + __u64 fm_length; /* logical length of mapping which + * userspace cares about (in) */ + __u32 fm_flags; /* FIEMAP_FLAG_* flags for request (in/out) */ + __u32 fm_mapped_extents; /* number of extents that were + * mapped (out) */ + __u32 fm_extent_count; /* size of fm_extents array (in) */ + __u32 fm_reserved; + struct fiemap_extent fm_extents[0]; /* array of mapped extents (out) */ + }; + + +fm_start, and fm_length specify the logical range within the file +which the process would like mappings for. Extents returned mirror +those on disk - that is, the logical offset of the 1st returned extent +may start before fm_start, and the range covered by the last returned +extent may end after fm_length. All offsets and lengths are in bytes. + +Certain flags to modify the way in which mappings are looked up can be +set in fm_flags. If the kernel doesn't understand some particular +flags, it will return EBADR and the contents of fm_flags will contain +the set of flags which caused the error. If the kernel is compatible +with all flags passed, the contents of fm_flags will be unmodified. +It is up to userspace to determine whether rejection of a particular +flag is fatal to its operation. This scheme is intended to allow the +fiemap interface to grow in the future but without losing +compatibility with old software. + +fm_extent_count specifies the number of elements in the fm_extents[] array +that can be used to return extents. If fm_extent_count is zero, then the +fm_extents[] array is ignored (no extents will be returned), and the +fm_mapped_extents count will hold the number of extents needed in +fm_extents[] to hold the file's current mapping. Note that there is +nothing to prevent the file from changing between calls to FIEMAP. + +The following flags can be set in fm_flags: + +FIEMAP_FLAG_SYNC + If this flag is set, the kernel will sync the file before mapping extents. + +FIEMAP_FLAG_XATTR + If this flag is set, the extents returned will describe the inodes + extended attribute lookup tree, instead of its data tree. + + +Extent Mapping +-------------- + +Extent information is returned within the embedded fm_extents array +which userspace must allocate along with the fiemap structure. The +number of elements in the fiemap_extents[] array should be passed via +fm_extent_count. The number of extents mapped by kernel will be +returned via fm_mapped_extents. If the number of fiemap_extents +allocated is less than would be required to map the requested range, +the maximum number of extents that can be mapped in the fm_extent[] +array will be returned and fm_mapped_extents will be equal to +fm_extent_count. In that case, the last extent in the array will not +complete the requested range and will not have the FIEMAP_EXTENT_LAST +flag set (see the next section on extent flags). + +Each extent is described by a single fiemap_extent structure as +returned in fm_extents:: + + struct fiemap_extent { + __u64 fe_logical; /* logical offset in bytes for the start of + * the extent */ + __u64 fe_physical; /* physical offset in bytes for the start + * of the extent */ + __u64 fe_length; /* length in bytes for the extent */ + __u64 fe_reserved64[2]; + __u32 fe_flags; /* FIEMAP_EXTENT_* flags for this extent */ + __u32 fe_reserved[3]; + }; + +All offsets and lengths are in bytes and mirror those on disk. It is valid +for an extents logical offset to start before the request or its logical +length to extend past the request. Unless FIEMAP_EXTENT_NOT_ALIGNED is +returned, fe_logical, fe_physical, and fe_length will be aligned to the +block size of the file system. With the exception of extents flagged as +FIEMAP_EXTENT_MERGED, adjacent extents will not be merged. + +The fe_flags field contains flags which describe the extent returned. +A special flag, FIEMAP_EXTENT_LAST is always set on the last extent in +the file so that the process making fiemap calls can determine when no +more extents are available, without having to call the ioctl again. + +Some flags are intentionally vague and will always be set in the +presence of other more specific flags. This way a program looking for +a general property does not have to know all existing and future flags +which imply that property. + +For example, if FIEMAP_EXTENT_DATA_INLINE or FIEMAP_EXTENT_DATA_TAIL +are set, FIEMAP_EXTENT_NOT_ALIGNED will also be set. A program looking +for inline or tail-packed data can key on the specific flag. Software +which simply cares not to try operating on non-aligned extents +however, can just key on FIEMAP_EXTENT_NOT_ALIGNED, and not have to +worry about all present and future flags which might imply unaligned +data. Note that the opposite is not true - it would be valid for +FIEMAP_EXTENT_NOT_ALIGNED to appear alone. + +FIEMAP_EXTENT_LAST + This is generally the last extent in the file. A mapping attempt past + this extent may return nothing. Some implementations set this flag to + indicate this extent is the last one in the range queried by the user + (via fiemap->fm_length). + +FIEMAP_EXTENT_UNKNOWN + The location of this extent is currently unknown. This may indicate + the data is stored on an inaccessible volume or that no storage has + been allocated for the file yet. + +FIEMAP_EXTENT_DELALLOC + This will also set FIEMAP_EXTENT_UNKNOWN. + + Delayed allocation - while there is data for this extent, its + physical location has not been allocated yet. + +FIEMAP_EXTENT_ENCODED + This extent does not consist of plain filesystem blocks but is + encoded (e.g. encrypted or compressed). Reading the data in this + extent via I/O to the block device will have undefined results. + +Note that it is *always* undefined to try to update the data +in-place by writing to the indicated location without the +assistance of the filesystem, or to access the data using the +information returned by the FIEMAP interface while the filesystem +is mounted. In other words, user applications may only read the +extent data via I/O to the block device while the filesystem is +unmounted, and then only if the FIEMAP_EXTENT_ENCODED flag is +clear; user applications must not try reading or writing to the +filesystem via the block device under any other circumstances. + +FIEMAP_EXTENT_DATA_ENCRYPTED + This will also set FIEMAP_EXTENT_ENCODED + The data in this extent has been encrypted by the file system. + +FIEMAP_EXTENT_NOT_ALIGNED + Extent offsets and length are not guaranteed to be block aligned. + +FIEMAP_EXTENT_DATA_INLINE + This will also set FIEMAP_EXTENT_NOT_ALIGNED + Data is located within a meta data block. + +FIEMAP_EXTENT_DATA_TAIL + This will also set FIEMAP_EXTENT_NOT_ALIGNED + Data is packed into a block with data from other files. + +FIEMAP_EXTENT_UNWRITTEN + Unwritten extent - the extent is allocated but its data has not been + initialized. This indicates the extent's data will be all zero if read + through the filesystem but the contents are undefined if read directly from + the device. + +FIEMAP_EXTENT_MERGED + This will be set when a file does not support extents, i.e., it uses a block + based addressing scheme. Since returning an extent for each block back to + userspace would be highly inefficient, the kernel will try to merge most + adjacent blocks into 'extents'. + + +VFS -> File System Implementation +--------------------------------- + +File systems wishing to support fiemap must implement a ->fiemap callback on +their inode_operations structure. The fs ->fiemap call is responsible for +defining its set of supported fiemap flags, and calling a helper function on +each discovered extent:: + + struct inode_operations { + ... + + int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, + u64 len); + +->fiemap is passed struct fiemap_extent_info which describes the +fiemap request:: + + struct fiemap_extent_info { + unsigned int fi_flags; /* Flags as passed from user */ + unsigned int fi_extents_mapped; /* Number of mapped extents */ + unsigned int fi_extents_max; /* Size of fiemap_extent array */ + struct fiemap_extent *fi_extents_start; /* Start of fiemap_extent array */ + }; + +It is intended that the file system should not need to access any of this +structure directly. Filesystem handlers should be tolerant to signals and return +EINTR once fatal signal received. + + +Flag checking should be done at the beginning of the ->fiemap callback via the +fiemap_prep() helper:: + + int fiemap_prep(struct inode *inode, struct fiemap_extent_info *fieinfo, + u64 start, u64 *len, u32 supported_flags); + +The struct fieinfo should be passed in as received from ioctl_fiemap(). The +set of fiemap flags which the fs understands should be passed via fs_flags. If +fiemap_prep finds invalid user flags, it will place the bad values in +fieinfo->fi_flags and return -EBADR. If the file system gets -EBADR, from +fiemap_prep(), it should immediately exit, returning that error back to +ioctl_fiemap(). Additionally the range is validate against the supported +maximum file size. + + +For each extent in the request range, the file system should call +the helper function, fiemap_fill_next_extent():: + + int fiemap_fill_next_extent(struct fiemap_extent_info *info, u64 logical, + u64 phys, u64 len, u32 flags, u32 dev); + +fiemap_fill_next_extent() will use the passed values to populate the +next free extent in the fm_extents array. 'General' extent flags will +automatically be set from specific flags on behalf of the calling file +system so that the userspace API is not broken. + +fiemap_fill_next_extent() returns 0 on success, and 1 when the +user-supplied fm_extents array is full. If an error is encountered +while copying the extent to user memory, -EFAULT will be returned.
diff --git a/Documentation/filesystems/fiemap.txt b/Documentation/filesystems/fiemap.txt deleted file mode 100644 index ac87e6f..0000000 --- a/Documentation/filesystems/fiemap.txt +++ /dev/null
@@ -1,231 +0,0 @@ -============ -Fiemap Ioctl -============ - -The fiemap ioctl is an efficient method for userspace to get file -extent mappings. Instead of block-by-block mapping (such as bmap), fiemap -returns a list of extents. - - -Request Basics --------------- - -A fiemap request is encoded within struct fiemap: - -struct fiemap { - __u64 fm_start; /* logical offset (inclusive) at - * which to start mapping (in) */ - __u64 fm_length; /* logical length of mapping which - * userspace cares about (in) */ - __u32 fm_flags; /* FIEMAP_FLAG_* flags for request (in/out) */ - __u32 fm_mapped_extents; /* number of extents that were - * mapped (out) */ - __u32 fm_extent_count; /* size of fm_extents array (in) */ - __u32 fm_reserved; - struct fiemap_extent fm_extents[0]; /* array of mapped extents (out) */ -}; - - -fm_start, and fm_length specify the logical range within the file -which the process would like mappings for. Extents returned mirror -those on disk - that is, the logical offset of the 1st returned extent -may start before fm_start, and the range covered by the last returned -extent may end after fm_length. All offsets and lengths are in bytes. - -Certain flags to modify the way in which mappings are looked up can be -set in fm_flags. If the kernel doesn't understand some particular -flags, it will return EBADR and the contents of fm_flags will contain -the set of flags which caused the error. If the kernel is compatible -with all flags passed, the contents of fm_flags will be unmodified. -It is up to userspace to determine whether rejection of a particular -flag is fatal to its operation. This scheme is intended to allow the -fiemap interface to grow in the future but without losing -compatibility with old software. - -fm_extent_count specifies the number of elements in the fm_extents[] array -that can be used to return extents. If fm_extent_count is zero, then the -fm_extents[] array is ignored (no extents will be returned), and the -fm_mapped_extents count will hold the number of extents needed in -fm_extents[] to hold the file's current mapping. Note that there is -nothing to prevent the file from changing between calls to FIEMAP. - -The following flags can be set in fm_flags: - -* FIEMAP_FLAG_SYNC -If this flag is set, the kernel will sync the file before mapping extents. - -* FIEMAP_FLAG_XATTR -If this flag is set, the extents returned will describe the inodes -extended attribute lookup tree, instead of its data tree. - - -Extent Mapping --------------- - -Extent information is returned within the embedded fm_extents array -which userspace must allocate along with the fiemap structure. The -number of elements in the fiemap_extents[] array should be passed via -fm_extent_count. The number of extents mapped by kernel will be -returned via fm_mapped_extents. If the number of fiemap_extents -allocated is less than would be required to map the requested range, -the maximum number of extents that can be mapped in the fm_extent[] -array will be returned and fm_mapped_extents will be equal to -fm_extent_count. In that case, the last extent in the array will not -complete the requested range and will not have the FIEMAP_EXTENT_LAST -flag set (see the next section on extent flags). - -Each extent is described by a single fiemap_extent structure as -returned in fm_extents. - -struct fiemap_extent { - __u64 fe_logical; /* logical offset in bytes for the start of - * the extent */ - __u64 fe_physical; /* physical offset in bytes for the start - * of the extent */ - __u64 fe_length; /* length in bytes for the extent */ - __u64 fe_reserved64[2]; - __u32 fe_flags; /* FIEMAP_EXTENT_* flags for this extent */ - __u32 fe_reserved[3]; -}; - -All offsets and lengths are in bytes and mirror those on disk. It is valid -for an extents logical offset to start before the request or its logical -length to extend past the request. Unless FIEMAP_EXTENT_NOT_ALIGNED is -returned, fe_logical, fe_physical, and fe_length will be aligned to the -block size of the file system. With the exception of extents flagged as -FIEMAP_EXTENT_MERGED, adjacent extents will not be merged. - -The fe_flags field contains flags which describe the extent returned. -A special flag, FIEMAP_EXTENT_LAST is always set on the last extent in -the file so that the process making fiemap calls can determine when no -more extents are available, without having to call the ioctl again. - -Some flags are intentionally vague and will always be set in the -presence of other more specific flags. This way a program looking for -a general property does not have to know all existing and future flags -which imply that property. - -For example, if FIEMAP_EXTENT_DATA_INLINE or FIEMAP_EXTENT_DATA_TAIL -are set, FIEMAP_EXTENT_NOT_ALIGNED will also be set. A program looking -for inline or tail-packed data can key on the specific flag. Software -which simply cares not to try operating on non-aligned extents -however, can just key on FIEMAP_EXTENT_NOT_ALIGNED, and not have to -worry about all present and future flags which might imply unaligned -data. Note that the opposite is not true - it would be valid for -FIEMAP_EXTENT_NOT_ALIGNED to appear alone. - -* FIEMAP_EXTENT_LAST -This is generally the last extent in the file. A mapping attempt past -this extent may return nothing. Some implementations set this flag to -indicate this extent is the last one in the range queried by the user -(via fiemap->fm_length). - -* FIEMAP_EXTENT_UNKNOWN -The location of this extent is currently unknown. This may indicate -the data is stored on an inaccessible volume or that no storage has -been allocated for the file yet. - -* FIEMAP_EXTENT_DELALLOC - - This will also set FIEMAP_EXTENT_UNKNOWN. -Delayed allocation - while there is data for this extent, its -physical location has not been allocated yet. - -* FIEMAP_EXTENT_ENCODED -This extent does not consist of plain filesystem blocks but is -encoded (e.g. encrypted or compressed). Reading the data in this -extent via I/O to the block device will have undefined results. - -Note that it is *always* undefined to try to update the data -in-place by writing to the indicated location without the -assistance of the filesystem, or to access the data using the -information returned by the FIEMAP interface while the filesystem -is mounted. In other words, user applications may only read the -extent data via I/O to the block device while the filesystem is -unmounted, and then only if the FIEMAP_EXTENT_ENCODED flag is -clear; user applications must not try reading or writing to the -filesystem via the block device under any other circumstances. - -* FIEMAP_EXTENT_DATA_ENCRYPTED - - This will also set FIEMAP_EXTENT_ENCODED -The data in this extent has been encrypted by the file system. - -* FIEMAP_EXTENT_NOT_ALIGNED -Extent offsets and length are not guaranteed to be block aligned. - -* FIEMAP_EXTENT_DATA_INLINE - This will also set FIEMAP_EXTENT_NOT_ALIGNED -Data is located within a meta data block. - -* FIEMAP_EXTENT_DATA_TAIL - This will also set FIEMAP_EXTENT_NOT_ALIGNED -Data is packed into a block with data from other files. - -* FIEMAP_EXTENT_UNWRITTEN -Unwritten extent - the extent is allocated but its data has not been -initialized. This indicates the extent's data will be all zero if read -through the filesystem but the contents are undefined if read directly from -the device. - -* FIEMAP_EXTENT_MERGED -This will be set when a file does not support extents, i.e., it uses a block -based addressing scheme. Since returning an extent for each block back to -userspace would be highly inefficient, the kernel will try to merge most -adjacent blocks into 'extents'. - - -VFS -> File System Implementation ---------------------------------- - -File systems wishing to support fiemap must implement a ->fiemap callback on -their inode_operations structure. The fs ->fiemap call is responsible for -defining its set of supported fiemap flags, and calling a helper function on -each discovered extent: - -struct inode_operations { - ... - - int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, - u64 len); - -->fiemap is passed struct fiemap_extent_info which describes the -fiemap request: - -struct fiemap_extent_info { - unsigned int fi_flags; /* Flags as passed from user */ - unsigned int fi_extents_mapped; /* Number of mapped extents */ - unsigned int fi_extents_max; /* Size of fiemap_extent array */ - struct fiemap_extent *fi_extents_start; /* Start of fiemap_extent array */ -}; - -It is intended that the file system should not need to access any of this -structure directly. Filesystem handlers should be tolerant to signals and return -EINTR once fatal signal received. - - -Flag checking should be done at the beginning of the ->fiemap callback via the -fiemap_check_flags() helper: - -int fiemap_check_flags(struct fiemap_extent_info *fieinfo, u32 fs_flags); - -The struct fieinfo should be passed in as received from ioctl_fiemap(). The -set of fiemap flags which the fs understands should be passed via fs_flags. If -fiemap_check_flags finds invalid user flags, it will place the bad values in -fieinfo->fi_flags and return -EBADR. If the file system gets -EBADR, from -fiemap_check_flags(), it should immediately exit, returning that error back to -ioctl_fiemap(). - - -For each extent in the request range, the file system should call -the helper function, fiemap_fill_next_extent(): - -int fiemap_fill_next_extent(struct fiemap_extent_info *info, u64 logical, - u64 phys, u64 len, u32 flags, u32 dev); - -fiemap_fill_next_extent() will use the passed values to populate the -next free extent in the fm_extents array. 'General' extent flags will -automatically be set from specific flags on behalf of the calling file -system so that the userspace API is not broken. - -fiemap_fill_next_extent() returns 0 on success, and 1 when the -user-supplied fm_extents array is full. If an error is encountered -while copying the extent to user memory, -EFAULT will be returned.
diff --git a/Documentation/filesystems/files.rst b/Documentation/filesystems/files.rst new file mode 100644 index 0000000..cbf8e57 --- /dev/null +++ b/Documentation/filesystems/files.rst
@@ -0,0 +1,128 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================== +File management in the Linux kernel +=================================== + +This document describes how locking for files (struct file) +and file descriptor table (struct files) works. + +Up until 2.6.12, the file descriptor table has been protected +with a lock (files->file_lock) and reference count (files->count). +->file_lock protected accesses to all the file related fields +of the table. ->count was used for sharing the file descriptor +table between tasks cloned with CLONE_FILES flag. Typically +this would be the case for posix threads. As with the common +refcounting model in the kernel, the last task doing +a put_files_struct() frees the file descriptor (fd) table. +The files (struct file) themselves are protected using +reference count (->f_count). + +In the new lock-free model of file descriptor management, +the reference counting is similar, but the locking is +based on RCU. The file descriptor table contains multiple +elements - the fd sets (open_fds and close_on_exec, the +array of file pointers, the sizes of the sets and the array +etc.). In order for the updates to appear atomic to +a lock-free reader, all the elements of the file descriptor +table are in a separate structure - struct fdtable. +files_struct contains a pointer to struct fdtable through +which the actual fd table is accessed. Initially the +fdtable is embedded in files_struct itself. On a subsequent +expansion of fdtable, a new fdtable structure is allocated +and files->fdtab points to the new structure. The fdtable +structure is freed with RCU and lock-free readers either +see the old fdtable or the new fdtable making the update +appear atomic. Here are the locking rules for +the fdtable structure - + +1. All references to the fdtable must be done through + the files_fdtable() macro:: + + struct fdtable *fdt; + + rcu_read_lock(); + + fdt = files_fdtable(files); + .... + if (n <= fdt->max_fds) + .... + ... + rcu_read_unlock(); + + files_fdtable() uses rcu_dereference() macro which takes care of + the memory barrier requirements for lock-free dereference. + The fdtable pointer must be read within the read-side + critical section. + +2. Reading of the fdtable as described above must be protected + by rcu_read_lock()/rcu_read_unlock(). + +3. For any update to the fd table, files->file_lock must + be held. + +4. To look up the file structure given an fd, a reader + must use either fcheck() or fcheck_files() APIs. These + take care of barrier requirements due to lock-free lookup. + + An example:: + + struct file *file; + + rcu_read_lock(); + file = fcheck(fd); + if (file) { + ... + } + .... + rcu_read_unlock(); + +5. Handling of the file structures is special. Since the look-up + of the fd (fget()/fget_light()) are lock-free, it is possible + that look-up may race with the last put() operation on the + file structure. This is avoided using atomic_long_inc_not_zero() + on ->f_count:: + + rcu_read_lock(); + file = fcheck_files(files, fd); + if (file) { + if (atomic_long_inc_not_zero(&file->f_count)) + *fput_needed = 1; + else + /* Didn't get the reference, someone's freed */ + file = NULL; + } + rcu_read_unlock(); + .... + return file; + + atomic_long_inc_not_zero() detects if refcounts is already zero or + goes to zero during increment. If it does, we fail + fget()/fget_light(). + +6. Since both fdtable and file structures can be looked up + lock-free, they must be installed using rcu_assign_pointer() + API. If they are looked up lock-free, rcu_dereference() + must be used. However it is advisable to use files_fdtable() + and fcheck()/fcheck_files() which take care of these issues. + +7. While updating, the fdtable pointer must be looked up while + holding files->file_lock. If ->file_lock is dropped, then + another thread expand the files thereby creating a new + fdtable and making the earlier fdtable pointer stale. + + For example:: + + spin_lock(&files->file_lock); + fd = locate_fd(files, file, start); + if (fd >= 0) { + /* locate_fd() may have expanded fdtable, load the ptr */ + fdt = files_fdtable(files); + __set_open_fd(fd, fdt); + __clear_close_on_exec(fd, fdt); + spin_unlock(&files->file_lock); + ..... + + Since locate_fd() can drop ->file_lock (and reacquire ->file_lock), + the fdtable pointer (fdt) must be loaded after locate_fd(). +
diff --git a/Documentation/filesystems/files.txt b/Documentation/filesystems/files.txt deleted file mode 100644 index 46dfc6b..0000000 --- a/Documentation/filesystems/files.txt +++ /dev/null
@@ -1,123 +0,0 @@ -File management in the Linux kernel ------------------------------------ - -This document describes how locking for files (struct file) -and file descriptor table (struct files) works. - -Up until 2.6.12, the file descriptor table has been protected -with a lock (files->file_lock) and reference count (files->count). -->file_lock protected accesses to all the file related fields -of the table. ->count was used for sharing the file descriptor -table between tasks cloned with CLONE_FILES flag. Typically -this would be the case for posix threads. As with the common -refcounting model in the kernel, the last task doing -a put_files_struct() frees the file descriptor (fd) table. -The files (struct file) themselves are protected using -reference count (->f_count). - -In the new lock-free model of file descriptor management, -the reference counting is similar, but the locking is -based on RCU. The file descriptor table contains multiple -elements - the fd sets (open_fds and close_on_exec, the -array of file pointers, the sizes of the sets and the array -etc.). In order for the updates to appear atomic to -a lock-free reader, all the elements of the file descriptor -table are in a separate structure - struct fdtable. -files_struct contains a pointer to struct fdtable through -which the actual fd table is accessed. Initially the -fdtable is embedded in files_struct itself. On a subsequent -expansion of fdtable, a new fdtable structure is allocated -and files->fdtab points to the new structure. The fdtable -structure is freed with RCU and lock-free readers either -see the old fdtable or the new fdtable making the update -appear atomic. Here are the locking rules for -the fdtable structure - - -1. All references to the fdtable must be done through - the files_fdtable() macro : - - struct fdtable *fdt; - - rcu_read_lock(); - - fdt = files_fdtable(files); - .... - if (n <= fdt->max_fds) - .... - ... - rcu_read_unlock(); - - files_fdtable() uses rcu_dereference() macro which takes care of - the memory barrier requirements for lock-free dereference. - The fdtable pointer must be read within the read-side - critical section. - -2. Reading of the fdtable as described above must be protected - by rcu_read_lock()/rcu_read_unlock(). - -3. For any update to the fd table, files->file_lock must - be held. - -4. To look up the file structure given an fd, a reader - must use either fcheck() or fcheck_files() APIs. These - take care of barrier requirements due to lock-free lookup. - An example : - - struct file *file; - - rcu_read_lock(); - file = fcheck(fd); - if (file) { - ... - } - .... - rcu_read_unlock(); - -5. Handling of the file structures is special. Since the look-up - of the fd (fget()/fget_light()) are lock-free, it is possible - that look-up may race with the last put() operation on the - file structure. This is avoided using atomic_long_inc_not_zero() - on ->f_count : - - rcu_read_lock(); - file = fcheck_files(files, fd); - if (file) { - if (atomic_long_inc_not_zero(&file->f_count)) - *fput_needed = 1; - else - /* Didn't get the reference, someone's freed */ - file = NULL; - } - rcu_read_unlock(); - .... - return file; - - atomic_long_inc_not_zero() detects if refcounts is already zero or - goes to zero during increment. If it does, we fail - fget()/fget_light(). - -6. Since both fdtable and file structures can be looked up - lock-free, they must be installed using rcu_assign_pointer() - API. If they are looked up lock-free, rcu_dereference() - must be used. However it is advisable to use files_fdtable() - and fcheck()/fcheck_files() which take care of these issues. - -7. While updating, the fdtable pointer must be looked up while - holding files->file_lock. If ->file_lock is dropped, then - another thread expand the files thereby creating a new - fdtable and making the earlier fdtable pointer stale. - For example : - - spin_lock(&files->file_lock); - fd = locate_fd(files, file, start); - if (fd >= 0) { - /* locate_fd() may have expanded fdtable, load the ptr */ - fdt = files_fdtable(files); - __set_open_fd(fd, fdt); - __clear_close_on_exec(fd, fdt); - spin_unlock(&files->file_lock); - ..... - - Since locate_fd() can drop ->file_lock (and reacquire ->file_lock), - the fdtable pointer (fdt) must be loaded after locate_fd(). -
diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index aa07211..f517af8 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst
@@ -292,8 +292,22 @@ Consequently, shrinking the filesystem may not be allowed. This format is optimized for use with inline encryption hardware -compliant with the UFS or eMMC standards, which support only 64 IV -bits per I/O request and may have only a small number of keyslots. +compliant with the UFS standard, which supports only 64 IV bits per +I/O request and may have only a small number of keyslots. + +IV_INO_LBLK_32 policies +----------------------- + +IV_INO_LBLK_32 policies work like IV_INO_LBLK_64, except that for +IV_INO_LBLK_32, the inode number is hashed with SipHash-2-4 (where the +SipHash key is derived from the master key) and added to the file +logical block number mod 2^32 to produce a 32-bit IV. + +This format is optimized for use with inline encryption hardware +compliant with the eMMC v5.2 standard, which supports only 32 IV bits +per I/O request and may have only a small number of keyslots. This +format results in some level of IV reuse, so it should only be used +when necessary due to hardware limitations. Key identifiers --------------- @@ -369,6 +383,10 @@ to 32 bits and is placed in bits 0-31 of the IV. The inode number (which is also limited to 32 bits) is placed in bits 32-63. +- With `IV_INO_LBLK_32 policies`_, the logical block number is limited + to 32 bits and is placed in bits 0-31 of the IV. The inode number + is then hashed and added mod 2^32. + Note that because file logical block numbers are included in the IVs, filesystems must enforce that blocks are never shifted around within encrypted files, e.g. via "collapse range" or "insert range". @@ -465,8 +483,15 @@ (0x3). - FSCRYPT_POLICY_FLAG_DIRECT_KEY: See `DIRECT_KEY policies`_. - FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64: See `IV_INO_LBLK_64 - policies`_. This is mutually exclusive with DIRECT_KEY and is not - supported on v1 policies. + policies`_. + - FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32: See `IV_INO_LBLK_32 + policies`_. + + v1 encryption policies only support the PAD_* and DIRECT_KEY flags. + The other flags are only supported by v2 encryption policies. + + The DIRECT_KEY, IV_INO_LBLK_64, and IV_INO_LBLK_32 flags are + mutually exclusive. - For v2 encryption policies, ``__reserved`` must be zeroed.
diff --git a/Documentation/filesystems/fuse-io.rst b/Documentation/filesystems/fuse-io.rst new file mode 100644 index 0000000..255a368 --- /dev/null +++ b/Documentation/filesystems/fuse-io.rst
@@ -0,0 +1,44 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============== +Fuse I/O Modes +============== + +Fuse supports the following I/O modes: + +- direct-io +- cached + + write-through + + writeback-cache + +The direct-io mode can be selected with the FOPEN_DIRECT_IO flag in the +FUSE_OPEN reply. + +In direct-io mode the page cache is completely bypassed for reads and writes. +No read-ahead takes place. Shared mmap is disabled. + +In cached mode reads may be satisfied from the page cache, and data may be +read-ahead by the kernel to fill the cache. The cache is always kept consistent +after any writes to the file. All mmap modes are supported. + +The cached mode has two sub modes controlling how writes are handled. The +write-through mode is the default and is supported on all kernels. The +writeback-cache mode may be selected by the FUSE_WRITEBACK_CACHE flag in the +FUSE_INIT reply. + +In write-through mode each write is immediately sent to userspace as one or more +WRITE requests, as well as updating any cached pages (and caching previously +uncached, but fully written pages). No READ requests are ever sent for writes, +so when an uncached page is partially written, the page is discarded. + +In writeback-cache mode (enabled by the FUSE_WRITEBACK_CACHE flag) writes go to +the cache only, which means that the write(2) syscall can often complete very +fast. Dirty pages are written back implicitly (background writeback or page +reclaim on memory pressure) or explicitly (invoked by close(2), fsync(2) and +when the last ref to the file is being released on munmap(2)). This mode +assumes that all changes to the filesystem go through the FUSE kernel module +(size and atime/ctime/mtime attributes are kept up-to-date by the kernel), so +it's generally not suitable for network filesystems. If a partial page is +written, then the page needs to be first read from userspace. This means, that +even for files opened for O_WRONLY it is possible that READ requests will be +generated by the kernel.
diff --git a/Documentation/filesystems/fuse-io.txt b/Documentation/filesystems/fuse-io.txt deleted file mode 100644 index 07b8f73f..0000000 --- a/Documentation/filesystems/fuse-io.txt +++ /dev/null
@@ -1,38 +0,0 @@ -Fuse supports the following I/O modes: - -- direct-io -- cached - + write-through - + writeback-cache - -The direct-io mode can be selected with the FOPEN_DIRECT_IO flag in the -FUSE_OPEN reply. - -In direct-io mode the page cache is completely bypassed for reads and writes. -No read-ahead takes place. Shared mmap is disabled. - -In cached mode reads may be satisfied from the page cache, and data may be -read-ahead by the kernel to fill the cache. The cache is always kept consistent -after any writes to the file. All mmap modes are supported. - -The cached mode has two sub modes controlling how writes are handled. The -write-through mode is the default and is supported on all kernels. The -writeback-cache mode may be selected by the FUSE_WRITEBACK_CACHE flag in the -FUSE_INIT reply. - -In write-through mode each write is immediately sent to userspace as one or more -WRITE requests, as well as updating any cached pages (and caching previously -uncached, but fully written pages). No READ requests are ever sent for writes, -so when an uncached page is partially written, the page is discarded. - -In writeback-cache mode (enabled by the FUSE_WRITEBACK_CACHE flag) writes go to -the cache only, which means that the write(2) syscall can often complete very -fast. Dirty pages are written back implicitly (background writeback or page -reclaim on memory pressure) or explicitly (invoked by close(2), fsync(2) and -when the last ref to the file is being released on munmap(2)). This mode -assumes that all changes to the filesystem go through the FUSE kernel module -(size and atime/ctime/mtime attributes are kept up-to-date by the kernel), so -it's generally not suitable for network filesystems. If a partial page is -written, then the page needs to be first read from userspace. This means, that -even for files opened for O_WRONLY it is possible that READ requests will be -generated by the kernel.
diff --git a/Documentation/filesystems/gfs2-glocks.rst b/Documentation/filesystems/gfs2-glocks.rst new file mode 100644 index 0000000..d14f230 --- /dev/null +++ b/Documentation/filesystems/gfs2-glocks.rst
@@ -0,0 +1,253 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================ +Glock internal locking rules +============================ + +This documents the basic principles of the glock state machine +internals. Each glock (struct gfs2_glock in fs/gfs2/incore.h) +has two main (internal) locks: + + 1. A spinlock (gl_lockref.lock) which protects the internal state such + as gl_state, gl_target and the list of holders (gl_holders) + 2. A non-blocking bit lock, GLF_LOCK, which is used to prevent other + threads from making calls to the DLM, etc. at the same time. If a + thread takes this lock, it must then call run_queue (usually via the + workqueue) when it releases it in order to ensure any pending tasks + are completed. + +The gl_holders list contains all the queued lock requests (not +just the holders) associated with the glock. If there are any +held locks, then they will be contiguous entries at the head +of the list. Locks are granted in strictly the order that they +are queued, except for those marked LM_FLAG_PRIORITY which are +used only during recovery, and even then only for journal locks. + +There are three lock states that users of the glock layer can request, +namely shared (SH), deferred (DF) and exclusive (EX). Those translate +to the following DLM lock modes: + +========== ====== ===================================================== +Glock mode DLM lock mode +========== ====== ===================================================== + UN IV/NL Unlocked (no DLM lock associated with glock) or NL + SH PR (Protected read) + DF CW (Concurrent write) + EX EX (Exclusive) +========== ====== ===================================================== + +Thus DF is basically a shared mode which is incompatible with the "normal" +shared lock mode, SH. In GFS2 the DF mode is used exclusively for direct I/O +operations. The glocks are basically a lock plus some routines which deal +with cache management. The following rules apply for the cache: + +========== ========== ============== ========== ============== +Glock mode Cache data Cache Metadata Dirty Data Dirty Metadata +========== ========== ============== ========== ============== + UN No No No No + SH Yes Yes No No + DF No Yes No No + EX Yes Yes Yes Yes +========== ========== ============== ========== ============== + +These rules are implemented using the various glock operations which +are defined for each type of glock. Not all types of glocks use +all the modes. Only inode glocks use the DF mode for example. + +Table of glock operations and per type constants: + +============= ============================================================= +Field Purpose +============= ============================================================= +go_xmote_th Called before remote state change (e.g. to sync dirty data) +go_xmote_bh Called after remote state change (e.g. to refill cache) +go_inval Called if remote state change requires invalidating the cache +go_demote_ok Returns boolean value of whether its ok to demote a glock + (e.g. checks timeout, and that there is no cached data) +go_lock Called for the first local holder of a lock +go_unlock Called on the final local unlock of a lock +go_dump Called to print content of object for debugfs file, or on + error to dump glock to the log. +go_type The type of the glock, ``LM_TYPE_*`` +go_callback Called if the DLM sends a callback to drop this lock +go_flags GLOF_ASPACE is set, if the glock has an address space + associated with it +============= ============================================================= + +The minimum hold time for each lock is the time after a remote lock +grant for which we ignore remote demote requests. This is in order to +prevent a situation where locks are being bounced around the cluster +from node to node with none of the nodes making any progress. This +tends to show up most with shared mmaped files which are being written +to by multiple nodes. By delaying the demotion in response to a +remote callback, that gives the userspace program time to make +some progress before the pages are unmapped. + +There is a plan to try and remove the go_lock and go_unlock callbacks +if possible, in order to try and speed up the fast path though the locking. +Also, eventually we hope to make the glock "EX" mode locally shared +such that any local locking will be done with the i_mutex as required +rather than via the glock. + +Locking rules for glock operations: + +============= ====================== ============================= +Operation GLF_LOCK bit lock held gl_lockref.lock spinlock held +============= ====================== ============================= +go_xmote_th Yes No +go_xmote_bh Yes No +go_inval Yes No +go_demote_ok Sometimes Yes +go_lock Yes No +go_unlock Yes No +go_dump Sometimes Yes +go_callback Sometimes (N/A) Yes +============= ====================== ============================= + +.. Note:: + + Operations must not drop either the bit lock or the spinlock + if its held on entry. go_dump and do_demote_ok must never block. + Note that go_dump will only be called if the glock's state + indicates that it is caching uptodate data. + +Glock locking order within GFS2: + + 1. i_rwsem (if required) + 2. Rename glock (for rename only) + 3. Inode glock(s) + (Parents before children, inodes at "same level" with same parent in + lock number order) + 4. Rgrp glock(s) (for (de)allocation operations) + 5. Transaction glock (via gfs2_trans_begin) for non-read operations + 6. i_rw_mutex (if required) + 7. Page lock (always last, very important!) + +There are two glocks per inode. One deals with access to the inode +itself (locking order as above), and the other, known as the iopen +glock is used in conjunction with the i_nlink field in the inode to +determine the lifetime of the inode in question. Locking of inodes +is on a per-inode basis. Locking of rgrps is on a per rgrp basis. +In general we prefer to lock local locks prior to cluster locks. + +Glock Statistics +---------------- + +The stats are divided into two sets: those relating to the +super block and those relating to an individual glock. The +super block stats are done on a per cpu basis in order to +try and reduce the overhead of gathering them. They are also +further divided by glock type. All timings are in nanoseconds. + +In the case of both the super block and glock statistics, +the same information is gathered in each case. The super +block timing statistics are used to provide default values for +the glock timing statistics, so that newly created glocks +should have, as far as possible, a sensible starting point. +The per-glock counters are initialised to zero when the +glock is created. The per-glock statistics are lost when +the glock is ejected from memory. + +The statistics are divided into three pairs of mean and +variance, plus two counters. The mean/variance pairs are +smoothed exponential estimates and the algorithm used is +one which will be very familiar to those used to calculation +of round trip times in network code. See "TCP/IP Illustrated, +Volume 1", W. Richard Stevens, sect 21.3, "Round-Trip Time Measurement", +p. 299 and onwards. Also, Volume 2, Sect. 25.10, p. 838 and onwards. +Unlike the TCP/IP Illustrated case, the mean and variance are +not scaled, but are in units of integer nanoseconds. + +The three pairs of mean/variance measure the following +things: + + 1. DLM lock time (non-blocking requests) + 2. DLM lock time (blocking requests) + 3. Inter-request time (again to the DLM) + +A non-blocking request is one which will complete right +away, whatever the state of the DLM lock in question. That +currently means any requests when (a) the current state of +the lock is exclusive, i.e. a lock demotion (b) the requested +state is either null or unlocked (again, a demotion) or (c) the +"try lock" flag is set. A blocking request covers all the other +lock requests. + +There are two counters. The first is there primarily to show +how many lock requests have been made, and thus how much data +has gone into the mean/variance calculations. The other counter +is counting queuing of holders at the top layer of the glock +code. Hopefully that number will be a lot larger than the number +of dlm lock requests issued. + +So why gather these statistics? There are several reasons +we'd like to get a better idea of these timings: + +1. To be able to better set the glock "min hold time" +2. To spot performance issues more easily +3. To improve the algorithm for selecting resource groups for + allocation (to base it on lock wait time, rather than blindly + using a "try lock") + +Due to the smoothing action of the updates, a step change in +some input quantity being sampled will only fully be taken +into account after 8 samples (or 4 for the variance) and this +needs to be carefully considered when interpreting the +results. + +Knowing both the time it takes a lock request to complete and +the average time between lock requests for a glock means we +can compute the total percentage of the time for which the +node is able to use a glock vs. time that the rest of the +cluster has its share. That will be very useful when setting +the lock min hold time. + +Great care has been taken to ensure that we +measure exactly the quantities that we want, as accurately +as possible. There are always inaccuracies in any +measuring system, but I hope this is as accurate as we +can reasonably make it. + +Per sb stats can be found here:: + + /sys/kernel/debug/gfs2/<fsname>/sbstats + +Per glock stats can be found here:: + + /sys/kernel/debug/gfs2/<fsname>/glstats + +Assuming that debugfs is mounted on /sys/kernel/debug and also +that <fsname> is replaced with the name of the gfs2 filesystem +in question. + +The abbreviations used in the output as are follows: + +========= ================================================================ +srtt Smoothed round trip time for non blocking dlm requests +srttvar Variance estimate for srtt +srttb Smoothed round trip time for (potentially) blocking dlm requests +srttvarb Variance estimate for srttb +sirt Smoothed inter request time (for dlm requests) +sirtvar Variance estimate for sirt +dlm Number of dlm requests made (dcnt in glstats file) +queue Number of glock requests queued (qcnt in glstats file) +========= ================================================================ + +The sbstats file contains a set of these stats for each glock type (so 8 lines +for each type) and for each cpu (one column per cpu). The glstats file contains +a set of these stats for each glock in a similar format to the glocks file, but +using the format mean/variance for each of the timing stats. + +The gfs2_glock_lock_time tracepoint prints out the current values of the stats +for the glock in question, along with some addition information on each dlm +reply that is received: + +====== ======================================= +status The status of the dlm request +flags The dlm request flags +tdiff The time taken by this specific request +====== ======================================= + +(remaining fields as per above list) + +
diff --git a/Documentation/filesystems/gfs2-glocks.txt b/Documentation/filesystems/gfs2-glocks.txt deleted file mode 100644 index 7059623..0000000 --- a/Documentation/filesystems/gfs2-glocks.txt +++ /dev/null
@@ -1,232 +0,0 @@ - Glock internal locking rules - ------------------------------ - -This documents the basic principles of the glock state machine -internals. Each glock (struct gfs2_glock in fs/gfs2/incore.h) -has two main (internal) locks: - - 1. A spinlock (gl_lockref.lock) which protects the internal state such - as gl_state, gl_target and the list of holders (gl_holders) - 2. A non-blocking bit lock, GLF_LOCK, which is used to prevent other - threads from making calls to the DLM, etc. at the same time. If a - thread takes this lock, it must then call run_queue (usually via the - workqueue) when it releases it in order to ensure any pending tasks - are completed. - -The gl_holders list contains all the queued lock requests (not -just the holders) associated with the glock. If there are any -held locks, then they will be contiguous entries at the head -of the list. Locks are granted in strictly the order that they -are queued, except for those marked LM_FLAG_PRIORITY which are -used only during recovery, and even then only for journal locks. - -There are three lock states that users of the glock layer can request, -namely shared (SH), deferred (DF) and exclusive (EX). Those translate -to the following DLM lock modes: - -Glock mode | DLM lock mode ------------------------------- - UN | IV/NL Unlocked (no DLM lock associated with glock) or NL - SH | PR (Protected read) - DF | CW (Concurrent write) - EX | EX (Exclusive) - -Thus DF is basically a shared mode which is incompatible with the "normal" -shared lock mode, SH. In GFS2 the DF mode is used exclusively for direct I/O -operations. The glocks are basically a lock plus some routines which deal -with cache management. The following rules apply for the cache: - -Glock mode | Cache data | Cache Metadata | Dirty Data | Dirty Metadata --------------------------------------------------------------------------- - UN | No | No | No | No - SH | Yes | Yes | No | No - DF | No | Yes | No | No - EX | Yes | Yes | Yes | Yes - -These rules are implemented using the various glock operations which -are defined for each type of glock. Not all types of glocks use -all the modes. Only inode glocks use the DF mode for example. - -Table of glock operations and per type constants: - -Field | Purpose ----------------------------------------------------------------------------- -go_xmote_th | Called before remote state change (e.g. to sync dirty data) -go_xmote_bh | Called after remote state change (e.g. to refill cache) -go_inval | Called if remote state change requires invalidating the cache -go_demote_ok | Returns boolean value of whether its ok to demote a glock - | (e.g. checks timeout, and that there is no cached data) -go_lock | Called for the first local holder of a lock -go_unlock | Called on the final local unlock of a lock -go_dump | Called to print content of object for debugfs file, or on - | error to dump glock to the log. -go_type | The type of the glock, LM_TYPE_..... -go_callback | Called if the DLM sends a callback to drop this lock -go_flags | GLOF_ASPACE is set, if the glock has an address space - | associated with it - -The minimum hold time for each lock is the time after a remote lock -grant for which we ignore remote demote requests. This is in order to -prevent a situation where locks are being bounced around the cluster -from node to node with none of the nodes making any progress. This -tends to show up most with shared mmaped files which are being written -to by multiple nodes. By delaying the demotion in response to a -remote callback, that gives the userspace program time to make -some progress before the pages are unmapped. - -There is a plan to try and remove the go_lock and go_unlock callbacks -if possible, in order to try and speed up the fast path though the locking. -Also, eventually we hope to make the glock "EX" mode locally shared -such that any local locking will be done with the i_mutex as required -rather than via the glock. - -Locking rules for glock operations: - -Operation | GLF_LOCK bit lock held | gl_lockref.lock spinlock held -------------------------------------------------------------------------- -go_xmote_th | Yes | No -go_xmote_bh | Yes | No -go_inval | Yes | No -go_demote_ok | Sometimes | Yes -go_lock | Yes | No -go_unlock | Yes | No -go_dump | Sometimes | Yes -go_callback | Sometimes (N/A) | Yes - -N.B. Operations must not drop either the bit lock or the spinlock -if its held on entry. go_dump and do_demote_ok must never block. -Note that go_dump will only be called if the glock's state -indicates that it is caching uptodate data. - -Glock locking order within GFS2: - - 1. i_rwsem (if required) - 2. Rename glock (for rename only) - 3. Inode glock(s) - (Parents before children, inodes at "same level" with same parent in - lock number order) - 4. Rgrp glock(s) (for (de)allocation operations) - 5. Transaction glock (via gfs2_trans_begin) for non-read operations - 6. i_rw_mutex (if required) - 7. Page lock (always last, very important!) - -There are two glocks per inode. One deals with access to the inode -itself (locking order as above), and the other, known as the iopen -glock is used in conjunction with the i_nlink field in the inode to -determine the lifetime of the inode in question. Locking of inodes -is on a per-inode basis. Locking of rgrps is on a per rgrp basis. -In general we prefer to lock local locks prior to cluster locks. - - Glock Statistics - ------------------ - -The stats are divided into two sets: those relating to the -super block and those relating to an individual glock. The -super block stats are done on a per cpu basis in order to -try and reduce the overhead of gathering them. They are also -further divided by glock type. All timings are in nanoseconds. - -In the case of both the super block and glock statistics, -the same information is gathered in each case. The super -block timing statistics are used to provide default values for -the glock timing statistics, so that newly created glocks -should have, as far as possible, a sensible starting point. -The per-glock counters are initialised to zero when the -glock is created. The per-glock statistics are lost when -the glock is ejected from memory. - -The statistics are divided into three pairs of mean and -variance, plus two counters. The mean/variance pairs are -smoothed exponential estimates and the algorithm used is -one which will be very familiar to those used to calculation -of round trip times in network code. See "TCP/IP Illustrated, -Volume 1", W. Richard Stevens, sect 21.3, "Round-Trip Time Measurement", -p. 299 and onwards. Also, Volume 2, Sect. 25.10, p. 838 and onwards. -Unlike the TCP/IP Illustrated case, the mean and variance are -not scaled, but are in units of integer nanoseconds. - -The three pairs of mean/variance measure the following -things: - - 1. DLM lock time (non-blocking requests) - 2. DLM lock time (blocking requests) - 3. Inter-request time (again to the DLM) - -A non-blocking request is one which will complete right -away, whatever the state of the DLM lock in question. That -currently means any requests when (a) the current state of -the lock is exclusive, i.e. a lock demotion (b) the requested -state is either null or unlocked (again, a demotion) or (c) the -"try lock" flag is set. A blocking request covers all the other -lock requests. - -There are two counters. The first is there primarily to show -how many lock requests have been made, and thus how much data -has gone into the mean/variance calculations. The other counter -is counting queuing of holders at the top layer of the glock -code. Hopefully that number will be a lot larger than the number -of dlm lock requests issued. - -So why gather these statistics? There are several reasons -we'd like to get a better idea of these timings: - -1. To be able to better set the glock "min hold time" -2. To spot performance issues more easily -3. To improve the algorithm for selecting resource groups for -allocation (to base it on lock wait time, rather than blindly -using a "try lock") - -Due to the smoothing action of the updates, a step change in -some input quantity being sampled will only fully be taken -into account after 8 samples (or 4 for the variance) and this -needs to be carefully considered when interpreting the -results. - -Knowing both the time it takes a lock request to complete and -the average time between lock requests for a glock means we -can compute the total percentage of the time for which the -node is able to use a glock vs. time that the rest of the -cluster has its share. That will be very useful when setting -the lock min hold time. - -Great care has been taken to ensure that we -measure exactly the quantities that we want, as accurately -as possible. There are always inaccuracies in any -measuring system, but I hope this is as accurate as we -can reasonably make it. - -Per sb stats can be found here: -/sys/kernel/debug/gfs2/<fsname>/sbstats -Per glock stats can be found here: -/sys/kernel/debug/gfs2/<fsname>/glstats - -Assuming that debugfs is mounted on /sys/kernel/debug and also -that <fsname> is replaced with the name of the gfs2 filesystem -in question. - -The abbreviations used in the output as are follows: - -srtt - Smoothed round trip time for non-blocking dlm requests -srttvar - Variance estimate for srtt -srttb - Smoothed round trip time for (potentially) blocking dlm requests -srttvarb - Variance estimate for srttb -sirt - Smoothed inter-request time (for dlm requests) -sirtvar - Variance estimate for sirt -dlm - Number of dlm requests made (dcnt in glstats file) -queue - Number of glock requests queued (qcnt in glstats file) - -The sbstats file contains a set of these stats for each glock type (so 8 lines -for each type) and for each cpu (one column per cpu). The glstats file contains -a set of these stats for each glock in a similar format to the glocks file, but -using the format mean/variance for each of the timing stats. - -The gfs2_glock_lock_time tracepoint prints out the current values of the stats -for the glock in question, along with some addition information on each dlm -reply that is received: - -status - The status of the dlm request -flags - The dlm request flags -tdiff - The time taken by this specific request -(remaining fields as per above list) - -
diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index e7b46da..4c536e6 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst
@@ -24,6 +24,22 @@ splice locking directory-locking + devpts + dnotify + fiemap + files + locks + mandatory-locking + mount_api + quota + seq_file + sharedsubtree + sysfs-pci + sysfs-tagging + + automount-support + + caching/index porting @@ -57,7 +73,10 @@ befs bfs btrfs + cifs/cifsroot ceph + coda + configfs cramfs debugfs dlmfs @@ -69,10 +88,12 @@ f2fs gfs2 gfs2-uevents + gfs2-glocks hfs hfsplus hpfs fuse + fuse-io inotify isofs nilfs2 @@ -88,6 +109,7 @@ ramfs-rootfs-initramfs relay romfs + spufs/index squashfs sysfs sysv-fs @@ -97,4 +119,6 @@ udf virtiofs vfat + xfs-delayed-logging-design + xfs-self-describing-metadata zonefs
diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 5057e4d..318605d 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst
@@ -239,6 +239,7 @@ int (*readpage)(struct file *, struct page *); int (*writepages)(struct address_space *, struct writeback_control *); int (*set_page_dirty)(struct page *page); + void (*readahead)(struct readahead_control *); int (*readpages)(struct file *filp, struct address_space *mapping, struct list_head *pages, unsigned nr_pages); int (*write_begin)(struct file *, struct address_space *mapping, @@ -271,7 +272,8 @@ readpage: yes, unlocks writepages: set_page_dirty no -readpages: +readahead: yes, unlocks +readpages: no write_begin: locks the page exclusive write_end: yes, unlocks exclusive bmap: @@ -295,6 +297,8 @@ ->readpage() unlocks the page, either synchronously or via I/O completion. +->readahead() unlocks the pages that I/O is attempted on like ->readpage(). + ->readpages() populates the pagecache with the passed pages and starts I/O against them. They come unlocked upon I/O completion. @@ -425,6 +429,7 @@ int (*lm_grant)(struct file_lock *, struct file_lock *, int); void (*lm_break)(struct file_lock *); /* break_lease callback */ int (*lm_change)(struct file_lock **, int); + bool (*lm_breaker_owns_lease)(struct file_lock *); locking rules: @@ -435,6 +440,7 @@ lm_grant: no no no lm_break: yes no no lm_change yes no no +lm_breaker_owns_lease: no no no ========== ============= ================= ========= buffer_head @@ -611,7 +617,7 @@ locking rules: ============= ======== =========================== -ops mmap_sem PageLocked(page) +ops mmap_lock PageLocked(page) ============= ======== =========================== open: yes close: yes
diff --git a/Documentation/filesystems/locks.rst b/Documentation/filesystems/locks.rst new file mode 100644 index 0000000..c5ae858 --- /dev/null +++ b/Documentation/filesystems/locks.rst
@@ -0,0 +1,72 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +File Locking Release Notes +========================== + + Andy Walker <andy@lysaker.kvaerner.no> + + 12 May 1997 + + +1. What's New? +============== + +1.1 Broken Flock Emulation +-------------------------- + +The old flock(2) emulation in the kernel was swapped for proper BSD +compatible flock(2) support in the 1.3.x series of kernels. With the +release of the 2.1.x kernel series, support for the old emulation has +been totally removed, so that we don't need to carry this baggage +forever. + +This should not cause problems for anybody, since everybody using a +2.1.x kernel should have updated their C library to a suitable version +anyway (see the file "Documentation/process/changes.rst".) + +1.2 Allow Mixed Locks Again +--------------------------- + +1.2.1 Typical Problems - Sendmail +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Because sendmail was unable to use the old flock() emulation, many sendmail +installations use fcntl() instead of flock(). This is true of Slackware 3.0 +for example. This gave rise to some other subtle problems if sendmail was +configured to rebuild the alias file. Sendmail tried to lock the aliases.dir +file with fcntl() at the same time as the GDBM routines tried to lock this +file with flock(). With pre 1.3.96 kernels this could result in deadlocks that, +over time, or under a very heavy mail load, would eventually cause the kernel +to lock solid with deadlocked processes. + + +1.2.2 The Solution +^^^^^^^^^^^^^^^^^^ +The solution I have chosen, after much experimentation and discussion, +is to make flock() and fcntl() locks oblivious to each other. Both can +exists, and neither will have any effect on the other. + +I wanted the two lock styles to be cooperative, but there were so many +race and deadlock conditions that the current solution was the only +practical one. It puts us in the same position as, for example, SunOS +4.1.x and several other commercial Unices. The only OS's that support +cooperative flock()/fcntl() are those that emulate flock() using +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. +
diff --git a/Documentation/filesystems/locks.txt b/Documentation/filesystems/locks.txt deleted file mode 100644 index 5368690..0000000 --- a/Documentation/filesystems/locks.txt +++ /dev/null
@@ -1,68 +0,0 @@ - File Locking Release Notes - - Andy Walker <andy@lysaker.kvaerner.no> - - 12 May 1997 - - -1. What's New? --------------- - -1.1 Broken Flock Emulation --------------------------- - -The old flock(2) emulation in the kernel was swapped for proper BSD -compatible flock(2) support in the 1.3.x series of kernels. With the -release of the 2.1.x kernel series, support for the old emulation has -been totally removed, so that we don't need to carry this baggage -forever. - -This should not cause problems for anybody, since everybody using a -2.1.x kernel should have updated their C library to a suitable version -anyway (see the file "Documentation/process/changes.rst".) - -1.2 Allow Mixed Locks Again ---------------------------- - -1.2.1 Typical Problems - Sendmail ---------------------------------- -Because sendmail was unable to use the old flock() emulation, many sendmail -installations use fcntl() instead of flock(). This is true of Slackware 3.0 -for example. This gave rise to some other subtle problems if sendmail was -configured to rebuild the alias file. Sendmail tried to lock the aliases.dir -file with fcntl() at the same time as the GDBM routines tried to lock this -file with flock(). With pre 1.3.96 kernels this could result in deadlocks that, -over time, or under a very heavy mail load, would eventually cause the kernel -to lock solid with deadlocked processes. - - -1.2.2 The Solution ------------------- -The solution I have chosen, after much experimentation and discussion, -is to make flock() and fcntl() locks oblivious to each other. Both can -exists, and neither will have any effect on the other. - -I wanted the two lock styles to be cooperative, but there were so many -race and deadlock conditions that the current solution was the only -practical one. It puts us in the same position as, for example, SunOS -4.1.x and several other commercial Unices. The only OS's that support -cooperative flock()/fcntl() are those that emulate flock() using -fcntl(), with all the problems that implies. - - -1.3 Mandatory Locking As A Mount Option ---------------------------------------- - -Mandatory locking, as described in -'Documentation/filesystems/mandatory-locking.txt' 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. -
diff --git a/Documentation/filesystems/mandatory-locking.rst b/Documentation/filesystems/mandatory-locking.rst new file mode 100644 index 0000000..9ce7354 --- /dev/null +++ b/Documentation/filesystems/mandatory-locking.rst
@@ -0,0 +1,188 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================================== +Mandatory File Locking For The Linux Operating System +===================================================== + + Andy Walker <andy@lysaker.kvaerner.no> + + 15 April 1996 + + (Updated September 2007) + +0. Why you should avoid mandatory locking +----------------------------------------- + +The Linux implementation is prey to a number of difficult-to-fix race +conditions which in practice make it not dependable: + + - The write system call checks for a mandatory lock only once + at its start. It is therefore possible for a lock request to + be granted after this check but before the data is modified. + A process may then see file data change even while a mandatory + lock was held. + - Similarly, an exclusive lock may be granted on a file after + the kernel has decided to proceed with a read, but before the + read has actually completed, and the reading process may see + the file data in a state which should not have been visible + to it. + - Similar races make the claimed mutual exclusion between lock + and mmap similarly unreliable. + +1. What is mandatory locking? +------------------------------ + +Mandatory locking is kernel enforced file locking, as opposed to the more usual +cooperative file locking used to guarantee sequential access to files among +processes. File locks are applied using the flock() and fcntl() system calls +(and the lockf() library routine which is a wrapper around fcntl().) It is +normally a process' responsibility to check for locks on a file it wishes to +update, before applying its own lock, updating the file and unlocking it again. +The most commonly used example of this (and in the case of sendmail, the most +troublesome) is access to a user's mailbox. The mail user agent and the mail +transfer agent must guard against updating the mailbox at the same time, and +prevent reading the mailbox while it is being updated. + +In a perfect world all processes would use and honour a cooperative, or +"advisory" locking scheme. However, the world isn't perfect, and there's +a lot of poorly written code out there. + +In trying to address this problem, the designers of System V UNIX came up +with a "mandatory" locking scheme, whereby the operating system kernel would +block attempts by a process to write to a file that another process holds a +"read" -or- "shared" lock on, and block attempts to both read and write to a +file that a process holds a "write " -or- "exclusive" lock on. + +The System V mandatory locking scheme was intended to have as little impact as +possible on existing user code. The scheme is based on marking individual files +as candidates for mandatory locking, and using the existing fcntl()/lockf() +interface for applying locks just as if they were normal, advisory locks. + +.. Note:: + + 1. In saying "file" in the paragraphs above I am actually not telling + the whole truth. System V locking is based on fcntl(). The granularity of + fcntl() is such that it allows the locking of byte ranges in files, in + addition to entire files, so the mandatory locking rules also have byte + level granularity. + + 2. POSIX.1 does not specify any scheme for mandatory locking, despite + borrowing the fcntl() locking scheme from System V. The mandatory locking + scheme is defined by the System V Interface Definition (SVID) Version 3. + +2. Marking a file for mandatory locking +--------------------------------------- + +A file is marked as a candidate for mandatory locking by setting the group-id +bit in its file mode but removing the group-execute bit. This is an otherwise +meaningless combination, and was chosen by the System V implementors so as not +to break existing user programs. + +Note that the group-id bit is usually automatically cleared by the kernel when +a setgid file is written to. This is a security measure. The kernel has been +modified to recognize the special case of a mandatory lock candidate and to +refrain from clearing this bit. Similarly the kernel has been modified not +to run mandatory lock candidates with setgid privileges. + +3. Available implementations +---------------------------- + +I have considered the implementations of mandatory locking available with +SunOS 4.1.x, Solaris 2.x and HP-UX 9.x. + +Generally I have tried to make the most sense out of the behaviour exhibited +by these three reference systems. There are many anomalies. + +All the reference systems reject all calls to open() for a file on which +another process has outstanding mandatory locks. This is in direct +contravention of SVID 3, which states that only calls to open() with the +O_TRUNC flag set should be rejected. The Linux implementation follows the SVID +definition, which is the "Right Thing", since only calls with O_TRUNC can +modify the contents of the file. + +HP-UX even disallows open() with O_TRUNC for a file with advisory locks, not +just mandatory locks. That would appear to contravene POSIX.1. + +mmap() is another interesting case. All the operating systems mentioned +prevent mandatory locks from being applied to an mmap()'ed file, but HP-UX +also disallows advisory locks for such a file. SVID actually specifies the +paranoid HP-UX behaviour. + +In my opinion only MAP_SHARED mappings should be immune from locking, and then +only from mandatory locks - that is what is currently implemented. + +SunOS is so hopeless that it doesn't even honour the O_NONBLOCK flag for +mandatory locks, so reads and writes to locked files always block when they +should return EAGAIN. + +I'm afraid that this is such an esoteric area that the semantics described +below are just as valid as any others, so long as the main points seem to +agree. + +4. Semantics +------------ + +1. Mandatory locks can only be applied via the fcntl()/lockf() locking + interface - in other words the System V/POSIX interface. BSD style + locks using flock() never result in a mandatory lock. + +2. If a process has locked a region of a file with a mandatory read lock, then + other processes are permitted to read from that region. If any of these + processes attempts to write to the region it will block until the lock is + released, unless the process has opened the file with the O_NONBLOCK + flag in which case the system call will return immediately with the error + status EAGAIN. + +3. If a process has locked a region of a file with a mandatory write lock, all + attempts to read or write to that region block until the lock is released, + unless a process has opened the file with the O_NONBLOCK flag in which case + the system call will return immediately with the error status EAGAIN. + +4. Calls to open() with O_TRUNC, or to creat(), on a existing file that has + any mandatory locks owned by other processes will be rejected with the + error status EAGAIN. + +5. Attempts to apply a mandatory lock to a file that is memory mapped and + shared (via mmap() with MAP_SHARED) will be rejected with the error status + EAGAIN. + +6. Attempts to create a shared memory map of a file (via mmap() with MAP_SHARED) + that has any mandatory locks in effect will be rejected with the error status + EAGAIN. + +5. Which system calls are affected? +----------------------------------- + +Those which modify a file's contents, not just the inode. That gives read(), +write(), readv(), writev(), open(), creat(), mmap(), truncate() and +ftruncate(). truncate() and ftruncate() are considered to be "write" actions +for the purposes of mandatory locking. + +The affected region is usually defined as stretching from the current position +for the total number of bytes read or written. For the truncate calls it is +defined as the bytes of a file removed or added (we must also consider bytes +added, as a lock can specify just "the whole file", rather than a specific +range of bytes.) + +Note 3: I may have overlooked some system calls that need mandatory lock +checking in my eagerness to get this code out the door. Please let me know, or +better still fix the system calls yourself and submit a patch to me or Linus. + +6. Warning! +----------- + +Not even root can override a mandatory lock, so runaway processes can wreak +havoc if they lock crucial files. The way around it is to change the file +permissions (remove the setgid bit) before trying to read or write to it. +Of course, that might be a bit tricky if the system is hung :-( + +7. The "mand" mount option +-------------------------- +Mandatory locking is disabled on all filesystems by default, and must be +administratively enabled by mounting with "-o mand". That mount option +is only allowed if the mounting task has the CAP_SYS_ADMIN capability. + +Since kernel v4.5, it is possible to disable mandatory locking +altogether by setting CONFIG_MANDATORY_FILE_LOCKING to "n". A kernel +with this disabled will reject attempts to mount filesystems with the +"mand" mount option with the error status EPERM.
diff --git a/Documentation/filesystems/mandatory-locking.txt b/Documentation/filesystems/mandatory-locking.txt deleted file mode 100644 index a251ca3..0000000 --- a/Documentation/filesystems/mandatory-locking.txt +++ /dev/null
@@ -1,181 +0,0 @@ - Mandatory File Locking For The Linux Operating System - - Andy Walker <andy@lysaker.kvaerner.no> - - 15 April 1996 - (Updated September 2007) - -0. Why you should avoid mandatory locking ------------------------------------------ - -The Linux implementation is prey to a number of difficult-to-fix race -conditions which in practice make it not dependable: - - - The write system call checks for a mandatory lock only once - at its start. It is therefore possible for a lock request to - be granted after this check but before the data is modified. - A process may then see file data change even while a mandatory - lock was held. - - Similarly, an exclusive lock may be granted on a file after - the kernel has decided to proceed with a read, but before the - read has actually completed, and the reading process may see - the file data in a state which should not have been visible - to it. - - Similar races make the claimed mutual exclusion between lock - and mmap similarly unreliable. - -1. What is mandatory locking? ------------------------------- - -Mandatory locking is kernel enforced file locking, as opposed to the more usual -cooperative file locking used to guarantee sequential access to files among -processes. File locks are applied using the flock() and fcntl() system calls -(and the lockf() library routine which is a wrapper around fcntl().) It is -normally a process' responsibility to check for locks on a file it wishes to -update, before applying its own lock, updating the file and unlocking it again. -The most commonly used example of this (and in the case of sendmail, the most -troublesome) is access to a user's mailbox. The mail user agent and the mail -transfer agent must guard against updating the mailbox at the same time, and -prevent reading the mailbox while it is being updated. - -In a perfect world all processes would use and honour a cooperative, or -"advisory" locking scheme. However, the world isn't perfect, and there's -a lot of poorly written code out there. - -In trying to address this problem, the designers of System V UNIX came up -with a "mandatory" locking scheme, whereby the operating system kernel would -block attempts by a process to write to a file that another process holds a -"read" -or- "shared" lock on, and block attempts to both read and write to a -file that a process holds a "write " -or- "exclusive" lock on. - -The System V mandatory locking scheme was intended to have as little impact as -possible on existing user code. The scheme is based on marking individual files -as candidates for mandatory locking, and using the existing fcntl()/lockf() -interface for applying locks just as if they were normal, advisory locks. - -Note 1: In saying "file" in the paragraphs above I am actually not telling -the whole truth. System V locking is based on fcntl(). The granularity of -fcntl() is such that it allows the locking of byte ranges in files, in addition -to entire files, so the mandatory locking rules also have byte level -granularity. - -Note 2: POSIX.1 does not specify any scheme for mandatory locking, despite -borrowing the fcntl() locking scheme from System V. The mandatory locking -scheme is defined by the System V Interface Definition (SVID) Version 3. - -2. Marking a file for mandatory locking ---------------------------------------- - -A file is marked as a candidate for mandatory locking by setting the group-id -bit in its file mode but removing the group-execute bit. This is an otherwise -meaningless combination, and was chosen by the System V implementors so as not -to break existing user programs. - -Note that the group-id bit is usually automatically cleared by the kernel when -a setgid file is written to. This is a security measure. The kernel has been -modified to recognize the special case of a mandatory lock candidate and to -refrain from clearing this bit. Similarly the kernel has been modified not -to run mandatory lock candidates with setgid privileges. - -3. Available implementations ----------------------------- - -I have considered the implementations of mandatory locking available with -SunOS 4.1.x, Solaris 2.x and HP-UX 9.x. - -Generally I have tried to make the most sense out of the behaviour exhibited -by these three reference systems. There are many anomalies. - -All the reference systems reject all calls to open() for a file on which -another process has outstanding mandatory locks. This is in direct -contravention of SVID 3, which states that only calls to open() with the -O_TRUNC flag set should be rejected. The Linux implementation follows the SVID -definition, which is the "Right Thing", since only calls with O_TRUNC can -modify the contents of the file. - -HP-UX even disallows open() with O_TRUNC for a file with advisory locks, not -just mandatory locks. That would appear to contravene POSIX.1. - -mmap() is another interesting case. All the operating systems mentioned -prevent mandatory locks from being applied to an mmap()'ed file, but HP-UX -also disallows advisory locks for such a file. SVID actually specifies the -paranoid HP-UX behaviour. - -In my opinion only MAP_SHARED mappings should be immune from locking, and then -only from mandatory locks - that is what is currently implemented. - -SunOS is so hopeless that it doesn't even honour the O_NONBLOCK flag for -mandatory locks, so reads and writes to locked files always block when they -should return EAGAIN. - -I'm afraid that this is such an esoteric area that the semantics described -below are just as valid as any others, so long as the main points seem to -agree. - -4. Semantics ------------- - -1. Mandatory locks can only be applied via the fcntl()/lockf() locking - interface - in other words the System V/POSIX interface. BSD style - locks using flock() never result in a mandatory lock. - -2. If a process has locked a region of a file with a mandatory read lock, then - other processes are permitted to read from that region. If any of these - processes attempts to write to the region it will block until the lock is - released, unless the process has opened the file with the O_NONBLOCK - flag in which case the system call will return immediately with the error - status EAGAIN. - -3. If a process has locked a region of a file with a mandatory write lock, all - attempts to read or write to that region block until the lock is released, - unless a process has opened the file with the O_NONBLOCK flag in which case - the system call will return immediately with the error status EAGAIN. - -4. Calls to open() with O_TRUNC, or to creat(), on a existing file that has - any mandatory locks owned by other processes will be rejected with the - error status EAGAIN. - -5. Attempts to apply a mandatory lock to a file that is memory mapped and - shared (via mmap() with MAP_SHARED) will be rejected with the error status - EAGAIN. - -6. Attempts to create a shared memory map of a file (via mmap() with MAP_SHARED) - that has any mandatory locks in effect will be rejected with the error status - EAGAIN. - -5. Which system calls are affected? ------------------------------------ - -Those which modify a file's contents, not just the inode. That gives read(), -write(), readv(), writev(), open(), creat(), mmap(), truncate() and -ftruncate(). truncate() and ftruncate() are considered to be "write" actions -for the purposes of mandatory locking. - -The affected region is usually defined as stretching from the current position -for the total number of bytes read or written. For the truncate calls it is -defined as the bytes of a file removed or added (we must also consider bytes -added, as a lock can specify just "the whole file", rather than a specific -range of bytes.) - -Note 3: I may have overlooked some system calls that need mandatory lock -checking in my eagerness to get this code out the door. Please let me know, or -better still fix the system calls yourself and submit a patch to me or Linus. - -6. Warning! ------------ - -Not even root can override a mandatory lock, so runaway processes can wreak -havoc if they lock crucial files. The way around it is to change the file -permissions (remove the setgid bit) before trying to read or write to it. -Of course, that might be a bit tricky if the system is hung :-( - -7. The "mand" mount option --------------------------- -Mandatory locking is disabled on all filesystems by default, and must be -administratively enabled by mounting with "-o mand". That mount option -is only allowed if the mounting task has the CAP_SYS_ADMIN capability. - -Since kernel v4.5, it is possible to disable mandatory locking -altogether by setting CONFIG_MANDATORY_FILE_LOCKING to "n". A kernel -with this disabled will reject attempts to mount filesystems with the -"mand" mount option with the error status EPERM.
diff --git a/Documentation/filesystems/mount_api.rst b/Documentation/filesystems/mount_api.rst new file mode 100644 index 0000000..dea22d