github-mirror/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2026-07-31 03:27:03 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity Graph

Snap for 8847255 from ff712ce9e0 to android-mainline-keystone-qcom-release

Browse Source 
Change-Id: Ie327a226497a531b5a69d309eae77e5b8824bdec
This commit is contained in:
Android Build Coastguard Worker 2022-07-20 00:00:31 +00:00
commit 79cfa1b728
5547 changed files with 171730 additions and 78243 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

218
.clang-format
View File

@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
#
# clang-format configuration file. Intended for clang-format >= 4.
# clang-format configuration file. Intended for clang-format >= 11.
#
# For more information, see:
#
@ -13,7 +13,7 @@ AccessModifierOffset: -4
AlignAfterOpenBracket: Align
AlignConsecutiveAssignments: false
AlignConsecutiveDeclarations: false
#AlignEscapedNewlines: Left # Unknown to clang-format-4.0
AlignEscapedNewlines: Left
AlignOperands: true
AlignTrailingComments: false
AllowAllParametersOfDeclarationOnNextLine: false
@ -37,24 +37,24 @@ BraceWrapping:
AfterObjCDeclaration: false
AfterStruct: false
AfterUnion: false
#AfterExternBlock: false # Unknown to clang-format-5.0
AfterExternBlock: false
BeforeCatch: false
BeforeElse: false
IndentBraces: false
#SplitEmptyFunction: true # Unknown to clang-format-4.0
#SplitEmptyRecord: true # Unknown to clang-format-4.0
#SplitEmptyNamespace: true # Unknown to clang-format-4.0
SplitEmptyFunction: true
SplitEmptyRecord: true
SplitEmptyNamespace: true
BreakBeforeBinaryOperators: None
BreakBeforeBraces: Custom
#BreakBeforeInheritanceComma: false # Unknown to clang-format-4.0
BreakBeforeInheritanceComma: false
BreakBeforeTernaryOperators: false
BreakConstructorInitializersBeforeComma: false
#BreakConstructorInitializers: BeforeComma # Unknown to clang-format-4.0
BreakConstructorInitializers: BeforeComma
BreakAfterJavaFieldAnnotations: false
BreakStringLiterals: false
ColumnLimit: 80
CommentPragmas: '^ IWYU pragma:'
#CompactNamespaces: false # Unknown to clang-format-4.0
CompactNamespaces: false
ConstructorInitializerAllOnOneLineOrOnePerLine: false
ConstructorInitializerIndentWidth: 8
ContinuationIndentWidth: 8
@ -62,39 +62,56 @@ Cpp11BracedListStyle: false
DerivePointerAlignment: false
DisableFormat: false
ExperimentalAutoDetectBinPacking: false
#FixNamespaceComments: false # Unknown to clang-format-4.0
FixNamespaceComments: false
# Taken from:
# git grep -h '^#define [^[:space:]]*for_each[^[:space:]]*(' include/ \
# git grep -h '^#define [^[:space:]]*for_each[^[:space:]]*(' include/ tools/ \
# | sed "s,^#define \([^[:space:]]*for_each[^[:space:]]*\)(.*$, - '\1'," \
# | sort | uniq
# | LC_ALL=C sort -u
ForEachMacros:
- '__ata_qc_for_each'
- '__bio_for_each_bvec'
- '__bio_for_each_segment'
- '__evlist__for_each_entry'
- '__evlist__for_each_entry_continue'
- '__evlist__for_each_entry_from'
- '__evlist__for_each_entry_reverse'
- '__evlist__for_each_entry_safe'
- '__for_each_mem_range'
- '__for_each_mem_range_rev'
- '__for_each_thread'
- '__hlist_for_each_rcu'
- '__map__for_each_symbol_by_name'
- '__perf_evlist__for_each_entry'
- '__perf_evlist__for_each_entry_reverse'
- '__perf_evlist__for_each_entry_safe'
- '__rq_for_each_bio'
- '__shost_for_each_device'
- 'apei_estatus_for_each_section'
- 'ata_for_each_dev'
- 'ata_for_each_link'
- '__ata_qc_for_each'
- 'ata_qc_for_each'
- 'ata_qc_for_each_raw'
- 'ata_qc_for_each_with_internal'
- 'ax25_for_each'
- 'ax25_uid_for_each'
- '__bio_for_each_bvec'
- 'bio_for_each_bvec'
- 'bio_for_each_bvec_all'
- 'bio_for_each_folio_all'
- 'bio_for_each_integrity_vec'
- '__bio_for_each_segment'
- 'bio_for_each_segment'
- 'bio_for_each_segment_all'
- 'bio_list_for_each'
- 'bip_for_each_vec'
- 'bitmap_for_each_clear_region'
- 'bitmap_for_each_set_region'
- 'blkg_for_each_descendant_post'
- 'blkg_for_each_descendant_pre'
- 'blk_queue_for_each_rl'
- 'bond_for_each_slave'
- 'bond_for_each_slave_rcu'
- 'bpf__perf_for_each_map'
- 'bpf__perf_for_each_map_named'
- 'bpf_for_each_spilled_reg'
- 'bpf_object__for_each_map'
- 'bpf_object__for_each_program'
- 'bpf_object__for_each_safe'
- 'bpf_perf_object__for_each'
- 'btree_for_each_safe128'
- 'btree_for_each_safe32'
- 'btree_for_each_safe64'
@ -102,6 +119,7 @@ ForEachMacros:
- 'card_for_each_dev'
- 'cgroup_taskset_for_each'
- 'cgroup_taskset_for_each_leader'
- 'cpufreq_for_each_efficient_entry_idx'
- 'cpufreq_for_each_entry'
- 'cpufreq_for_each_entry_idx'
- 'cpufreq_for_each_valid_entry'
@ -109,9 +127,22 @@ ForEachMacros:
- 'css_for_each_child'
- 'css_for_each_descendant_post'
- 'css_for_each_descendant_pre'
- 'damon_for_each_region'
- 'damon_for_each_region_safe'
- 'damon_for_each_scheme'
- 'damon_for_each_scheme_safe'
- 'damon_for_each_target'
- 'damon_for_each_target_safe'
- 'data__for_each_file'
- 'data__for_each_file_new'
- 'data__for_each_file_start'
- 'device_for_each_child_node'
- 'displayid_iter_for_each'
- 'dma_fence_array_for_each'
- 'dma_fence_chain_for_each'
- 'dma_fence_unwrap_for_each'
- 'dma_resv_for_each_fence'
- 'dma_resv_for_each_fence_unlocked'
- 'do_for_each_ftrace_op'
- 'drm_atomic_crtc_for_each_plane'
- 'drm_atomic_crtc_state_for_each_plane'
@ -135,6 +166,25 @@ ForEachMacros:
- 'drm_mm_for_each_node'
- 'drm_mm_for_each_node_in_range'
- 'drm_mm_for_each_node_safe'
- 'dsa_switch_for_each_available_port'
- 'dsa_switch_for_each_cpu_port'
- 'dsa_switch_for_each_port'
- 'dsa_switch_for_each_port_continue_reverse'
- 'dsa_switch_for_each_port_safe'
- 'dsa_switch_for_each_user_port'
- 'dsa_tree_for_each_user_port'
- 'dso__for_each_symbol'
- 'dsos__for_each_with_build_id'
- 'elf_hash_for_each_possible'
- 'elf_section__for_each_rel'
- 'elf_section__for_each_rela'
- 'elf_symtab__for_each_symbol'
- 'evlist__for_each_cpu'
- 'evlist__for_each_entry'
- 'evlist__for_each_entry_continue'
- 'evlist__for_each_entry_from'
- 'evlist__for_each_entry_reverse'
- 'evlist__for_each_entry_safe'
- 'flow_action_for_each'
- 'for_each_acpi_dev_match'
- 'for_each_active_dev_scope'
@ -142,8 +192,11 @@ ForEachMacros:
- 'for_each_active_iommu'
- 'for_each_aggr_pgid'
- 'for_each_available_child_of_node'
- 'for_each_bench'
- 'for_each_bio'
- 'for_each_board_func_rsrc'
- 'for_each_btf_ext_rec'
- 'for_each_btf_ext_sec'
- 'for_each_bvec'
- 'for_each_card_auxs'
- 'for_each_card_auxs_safe'
@ -159,17 +212,22 @@ ForEachMacros:
- 'for_each_child_of_node'
- 'for_each_clear_bit'
- 'for_each_clear_bit_from'
- 'for_each_clear_bitrange'
- 'for_each_clear_bitrange_from'
- 'for_each_cmd'
- 'for_each_cmsghdr'
- 'for_each_collection'
- 'for_each_comp_order'
- 'for_each_compatible_node'
- 'for_each_component_dais'
- 'for_each_component_dais_safe'
- 'for_each_comp_order'
- 'for_each_console'
- 'for_each_cpu'
- 'for_each_cpu_and'
- 'for_each_cpu_not'
- 'for_each_cpu_wrap'
- 'for_each_dapm_widgets'
- 'for_each_dedup_cand'
- 'for_each_dev_addr'
- 'for_each_dev_scope'
- 'for_each_dma_cap_mask'
@ -179,13 +237,14 @@ ForEachMacros:
- 'for_each_dpcm_fe'
- 'for_each_drhd_unit'
- 'for_each_dss_dev'
- 'for_each_dtpm_table'
- 'for_each_efi_memory_desc'
- 'for_each_efi_memory_desc_in_map'
- 'for_each_element'
- 'for_each_element_extid'
- 'for_each_element_id'
- 'for_each_endpoint_of_node'
- 'for_each_event'
- 'for_each_event_tps'
- 'for_each_evictable_lru'
- 'for_each_fib6_node_rt_rcu'
- 'for_each_fib6_walker_rt'
@ -194,30 +253,35 @@ ForEachMacros:
- 'for_each_free_mem_range'
- 'for_each_free_mem_range_reverse'
- 'for_each_func_rsrc'
- 'for_each_group_evsel'
- 'for_each_group_member'
- 'for_each_hstate'
- 'for_each_if'
- 'for_each_inject_fn'
- 'for_each_insn'
- 'for_each_insn_prefix'
- 'for_each_intid'
- 'for_each_iommu'
- 'for_each_ip_tunnel_rcu'
- 'for_each_irq_nr'
- 'for_each_lang'
- 'for_each_link_codecs'
- 'for_each_link_cpus'
- 'for_each_link_platforms'
- 'for_each_lru'
- 'for_each_matching_node'
- 'for_each_matching_node_and_match'
- 'for_each_member'
- 'for_each_memcg_cache_index'
- 'for_each_mem_pfn_range'
- '__for_each_mem_range'
- 'for_each_mem_range'
- '__for_each_mem_range_rev'
- 'for_each_mem_range_rev'
- 'for_each_mem_region'
- 'for_each_member'
- 'for_each_memory'
- 'for_each_migratetype_order'
- 'for_each_msi_entry'
- 'for_each_msi_entry_safe'
- 'for_each_missing_reg'
- 'for_each_net'
- 'for_each_net_continue_reverse'
- 'for_each_net_rcu'
- 'for_each_netdev'
- 'for_each_netdev_continue'
- 'for_each_netdev_continue_rcu'
@ -227,12 +291,13 @@ ForEachMacros:
- 'for_each_netdev_rcu'
- 'for_each_netdev_reverse'
- 'for_each_netdev_safe'
- 'for_each_net_rcu'
- 'for_each_new_connector_in_state'
- 'for_each_new_crtc_in_state'
- 'for_each_new_mst_mgr_in_state'
- 'for_each_new_plane_in_state'
- 'for_each_new_plane_in_state_reverse'
- 'for_each_new_private_obj_in_state'
- 'for_each_new_reg'
- 'for_each_node'
- 'for_each_node_by_name'
- 'for_each_node_by_type'
@ -248,20 +313,20 @@ ForEachMacros:
- 'for_each_old_connector_in_state'
- 'for_each_old_crtc_in_state'
- 'for_each_old_mst_mgr_in_state'
- 'for_each_old_plane_in_state'
- 'for_each_old_private_obj_in_state'
- 'for_each_oldnew_connector_in_state'
- 'for_each_oldnew_crtc_in_state'
- 'for_each_oldnew_mst_mgr_in_state'
- 'for_each_oldnew_plane_in_state'
- 'for_each_oldnew_plane_in_state_reverse'
- 'for_each_oldnew_private_obj_in_state'
- 'for_each_old_plane_in_state'
- 'for_each_old_private_obj_in_state'
- 'for_each_online_cpu'
- 'for_each_online_node'
- 'for_each_online_pgdat'
- 'for_each_path'
- 'for_each_pci_bridge'
- 'for_each_pci_dev'
- 'for_each_pci_msi_entry'
- 'for_each_pcm_streams'
- 'for_each_physmem_range'
- 'for_each_populated_zone'
@ -269,6 +334,7 @@ ForEachMacros:
- 'for_each_present_cpu'
- 'for_each_prime_number'
- 'for_each_prime_number_from'
- 'for_each_probe_cache_entry'
- 'for_each_process'
- 'for_each_process_thread'
- 'for_each_prop_codec_conf'
@ -278,6 +344,8 @@ ForEachMacros:
- 'for_each_prop_dlc_cpus'
- 'for_each_prop_dlc_platforms'
- 'for_each_property_of_node'
- 'for_each_reg'
- 'for_each_reg_filtered'
- 'for_each_registered_fb'
- 'for_each_requested_gpio'
- 'for_each_requested_gpio_in_range'
@ -287,8 +355,12 @@ ForEachMacros:
- 'for_each_rtd_components'
- 'for_each_rtd_cpu_dais'
- 'for_each_rtd_dais'
- 'for_each_script'
- 'for_each_sec'
- 'for_each_set_bit'
- 'for_each_set_bit_from'
- 'for_each_set_bitrange'
- 'for_each_set_bitrange_from'
- 'for_each_set_clump8'
- 'for_each_sg'
- 'for_each_sg_dma_page'
@ -297,18 +369,25 @@ ForEachMacros:
- 'for_each_sgtable_dma_sg'
- 'for_each_sgtable_page'
- 'for_each_sgtable_sg'
- 'for_each_shell_test'
- 'for_each_sibling_event'
- 'for_each_subelement'
- 'for_each_subelement_extid'
- 'for_each_subelement_id'
- '__for_each_thread'
- 'for_each_sublist'
- 'for_each_subsystem'
- 'for_each_supported_activate_fn'
- 'for_each_supported_inject_fn'
- 'for_each_test'
- 'for_each_thread'
- 'for_each_token'
- 'for_each_unicast_dest_pgid'
- 'for_each_vsi'
- 'for_each_wakeup_source'
- 'for_each_zone'
- 'for_each_zone_zonelist'
- 'for_each_zone_zonelist_nodemask'
- 'func_for_each_insn'
- 'fwnode_for_each_available_child_node'
- 'fwnode_for_each_child_node'
- 'fwnode_graph_for_each_endpoint'
@ -322,7 +401,13 @@ ForEachMacros:
- 'hash_for_each_possible_safe'
- 'hash_for_each_rcu'
- 'hash_for_each_safe'
- 'hashmap__for_each_entry'
- 'hashmap__for_each_entry_safe'
- 'hashmap__for_each_key_entry'
- 'hashmap__for_each_key_entry_safe'
- 'hctx_for_each_ctx'
- 'hists__for_each_format'
- 'hists__for_each_sort_list'
- 'hlist_bl_for_each_entry'
- 'hlist_bl_for_each_entry_rcu'
- 'hlist_bl_for_each_entry_safe'
@ -338,7 +423,6 @@ ForEachMacros:
- 'hlist_for_each_entry_rcu_notrace'
- 'hlist_for_each_entry_safe'
- 'hlist_for_each_entry_srcu'
- '__hlist_for_each_rcu'
- 'hlist_for_each_safe'
- 'hlist_nulls_for_each_entry'
- 'hlist_nulls_for_each_entry_from'
@ -346,9 +430,6 @@ ForEachMacros:
- 'hlist_nulls_for_each_entry_safe'
- 'i3c_bus_for_each_i2cdev'
- 'i3c_bus_for_each_i3cdev'
- 'ide_host_for_each_port'
- 'ide_port_for_each_dev'
- 'ide_port_for_each_present_dev'
- 'idr_for_each_entry'
- 'idr_for_each_entry_continue'
- 'idr_for_each_entry_continue_ul'
@ -356,7 +437,12 @@ ForEachMacros:
- 'in_dev_for_each_ifa_rcu'
- 'in_dev_for_each_ifa_rtnl'
- 'inet_bind_bucket_for_each'
- 'inet_lhash2_for_each_icsk'
- 'inet_lhash2_for_each_icsk_continue'
- 'inet_lhash2_for_each_icsk_rcu'
- 'intlist__for_each_entry'
- 'intlist__for_each_entry_safe'
- 'kcore_copy__for_each_phdr'
- 'key_for_each'
- 'key_for_each_safe'
- 'klp_for_each_func'
@ -367,7 +453,9 @@ ForEachMacros:
- 'klp_for_each_object_static'
- 'kunit_suite_for_each_test_case'
- 'kvm_for_each_memslot'
- 'kvm_for_each_memslot_in_gfn_range'
- 'kvm_for_each_vcpu'
- 'libbpf_nla_for_each_attr'
- 'list_for_each'
- 'list_for_each_codec'
- 'list_for_each_codec_safe'
@ -387,6 +475,7 @@ ForEachMacros:
- 'list_for_each_entry_safe_from'
- 'list_for_each_entry_safe_reverse'
- 'list_for_each_entry_srcu'
- 'list_for_each_from'
- 'list_for_each_prev'
- 'list_for_each_prev_safe'
- 'list_for_each_safe'
@ -394,11 +483,18 @@ ForEachMacros:
- 'llist_for_each_entry'
- 'llist_for_each_entry_safe'
- 'llist_for_each_safe'
- 'map__for_each_symbol'
- 'map__for_each_symbol_by_name'
- 'map_for_each_event'
- 'map_for_each_metric'
- 'maps__for_each_entry'
- 'maps__for_each_entry_safe'
- 'mci_for_each_dimm'
- 'media_device_for_each_entity'
- 'media_device_for_each_intf'
- 'media_device_for_each_link'
- 'media_device_for_each_pad'
- 'msi_for_each_desc'
- 'nanddev_io_for_each_page'
- 'netdev_for_each_lower_dev'
- 'netdev_for_each_lower_private'
@ -423,6 +519,20 @@ ForEachMacros:
- 'pcl_for_each_chunk'
- 'pcl_for_each_segment'
- 'pcm_for_each_format'
- 'perf_config_items__for_each_entry'
- 'perf_config_sections__for_each_entry'
- 'perf_config_set__for_each_entry'
- 'perf_cpu_map__for_each_cpu'
- 'perf_evlist__for_each_entry'
- 'perf_evlist__for_each_entry_reverse'
- 'perf_evlist__for_each_entry_safe'
- 'perf_evlist__for_each_evsel'
- 'perf_evlist__for_each_mmap'
- 'perf_hpp_list__for_each_format'
- 'perf_hpp_list__for_each_format_safe'
- 'perf_hpp_list__for_each_sort_list'
- 'perf_hpp_list__for_each_sort_list_safe'
- 'perf_pmu__for_each_hybrid_pmu'
- 'ping_portaddr_for_each_entry'
- 'plist_for_each'
- 'plist_for_each_continue'
@ -442,6 +552,7 @@ ForEachMacros:
- 'rdma_for_each_block'
- 'rdma_for_each_port'
- 'rdma_umem_for_each_dma_block'
- 'resort_rb__for_each_entry'
- 'resource_list_for_each_entry'
- 'resource_list_for_each_entry_safe'
- 'rhl_for_each_entry_rcu'
@ -455,15 +566,18 @@ ForEachMacros:
- 'rht_for_each_from'
- 'rht_for_each_rcu'
- 'rht_for_each_rcu_from'
- '__rq_for_each_bio'
- 'rq_for_each_bvec'
- 'rq_for_each_segment'
- 'rq_list_for_each'
- 'rq_list_for_each_safe'
- 'scsi_for_each_prot_sg'
- 'scsi_for_each_sg'
- 'sctp_for_each_hentry'
- 'sctp_skb_for_each'
- 'sec_for_each_insn'
- 'sec_for_each_insn_continue'
- 'sec_for_each_insn_from'
- 'shdma_for_each_chan'
- '__shost_for_each_device'
- 'shost_for_each_device'
- 'sk_for_each'
- 'sk_for_each_bound'
@ -480,7 +594,13 @@ ForEachMacros:
- 'snd_soc_dapm_widget_for_each_path_safe'
- 'snd_soc_dapm_widget_for_each_sink_path'
- 'snd_soc_dapm_widget_for_each_source_path'
- 'strlist__for_each_entry'
- 'strlist__for_each_entry_safe'
- 'sym_for_each_insn'
- 'sym_for_each_insn_continue_reverse'
- 'symbols__for_each_entry'
- 'tb_property_for_each'
- 'tcf_act_for_each_action'
- 'tcf_exts_for_each_action'
- 'udp_portaddr_for_each_entry'
- 'udp_portaddr_for_each_entry_rcu'
@ -504,15 +624,17 @@ ForEachMacros:
- 'xbc_node_for_each_array_value'
- 'xbc_node_for_each_child'
- 'xbc_node_for_each_key_value'
- 'xbc_node_for_each_subkey'
- 'zorro_for_each_dev'
#IncludeBlocks: Preserve # Unknown to clang-format-5.0
IncludeBlocks: Preserve
IncludeCategories:
- Regex: '.*'
Priority: 1
IncludeIsMainRegex: '(Test)?$'
IndentCaseLabels: false
#IndentPPDirectives: None # Unknown to clang-format-5.0
IndentGotoLabels: false
IndentPPDirectives: None
IndentWidth: 8
IndentWrappedFunctionNames: false
JavaScriptQuotes: Leave
@ -522,13 +644,13 @@ MacroBlockBegin: ''
MacroBlockEnd: ''
MaxEmptyLinesToKeep: 1
NamespaceIndentation: None
#ObjCBinPackProtocolList: Auto # Unknown to clang-format-5.0
ObjCBinPackProtocolList: Auto
ObjCBlockIndentWidth: 8
ObjCSpaceAfterProperty: true
ObjCSpaceBeforeProtocolList: true
# Taken from git's rules
#PenaltyBreakAssignment: 10 # Unknown to clang-format-4.0
PenaltyBreakAssignment: 10
PenaltyBreakBeforeFirstCallParameter: 30
PenaltyBreakComment: 10
PenaltyBreakFirstLessLess: 0
@ -539,14 +661,14 @@ PenaltyReturnTypeOnItsOwnLine: 60
PointerAlignment: Right
ReflowComments: false
SortIncludes: false
#SortUsingDeclarations: false # Unknown to clang-format-4.0
SortUsingDeclarations: false
SpaceAfterCStyleCast: false
SpaceAfterTemplateKeyword: true
SpaceBeforeAssignmentOperators: true
#SpaceBeforeCtorInitializerColon: true # Unknown to clang-format-5.0
#SpaceBeforeInheritanceColon: true # Unknown to clang-format-5.0
SpaceBeforeParens: ControlStatements
#SpaceBeforeRangeBasedForLoopColon: true # Unknown to clang-format-5.0
SpaceBeforeCtorInitializerColon: true
SpaceBeforeInheritanceColon: true
SpaceBeforeParens: ControlStatementsExceptForEachMacros
SpaceBeforeRangeBasedForLoopColon: true
SpaceInEmptyParentheses: false
SpacesBeforeTrailingComments: 1
SpacesInAngles: false

10
.mailmap
View File

@ -10,6 +10,8 @@
# Please keep this list dictionary sorted.
#
Aaron Durbin <adurbin@google.com>
Abel Vesa <abelvesa@kernel.org> <abel.vesa@nxp.com>
Abel Vesa <abelvesa@kernel.org> <abelvesa@gmail.com>
Abhinav Kumar <quic_abhinavk@quicinc.com> <abhinavk@codeaurora.org>
Adam Oldham <oldhamca@gmail.com>
Adam Radford <aradford@gmail.com>
@ -62,6 +64,9 @@ Bart Van Assche <bvanassche@acm.org> <bart.vanassche@sandisk.com>
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
Ben Gardner <bgardner@wabtec.com>
Ben M Cahill <ben.m.cahill@intel.com>
Ben Widawsky <bwidawsk@kernel.org> <ben@bwidawsk.net>
Ben Widawsky <bwidawsk@kernel.org> <ben.widawsky@intel.com>
Ben Widawsky <bwidawsk@kernel.org> <benjamin.widawsky@intel.com>
Björn Steinbrink <B.Steinbrink@gmx.de>
Björn Töpel <bjorn@kernel.org> <bjorn.topel@gmail.com>
Björn Töpel <bjorn@kernel.org> <bjorn.topel@intel.com>
@ -85,6 +90,7 @@ Christian Borntraeger <borntraeger@linux.ibm.com> <borntrae@de.ibm.com>
Christian Brauner <brauner@kernel.org> <christian@brauner.io>
Christian Brauner <brauner@kernel.org> <christian.brauner@canonical.com>
Christian Brauner <brauner@kernel.org> <christian.brauner@ubuntu.com>
Christian Marangi <ansuelsmth@gmail.com>
Christophe Ricard <christophe.ricard@gmail.com>
Christoph Hellwig <hch@lst.de>
Colin Ian King <colin.king@intel.com> <colin.king@canonical.com>
@ -165,6 +171,7 @@ Jan Glauber <jan.glauber@gmail.com> <jang@de.ibm.com>
Jan Glauber <jan.glauber@gmail.com> <jang@linux.vnet.ibm.com>
Jan Glauber <jan.glauber@gmail.com> <jglauber@cavium.com>
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@linux.intel.com>
Jarkko Sakkinen <jarkko@kernel.org> <jarkko@profian.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgg@nvidia.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
@ -201,6 +208,8 @@ Jordan Crouse <jordan@cosmicpenguin.net> <jcrouse@codeaurora.org>
<josh@joshtriplett.org> <josht@linux.vnet.ibm.com>
<josh@joshtriplett.org> <josht@us.ibm.com>
<josh@joshtriplett.org> <josht@vnet.ibm.com>
Josh Poimboeuf <jpoimboe@kernel.org> <jpoimboe@redhat.com>
Josh Poimboeuf <jpoimboe@kernel.org> <jpoimboe@us.ibm.com>
Juha Yrjola <at solidboot.com>
Juha Yrjola <juha.yrjola@nokia.com>
Juha Yrjola <juha.yrjola@solidboot.com>
@ -236,6 +245,7 @@ Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
<linux-hardening@vger.kernel.org> <kernel-hardening@lists.openwall.com>
Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
Lorenzo Pieralisi <lpieralisi@kernel.org> <lorenzo.pieralisi@arm.com>
Lukasz Luba <lukasz.luba@arm.com> <l.luba@partner.samsung.com>
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
Maciej W. Rozycki <macro@orcam.me.uk> <macro@linux-mips.org>

4
BUILD.bazel
View File

@ -98,6 +98,7 @@ define_db845c(
"drivers/interconnect/qcom/qnoc-sm8450.ko",
"drivers/iommu/arm/arm-smmu/arm_smmu.ko",
"drivers/irqchip/qcom-pdc.ko",
"drivers/leds/rgb/leds-qcom-lpg.ko",
"drivers/mailbox/qcom-apcs-ipc-mailbox.ko",
"drivers/mailbox/qcom-ipcc.ko",
"drivers/media/platform/qcom/venus/venus-core.ko",
@ -125,6 +126,7 @@ define_db845c(
"drivers/pinctrl/qcom/pinctrl-msm.ko",
"drivers/pinctrl/qcom/pinctrl-sdm845.ko",
"drivers/pinctrl/qcom/pinctrl-sm8250.ko",
"drivers/pinctrl/qcom/pinctrl-sm8250-lpass-lpi.ko",
"drivers/pinctrl/qcom/pinctrl-sm8450.ko",
"drivers/pinctrl/qcom/pinctrl-spmi-gpio.ko",
"drivers/pinctrl/qcom/pinctrl-spmi-mpp.ko",
@ -151,7 +153,6 @@ define_db845c(
"drivers/rpmsg/qcom_smd.ko",
"drivers/rpmsg/rpmsg_ns.ko",
"drivers/rtc/rtc-pm8xxx.ko",
"drivers/scsi/ufs/ufs_qcom.ko",
"drivers/slimbus/slim-qcom-ngd-ctrl.ko",
"drivers/slimbus/slimbus.ko",
"drivers/soc/qcom/apr.ko",
@ -182,6 +183,7 @@ define_db845c(
"drivers/thermal/qcom/qcom-spmi-temp-alarm.ko",
"drivers/thermal/qcom/qcom_tsens.ko",
"drivers/tty/serial/msm_serial.ko",
"drivers/ufs/host/ufs_qcom.ko",
"drivers/usb/common/ulpi.ko",
"drivers/usb/host/ohci-hcd.ko",
"drivers/usb/host/ohci-pci.ko",

10
Documentation/ABI/stable/sysfs-bus-mhi
View File

@ -19,3 +19,13 @@ Description: The file holds the OEM PK Hash value of the endpoint device
read without having the device power on at least once, the file
will read all 0's.
Users: Any userspace application or clients interested in device info.
What: /sys/bus/mhi/devices/.../soc_reset
Date: April 2022
KernelVersion: 5.19
Contact: mhi@lists.linux.dev
Description: Initiates a SoC reset on the MHI controller. A SoC reset is
a reset of last resort, and will require a complete re-init.
This can be useful as a method of recovery if the device is
non-responsive, or as a means of loading new firmware as a
system administration task.

1
Documentation/ABI/testing/configfs-usb-gadget-uvc
View File

@ -7,6 +7,7 @@ Description: UVC function directory
streaming_maxburst 0..15 (ss only)
streaming_maxpacket 1..1023 (fs), 1..3072 (hs/ss)
streaming_interval 1..16
function_name string [32]
=================== =============================
What: /config/usb-gadget/gadget/functions/uvc.name/control

38
Documentation/ABI/testing/debugfs-driver-habanalabs
View File

@ -170,6 +170,20 @@ KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Sets the state of the third S/W led on the device
What: /sys/kernel/debug/habanalabs/hl<n>/memory_scrub
Date: May 2022
KernelVersion: 5.19
Contact: dhirschfeld@habana.ai
Description: Allows the root user to scrub the dram memory. The scrubbing
value can be set using the debugfs file memory_scrub_val.
What: /sys/kernel/debug/habanalabs/hl<n>/memory_scrub_val
Date: May 2022
KernelVersion: 5.19
Contact: dhirschfeld@habana.ai
Description: The value to which the dram will be set to when the user
scrubs the dram using 'memory_scrub' debugfs file
What: /sys/kernel/debug/habanalabs/hl<n>/mmu
Date: Jan 2019
KernelVersion: 5.1
@ -190,6 +204,30 @@ Description: Check and display page fault or access violation mmu errors for
echo "0x200" > /sys/kernel/debug/habanalabs/hl0/mmu_error
cat /sys/kernel/debug/habanalabs/hl0/mmu_error
What: /sys/kernel/debug/habanalabs/hl<n>/monitor_dump
Date: Mar 2022
KernelVersion: 5.19
Contact: osharabi@habana.ai
Description: Allows the root user to dump monitors status from the device's
protected config space.
This property is a binary blob that contains the result of the
monitors registers dump.
This custom interface is needed (instead of using the generic
Linux user-space PCI mapping) because this space is protected
and cannot be accessed using PCI read.
This interface doesn't support concurrency in the same device.
Only supported on GAUDI.
What: /sys/kernel/debug/habanalabs/hl<n>/monitor_dump_trig
Date: Mar 2022
KernelVersion: 5.19
Contact: osharabi@habana.ai
Description: Triggers dump of monitor data. The value to trigger the operation
must be 1. Triggering the monitor dump operation initiates dump of
current registers values of all monitors.
When the write is finished, the user can read the "monitor_dump"
blob
What: /sys/kernel/debug/habanalabs/hl<n>/set_power_state
Date: Jan 2019
KernelVersion: 5.1

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

@ -104,6 +104,20 @@ 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>/qm/diff_regs
Date: Mar 2022
Contact: linux-crypto@vger.kernel.org
Description: QM debug registers(regs) read hardware register value. This
node is used to show the change of the qm register values. This
node can be help users to check the change of register values.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/diff_regs
Date: Mar 2022
Contact: linux-crypto@vger.kernel.org
Description: HPRE debug registers(regs) read hardware register value. This
node is used to show the change of the register values. This
node can be help users to check the change of register values.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org

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

@ -84,6 +84,20 @@ 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>/qm/diff_regs
Date: Mar 2022
Contact: linux-crypto@vger.kernel.org
Description: QM debug registers(regs) read hardware register value. This
node is used to show the change of the qm register values. This
node can be help users to check the change of register values.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/diff_regs
Date: Mar 2022
Contact: linux-crypto@vger.kernel.org
Description: SEC debug registers(regs) read hardware register value. This
node is used to show the change of the register values. This
node can be help users to check the change of register values.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org

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

@ -97,6 +97,20 @@ 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>/qm/diff_regs
Date: Mar 2022
Contact: linux-crypto@vger.kernel.org
Description: QM debug registers(regs) read hardware register value. This
node is used to show the change of the qm registers value. This
node can be help users to check the change of register values.
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/diff_regs
Date: Mar 2022
Contact: linux-crypto@vger.kernel.org
Description: ZIP debug registers(regs) read hardware register value. This
node is used to show the change of the registers value. this
node can be help users to check the change of register values.
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org

11
Documentation/ABI/testing/sysfs-ata
View File

@ -107,13 +107,14 @@ Description:
described in ATA8 7.16 and 7.17. Only valid if
the device is not a PM.
pio_mode: (RO) Transfer modes supported by the device when
in PIO mode. Mostly used by PATA device.
pio_mode: (RO) PIO transfer mode used by the device.
Mostly used by PATA devices.
xfer_mode: (RO) Current transfer mode
xfer_mode: (RO) Current transfer mode. Mostly used by
PATA devices.
dma_mode: (RO) Transfer modes supported by the device when
in DMA mode. Mostly used by PATA device.
dma_mode: (RO) DMA transfer mode used by the device.
Mostly used by PATA devices.
class: (RO) Device class. Can be "ata" for disk,
"atapi" for packet device, "pmp" for PM, or

2
Documentation/ABI/testing/sysfs-bus-iio-vf610
View File

@ -1,4 +1,4 @@
What: /sys/bus/iio/devices/iio:deviceX/conversion_mode
What: /sys/bus/iio/devices/iio:deviceX/in_conversion_mode
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org
Description:

10
Documentation/ABI/testing/sysfs-bus-thunderbolt
View File

@ -293,6 +293,16 @@ Contact: thunderbolt-software@lists.01.org
Description: This contains XDomain service specific settings as
bitmask. Format: %x
What: /sys/bus/thunderbolt/devices/usb4_portX/connector
Date: April 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Symlink to the USB Type-C connector. This link is only
created when USB Type-C Connector Class is enabled,
and only if the system firmware is capable of
describing the connection between a port and its
connector.
What: /sys/bus/thunderbolt/devices/usb4_portX/link
Date: Sep 2021
KernelVersion: v5.14

4
Documentation/ABI/testing/sysfs-class-cxl
View File

@ -103,8 +103,8 @@ What: /sys/class/cxl/<afu>/api_version_compatible
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the the lowest version of the userspace API
this this kernel supports.
Decimal value of the lowest version of the userspace API
this kernel supports.
Users: https://github.com/ibm-capi/libcxl

77
Documentation/ABI/testing/sysfs-class-firmware Normal file
View File

@ -0,0 +1,77 @@
What: /sys/class/firmware/.../data
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: The data sysfs file is used for firmware-fallback and for
firmware uploads. Cat a firmware image to this sysfs file
after you echo 1 to the loading sysfs file. When the firmware
image write is complete, echo 0 to the loading sysfs file. This
sequence will signal the completion of the firmware write and
signal the lower-level driver that the firmware data is
available.
What: /sys/class/firmware/.../cancel
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Write-only. For firmware uploads, write a "1" to this file to
request that the transfer of firmware data to the lower-level
device be canceled. This request will be rejected (EBUSY) if
the update cannot be canceled (e.g. a FLASH write is in
progress) or (ENODEV) if there is no firmware update in progress.
What: /sys/class/firmware/.../error
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Read-only. Returns a string describing a failed firmware
upload. This string will be in the form of <STATUS>:<ERROR>,
where <STATUS> will be one of the status strings described
for the status sysfs file and <ERROR> will be one of the
following: "hw-error", "timeout", "user-abort", "device-busy",
"invalid-file-size", "read-write-error", "flash-wearout". The
error sysfs file is only meaningful when the current firmware
upload status is "idle". If this file is read while a firmware
transfer is in progress, then the read will fail with EBUSY.
What: /sys/class/firmware/.../loading
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: The loading sysfs file is used for both firmware-fallback and
for firmware uploads. Echo 1 onto the loading file to indicate
you are writing a firmware file to the data sysfs node. Echo
-1 onto this file to abort the data write or echo 0 onto this
file to indicate that the write is complete. For firmware
uploads, the zero value also triggers the transfer of the
firmware data to the lower-level device driver.
What: /sys/class/firmware/.../remaining_size
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Read-only. For firmware upload, this file contains the size
of the firmware data that remains to be transferred to the
lower-level device driver. The size value is initialized to
the full size of the firmware image that was previously
written to the data sysfs file. This value is periodically
updated during the "transferring" phase of the firmware
upload.
Format: "%u".
What: /sys/class/firmware/.../status
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Read-only. Returns a string describing the current status of
a firmware upload. The string will be one of the following:
idle, "receiving", "preparing", "transferring", "programming".
What: /sys/class/firmware/.../timeout
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: This file supports the timeout mechanism for firmware
fallback. This file has no affect on firmware uploads. For
more information on timeouts please see the documentation
for firmware fallback.

42
Documentation/ABI/testing/sysfs-devices-physical_location Normal file
View File

@ -0,0 +1,42 @@
What: /sys/devices/.../physical_location
Date: March 2022
Contact: Won Chung <wonchung@google.com>
Description:
This directory contains information on physical location of
the device connection point with respect to the system's
housing.
What: /sys/devices/.../physical_location/panel
Date: March 2022
Contact: Won Chung <wonchung@google.com>
Description:
Describes which panel surface of the system’s housing the
device connection point resides on.
What: /sys/devices/.../physical_location/vertical_position
Date: March 2022
Contact: Won Chung <wonchung@google.com>
Description:
Describes vertical position of the device connection point on
the panel surface.
What: /sys/devices/.../physical_location/horizontal_position
Date: March 2022
Contact: Won Chung <wonchung@google.com>
Description:
Describes horizontal position of the device connection point on
the panel surface.
What: /sys/devices/.../physical_location/dock
Date: March 2022
Contact: Won Chung <wonchung@google.com>
Description:
"Yes" if the device connection point resides in a docking
station or a port replicator. "No" otherwise.
What: /sys/devices/.../physical_location/lid
Date: March 2022
Contact: Won Chung <wonchung@google.com>
Description:
"Yes" if the device connection point resides on the lid of
laptop system. "No" otherwise.

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

@ -526,6 +526,7 @@ What: /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/srbds
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
/sys/devices/system/cpu/vulnerabilities/itlb_multihit
/sys/devices/system/cpu/vulnerabilities/mmio_stale_data
Date: January 2018
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Information about CPU vulnerabilities

2
Documentation/ABI/testing/sysfs-driver-bd9571mwv-regulator
View File

@ -26,6 +26,6 @@ Description: Read/write the current state of DDR Backup Mode, which controls
DDR Backup Mode must be explicitly enabled by the user,
to invoke step 1.
See also Documentation/devicetree/bindings/mfd/bd9571mwv.txt.
See also Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml.
Users: User space applications for embedded boards equipped with a
BD9571MWV PMIC.

87
Documentation/ABI/testing/sysfs-driver-ccp Normal file
View File

@ -0,0 +1,87 @@
What: /sys/bus/pci/devices/<BDF>/fused_part
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/fused_part file reports
whether the CPU or APU has been fused to prevent tampering.
0: Not fused
1: Fused
What: /sys/bus/pci/devices/<BDF>/debug_lock_on
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/debug_lock_on reports
whether the AMD CPU or APU has been unlocked for debugging.
Possible values:
0: Not locked
1: Locked
What: /sys/bus/pci/devices/<BDF>/tsme_status
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/tsme_status file reports
the status of transparent secure memory encryption on AMD systems.
Possible values:
0: Not active
1: Active
What: /sys/bus/pci/devices/<BDF>/anti_rollback_status
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/anti_rollback_status file reports
whether the PSP is enforcing rollback protection.
Possible values:
0: Not enforcing
1: Enforcing
What: /sys/bus/pci/devices/<BDF>/rpmc_production_enabled
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/rpmc_production_enabled file reports
whether Replay Protected Monotonic Counter support has been enabled.
Possible values:
0: Not enabled
1: Enabled
What: /sys/bus/pci/devices/<BDF>/rpmc_spirom_available
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/rpmc_spirom_available file reports
whether an Replay Protected Monotonic Counter supported SPI is installed
on the system.
Possible values:
0: Not present
1: Present
What: /sys/bus/pci/devices/<BDF>/hsp_tpm_available
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/hsp_tpm_available file reports
whether the HSP TPM has been activated.
Possible values:
0: Not activated or present
1: Activated
What: /sys/bus/pci/devices/<BDF>/rom_armor_enforced
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/rom_armor_enforced file reports
whether RomArmor SPI protection is enforced.
Possible values:
0: Not enforced
1: Enforced

4
Documentation/PCI/pci.rst
View File

@ -273,12 +273,12 @@ Set the DMA mask size
While all drivers should explicitly indicate the DMA capability
(e.g. 32 or 64 bit) of the PCI bus master, devices with more than
32-bit bus master capability for streaming data need the driver
to "register" this capability by calling pci_set_dma_mask() with
to "register" this capability by calling dma_set_mask() with
appropriate parameters. In general this allows more efficient DMA
on systems where System RAM exists above 4G _physical_ address.
Drivers for all PCI-X and PCIe compliant devices must call
set_dma_mask() as they are 64-bit DMA devices.
dma_set_mask() as they are 64-bit DMA devices.
Similarly, drivers must also "register" this capability if the device
can directly address "coherent memory" in System RAM above 4G physical

5
Documentation/accounting/delay-accounting.rst
View File

@ -15,6 +15,7 @@ c) swapping in pages
d) memory reclaim
e) thrashing page cache
f) direct compact
g) write-protect copy
and makes these statistics available to userspace through
the taskstats interface.
@ -48,7 +49,7 @@ this structure. See
for a description of the fields pertaining to delay accounting.
It will generally be in the form of counters returning the cumulative
delay seen for cpu, sync block I/O, swapin, memory reclaim, thrash page
cache, direct compact etc.
cache, direct compact, write-protect copy etc.
Taking the difference of two successive readings of a given
counter (say cpu_delay_total) for a task will give the delay
@ -117,6 +118,8 @@ Get sum of delays, since system boot, for all pids with tgid 5::
0 0 0ms
COMPACT count delay total delay average
0 0 0ms
WPCOPY count delay total delay average
0 0 0ms
Get IO accounting for pid 1, it works only with -p::

6
Documentation/admin-guide/blockdev/index.rst
View File

@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
===========================
The Linux RapidIO Subsystem
===========================
=============
Block Devices
=============
.. toctree::
:maxdepth: 1

31
Documentation/admin-guide/bootconfig.rst
View File

@ -158,9 +158,15 @@ Each key-value pair is shown in each line with following style::
Boot Kernel With a Boot Config
==============================
Since the boot configuration file is loaded with initrd, it will be added
to the end of the initrd (initramfs) image file with padding, size,
checksum and 12-byte magic word as below.
There are two options to boot the kernel with bootconfig: attaching the
bootconfig to the initrd image or embedding it in the kernel itself.
Attaching a Boot Config to Initrd
---------------------------------
Since the boot configuration file is loaded with initrd by default,
it will be added to the end of the initrd (initramfs) image file with
padding, size, checksum and 12-byte magic word as below.
[initrd][bootconfig][padding][size(le32)][checksum(le32)][#BOOTCONFIG\n]
@ -196,6 +202,25 @@ To remove the config from the image, you can use -d option as below::
Then add "bootconfig" on the normal kernel command line to tell the
kernel to look for the bootconfig at the end of the initrd file.
Embedding a Boot Config into Kernel
-----------------------------------
If you can not use initrd, you can also embed the bootconfig file in the
kernel by Kconfig options. In this case, you need to recompile the kernel
with the following configs::
CONFIG_BOOT_CONFIG_EMBED=y
CONFIG_BOOT_CONFIG_EMBED_FILE="/PATH/TO/BOOTCONFIG/FILE"
``CONFIG_BOOT_CONFIG_EMBED_FILE`` requires an absolute path or a relative
path to the bootconfig file from source tree or object tree.
The kernel will embed it as the default bootconfig.
Just as when attaching the bootconfig to the initrd, you need ``bootconfig``
option on the kernel command line to enable the embedded bootconfig.
Note that even if you set this option, you can override the embedded
bootconfig by another bootconfig which attached to the initrd.
Kernel parameters via Boot Config
=================================

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

@ -17,3 +17,4 @@ are configurable at compile, boot or run time.
special-register-buffer-data-sampling.rst
core-scheduling.rst
l1d_flush.rst
processor_mmio_stale_data.rst

246
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst Normal file
View File

@ -0,0 +1,246 @@
=========================================
Processor MMIO Stale Data Vulnerabilities
=========================================
Processor MMIO Stale Data Vulnerabilities are a class of memory-mapped I/O
(MMIO) vulnerabilities that can expose data. The sequences of operations for
exposing data range from simple to very complex. Because most of the
vulnerabilities require the attacker to have access to MMIO, many environments
are not affected. System environments using virtualization where MMIO access is
provided to untrusted guests may need mitigation. These vulnerabilities are
not transient execution attacks. However, these vulnerabilities may propagate
stale data into core fill buffers where the data can subsequently be inferred
by an unmitigated transient execution attack. Mitigation for these
vulnerabilities includes a combination of microcode update and software
changes, depending on the platform and usage model. Some of these mitigations
are similar to those used to mitigate Microarchitectural Data Sampling (MDS) or
those used to mitigate Special Register Buffer Data Sampling (SRBDS).
Data Propagators
================
Propagators are operations that result in stale data being copied or moved from
one microarchitectural buffer or register to another. Processor MMIO Stale Data
Vulnerabilities are operations that may result in stale data being directly
read into an architectural, software-visible state or sampled from a buffer or
register.
Fill Buffer Stale Data Propagator (FBSDP)
-----------------------------------------
Stale data may propagate from fill buffers (FB) into the non-coherent portion
of the uncore on some non-coherent writes. Fill buffer propagation by itself
does not make stale data architecturally visible. Stale data must be propagated
to a location where it is subject to reading or sampling.
Sideband Stale Data Propagator (SSDP)
-------------------------------------
The sideband stale data propagator (SSDP) is limited to the client (including
Intel Xeon server E3) uncore implementation. The sideband response buffer is
shared by all client cores. For non-coherent reads that go to sideband
destinations, the uncore logic returns 64 bytes of data to the core, including
both requested data and unrequested stale data, from a transaction buffer and
the sideband response buffer. As a result, stale data from the sideband
response and transaction buffers may now reside in a core fill buffer.
Primary Stale Data Propagator (PSDP)
------------------------------------
The primary stale data propagator (PSDP) is limited to the client (including
Intel Xeon server E3) uncore implementation. Similar to the sideband response
buffer, the primary response buffer is shared by all client cores. For some
processors, MMIO primary reads will return 64 bytes of data to the core fill
buffer including both requested data and unrequested stale data. This is
similar to the sideband stale data propagator.
Vulnerabilities
===============
Device Register Partial Write (DRPW) (CVE-2022-21166)
-----------------------------------------------------
Some endpoint MMIO registers incorrectly handle writes that are smaller than
the register size. Instead of aborting the write or only copying the correct
subset of bytes (for example, 2 bytes for a 2-byte write), more bytes than
specified by the write transaction may be written to the register. On
processors affected by FBSDP, this may expose stale data from the fill buffers
of the core that created the write transaction.
Shared Buffers Data Sampling (SBDS) (CVE-2022-21125)
----------------------------------------------------
After propagators may have moved data around the uncore and copied stale data
into client core fill buffers, processors affected by MFBDS can leak data from
the fill buffer. It is limited to the client (including Intel Xeon server E3)
uncore implementation.
Shared Buffers Data Read (SBDR) (CVE-2022-21123)
------------------------------------------------
It is similar to Shared Buffer Data Sampling (SBDS) except that the data is
directly read into the architectural software-visible state. It is limited to
the client (including Intel Xeon server E3) uncore implementation.
Affected Processors
===================
Not all the CPUs are affected by all the variants. For instance, most
processors for the server market (excluding Intel Xeon E3 processors) are
impacted by only Device Register Partial Write (DRPW).
Below is the list of affected Intel processors [#f1]_:
=================== ============ =========
Common name Family_Model Steppings
=================== ============ =========
HASWELL_X 06_3FH 2,4
SKYLAKE_L 06_4EH 3
BROADWELL_X 06_4FH All
SKYLAKE_X 06_55H 3,4,6,7,11
BROADWELL_D 06_56H 3,4,5
SKYLAKE 06_5EH 3
ICELAKE_X 06_6AH 4,5,6
ICELAKE_D 06_6CH 1
ICELAKE_L 06_7EH 5
ATOM_TREMONT_D 06_86H All
LAKEFIELD 06_8AH 1
KABYLAKE_L 06_8EH 9 to 12
ATOM_TREMONT 06_96H 1
ATOM_TREMONT_L 06_9CH 0
KABYLAKE 06_9EH 9 to 13
COMETLAKE 06_A5H 2,3,5
COMETLAKE_L 06_A6H 0,1
ROCKETLAKE 06_A7H 1
=================== ============ =========
If a CPU is in the affected processor list, but not affected by a variant, it
is indicated by new bits in MSR IA32_ARCH_CAPABILITIES. As described in a later
section, mitigation largely remains the same for all the variants, i.e. to
clear the CPU fill buffers via VERW instruction.
New bits in MSRs
================
Newer processors and microcode update on existing affected processors added new
bits to IA32_ARCH_CAPABILITIES MSR. These bits can be used to enumerate
specific variants of Processor MMIO Stale Data vulnerabilities and mitigation
capability.
MSR IA32_ARCH_CAPABILITIES
--------------------------
Bit 13 - SBDR_SSDP_NO - When set, processor is not affected by either the
Shared Buffers Data Read (SBDR) vulnerability or the sideband stale
data propagator (SSDP).
Bit 14 - FBSDP_NO - When set, processor is not affected by the Fill Buffer
Stale Data Propagator (FBSDP).
Bit 15 - PSDP_NO - When set, processor is not affected by Primary Stale Data
Propagator (PSDP).
Bit 17 - FB_CLEAR - When set, VERW instruction will overwrite CPU fill buffer
values as part of MD_CLEAR operations. Processors that do not
enumerate MDS_NO (meaning they are affected by MDS) but that do
enumerate support for both L1D_FLUSH and MD_CLEAR implicitly enumerate
FB_CLEAR as part of their MD_CLEAR support.
Bit 18 - FB_CLEAR_CTRL - Processor supports read and write to MSR
IA32_MCU_OPT_CTRL[FB_CLEAR_DIS]. On such processors, the FB_CLEAR_DIS
bit can be set to cause the VERW instruction to not perform the
FB_CLEAR action. Not all processors that support FB_CLEAR will support
FB_CLEAR_CTRL.
MSR IA32_MCU_OPT_CTRL
---------------------
Bit 3 - FB_CLEAR_DIS - When set, VERW instruction does not perform the FB_CLEAR
action. This may be useful to reduce the performance impact of FB_CLEAR in
cases where system software deems it warranted (for example, when performance
is more critical, or the untrusted software has no MMIO access). Note that
FB_CLEAR_DIS has no impact on enumeration (for example, it does not change
FB_CLEAR or MD_CLEAR enumeration) and it may not be supported on all processors
that enumerate FB_CLEAR.
Mitigation
==========
Like MDS, all variants of Processor MMIO Stale Data vulnerabilities have the
same mitigation strategy to force the CPU to clear the affected buffers before
an attacker can extract the secrets.
This is achieved by using the otherwise unused and obsolete VERW instruction in
combination with a microcode update. The microcode clears the affected CPU
buffers when the VERW instruction is executed.
Kernel reuses the MDS function to invoke the buffer clearing:
mds_clear_cpu_buffers()
On MDS affected CPUs, the kernel already invokes CPU buffer clear on
kernel/userspace, hypervisor/guest and C-state (idle) transitions. No
additional mitigation is needed on such CPUs.
For CPUs not affected by MDS or TAA, mitigation is needed only for the attacker
with MMIO capability. Therefore, VERW is not required for kernel/userspace. For
virtualization case, VERW is only needed at VMENTER for a guest with MMIO
capability.
Mitigation points
-----------------
Return to user space
^^^^^^^^^^^^^^^^^^^^
Same mitigation as MDS when affected by MDS/TAA, otherwise no mitigation
needed.
C-State transition
^^^^^^^^^^^^^^^^^^
Control register writes by CPU during C-state transition can propagate data
from fill buffer to uncore buffers. Execute VERW before C-state transition to
clear CPU fill buffers.
Guest entry point
^^^^^^^^^^^^^^^^^
Same mitigation as MDS when processor is also affected by MDS/TAA, otherwise
execute VERW at VMENTER only for MMIO capable guests. On CPUs not affected by
MDS/TAA, guest without MMIO access cannot extract secrets using Processor MMIO
Stale Data vulnerabilities, so there is no need to execute VERW for such guests.
Mitigation control on the kernel command line
---------------------------------------------
The kernel command line allows to control the Processor MMIO Stale Data
mitigations at boot time with the option "mmio_stale_data=". The valid
arguments for this option are:
========== =================================================================
full If the CPU is vulnerable, enable mitigation; CPU buffer clearing
on exit to userspace and when entering a VM. Idle transitions are
protected as well. It does not automatically disable SMT.
full,nosmt Same as full, with SMT disabled on vulnerable CPUs. This is the
complete mitigation.
off Disables mitigation completely.
========== =================================================================
If the CPU is affected and mmio_stale_data=off is not supplied on the kernel
command line, then the kernel selects the appropriate mitigation.
Mitigation status information
-----------------------------
The Linux kernel provides a sysfs interface to enumerate the current
vulnerability status of the system: whether the system is vulnerable, and
which mitigations are active. The relevant sysfs file is:
/sys/devices/system/cpu/vulnerabilities/mmio_stale_data
The possible values in this file are:
.. list-table::
* - 'Not affected'
- The processor is not vulnerable
* - 'Vulnerable'
- The processor is vulnerable, but no mitigation enabled
* - 'Vulnerable: Clear CPU buffers attempted, no microcode'
- The processor is vulnerable, but microcode is not updated. The
mitigation is enabled on a best effort basis.
* - 'Mitigation: Clear CPU buffers'
- The processor is vulnerable and the CPU buffer clearing mitigation is
enabled.
If the processor is vulnerable then the following information is appended to
the above information:
======================== ===========================================
'SMT vulnerable' SMT is enabled
'SMT disabled' SMT is disabled
'SMT Host state unknown' Kernel runs in a VM, Host SMT state unknown
======================== ===========================================
References
----------
.. [#f1] Affected Processors
https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html

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

@ -979,8 +979,10 @@
[KNL] Debugging option to set a timeout in seconds for
deferred probe to give up waiting on dependencies to
probe. Only specific dependencies (subsystems or
drivers) that have opted in will be ignored. A timeout of 0
will timeout at the end of initcalls. This option will also
drivers) that have opted in will be ignored. A timeout
of 0 will timeout at the end of initcalls. If the time
out hasn't expired, it'll be restarted by each
successful driver registration. This option will also
dump out devices still on the deferred probe list after
retrying.
@ -1101,7 +1103,10 @@
driver later using sysfs.
driver_async_probe= [KNL]
List of driver names to be probed asynchronously.
List of driver names to be probed asynchronously. *
matches with all driver names. If * is specified, the
rest of the listed driver names are those that will NOT
match the *.
Format: <driver_name1>,<driver_name2>...
drm.edid_firmware=[<connector>:]<file>[,[<connector>:]<file>]
@ -2472,7 +2477,6 @@
protected: nVHE-based mode with support for guests whose
state is kept private from the host.
Not valid if the kernel is running in EL2.
Defaults to VHE/nVHE based on hardware support. Setting
mode to "protected" will disable kexec and hibernation
@ -3179,6 +3183,7 @@
srbds=off [X86,INTEL]
no_entry_flush [PPC]
no_uaccess_flush [PPC]
mmio_stale_data=off [X86]
Exceptions:
This does not have any effect on
@ -3200,6 +3205,7 @@
Equivalent to: l1tf=flush,nosmt [X86]
mds=full,nosmt [X86]
tsx_async_abort=full,nosmt [X86]
mmio_stale_data=full,nosmt [X86]
mminit_loglevel=
[KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
@ -3209,6 +3215,40 @@
log everything. Information is printed at KERN_DEBUG
so loglevel=8 may also need to be specified.
mmio_stale_data=
[X86,INTEL] Control mitigation for the Processor
MMIO Stale Data vulnerabilities.
Processor MMIO Stale Data is a class of
vulnerabilities that may expose data after an MMIO
operation. Exposed data could originate or end in
the same CPU buffers as affected by MDS and TAA.
Therefore, similar to MDS and TAA, the mitigation
is to clear the affected CPU buffers.
This parameter controls the mitigation. The
options are:
full - Enable mitigation on vulnerable CPUs
full,nosmt - Enable mitigation and disable SMT on
vulnerable CPUs.
off - Unconditionally disable mitigation
On MDS or TAA affected machines,
mmio_stale_data=off can be prevented by an active
MDS or TAA mitigation as these vulnerabilities are
mitigated with the same mechanism so in order to
disable this mitigation, you need to specify
mds=off and tsx_async_abort=off too.
Not specifying this option is equivalent to
mmio_stale_data=full.
For details see:
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
module.sig_enforce
[KNL] When CONFIG_MODULE_SIG is set, this means that
modules without (valid) signatures will fail to load.
@ -4107,6 +4147,15 @@
please report a bug.
nocrs [X86] Ignore PCI host bridge windows from ACPI.
If you need to use this, please report a bug.
use_e820 [X86] Use E820 reservations to exclude parts of
PCI host bridge windows. This is a workaround
for BIOS defects in host bridge _CRS methods.
If you need to use this, please report a bug to
<linux-pci@vger.kernel.org>.
no_e820 [X86] Ignore E820 reservations for PCI host
bridge windows. This is the default on modern
hardware. If you need to use this, please report
a bug to <linux-pci@vger.kernel.org>.
routeirq Do IRQ routing for all PCI devices.
This is normally done in pci_enable_device(),
so this option is a temporary workaround
@ -5156,6 +5205,30 @@
retain_initrd [RAM] Keep initrd memory after extraction
retbleed= [X86] Control mitigation of RETBleed (Arbitrary
Speculative Code Execution with Return Instructions)
vulnerability.
off - no mitigation
auto - automatically select a migitation
auto,nosmt - automatically select a mitigation,
disabling SMT if necessary for
the full mitigation (only on Zen1
and older without STIBP).
ibpb - mitigate short speculation windows on
basic block boundaries too. Safe, highest
perf impact.
unret - force enable untrained return thunks,
only effective on AMD f15h-f17h
based systems.
unret,nosmt - like unret, will disable SMT when STIBP
is not available.
Selecting 'auto' will choose a mitigation method at run
time according to the CPU.
Not specifying this option is equivalent to retbleed=auto.
rfkill.default_state=
0 "airplane mode". All wifi, bluetooth, wimax, gps, fm,
etc. communication is blocked by default.
@ -5527,6 +5600,7 @@
eibrs - enhanced IBRS
eibrs,retpoline - enhanced IBRS + Retpolines
eibrs,lfence - enhanced IBRS + LFENCE
ibrs - use IBRS to protect kernel
Not specifying this option is equivalent to
spectre_v2=auto.

15
Documentation/admin-guide/nfs/nfs-client.rst
View File

@ -36,10 +36,9 @@ administrative requirements that require particular behavior that does not
work well as part of an nfs_client_id4 string.
The nfs.nfs4_unique_id boot parameter specifies a unique string that can be
used instead of a system's node name when an NFS client identifies itself to
a server. Thus, if the system's node name is not unique, or it changes, its
nfs.nfs4_unique_id stays the same, preventing collision with other clients
or loss of state during NFS reboot recovery or transparent state migration.
used together with a system's node name when an NFS client identifies itself to
a server. Thus, if the system's node name is not unique, its
nfs.nfs4_unique_id can help prevent collisions with other clients.
The nfs.nfs4_unique_id string is typically a UUID, though it can contain
anything that is believed to be unique across all NFS clients. An
@ -53,8 +52,12 @@ outstanding NFSv4 state has expired, to prevent loss of NFSv4 state.
This string can be stored in an NFS client's grub.conf, or it can be provided
via a net boot facility such as PXE. It may also be specified as an nfs.ko
module parameter. Specifying a uniquifier string is not support for NFS
clients running in containers.
module parameter.
This uniquifier string will be the same for all NFS clients running in
containers unless it is overridden by a value written to
/sys/fs/nfs/net/nfs_client/identifier which will be local to the network
namespace of the process which writes.
The DNS resolver

22
Documentation/admin-guide/pm/intel-speed-select.rst
View File

@ -262,6 +262,28 @@ 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.
Changing performance level via BMC Interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is possible to change SST-PP level using out of band (OOB) agent (Via some
remote management console, through BMC "Baseboard Management Controller"
interface). This mode is supported from the Sapphire Rapids processor
generation. The kernel and tool change to support this mode is added to Linux
kernel version 5.18. To enable this feature, kernel config
"CONFIG_INTEL_HFI_THERMAL" is required. The minimum version of the tool
is "v1.12" to support this feature, which is part of Linux kernel version 5.18.
To support such configuration, this tool can be used as a daemon. Add
a command line option --oob::
# intel-speed-select --oob
Intel(R) Speed Select Technology
Executing on CPU model:143[0x8f]
OOB mode is enabled and will run as daemon
In this mode the tool will online/offline CPUs based on the new performance
level.
Check presence of other Intel(R) SST features
---------------------------------------------

1
Documentation/arch.rst
View File

@ -13,6 +13,7 @@ implementation.
arm/index
arm64/index
ia64/index
loongarch/index
m68k/index
mips/index
nios2/index

7
Documentation/arm/marvell.rst
View File

@ -374,8 +374,6 @@ PXA 2xx/3xx/93x/95x family
Linux kernel mach directory:
arch/arm/mach-pxa
Linux kernel plat directory:
arch/arm/plat-pxa
MMP/MMP2/MMP3 family (communication processor)
----------------------------------------------
@ -429,8 +427,6 @@ MMP/MMP2/MMP3 family (communication processor)
Linux kernel mach directory:
arch/arm/mach-mmp
Linux kernel plat directory:
arch/arm/plat-pxa
Berlin family (Multimedia Solutions)
-------------------------------------
@ -518,9 +514,6 @@ Long-term plans
Business Unit) in a single mach-<foo> directory. The plat-orion/
would therefore disappear.
* Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa
directory. The plat-pxa/ would therefore disappear.
Credits
-------

2
Documentation/arm/tcm.rst
View File

@ -34,7 +34,7 @@ CPU so it is usually wise not to overlap any physical RAM with
the TCM.
The TCM memory can then be remapped to another address again using
the MMU, but notice that the TCM if often used in situations where
the MMU, but notice that the TCM is often used in situations where
the MMU is turned off. To avoid confusion the current Linux
implementation will map the TCM 1 to 1 from physical to virtual
memory in the location specified by the kernel. Currently Linux

2
Documentation/arm64/sme.rst
View File

@ -371,7 +371,7 @@ The regset data starts with struct user_za_header, containing:
Appendix A. SME programmer's model (informative)
=================================================
This section provides a minimal description of the additions made by SVE to the
This section provides a minimal description of the additions made by SME to the
ARMv8-A programmer's model that are relevant to this document.
Note: This section is for information only and not intended to be complete or

2
Documentation/conf.py
View File

@ -161,7 +161,7 @@ finally:
#
# This is also used if you do content translation via gettext catalogs.
# Usually you set "language" from the command line for these cases.
language = None
language = 'en'
# There are two options for replacing |today|: either, you set today to some
# non-false value, then it is used:

2
Documentation/core-api/kernel-api.rst
View File

@ -223,7 +223,7 @@ Module Loading
Inter Module support
--------------------
Refer to the file kernel/module.c for more information.
Refer to the files in kernel/module/ for more information.
Hardware Interfaces
===================

4
Documentation/core-api/symbol-namespaces.rst
View File

@ -51,8 +51,8 @@ namespace ``USB_STORAGE``, use::
The corresponding ksymtab entry struct ``kernel_symbol`` will have the member
``namespace`` set accordingly. A symbol that is exported without a namespace will
refer to ``NULL``. There is no default namespace if none is defined. ``modpost``
and kernel/module.c make use the namespace at build time or module load time,
respectively.
and kernel/module/main.c make use the namespace at build time or module load
time, respectively.
2.2 Using the DEFAULT_SYMBOL_NAMESPACE define
=============================================

27
Documentation/devicetree/bindings/arm/hpe,gxp.yaml Normal file
View File

@ -0,0 +1,27 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/hpe,gxp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: HPE BMC GXP platforms
maintainers:
- Nick Hawkins <nick.hawkins@hpe.com>
- Jean-Marie Verdun <verdun@hpe.com>
properties:
compatible:
oneOf:
- description: GXP Based Boards
items:
- enum:
- hpe,gxp-dl360gen10
- const: hpe,gxp
required:
- compatible
additionalProperties: true
...

1
Documentation/devicetree/bindings/arm/intel,socfpga.yaml
View File

@ -18,6 +18,7 @@ properties:
items:
- enum:
- intel,n5x-socdk
- intel,socfpga-agilex-n6000
- intel,socfpga-agilex-socdk
- const: intel,socfpga-agilex

56
Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml Normal file
View File

@ -0,0 +1,56 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-clock.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MediaTek Functional Clock Controller for MT8186
maintainers:
- Chun-Jie Chen <chun-jie.chen@mediatek.com>
description: |
The clock architecture in MediaTek like below
PLLs -->
dividers -->
muxes
-->
clock gate
The devices provide clock gate control in different IP blocks.
properties:
compatible:
items:
- enum:
- mediatek,mt8186-imp_iic_wrap
- mediatek,mt8186-mfgsys
- mediatek,mt8186-wpesys
- mediatek,mt8186-imgsys1
- mediatek,mt8186-imgsys2
- mediatek,mt8186-vdecsys
- mediatek,mt8186-vencsys
- mediatek,mt8186-camsys
- mediatek,mt8186-camsys_rawa
- mediatek,mt8186-camsys_rawb
- mediatek,mt8186-mdpsys
- mediatek,mt8186-ipesys
reg:
maxItems: 1
'#clock-cells':
const: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
imp_iic_wrap: clock-controller@11017000 {
compatible = "mediatek,mt8186-imp_iic_wrap";
reg = <0x11017000 0x1000>;
#clock-cells = <1>;
};

54
Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml Normal file
View File

@ -0,0 +1,54 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-sys-clock.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MediaTek System Clock Controller for MT8186
maintainers:
- Chun-Jie Chen <chun-jie.chen@mediatek.com>
description: |
The clock architecture in MediaTek like below
PLLs -->
dividers -->
muxes
-->
clock gate
The apmixedsys provides most of PLLs which generated from SoC 26m.
The topckgen provides dividers and muxes which provide the clock source to other IP blocks.
The infracfg_ao provides clock gate in peripheral and infrastructure IP blocks.
The mcusys provides mux control to select the clock source in AP MCU.
The device nodes also provide the system control capacity for configuration.
properties:
compatible:
items:
- enum:
- mediatek,mt8186-mcusys
- mediatek,mt8186-topckgen
- mediatek,mt8186-infracfg_ao
- mediatek,mt8186-apmixedsys
- const: syscon
reg:
maxItems: 1
'#clock-cells':
const: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
topckgen: syscon@10000000 {
compatible = "mediatek,mt8186-topckgen", "syscon";
reg = <0x10000000 0x1000>;
#clock-cells = <1>;
};

52
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml Normal file
View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra-ccplex-cluster.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: NVIDIA Tegra CPU COMPLEX CLUSTER area device tree bindings
maintainers:
- Sumit Gupta <sumitg@nvidia.com>
- Mikko Perttunen <mperttunen@nvidia.com>
- Jon Hunter <jonathanh@nvidia.com>
- Thierry Reding <thierry.reding@gmail.com>
description: |+
The Tegra CPU COMPLEX CLUSTER area contains memory-mapped
registers that initiate CPU frequency/voltage transitions.
properties:
$nodename:
pattern: "ccplex@([0-9a-f]+)$"
compatible:
enum:
- nvidia,tegra186-ccplex-cluster
- nvidia,tegra234-ccplex-cluster
reg:
maxItems: 1
nvidia,bpmp:
$ref: '/schemas/types.yaml#/definitions/phandle'
description: |
Specifies the BPMP node that needs to be queried to get
operating point data for all CPUs.
additionalProperties: false
required:
- compatible
- reg
- nvidia,bpmp
- status
examples:
- |
ccplex@e000000 {
compatible = "nvidia,tegra234-ccplex-cluster";
reg = <0x0e000000 0x5ffff>;
nvidia,bpmp = <&bpmp>;
status = "okay";
};

58
Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml Normal file
View File

@ -0,0 +1,58 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/airoha,en7523-scu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: EN7523 Clock Device Tree Bindings
maintainers:
- Felix Fietkau <nbd@nbd.name>
- John Crispin <nbd@nbd.name>
description: |
This node defines the System Control Unit of the EN7523 SoC,
a collection of registers configuring many different aspects of the SoC.
The clock driver uses it to read and configure settings of the
PLL controller, which provides clocks for the CPU, the bus and
other SoC internal peripherals.
Each clock is assigned an identifier and client nodes use this identifier
to specify which clock they consume.
All these identifiers can be found in:
[1]: <include/dt-bindings/clock/en7523-clk.h>.
The clocks are provided inside a system controller node.
properties:
compatible:
items:
- const: airoha,en7523-scu
reg:
maxItems: 2
"#clock-cells":
description:
The first cell indicates the clock number, see [1] for available
clocks.
const: 1
required:
- compatible
- reg
- '#clock-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/en7523-clk.h>
scu: system-controller@1fa20000 {
compatible = "airoha,en7523-scu";
reg = <0x1fa20000 0x400>,
<0x1fb00000 0x1000>;
#clock-cells = <1>;
};

188
Documentation/devicetree/bindings/clock/clock-bindings.txt
View File

@ -1,186 +1,2 @@
This binding is a work-in-progress, and are based on some experimental
work by benh[1].
Sources of clock signal can be represented by any node in the device
tree. Those nodes are designated as clock providers. Clock consumer
nodes use a phandle and clock specifier pair to connect clock provider
outputs to clock inputs. Similar to the gpio specifiers, a clock
specifier is an array of zero, one or more cells identifying the clock
output on a device. The length of a clock specifier is defined by the
value of a #clock-cells property in the clock provider node.
[1] https://patchwork.ozlabs.org/patch/31551/
==Clock providers==
Required properties:
#clock-cells: Number of cells in a clock specifier; Typically 0 for nodes
with a single clock output and 1 for nodes with multiple
clock outputs.
Optional properties:
clock-output-names: Recommended to be a list of strings of clock output signal
names indexed by the first cell in the clock specifier.
However, the meaning of clock-output-names is domain
specific to the clock provider, and is only provided to
encourage using the same meaning for the majority of clock
providers. This format may not work for clock providers
using a complex clock specifier format. In those cases it
is recommended to omit this property and create a binding
specific names property.
Clock consumer nodes must never directly reference
the provider's clock-output-names property.
For example:
oscillator {
#clock-cells = <1>;
clock-output-names = "ckil", "ckih";
};
- this node defines a device with two clock outputs, the first named
"ckil" and the second named "ckih". Consumer nodes always reference
clocks by index. The names should reflect the clock output signal
names for the device.
clock-indices: If the identifying number for the clocks in the node
is not linear from zero, then this allows the mapping of
identifiers into the clock-output-names array.
For example, if we have two clocks <&oscillator 1> and <&oscillator 3>:
oscillator {
compatible = "myclocktype";
#clock-cells = <1>;
clock-indices = <1>, <3>;
clock-output-names = "clka", "clkb";
}
This ensures we do not have any empty strings in clock-output-names
==Clock consumers==
Required properties:
clocks: List of phandle and clock specifier pairs, one pair
for each clock input to the device. Note: if the
clock provider specifies '0' for #clock-cells, then
only the phandle portion of the pair will appear.
Optional properties:
clock-names: List of clock input name strings sorted in the same
order as the clocks property. Consumers drivers
will use clock-names to match clock input names
with clocks specifiers.
clock-ranges: Empty property indicating that child nodes can inherit named
clocks from this node. Useful for bus nodes to provide a
clock to their children.
For example:
device {
clocks = <&osc 1>, <&ref 0>;
clock-names = "baud", "register";
};
This represents a device with two clock inputs, named "baud" and "register".
The baud clock is connected to output 1 of the &osc device, and the register
clock is connected to output 0 of the &ref.
==Example==
/* external oscillator */
osc: oscillator {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32678>;
clock-output-names = "osc";
};
/* phase-locked-loop device, generates a higher frequency clock
* from the external oscillator reference */
pll: pll@4c000 {
compatible = "vendor,some-pll-interface"
#clock-cells = <1>;
clocks = <&osc 0>;
clock-names = "ref";
reg = <0x4c000 0x1000>;
clock-output-names = "pll", "pll-switched";
};
/* UART, using the low frequency oscillator for the baud clock,
* and the high frequency switched PLL output for register
* clocking */
uart@a000 {
compatible = "fsl,imx-uart";
reg = <0xa000 0x1000>;
interrupts = <33>;
clocks = <&osc 0>, <&pll 1>;
clock-names = "baud", "register";
};
This DT fragment defines three devices: an external oscillator to provide a
low-frequency reference clock, a PLL device to generate a higher frequency
clock signal, and a UART.
* The oscillator is fixed-frequency, and provides one clock output, named "osc".
* The PLL is both a clock provider and a clock consumer. It uses the clock
signal generated by the external oscillator, and provides two output signals
("pll" and "pll-switched").
* The UART has its baud clock connected the external oscillator and its
register clock connected to the PLL clock (the "pll-switched" signal)
==Assigned clock parents and rates==
Some platforms may require initial configuration of default parent clocks
and clock frequencies. Such a configuration can be specified in a device tree
node through assigned-clocks, assigned-clock-parents and assigned-clock-rates
properties. The assigned-clock-parents property should contain a list of parent
clocks in the form of a phandle and clock specifier pair and the
assigned-clock-rates property should contain a list of frequencies in Hz. Both
these properties should correspond to the clocks listed in the assigned-clocks
property.
To skip setting parent or rate of a clock its corresponding entry should be
set to 0, or can be omitted if it is not followed by any non-zero entry.
uart@a000 {
compatible = "fsl,imx-uart";
reg = <0xa000 0x1000>;
...
clocks = <&osc 0>, <&pll 1>;
clock-names = "baud", "register";
assigned-clocks = <&clkcon 0>, <&pll 2>;
assigned-clock-parents = <&pll 2>;
assigned-clock-rates = <0>, <460800>;
};
In this example the <&pll 2> clock is set as parent of clock <&clkcon 0> and
the <&pll 2> clock is assigned a frequency value of 460800 Hz.
Configuring a clock's parent and rate through the device node that consumes
the clock can be done only for clocks that have a single user. Specifying
conflicting parent or rate configuration in multiple consumer nodes for
a shared clock is forbidden.
Configuration of common clocks, which affect multiple consumer devices can
be similarly specified in the clock provider node.
==Protected clocks==
Some platforms or firmwares may not fully expose all the clocks to the OS, such
as in situations where those clks are used by drivers running in ARM secure
execution levels. Such a configuration can be specified in device tree with the
protected-clocks property in the form of a clock specifier list. This property should
only be specified in the node that is providing the clocks being protected:
clock-controller@a000f000 {
compatible = "vendor,clk95;
reg = <0xa000f000 0x1000>
#clocks-cells = <1>;
...
protected-clocks = <UART3_CLK>, <SPI5_CLK>;
};
This file has moved to the clock binding schema:
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/clock/clock.yaml

2
Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
View File

@ -45,7 +45,7 @@ description: |
The case where SH and SP are both 1 is likely not very interesting.
maintainers:
- Luca Ceresoli <luca@lucaceresoli.net>
- Luca Ceresoli <luca.ceresoli@bootlin.com>
properties:
compatible:

4
Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
View File

@ -20,12 +20,10 @@ description: |
See also:
- dt-bindings/clock/qcom,gcc-msm8960.h
- dt-bindings/reset/qcom,gcc-msm8960.h
- dt-bindings/clock/qcom,gcc-apq8084.h
- dt-bindings/reset/qcom,gcc-apq8084.h
properties:
compatible:
const: qcom,gcc-apq8084
const: qcom,gcc-apq8064
nvmem-cells:
minItems: 1

42
Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml Normal file
View File

@ -0,0 +1,42 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,gcc-apq8084.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller Binding for APQ8084
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module which supports the clocks, resets and
power domains on APQ8084.
See also::
- dt-bindings/clock/qcom,gcc-apq8084.h
- dt-bindings/reset/qcom,gcc-apq8084.h
allOf:
- $ref: qcom,gcc.yaml#
properties:
compatible:
const: qcom,gcc-apq8084
required:
- compatible
unevaluatedProperties: false
examples:
- |
clock-controller@fc400000 {
compatible = "qcom,gcc-apq8084";
reg = <0xfc400000 0x4000>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

128
Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml Normal file
View File

@ -0,0 +1,128 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,gcc-sc8280xp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller Binding for SC8280xp
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
description: |
Qualcomm global clock control module which supports the clocks, resets and
power domains on SC8280xp.
See also:
- include/dt-bindings/clock/qcom,gcc-sc8280xp.h
properties:
compatible:
const: qcom,gcc-sc8280xp
clocks:
items:
- description: XO reference clock
- description: Sleep clock
- description: UFS memory first RX symbol clock
- description: UFS memory second RX symbol clock
- description: UFS memory first TX symbol clock
- description: UFS card first RX symbol clock
- description: UFS card second RX symbol clock
- description: UFS card first TX symbol clock
- description: Primary USB SuperSpeed pipe clock
- description: USB4 PHY pipegmux clock source
- description: USB4 PHY DP gmux clock source
- description: USB4 PHY sys piegmux clock source
- description: USB4 PHY PCIe pipe clock
- description: USB4 PHY router max pipe clock
- description: Primary USB4 RX0 clock
- description: Primary USB4 RX1 clock
- description: Secondary USB SuperSpeed pipe clock
- description: Second USB4 PHY pipegmux clock source
- description: Second USB4 PHY DP gmux clock source
- description: Second USB4 PHY sys pipegmux clock source
- description: Second USB4 PHY PCIe pipe clock
- description: Second USB4 PHY router max pipe clock
- description: Secondary USB4 RX0 clock
- description: Secondary USB4 RX1 clock
- description: Multiport USB first SupserSpeed pipe clock
- description: Multiport USB second SuperSpeed pipe clock
- description: PCIe 2a pipe clock
- description: PCIe 2b pipe clock
- description: PCIe 3a pipe clock
- description: PCIe 3b pipe clock
- description: PCIe 4 pipe clock
- description: First EMAC controller reference clock
- description: Second EMAC controller reference clock
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
protected-clocks:
maxItems: 389
required:
- compatible
- clocks
- reg
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
clock-controller@100000 {
compatible = "qcom,gcc-sc8280xp";
reg = <0x00100000 0x1f0000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&sleep_clk>,
<&ufs_phy_rx_symbol_0_clk>,
<&ufs_phy_rx_symbol_1_clk>,
<&ufs_phy_tx_symbol_0_clk>,
<&ufs_card_rx_symbol_0_clk>,
<&ufs_card_rx_symbol_1_clk>,
<&ufs_card_tx_symbol_0_clk>,
<&usb_0_ssphy>,
<&gcc_usb4_phy_pipegmux_clk_src>,
<&gcc_usb4_phy_dp_gmux_clk_src>,
<&gcc_usb4_phy_sys_pipegmux_clk_src>,
<&usb4_phy_gcc_usb4_pcie_pipe_clk>,
<&usb4_phy_gcc_usb4rtr_max_pipe_clk>,
<&qusb4phy_gcc_usb4_rx0_clk>,
<&qusb4phy_gcc_usb4_rx1_clk>,
<&usb_1_ssphy>,
<&gcc_usb4_1_phy_pipegmux_clk_src>,
<&gcc_usb4_1_phy_dp_gmux_clk_src>,
<&gcc_usb4_1_phy_sys_pipegmux_clk_src>,
<&usb4_1_phy_gcc_usb4_pcie_pipe_clk>,
<&usb4_1_phy_gcc_usb4rtr_max_pipe_clk>,
<&qusb4phy_1_gcc_usb4_rx0_clk>,
<&qusb4phy_1_gcc_usb4_rx1_clk>,
<&usb_2_ssphy>,
<&usb_3_ssphy>,
<&pcie2a_lane>,
<&pcie2b_lane>,
<&pcie3a_lane>,
<&pcie3b_lane>,
<&pcie4_lane>,
<&rxc0_ref_clk>,
<&rxc1_ref_clk>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

2
Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Multimedia Clock & Reset Controller Binding
maintainers:
- Jeffrey Hugo <jhugo@codeaurora.org>
- Jeffrey Hugo <quic_jhugo@quicinc.com>
- Taniya Das <tdas@codeaurora.org>
description: |

63
Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
View File

@ -1,63 +0,0 @@
Qualcomm RPM Clock Controller Binding
------------------------------------------------
The RPM is a dedicated hardware engine for managing the shared
SoC resources in order to keep the lowest power profile. It
communicates with other hardware subsystems via shared memory
and accepts clock requests, aggregates the requests and turns
the clocks on/off or scales them on demand.
Required properties :
- compatible : shall contain only one of the following. The generic
compatible "qcom,rpmcc" should be also included.
"qcom,rpmcc-mdm9607", "qcom,rpmcc"
"qcom,rpmcc-msm8660", "qcom,rpmcc"
"qcom,rpmcc-apq8060", "qcom,rpmcc"
"qcom,rpmcc-msm8226", "qcom,rpmcc"
"qcom,rpmcc-msm8916", "qcom,rpmcc"
"qcom,rpmcc-msm8936", "qcom,rpmcc"
"qcom,rpmcc-msm8953", "qcom,rpmcc"
"qcom,rpmcc-msm8974", "qcom,rpmcc"
"qcom,rpmcc-msm8976", "qcom,rpmcc"
"qcom,rpmcc-apq8064", "qcom,rpmcc"
"qcom,rpmcc-ipq806x", "qcom,rpmcc"
"qcom,rpmcc-msm8992",·"qcom,rpmcc"
"qcom,rpmcc-msm8994",·"qcom,rpmcc"
"qcom,rpmcc-msm8996", "qcom,rpmcc"
"qcom,rpmcc-msm8998", "qcom,rpmcc"
"qcom,rpmcc-qcm2290", "qcom,rpmcc"
"qcom,rpmcc-qcs404", "qcom,rpmcc"
"qcom,rpmcc-sdm660", "qcom,rpmcc"
"qcom,rpmcc-sm6115", "qcom,rpmcc"
"qcom,rpmcc-sm6125", "qcom,rpmcc"
- #clock-cells : shall contain 1
The clock enumerators are defined in <dt-bindings/clock/qcom,rpmcc.h>
and come in pairs: FOO_CLK followed by FOO_A_CLK. The latter clock
is an "active" clock, which means that the consumer only care that the
clock is available when the apps CPU subsystem is active, i.e. not
suspended or in deep idle. If it is important that the clock keeps running
during system suspend, you need to specify the non-active clock, the one
not containing *_A_* in the enumerator name.
Example:
smd {
compatible = "qcom,smd";
rpm {
interrupts = <0 168 1>;
qcom,ipc = <&apcs 8 0>;
qcom,smd-edge = <15>;
rpm_requests {
compatible = "qcom,rpm-msm8916";
qcom,smd-channels = "rpm_requests";
rpmcc: clock-controller {
compatible = "qcom,rpmcc-msm8916", "qcom,rpmcc";
#clock-cells = <1>;
};
};
};
};

75
Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml Normal file
View File

@ -0,0 +1,75 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,rpmcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm RPM Clock Controller
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
- Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
description: |
The clock enumerators are defined in <dt-bindings/clock/qcom,rpmcc.h> and
come in pairs:: FOO_CLK followed by FOO_A_CLK. The latter clock is
an "active" clock, which means that the consumer only care that the clock is
available when the apps CPU subsystem is active, i.e. not suspended or in
deep idle. If it is important that the clock keeps running during system
suspend, you need to specify the non-active clock, the one not containing
*_A_* in the enumerator name.
properties:
compatible:
items:
- enum:
- qcom,rpmcc-apq8060
- qcom,rpmcc-apq8064
- qcom,rpmcc-ipq806x
- qcom,rpmcc-mdm9607
- qcom,rpmcc-msm8226
- qcom,rpmcc-msm8660
- qcom,rpmcc-msm8916
- qcom,rpmcc-msm8936
- qcom,rpmcc-msm8953
- qcom,rpmcc-msm8974
- qcom,rpmcc-msm8976
- qcom,rpmcc-msm8992
- qcom,rpmcc-msm8994
- qcom,rpmcc-msm8996
- qcom,rpmcc-msm8998
- qcom,rpmcc-qcm2290
- qcom,rpmcc-qcs404
- qcom,rpmcc-sdm660
- qcom,rpmcc-sm6115
- qcom,rpmcc-sm6125
- const: qcom,rpmcc
'#clock-cells':
const: 1
clocks:
maxItems: 1
clock-names:
const: xo
required:
- compatible
- '#clock-cells'
additionalProperties: false
examples:
- |
rpm {
rpm-requests {
compatible = "qcom,rpm-msm8916";
qcom,smd-channels = "rpm_requests";
clock-controller {
compatible = "qcom,rpmcc-msm8916", "qcom,rpmcc";
#clock-cells = <1>;
};
};
};

1
Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml
View File

@ -49,6 +49,7 @@ properties:
- renesas,r8a77995-cpg-mssr # R-Car D3
- renesas,r8a779a0-cpg-mssr # R-Car V3U
- renesas,r8a779f0-cpg-mssr # R-Car S4-8
- renesas,r8a779g0-cpg-mssr # R-Car V4H
reg:
maxItems: 1

11
Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml
View File

@ -39,6 +39,17 @@ properties:
'#power-domain-cells':
const: 0
'#address-cells':
const: 1
'#size-cells':
const: 1
patternProperties:
"^dma-router@[a-f0-9]+$":
type: object
$ref: "../dma/renesas,rzn1-dmamux.yaml#"
required:
- compatible
- reg

20
Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml
View File

@ -4,14 +4,15 @@
$id: "http://devicetree.org/schemas/clock/renesas,rzg2l-cpg.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Renesas RZ/{G2L,V2L} Clock Pulse Generator / Module Standby Mode
title: Renesas RZ/{G2L,V2L,V2M} Clock Pulse Generator / Module Standby Mode
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
description: |
On Renesas RZ/{G2L,V2L} SoC, the CPG (Clock Pulse Generator) and Module
Standby Mode share the same register block.
On Renesas RZ/{G2L,V2L}-alike SoC's, the CPG (Clock Pulse Generator) and Module
Standby Mode share the same register block. On RZ/V2M, the functionality is
similar, but does not have Clock Monitor Registers.
They provide the following functionalities:
- The CPG block generates various core clocks,
@ -23,8 +24,10 @@ description: |
properties:
compatible:
enum:
- renesas,r9a07g044-cpg # RZ/G2{L,LC}
- renesas,r9a07g054-cpg # RZ/V2L
- renesas,r9a07g043-cpg # RZ/G2UL{Type-1,Type-2}
- renesas,r9a07g044-cpg # RZ/G2{L,LC}
- renesas,r9a07g054-cpg # RZ/V2L
- renesas,r9a09g011-cpg # RZ/V2M
reg:
maxItems: 1
@ -42,9 +45,10 @@ properties:
description: |
- For CPG core clocks, the two clock specifier cells must be "CPG_CORE"
and a core clock reference, as defined in
<dt-bindings/clock/r9a07g*-cpg.h>
<dt-bindings/clock/r9a0*-cpg.h>
- For module clocks, the two clock specifier cells must be "CPG_MOD" and
a module number, as defined in the <dt-bindings/clock/r9a07g0*-cpg.h>.
a module number, as defined in the <dt-bindings/clock/r9a07g0*-cpg.h> or
<dt-bindings/clock/r9a09g011-cpg.h>.
const: 2
'#power-domain-cells':
@ -58,7 +62,7 @@ properties:
'#reset-cells':
description:
The single reset specifier cell must be the module number, as defined in
the <dt-bindings/clock/r9a07g0*-cpg.h>.
the <dt-bindings/clock/r9a07g0*-cpg.h> or <dt-bindings/clock/r9a09g011-cpg.h>.
const: 1
required:

70
Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt
View File

@ -1,70 +0,0 @@
* Rockchip PX30 Clock and Reset Unit
The PX30 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: PMU for CRU should be "rockchip,px30-pmu-cru"
- compatible: CRU should be "rockchip,px30-cru"
- reg: physical base address of the controller and length of memory mapped
region.
- clocks: A list of phandle + clock-specifier pairs for the clocks listed
in clock-names
- clock-names: Should contain the following:
- "xin24m" for both PMUCRU and CRU
- "gpll" for CRU (sourced from PMUCRU)
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Optional Properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
If missing, pll rates are not changeable, due to the missing pll lock status.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/px30-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "xin32k" - rtc clock - optional,
- "i2sx_clkin" - external I2S clock - optional,
- "gmac_clkin" - external GMAC clock - optional
Example: Clock controller node:
pmucru: clock-controller@ff2bc000 {
compatible = "rockchip,px30-pmucru";
reg = <0x0 0xff2bc000 0x0 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};
cru: clock-controller@ff2b0000 {
compatible = "rockchip,px30-cru";
reg = <0x0 0xff2b0000 0x0 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@ff030000 {
compatible = "rockchip,px30-uart", "snps,dw-apb-uart";
reg = <0x0 0xff030000 0x0 0x100>;
interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&pmucru SCLK_UART0_PMU>, <&pmucru PCLK_UART0_PMU>;
clock-names = "baudclk", "apb_pclk";
reg-shift = <2>;
reg-io-width = <4>;
};

119
Documentation/devicetree/bindings/clock/rockchip,px30-cru.yaml Normal file
View File

@ -0,0 +1,119 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,px30-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip PX30 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The PX30 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/px30-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "xin32k" - rtc clock - optional
- "i2sx_clkin" - external I2S clock - optional
- "gmac_clkin" - external GMAC clock - optional
properties:
compatible:
enum:
- rockchip,px30-cru
- rockchip,px30-pmucru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
minItems: 1
items:
- description: Clock for both PMUCRU and CRU
- description: Clock for CRU (sourced from PMUCRU)
clock-names:
minItems: 1
items:
- const: xin24m
- const: gpll
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- clocks
- clock-names
- "#clock-cells"
- "#reset-cells"
allOf:
- if:
properties:
compatible:
contains:
const: rockchip,px30-cru
then:
properties:
clocks:
minItems: 2
clock-names:
minItems: 2
else:
properties:
clocks:
maxItems: 1
clock-names:
maxItems: 1
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/px30-cru.h>
pmucru: clock-controller@ff2bc000 {
compatible = "rockchip,px30-pmucru";
reg = <0xff2bc000 0x1000>;
clocks = <&xin24m>;
clock-names = "xin24m";
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
cru: clock-controller@ff2b0000 {
compatible = "rockchip,px30-cru";
reg = <0xff2b0000 0x1000>;
clocks = <&xin24m>, <&pmucru PLL_GPLL>;
clock-names = "xin24m", "gpll";
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

56
Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
View File

@ -1,56 +0,0 @@
* Rockchip RK3036 Clock and Reset Unit
The RK3036 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: should be "rockchip,rk3036-cru"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Optional Properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
If missing pll rates are not changeable, due to the missing pll lock status.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3036-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "ext_i2s" - external I2S clock - optional,
- "rmii_clkin" - external EMAC clock - optional
Example: Clock controller node:
cru: cru@20000000 {
compatible = "rockchip,rk3036-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@20060000 {
compatible = "snps,dw-apb-uart";
reg = <0x20060000 0x100>;
interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <&cru SCLK_UART0>;
};

72
Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.yaml Normal file
View File

@ -0,0 +1,72 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3036-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RK3036 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RK3036 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3036-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "ext_i2s" - external I2S clock - optional
- "rmii_clkin" - external EMAC clock - optional
properties:
compatible:
enum:
- rockchip,rk3036-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@20000000 {
compatible = "rockchip,rk3036-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

61
Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.txt
View File

@ -1,61 +0,0 @@
* Rockchip RK3188/RK3066 Clock and Reset Unit
The RK3188/RK3066 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: should be "rockchip,rk3188-cru", "rockchip,rk3188a-cru" or
"rockchip,rk3066a-cru"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Optional Properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
If missing pll rates are not changeable, due to the missing pll lock status.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3188-cru.h and
dt-bindings/clock/rk3066-cru.h headers and can be used in device tree sources.
Similar macros exist for the reset sources in these files.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "xin32k" - rtc clock - optional,
- "xin27m" - 27mhz crystal input on rk3066 - optional,
- "ext_hsadc" - external HSADC clock - optional,
- "ext_cif0" - external camera clock - optional,
- "ext_rmii" - external RMII clock - optional,
- "ext_jtag" - externalJTAG clock - optional
Example: Clock controller node:
cru: cru@20000000 {
compatible = "rockchip,rk3188-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@10124000 {
compatible = "snps,dw-apb-uart";
reg = <0x10124000 0x400>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <1>;
clocks = <&cru SCLK_UART0>;
};

78
Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.yaml Normal file
View File

@ -0,0 +1,78 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3188-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RK3188/RK3066 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RK3188/RK3066 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3188-cru.h and
dt-bindings/clock/rk3066-cru.h headers and can be used in device tree sources.
Similar macros exist for the reset sources in these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "xin32k" - RTC clock - optional
- "xin27m" - 27mhz crystal input on RK3066 - optional
- "ext_hsadc" - external HSADC clock - optional
- "ext_cif0" - external camera clock - optional
- "ext_rmii" - external RMII clock - optional
- "ext_jtag" - external JTAG clock - optional
properties:
compatible:
enum:
- rockchip,rk3066a-cru
- rockchip,rk3188-cru
- rockchip,rk3188a-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@20000000 {
compatible = "rockchip,rk3188-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

58
Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.txt
View File

@ -1,58 +0,0 @@
* Rockchip RK3228 Clock and Reset Unit
The RK3228 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: should be "rockchip,rk3228-cru"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Optional Properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
If missing pll rates are not changeable, due to the missing pll lock status.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3228-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "ext_i2s" - external I2S clock - optional,
- "ext_gmac" - external GMAC clock - optional
- "ext_hsadc" - external HSADC clock - optional
- "phy_50m_out" - output clock of the pll in the mac phy
Example: Clock controller node:
cru: cru@20000000 {
compatible = "rockchip,rk3228-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@10110000 {
compatible = "snps,dw-apb-uart";
reg = <0x10110000 0x100>;
interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <&cru SCLK_UART0>;
};

74
Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.yaml Normal file
View File

@ -0,0 +1,74 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3228-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RK3228 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RK3228 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3228-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "ext_i2s" - external I2S clock - optional
- "ext_gmac" - external GMAC clock - optional
- "ext_hsadc" - external HSADC clock - optional
- "phy_50m_out" - output clock of the pll in the mac phy
properties:
compatible:
enum:
- rockchip,rk3228-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@20000000 {
compatible = "rockchip,rk3228-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

67
Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt
View File

@ -1,67 +0,0 @@
* Rockchip RK3288 Clock and Reset Unit
The RK3288 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
A revision of this SoC is available: rk3288w. The clock tree is a bit
different so another dt-compatible is available. Noticed that it is only
setting the difference but there is no automatic revision detection. This
should be performed by bootloaders.
Required Properties:
- compatible: should be "rockchip,rk3288-cru" or "rockchip,rk3288w-cru" in
case of this revision of Rockchip rk3288.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Optional Properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
If missing pll rates are not changeable, due to the missing pll lock status.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3288-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "xin32k" - rtc clock - optional,
- "ext_i2s" - external I2S clock - optional,
- "ext_hsadc" - external HSADC clock - optional,
- "ext_edp_24m" - external display port clock - optional,
- "ext_vip" - external VIP clock - optional,
- "ext_isp" - external ISP clock - optional,
- "ext_jtag" - external JTAG clock - optional
Example: Clock controller node:
cru: cru@20000000 {
compatible = "rockchip,rk3188-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@10124000 {
compatible = "snps,dw-apb-uart";
reg = <0x10124000 0x400>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <1>;
clocks = <&cru SCLK_UART0>;
};

85
Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.yaml Normal file
View File

@ -0,0 +1,85 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3288-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RK3288 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RK3288 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
A revision of this SoC is available: rk3288w. The clock tree is a bit
different so another dt-compatible is available. Noticed that it is only
setting the difference but there is no automatic revision detection. This
should be performed by boot loaders.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3288-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "xin32k" - rtc clock - optional,
- "ext_i2s" - external I2S clock - optional,
- "ext_hsadc" - external HSADC clock - optional,
- "ext_edp_24m" - external display port clock - optional,
- "ext_vip" - external VIP clock - optional,
- "ext_isp" - external ISP clock - optional,
- "ext_jtag" - external JTAG clock - optional
properties:
compatible:
enum:
- rockchip,rk3288-cru
- rockchip,rk3288w-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@ff760000 {
compatible = "rockchip,rk3288-cru";
reg = <0xff760000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

60
Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.txt
View File

@ -1,60 +0,0 @@
* Rockchip RK3308 Clock and Reset Unit
The RK3308 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: CRU should be "rockchip,rk3308-cru"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Optional Properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
If missing, pll rates are not changeable, due to the missing pll lock status.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3308-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "xin32k" - rtc clock - optional,
- "mclk_i2s0_8ch_in", "mclk_i2s1_8ch_in", "mclk_i2s2_8ch_in",
"mclk_i2s3_8ch_in", "mclk_i2s0_2ch_in",
"mclk_i2s1_2ch_in" - external I2S or SPDIF clock - optional,
- "mac_clkin" - external MAC clock - optional
Example: Clock controller node:
cru: clock-controller@ff500000 {
compatible = "rockchip,rk3308-cru";
reg = <0x0 0xff500000 0x0 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@ff0a0000 {
compatible = "rockchip,rk3308-uart", "snps,dw-apb-uart";
reg = <0x0 0xff0a0000 0x0 0x100>;
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
clock-names = "baudclk", "apb_pclk";
reg-shift = <2>;
reg-io-width = <4>;
status = "disabled";
};

76
Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.yaml Normal file
View File

@ -0,0 +1,76 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3308-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RK3308 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RK3308 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3308-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "xin32k" - rtc clock - optional
- "mclk_i2s0_8ch_in", "mclk_i2s1_8ch_in",
"mclk_i2s2_8ch_in", "mclk_i2s3_8ch_in",
"mclk_i2s0_2ch_in", "mclk_i2s1_2ch_in" - external I2S or
SPDIF clock - optional
- "mac_clkin" - external MAC clock - optional
properties:
compatible:
enum:
- rockchip,rk3308-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@ff500000 {
compatible = "rockchip,rk3308-cru";
reg = <0xff500000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

61
Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.txt
View File

@ -1,61 +0,0 @@
* Rockchip RK3368 Clock and Reset Unit
The RK3368 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: should be "rockchip,rk3368-cru"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Optional Properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
If missing, pll rates are not changeable, due to the missing pll lock status.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3368-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "xin32k" - rtc clock - optional,
- "ext_i2s" - external I2S clock - optional,
- "ext_gmac" - external GMAC clock - optional
- "ext_hsadc" - external HSADC clock - optional,
- "ext_isp" - external ISP clock - optional,
- "ext_jtag" - external JTAG clock - optional
- "ext_vip" - external VIP clock - optional,
- "usbotg_out" - output clock of the pll in the otg phy
Example: Clock controller node:
cru: clock-controller@ff760000 {
compatible = "rockchip,rk3368-cru";
reg = <0x0 0xff760000 0x0 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@10124000 {
compatible = "snps,dw-apb-uart";
reg = <0x10124000 0x400>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <1>;
clocks = <&cru SCLK_UART0>;
};

78
Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.yaml Normal file
View File

@ -0,0 +1,78 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3368-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RK3368 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RK3368 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3368-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "xin32k" - rtc clock - optional
- "ext_i2s" - external I2S clock - optional
- "ext_gmac" - external GMAC clock - optional
- "ext_hsadc" - external HSADC clock - optional
- "ext_isp" - external ISP clock - optional
- "ext_jtag" - external JTAG clock - optional
- "ext_vip" - external VIP clock - optional
- "usbotg_out" - output clock of the pll in the otg phy
properties:
compatible:
enum:
- rockchip,rk3368-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@ff760000 {
compatible = "rockchip,rk3368-cru";
reg = <0xff760000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

33
Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RK3399 Clock and Reset Unit
maintainers:
- Xing Zheng <zhengxing@rock-chips.com>
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
@ -22,11 +22,11 @@ description: |
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "xin32k" - rtc clock - optional,
- "clkin_gmac" - external GMAC clock - optional,
- "clkin_i2s" - external I2S clock - optional,
- "pclkin_cif" - external ISP clock - optional,
- "xin24m" - crystal input - required,
- "xin32k" - rtc clock - optional,
- "clkin_gmac" - external GMAC clock - optional,
- "clkin_i2s" - external I2S clock - optional,
- "pclkin_cif" - external ISP clock - optional,
- "clk_usbphy0_480m" - output clock of the pll in the usbphy0
- "clk_usbphy1_480m" - output clock of the pll in the usbphy1
@ -46,24 +46,15 @@ properties:
const: 1
clocks:
minItems: 1
maxItems: 1
assigned-clocks:
minItems: 1
maxItems: 64
assigned-clock-parents:
minItems: 1
maxItems: 64
assigned-clock-rates:
minItems: 1
maxItems: 64
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description: >
phandle to the syscon managing the "general register files". It is used
description:
Phandle to the syscon managing the "general register files". It is used
for GRF muxes, if missing any muxes present in the GRF will not be
available.
@ -77,7 +68,7 @@ additionalProperties: false
examples:
- |
pmucru: pmu-clock-controller@ff750000 {
pmucru: clock-controller@ff750000 {
compatible = "rockchip,rk3399-pmucru";
reg = <0xff750000 0x1000>;
#clock-cells = <1>;

13
Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml
View File

@ -34,6 +34,19 @@ properties:
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg

59
Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.txt
View File

@ -1,59 +0,0 @@
* Rockchip RV1108 Clock and Reset Unit
The RV1108 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: should be "rockchip,rv1108-cru"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Optional Properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
If missing pll rates are not changeable, due to the missing pll lock status.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rv1108-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "ext_vip" - external VIP clock - optional
- "ext_i2s" - external I2S clock - optional
- "ext_gmac" - external GMAC clock - optional
- "hdmiphy" - external clock input derived from HDMI PHY - optional
- "usbphy" - external clock input derived from USB PHY - optional
Example: Clock controller node:
cru: cru@20200000 {
compatible = "rockchip,rv1108-cru";
reg = <0x20200000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@10230000 {
compatible = "rockchip,rv1108-uart", "snps,dw-apb-uart";
reg = <0x10230000 0x100>;
interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <&cru SCLK_UART0>;
};

75
Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.yaml Normal file
View File

@ -0,0 +1,75 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rv1108-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RV1108 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RV1108 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rv1108-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "ext_vip" - external VIP clock - optional
- "ext_i2s" - external I2S clock - optional
- "ext_gmac" - external GMAC clock - optional
- "hdmiphy" - external clock input derived from HDMI PHY - optional
- "usbphy" - external clock input derived from USB PHY - optional
properties:
compatible:
enum:
- rockchip,rv1108-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@20200000 {
compatible = "rockchip,rv1108-cru";
reg = <0x20200000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

2
Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
View File

@ -41,6 +41,7 @@ description: |
The list of valid indices for STM32MP1 is available in:
include/dt-bindings/reset-controller/stm32mp1-resets.h
include/dt-bindings/reset-controller/stm32mp13-resets.h
This file implements defines like:
#define LTDC_R 3072
@ -57,6 +58,7 @@ properties:
- enum:
- st,stm32mp1-rcc-secure
- st,stm32mp1-rcc
- st,stm32mp13-rcc
- const: syscon
clocks: true
clock-names: true

57
Documentation/devicetree/bindings/clock/stericsson,u8500-clks.yaml
View File

@ -109,6 +109,25 @@ properties:
additionalProperties: false
clkout-clock:
description: A subnode with three clock cells for externally routed clocks,
output clocks. These are two PRCMU-internal clocks that can be divided and
muxed out on the pads of the DB8500 SoC.
type: object
properties:
'#clock-cells':
description:
The first cell indicates which output clock we are using,
possible values are 0 (CLKOUT1) and 1 (CLKOUT2).
The second cell indicates which clock we want to use as source,
possible values are 0 thru 7, see the defines for the different
source clocks.
The third cell is a divider, legal values are 1 thru 63.
const: 3
additionalProperties: false
required:
- compatible
- reg
@ -119,3 +138,41 @@ required:
- smp-twd-clock
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/ste-db8500-clkout.h>
clocks@8012 {
compatible = "stericsson,u8500-clks";
reg = <0x8012f000 0x1000>, <0x8011f000 0x1000>,
<0x8000f000 0x1000>, <0xa03ff000 0x1000>,
<0xa03cf000 0x1000>;
prcmu_clk: prcmu-clock {
#clock-cells = <1>;
};
prcc_pclk: prcc-periph-clock {
#clock-cells = <2>;
};
prcc_kclk: prcc-kernel-clock {
#clock-cells = <2>;
};
prcc_reset: prcc-reset-controller {
#reset-cells = <2>;
};
rtc_clk: rtc32k-clock {
#clock-cells = <0>;
};
smp_twd_clk: smp-twd-clock {
#clock-cells = <0>;
};
clkout_clk: clkout-clock {
#clock-cells = <3>;
};
};

1
Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml
View File

@ -15,6 +15,7 @@ properties:
- enum:
- ti,am654-ehrpwm-tbclk
- ti,am64-epwm-tbclk
- ti,am62-epwm-tbclk
- const: syscon
"#clock-cells":

2
Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
View File

@ -16,7 +16,7 @@ has been processed. See [2] for more information on the brcm,l2-intc node.
firmware. On some SoCs, this firmware supports DFS and DVFS in addition to
Adaptive Voltage Scaling.
[2] Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
[2] Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.yaml
Node brcm,avs-cpu-data-mem

7
Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
View File

@ -20,6 +20,13 @@ Optional properties:
Vsram to fit SoC specific needs. When absent, the voltage scaling
flow is handled by hardware, hence no software "voltage tracking" is
needed.
- mediatek,cci:
Used to confirm the link status between cpufreq and mediatek cci. Because
cpufreq and mediatek cci could share the same regulator in some MediaTek SoCs.
To prevent the issue of high frequency and low voltage, we need to use this
property to make sure mediatek cci is ready.
For details of mediatek cci, please refer to
Documentation/devicetree/bindings/interconnect/mediatek,cci.yaml
- #cooling-cells:
For details, please refer to
Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml

1
Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
View File

@ -15,6 +15,7 @@ properties:
- ti,j721e-sa2ul
- ti,am654-sa2ul
- ti,am64-sa2ul
- ti,am62-sa3ul
reg:
maxItems: 1

7
Documentation/devicetree/bindings/display/arm,malidp.yaml
View File

@ -71,11 +71,6 @@ properties:
- description: number of output lines for the green channel (G)
- description: number of output lines for the blue channel (B)
arm,malidp-arqos-high-level:
$ref: /schemas/types.yaml#/definitions/uint32
description:
integer describing the ARQoS levels of DP500's QoS signaling
arm,malidp-arqos-value:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@ -113,7 +108,7 @@ examples:
clocks = <&oscclk2>, <&fpgaosc0>, <&fpgaosc1>, <&fpgaosc1>;
clock-names = "pxlclk", "mclk", "aclk", "pclk";
arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
arm,malidp-arqos-high-level = <0xd000d000>;
arm,malidp-arqos-value = <0xd000d000>;
port {
dp0_output: endpoint {

2
Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display DPU dt properties for SC7180 target
maintainers:
- Krishna Manikandan <mkrishn@codeaurora.org>
- Krishna Manikandan <quic_mkrishn@quicinc.com>
description: |
Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates

2
Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display DPU dt properties for SC7280
maintainers:
- Krishna Manikandan <mkrishn@codeaurora.org>
- Krishna Manikandan <quic_mkrishn@quicinc.com>
description: |
Device tree bindings for MSM Mobile Display Subsystem (MDSS) that encapsulates

2
Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display DPU dt properties for SDM845 target
maintainers:
- Krishna Manikandan <mkrishn@codeaurora.org>
- Krishna Manikandan <quic_mkrishn@quicinc.com>
description: |
Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates

2
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display DSI controller
maintainers:
- Krishna Manikandan <mkrishn@codeaurora.org>
- Krishna Manikandan <quic_mkrishn@quicinc.com>
allOf:
- $ref: "../dsi-controller.yaml#"

2
Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display DSI 10nm PHY
maintainers:
- Krishna Manikandan <mkrishn@codeaurora.org>
- Krishna Manikandan <quic_mkrishn@quicinc.com>
allOf:
- $ref: dsi-phy-common.yaml#

2
Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display DSI 14nm PHY
maintainers:
- Krishna Manikandan <mkrishn@codeaurora.org>
- Krishna Manikandan <quic_mkrishn@quicinc.com>
allOf:
- $ref: dsi-phy-common.yaml#

2
Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display DSI 20nm PHY
maintainers:
- Krishna Manikandan <mkrishn@codeaurora.org>
- Krishna Manikandan <quic_mkrishn@quicinc.com>
allOf:
- $ref: dsi-phy-common.yaml#

2
Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display DSI 28nm PHY
maintainers:
- Krishna Manikandan <mkrishn@codeaurora.org>
- Krishna Manikandan <quic_mkrishn@quicinc.com>
allOf:
- $ref: dsi-phy-common.yaml#

2
Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Description of Qualcomm Display DSI PHY common dt properties
maintainers:
- Krishna Manikandan <mkrishn@codeaurora.org>
- Krishna Manikandan <quic_mkrishn@quicinc.com>
description: |
This defines the DSI PHY dt properties which are common for all

11
Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
View File

@ -20,9 +20,11 @@ properties:
compatible:
oneOf:
- const: allwinner,sun50i-a64-dma
- const: allwinner,sun50i-a100-dma
- const: allwinner,sun50i-h6-dma
- enum:
- allwinner,sun20i-d1-dma
- allwinner,sun50i-a64-dma
- allwinner,sun50i-a100-dma
- allwinner,sun50i-h6-dma
- items:
- const: allwinner,sun8i-r40-dma
- const: allwinner,sun50i-a64-dma
@ -58,13 +60,14 @@ if:
properties:
compatible:
enum:
- allwinner,sun20i-d1-dma
- allwinner,sun50i-a100-dma
- allwinner,sun50i-h6-dma
then:
properties:
clocks:
maxItems: 2
minItems: 2
required:
- clock-names

2
Documentation/devicetree/bindings/dma/altr,msgdma.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Altera mSGDMA IP core
maintainers:
- Olivier Dautricourt <olivier.dautricourt@orolia.com>
- Olivier Dautricourt <olivierdautricourt@gmail.com>
description: |
Altera / Intel modular Scatter-Gather Direct Memory Access (mSGDMA)

3
Documentation/devicetree/bindings/dma/arm,pl330.yaml
View File

@ -55,6 +55,9 @@ properties:
dma-coherent: true
power-domains:
maxItems: 1
resets:
minItems: 1
maxItems: 2

10
Documentation/devicetree/bindings/dma/mmp-dma.txt
View File

@ -10,10 +10,12 @@ Required properties:
or one irq for pdma device
Optional properties:
- #dma-channels: Number of DMA channels supported by the controller (defaults
- dma-channels: Number of DMA channels supported by the controller (defaults
to 32 when not specified)
- #dma-requests: Number of DMA requestor lines supported by the controller
- #dma-channels: deprecated
- dma-requests: Number of DMA requestor lines supported by the controller
(defaults to 32 when not specified)
- #dma-requests: deprecated
"marvell,pdma-1.0"
Used platforms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688.
@ -33,7 +35,7 @@ pdma: dma-controller@d4000000 {
reg = <0xd4000000 0x10000>;
interrupts = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15>;
interrupt-parent = <&intcmux32>;
#dma-channels = <16>;
dma-channels = <16>;
};
/*
@ -45,7 +47,7 @@ pdma: dma-controller@d4000000 {
compatible = "marvell,pdma-1.0";
reg = <0xd4000000 0x10000>;
interrupts = <47>;
#dma-channels = <16>;
dma-channels = <16>;
};

110
Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml Normal file
View File

@ -0,0 +1,110 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/nvidia,tegra186-gpc-dma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra GPC DMA Controller Device Tree Bindings
description: |
The Tegra General Purpose Central (GPC) DMA controller is used for faster
data transfers between memory to memory, memory to device and device to
memory.
maintainers:
- Jon Hunter <jonathanh@nvidia.com>
- Rajesh Gumasta <rgumasta@nvidia.com>
allOf:
- $ref: "dma-controller.yaml#"
properties:
compatible:
oneOf:
- const: nvidia,tegra186-gpcdma
- items:
- const: nvidia,tegra194-gpcdma
- const: nvidia,tegra186-gpcdma
"#dma-cells":
const: 1
reg:
maxItems: 1
interrupts:
description:
Should contain all of the per-channel DMA interrupts in
ascending order with respect to the DMA channel index.
minItems: 1
maxItems: 31
resets:
maxItems: 1
reset-names:
const: gpcdma
iommus:
maxItems: 1
dma-coherent: true
required:
- compatible
- reg
- interrupts
- resets
- reset-names
- "#dma-cells"
- iommus
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/memory/tegra186-mc.h>
#include <dt-bindings/reset/tegra186-reset.h>
dma-controller@2600000 {
compatible = "nvidia,tegra186-gpcdma";
reg = <0x2600000 0x210000>;
resets = <&bpmp TEGRA186_RESET_GPCDMA>;
reset-names = "gpcdma";
interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
#dma-cells = <1>;
iommus = <&smmu TEGRA186_SID_GPCDMA_0>;
dma-coherent;
};
...

3
Documentation/devicetree/bindings/dma/qcom,gpi.yaml
View File

@ -19,9 +19,12 @@ allOf:
properties:
compatible:
enum:
- qcom,sc7280-gpi-dma
- qcom,sdm845-gpi-dma
- qcom,sm8150-gpi-dma
- qcom,sm8250-gpi-dma
- qcom,sm8350-gpi-dma
- qcom,sm8450-gpi-dma
reg:
maxItems: 1

10
Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
View File

@ -42,11 +42,10 @@ properties:
- const: renesas,rcar-dmac
- items:
- const: renesas,dmac-r8a779a0 # R-Car V3U
- items:
- const: renesas,dmac-r8a779f0 # R-Car S4-8
- const: renesas,rcar-gen4-dmac
- enum:
- renesas,dmac-r8a779a0 # R-Car V3U
- renesas,dmac-r8a779f0 # R-Car S4-8
- const: renesas,rcar-gen4-dmac # R-Car Gen4
reg: true
@ -121,7 +120,6 @@ if:
compatible:
contains:
enum:
- renesas,dmac-r8a779a0
- renesas,rcar-gen4-dmac
then:
properties:

51
Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml Normal file
View File

@ -0,0 +1,51 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/renesas,rzn1-dmamux.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/N1 DMA mux
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
allOf:
- $ref: "dma-router.yaml#"
properties:
compatible:
const: renesas,rzn1-dmamux
reg:
maxItems: 1
description: DMA mux first register offset within the system control parent.
'#dma-cells':
const: 6
description:
The first four cells are dedicated to the master DMA controller. The fifth
cell gives the DMA mux bit index that must be set starting from 0. The
sixth cell gives the binary value that must be written there, ie. 0 or 1.
dma-masters:
minItems: 1
maxItems: 2
dma-requests:
const: 32
required:
- reg
- dma-requests
additionalProperties: false
examples:
- |
dma-router@a0 {
compatible = "renesas,rzn1-dmamux";
reg = <0xa0 4>;
#dma-cells = <6>;
dma-masters = <&dma0 &dma1>;
dma-requests = <32>;
};

19
Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml
View File

@ -28,7 +28,15 @@ allOf:
properties:
compatible:
items:
- const: sifive,fu540-c000-pdma
- enum:
- sifive,fu540-c000-pdma
- const: sifive,pdma0
description:
Should be "sifive,<chip>-pdma" and "sifive,pdma<version>".
Supported compatible strings are -
"sifive,fu540-c000-pdma" for the SiFive PDMA v0 as integrated onto the
SiFive FU540 chip resp and "sifive,pdma0" for the SiFive PDMA v0 IP block
with no chip integration tweaks.
reg:
maxItems: 1
@ -37,6 +45,12 @@ properties:
minItems: 1
maxItems: 8
dma-channels:
description: For backwards-compatibility, the default value is 4
minimum: 1
maximum: 4
default: 4
'#dma-cells':
const: 1
@ -50,8 +64,9 @@ unevaluatedProperties: false
examples:
- |
dma-controller@3000000 {
compatible = "sifive,fu540-c000-pdma";
compatible = "sifive,fu540-c000-pdma", "sifive,pdma0";
reg = <0x3000000 0x8000>;
dma-channels = <4>;
interrupts = <23>, <24>, <25>, <26>, <27>, <28>, <29>, <30>;
#dma-cells = <1>;
};

8
Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
View File

@ -15,7 +15,13 @@ allOf:
properties:
compatible:
const: snps,dma-spear1340
oneOf:
- const: snps,dma-spear1340
- items:
- enum:
- renesas,r9a06g032-dma
- const: renesas,rzn1-dma
"#dma-cells":
minimum: 3

7
Documentation/devicetree/bindings/dma/sprd-dma.txt
View File

@ -8,10 +8,13 @@ Required properties:
- interrupts: Should contain one interrupt shared by all channel.
- #dma-cells: must be <1>. Used to represent the number of integer
cells in the dmas property of client device.
- #dma-channels : Number of DMA channels supported. Should be 32.
- dma-channels : Number of DMA channels supported. Should be 32.
- clock-names: Should contain the clock of the DMA controller.
- clocks: Should contain a clock specifier for each entry in clock-names.
Deprecated properties:
- #dma-channels : Number of DMA channels supported. Should be 32.
Example:
Controller:
@ -20,7 +23,7 @@ apdma: dma-controller@20100000 {
reg = <0x20100000 0x4000>;
interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
#dma-cells = <1>;
#dma-channels = <32>;
dma-channels = <32>;
clock-names = "enable";
clocks = <&clk_ap_ahb_gates 5>;
};

6
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
View File

@ -110,7 +110,11 @@ axi_vdma_0: axivdma@40030000 {
Required properties:
- dmas: a list of <[Video DMA device phandle] [Channel ID]> pairs,
where Channel ID is '0' for write/tx and '1' for read/rx
channel.
channel. For MCMDA, MM2S channel(write/tx) ID start from
'0' and is in [0-15] range. S2MM channel(read/rx) ID start
from '16' and is in [16-31] range. These channels ID are
fixed irrespective of IP configuration.
- dma-names: a list of DMA channel names, one per "dmas" entry
Example:

5
Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml
View File

@ -20,11 +20,12 @@ properties:
enum:
- siliconmitus,sm5502-muic
- siliconmitus,sm5504-muic
- siliconmitus,sm5703-muic
reg:
maxItems: 1
description: I2C slave address of the device. Usually 0x25 for SM5502,
0x14 for SM5504.
description: I2C slave address of the device. Usually 0x25 for SM5502
and SM5703, 0x14 for SM5504.
interrupts:
maxItems: 1

5
Documentation/devicetree/bindings/gpio/gpio-altera.txt
View File

@ -9,8 +9,9 @@ Required properties:
- The second cell is reserved and is currently unused.
- gpio-controller : Marks the device node as a GPIO controller.
- interrupt-controller: Mark the device node as an interrupt controller
- #interrupt-cells : Should be 1. The interrupt type is fixed in the hardware.
- #interrupt-cells : Should be 2. The interrupt type is fixed in the hardware.
- The first cell is the GPIO offset number within the GPIO controller.
- The second cell is the interrupt trigger type and level flags.
- interrupts: Specify the interrupt.
- altr,interrupt-type: Specifies the interrupt trigger type the GPIO
hardware is synthesized. This field is required if the Altera GPIO controller
@ -38,6 +39,6 @@ gpio_altr: gpio@ff200000 {
altr,interrupt-type = <IRQ_TYPE_EDGE_RISING>;
#gpio-cells = <2>;
gpio-controller;
#interrupt-cells = <1>;
#interrupt-cells = <2>;
interrupt-controller;
};

5
Documentation/devicetree/bindings/hwmon/ti,tmp401.yaml
View File

@ -40,9 +40,8 @@ properties:
value to be used for converting remote channel measurements to
temperature.
$ref: /schemas/types.yaml#/definitions/int32
items:
minimum: -128
maximum: 127
minimum: -128
maximum: 127
ti,beta-compensation:
description:

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