aleph/lkl_linux
1
0
Fork 0
mirror of https://github.com/lkl/linux.git synced 2025-12-19 08:03:01 +09:00
Code Issues Packages Projects Releases Wiki Activity

Merge part of branch 'for-next.instantiate' into for-next

Browse Source
This commit is contained in:
Andreas Gruenbacher
2022-08-05 18:37:03 +02:00
parent 44dab005fd 6feaec8147
commit 446279168e
11185 changed files with 969311 additions and 226239 deletions
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

1
.gitignore vendored
View File

@@ -45,6 +45,7 @@
*.symversions
*.tab.[ch]
*.tar
*.usyms
*.xz
*.zst
Module.symvers

7
.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>
@@ -85,6 +87,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 +168,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 +205,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 +242,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>

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

137
Documentation/ABI/testing/sysfs-driver-chromeos-acpi Normal file
View File

@@ -0,0 +1,137 @@
What: /sys/bus/platform/devices/GGL0001:*/BINF.2
Date: May 2022
KernelVersion: 5.19
Description:
Returns active EC firmware of current boot (boolean).
== ===============================
0 Read only (recovery) firmware.
1 Rewritable firmware.
== ===============================
What: /sys/bus/platform/devices/GGL0001:*/BINF.3
Date: May 2022
KernelVersion: 5.19
Description:
Returns main firmware type for current boot (integer).
== =====================================
0 Recovery.
1 Normal.
2 Developer.
3 Netboot (factory installation only).
== =====================================
What: /sys/bus/platform/devices/GGL0001:*/CHSW
Date: May 2022
KernelVersion: 5.19
Description:
Returns switch position for Chrome OS specific hardware
switches when the firmware is booted (integer).
==== ===========================================
0 No changes.
2 Recovery button was pressed.
4 Recovery button was pressed (EC firmware).
32 Developer switch was enabled.
512 Firmware write protection was disabled.
==== ===========================================
What: /sys/bus/platform/devices/GGL0001:*/FMAP
Date: May 2022
KernelVersion: 5.19
Description:
Returns physical memory address of the start of the main
processor firmware flashmap.
What: /sys/bus/platform/devices/GGL0001:*/FRID
Date: May 2022
KernelVersion: 5.19
Description:
Returns firmware version for the read-only portion of the
main processor firmware.
What: /sys/bus/platform/devices/GGL0001:*/FWID
Date: May 2022
KernelVersion: 5.19
Description:
Returns firmware version for the rewritable portion of the
main processor firmware.
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.0
Date: May 2022
KernelVersion: 5.19
Description:
Returns type of the GPIO signal for the Chrome OS specific
GPIO assignments (integer).
=========== ==================================
1 Recovery button.
2 Developer mode switch.
3 Firmware write protection switch.
256 to 511 Debug header GPIO 0 to GPIO 255.
=========== ==================================
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.1
Date: May 2022
KernelVersion: 5.19
Description:
Returns signal attributes of the GPIO signal (integer bitfield).
== =======================
0 Signal is active low.
1 Signal is active high.
== =======================
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.2
Date: May 2022
KernelVersion: 5.19
Description:
Returns the GPIO number on the specified GPIO
controller.
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.3
Date: May 2022
KernelVersion: 5.19
Description:
Returns name of the GPIO controller.
What: /sys/bus/platform/devices/GGL0001:*/HWID
Date: May 2022
KernelVersion: 5.19
Description:
Returns hardware ID for the Chromebook.
What: /sys/bus/platform/devices/GGL0001:*/MECK
Date: May 2022
KernelVersion: 5.19
Description:
Returns the SHA-1 or SHA-256 hash that is read out of the
Management Engine extended registers during boot. The hash
is exported via ACPI so the OS can verify that the Management
Engine firmware has not changed. If Management Engine is not
present, or if the firmware was unable to read the extended registers, this buffer size can be zero.
What: /sys/bus/platform/devices/GGL0001:*/VBNV.0
Date: May 2022
KernelVersion: 5.19
Description:
Returns offset in CMOS bank 0 of the verified boot non-volatile
storage block, counting from the first writable CMOS byte
(that is, 'offset = 0' is the byte following the 14 bytes of
clock data).
What: /sys/bus/platform/devices/GGL0001:*/VBNV.1
Date: May 2022
KernelVersion: 5.19
Description:
Return the size in bytes of the verified boot non-volatile
storage block.
What: /sys/bus/platform/devices/GGL0001:*/VDAT
Date: May 2022
KernelVersion: 5.19
Description:
Returns the verified boot data block shared between the
firmware verification step and the kernel verification step
(binary).

18
Documentation/ABI/testing/sysfs-driver-ufs
View File

@@ -1518,7 +1518,7 @@ Description: This entry shows the number of reads that cannot be changed to
The file is read only.
What: /sys/class/scsi_device/*/device/hpb_stats/rb_noti_cnt
What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_noti_cnt
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the number of response UPIUs that has
@@ -1526,19 +1526,23 @@ Description: This entry shows the number of response UPIUs that has
The file is read only.
What: /sys/class/scsi_device/*/device/hpb_stats/rb_active_cnt
What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_active_cnt
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the number of active sub-regions recommended by
response UPIUs.
Description: For the HPB device control mode, this entry shows the number of
active sub-regions recommended by response UPIUs. For the HPB host control
mode, this entry shows the number of active sub-regions recommended by the
HPB host control mode heuristic algorithm.
The file is read only.
What: /sys/class/scsi_device/*/device/hpb_stats/rb_inactive_cnt
What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_inactive_cnt
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the number of inactive regions recommended by
response UPIUs.
Description: For the HPB device control mode, this entry shows the number of
inactive regions recommended by response UPIUs. For the HPB host control
mode, this entry shows the number of inactive regions recommended by the
HPB host control mode heuristic algorithm.
The file is read only.

25
Documentation/ABI/testing/sysfs-kernel-mm-damon
View File

@@ -23,9 +23,10 @@ Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Description: Writing 'on' or 'off' to this file makes the kdamond starts or
stops, respectively. Reading the file returns the keywords
based on the current status. Writing 'update_schemes_stats' to
the file updates contents of schemes stats files of the
kdamond.
based on the current status. Writing 'commit' to this file
makes the kdamond reads the user inputs in the sysfs files
except 'state' again. Writing 'update_schemes_stats' to the
file updates contents of schemes stats files of the kdamond.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/pid
Date: Mar 2022
@@ -40,14 +41,24 @@ Description: Writing a number 'N' to this file creates the number of
directories for controlling each DAMON context named '0' to
'N-1' under the contexts/ directory.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/avail_operations
Date: Apr 2022
Contact: SeongJae Park <sj@kernel.org>
Description: Reading this file returns the available monitoring operations
sets on the currently running kernel.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/operations
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Description: Writing a keyword for a monitoring operations set ('vaddr' for
virtual address spaces monitoring, and 'paddr' for the physical
address space monitoring) to this file makes the context to use
the operations set. Reading the file returns the keyword for
the operations set the context is set to use.
virtual address spaces monitoring, 'fvaddr' for fixed virtual
address ranges monitoring, and 'paddr' for the physical address
space monitoring) to this file makes the context to use the
operations set. Reading the file returns the keyword for the
operations set the context is set to use.
Note that only the operations sets that listed in
'avail_operations' file are valid inputs.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/sample_us
Date: Mar 2022

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

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

@@ -343,6 +343,11 @@ Admin can request writeback of those idle pages at right timing via::
With the command, zram will writeback idle pages from memory to the storage.
Additionally, if a user choose to writeback only huge and idle pages
this can be accomplished with::
echo huge_idle > /sys/block/zramX/writeback
If an admin wants to write a specific page in zram device to the backing device,
they could write a page index into the interface.

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
=================================

51
Documentation/admin-guide/cgroup-v2.rst
View File

@@ -1208,6 +1208,34 @@ PAGE_SIZE multiple when read back.
high limit is used and monitored properly, this limit's
utility is limited to providing the final safety net.
memory.reclaim
A write-only nested-keyed file which exists for all cgroups.
This is a simple interface to trigger memory reclaim in the
target cgroup.
This file accepts a single key, the number of bytes to reclaim.
No nested keys are currently supported.
Example::
echo "1G" > memory.reclaim
The interface can be later extended with nested keys to
configure the reclaim behavior. For example, specify the
type of memory to reclaim from (anon, file, ..).
Please note that the kernel can over or under reclaim from
the target cgroup. If less bytes are reclaimed than the
specified amount, -EAGAIN is returned.
memory.peak
A read-only single value file which exists on non-root
cgroups.
The max memory usage recorded for the cgroup and its
descendants since the creation of the cgroup.
memory.oom.group
A read-write single value file which exists on non-root
cgroups. The default value is "0".
@@ -1326,6 +1354,12 @@ PAGE_SIZE multiple when read back.
Amount of cached filesystem data that is swap-backed,
such as tmpfs, shm segments, shared anonymous mmap()s
zswap
Amount of memory consumed by the zswap compression backend.
zswapped
Amount of application memory swapped out to zswap.
file_mapped
Amount of cached filesystem data mapped with mmap()
@@ -1516,6 +1550,21 @@ PAGE_SIZE multiple when read back.
higher than the limit for an extended period of time. This
reduces the impact on the workload and memory management.
memory.zswap.current
A read-only single value file which exists on non-root
cgroups.
The total amount of memory consumed by the zswap compression
backend.
memory.zswap.max
A read-write single value file which exists on non-root
cgroups. The default is "max".
Zswap usage hard limit. If a cgroup's zswap pool reaches this
limit, it will refuse to take any more stores before existing
entries fault back in or are written out to disk.
memory.pressure
A read-only nested-keyed file.
@@ -1881,7 +1930,7 @@ IO Latency Interface Files
io.latency
This takes a similar format as the other controllers.
"MAJOR:MINOR target=<target time in microseconds"
"MAJOR:MINOR target=<target time in microseconds>"
io.stat
If the controller is enabled you will see extra stats in io.stat in

2
Documentation/admin-guide/devices.txt
View File

@@ -1933,7 +1933,7 @@
...
255= /dev/umem/d15p15 15th partition of 16th board.
117 char COSA/SRP synchronous serial card
117 char [REMOVED] COSA/SRP synchronous serial card
0 = /dev/cosa0c0 1st board, 1st channel
1 = /dev/cosa0c1 1st board, 2nd channel
...

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

11
Documentation/admin-guide/kernel-parameters.rst
View File

@@ -99,6 +99,7 @@ parameter is applicable::
ALSA ALSA sound support is enabled.
APIC APIC support is enabled.
APM Advanced Power Management support is enabled.
APPARMOR AppArmor support is enabled.
ARM ARM architecture is enabled.
ARM64 ARM64 architecture is enabled.
AX25 Appropriate AX.25 support is enabled.
@@ -108,15 +109,15 @@ parameter is applicable::
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
EFI EFI Partitioning (GPT) is enabled
EIDE EIDE/ATAPI support is enabled.
EVM Extended Verification Module
FB The frame buffer device is enabled.
FTRACE Function tracing enabled.
GCOV GCOV profiling is enabled.
HIBERNATION HIBERNATION is enabled.
HW Appropriate hardware is enabled.
HYPER_V HYPERV support is enabled.
IA-64 IA-64 architecture is enabled.
IMA Integrity measurement architecture is enabled.
IOSCHED More than one I/O scheduler is enabled.
IP_PNP IP DHCP, BOOTP, or RARP is enabled.
IPV6 IPv6 support is enabled.
ISAPNP ISA PnP code is enabled.
@@ -140,7 +141,6 @@ parameter is applicable::
NUMA NUMA support is enabled.
NFS Appropriate NFS support is enabled.
OF Devicetree is enabled.
OSS OSS sound support is enabled.
PV_OPS A paravirtualized kernel is enabled.
PARIDE The ParIDE (parallel port IDE) subsystem is enabled.
PARISC The PA-RISC architecture is enabled.
@@ -160,7 +160,6 @@ parameter is applicable::
the Documentation/scsi/ sub-directory.
SECURITY Different security models are enabled.
SELINUX SELinux support is enabled.
APPARMOR AppArmor support is enabled.
SERIAL Serial support is enabled.
SH SuperH architecture is enabled.
SMP The kernel is an SMP kernel.
@@ -168,7 +167,6 @@ parameter is applicable::
SWSUSP Software suspend (hibernation) is enabled.
SUSPEND System suspend states are enabled.
TPM TPM drivers are enabled.
TS Appropriate touchscreen support is enabled.
UMS USB Mass Storage support is enabled.
USB USB support is enabled.
USBHID USB Human Interface Device support is enabled.
@@ -177,7 +175,6 @@ parameter is applicable::
VGA The VGA console has been enabled.
VT Virtual terminal support is enabled.
WDT Watchdog support is enabled.
XT IBM PC/XT MFM hard disk support is enabled.
X86-32 X86-32, aka i386 architecture is enabled.
X86-64 X86-64 architecture is enabled.
More X86-64 boot options can be found in
@@ -211,7 +208,7 @@ The number of kernel parameters is not limited, but the length of the
complete command line (parameters including spaces etc.) is limited to
a fixed number of characters. This limit depends on the architecture
and is between 256 and 4096 characters. It is defined in the file
./include/asm/setup.h as COMMAND_LINE_SIZE.
./include/uapi/asm-generic/setup.h as COMMAND_LINE_SIZE.
Finally, the [KMG] suffix is commonly described after a number of kernel
parameter values. These 'K', 'M', and 'G' letters represent the _binary_

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

@@ -461,6 +461,12 @@
Format: <io>,<irq>,<mode>
See header of drivers/net/hamradio/baycom_ser_hdx.c.
bert_disable [ACPI]
Disable BERT OS support on buggy BIOSes.
bgrt_disable [ACPI][X86]
Disable BGRT to avoid flickering OEM logo.
blkdevparts= Manual partition parsing of block device(s) for
embedded devices based on command line input.
See Documentation/block/cmdline-partition.rst
@@ -476,12 +482,6 @@
See Documentation/admin-guide/bootconfig.rst
bert_disable [ACPI]
Disable BERT OS support on buggy BIOSes.
bgrt_disable [ACPI][X86]
Disable BGRT to avoid flickering OEM logo.
bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards)
bttv.radio= Most important insmod options are available as
kernel args too.
@@ -563,6 +563,25 @@
cio_ignore= [S390]
See Documentation/s390/common_io.rst for details.
clearcpuid=X[,X...] [X86]
Disable CPUID feature X for the kernel. See
arch/x86/include/asm/cpufeatures.h for the valid bit
numbers X. Note the Linux-specific bits are not necessarily
stable over kernel options, but the vendor-specific
ones should be.
X can also be a string as appearing in the flags: line
in /proc/cpuinfo which does not have the above
instability issue. However, not all features have names
in /proc/cpuinfo.
Note that using this option will taint your kernel.
Also note that user programs calling CPUID directly
or using the feature without checking anything
will still see it. This just prevents it from
being used by the kernel or shown in /proc/cpuinfo.
Also note the kernel might malfunction if you disable
some critical bits.
clk_ignore_unused
[CLK]
Prevents the clock framework from automatically gating
@@ -631,24 +650,6 @@
Defaults to zero when built as a module and to
10 seconds when built into the kernel.
clearcpuid=X[,X...] [X86]
Disable CPUID feature X for the kernel. See
arch/x86/include/asm/cpufeatures.h for the valid bit
numbers X. Note the Linux-specific bits are not necessarily
stable over kernel options, but the vendor-specific
ones should be.
X can also be a string as appearing in the flags: line
in /proc/cpuinfo which does not have the above
instability issue. However, not all features have names
in /proc/cpuinfo.
Note that using this option will taint your kernel.
Also note that user programs calling CPUID directly
or using the feature without checking anything
will still see it. This just prevents it from
being used by the kernel or shown in /proc/cpuinfo.
Also note the kernel might malfunction if you disable
some critical bits.
cma=nn[MG]@[start[MG][-end[MG]]]
[KNL,CMA]
Sets the size of kernel global memory area for
@@ -770,6 +771,24 @@
0: default value, disable debugging
1: enable debugging at boot time
cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver
Format:
<first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
cpu0_hotplug [X86] Turn on CPU0 hotplug feature when
CONFIG_BOOTPARAM_HOTPLUG_CPU0 is off.
Some features depend on CPU0. Known dependencies are:
1. Resume from suspend/hibernate depends on CPU0.
Suspend/hibernate will fail if CPU0 is offline and you
need to online CPU0 before suspend/hibernate.
2. PIC interrupts also depend on CPU0. CPU0 can't be
removed if a PIC interrupt is detected.
It's said poweroff/reboot may depend on CPU0 on some
machines although I haven't seen such issues so far
after CPU0 is offline on a few tested machines.
If the dependencies are under your control, you can
turn on cpu0_hotplug.
cpuidle.off=1 [CPU_IDLE]
disable the cpuidle sub-system
@@ -790,9 +809,13 @@
on every CPU online, such as boot, and resume from suspend.
Default: 10000
cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver
Format:
<first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
crash_kexec_post_notifiers
Run kdump after running panic-notifiers and dumping
kmsg. This only for the users who doubt kdump always
succeeds in any situation.
Note that this also increases risks of kdump failure,
because some panic notifiers can make the crashed
kernel more unstable.
crashkernel=size[KMG][@offset[KMG]]
[KNL] Using kexec, Linux can switch to a 'crash kernel'
@@ -956,11 +979,15 @@
[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.
delayacct [KNL] Enable per-task delay accounting
dell_smm_hwmon.ignore_dmi=
[HW] Continue probing hardware even if DMI data
indicates that the driver is running on unsupported
@@ -1014,17 +1041,6 @@
disable= [IPV6]
See Documentation/networking/ipv6.rst.
hardened_usercopy=
[KNL] Under CONFIG_HARDENED_USERCOPY, whether
hardening is enabled for this boot. Hardened
usercopy checking is used to protect the kernel
from reading or writing beyond known memory
allocation boundaries as a proactive defense
against bounds-checking flaws in the kernel's
copy_to_user()/copy_from_user() interface.
on Perform hardened usercopy checks (default).
off Disable hardened usercopy checks.
disable_radix [PPC]
Disable RADIX MMU mode on POWER9
@@ -1087,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>]
@@ -1293,7 +1312,7 @@
Append ",keep" to not disable it when the real console
takes over.
Only one of vga, efi, serial, or usb debug port can
Only one of vga, serial, or usb debug port can
be used at a time.
Currently only ttyS0 and ttyS1 may be specified by
@@ -1308,7 +1327,7 @@
Interaction with the standard serial driver is not
very good.
The VGA and EFI output is eventually overwritten by
The VGA output is eventually overwritten by
the real console.
The xen option can only be used in Xen domains.
@@ -1327,17 +1346,6 @@
force: enforce the use of EDAC to report H/W event.
default: on.
ekgdboc= [X86,KGDB] Allow early kernel console debugging
ekgdboc=kbd
This is designed to be used in conjunction with
the boot argument: earlyprintk=vga
This parameter works in place of the kgdboc parameter
but can only be used if the backing tty is available
very early in the boot process. For early debugging
via a serial port see kgdboc_earlycon instead.
edd= [EDD]
Format: {"off" | "on" | "skip[mbr]"}
@@ -1399,6 +1407,17 @@
eisa_irq_edge= [PARISC,HW]
See header of drivers/parisc/eisa.c.
ekgdboc= [X86,KGDB] Allow early kernel console debugging
Format: ekgdboc=kbd
This is designed to be used in conjunction with
the boot argument: earlyprintk=vga
This parameter works in place of the kgdboc parameter
but can only be used if the backing tty is available
very early in the boot process. For early debugging
via a serial port see kgdboc_earlycon instead.
elanfreq= [X86-32]
See comment before function elanfreq_setup() in
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
@@ -1597,6 +1616,17 @@
Format: <unsigned int> such that (rxsize & ~0x1fffc0) == 0.
Default: 1024
hardened_usercopy=
[KNL] Under CONFIG_HARDENED_USERCOPY, whether
hardening is enabled for this boot. Hardened
usercopy checking is used to protect the kernel
from reading or writing beyond known memory
allocation boundaries as a proactive defense
against bounds-checking flaws in the kernel's
copy_to_user()/copy_from_user() interface.
on Perform hardened usercopy checks (default).
off Disable hardened usercopy checks.
hardlockup_all_cpu_backtrace=
[KNL] Should the hard-lockup detector generate
backtraces on all cpus.
@@ -1617,6 +1647,15 @@
corresponding firmware-first mode error processing
logic will be disabled.
hibernate= [HIBERNATION]
noresume Don't check if there's a hibernation image
present during boot.
nocompress Don't compress/decompress hibernation images.
no Disable hibernation and resume.
protect_image Turn on image protection during restoration
(that will set all pages holding image data
during restoration read-only).
highmem=nn[KMG] [KNL,BOOT] forces the highmem zone to have an exact
size of <nn>. This works even on boxes that have no
highmem otherwise. This also works to reduce highmem
@@ -1639,16 +1678,6 @@
hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET
registers. Default set by CONFIG_HPET_MMAP_DEFAULT.
hugetlb_cma= [HW,CMA] The size of a CMA area used for allocation
of gigantic hugepages. Or using node format, the size
of a CMA area per node can be specified.
Format: nn[KMGTPE] or (node format)
<node>:nn[KMGTPE][,<node>:nn[KMGTPE]]
Reserve a CMA area of given size and allocate gigantic
hugepages using the CMA allocator. If enabled, the
boot-time allocation of gigantic hugepages is skipped.
hugepages= [HW] Number of HugeTLB pages to allocate at boot.
If this follows hugepagesz (below), it specifies
the number of pages of hugepagesz to be allocated.
@@ -1670,17 +1699,27 @@
Documentation/admin-guide/mm/hugetlbpage.rst.
Format: size[KMG]
hugetlb_cma= [HW,CMA] The size of a CMA area used for allocation
of gigantic hugepages. Or using node format, the size
of a CMA area per node can be specified.
Format: nn[KMGTPE] or (node format)
<node>:nn[KMGTPE][,<node>:nn[KMGTPE]]
Reserve a CMA area of given size and allocate gigantic
hugepages using the CMA allocator. If enabled, the
boot-time allocation of gigantic hugepages is skipped.
hugetlb_free_vmemmap=
[KNL] Reguires CONFIG_HUGETLB_PAGE_FREE_VMEMMAP
[KNL] Reguires CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
enabled.
Allows heavy hugetlb users to free up some more
memory (7 * PAGE_SIZE for each 2MB hugetlb page).
Format: { on | off (default) }
Format: { [oO][Nn]/Y/y/1 | [oO][Ff]/N/n/0 (default) }
on: enable the feature
off: disable the feature
[oO][Nn]/Y/y/1: enable the feature
[oO][Ff]/N/n/0: disable the feature
Built with CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON=y,
Built with CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON=y,
the default is on.
This is not compatible with memory_hotplug.memmap_on_memory.
@@ -1769,26 +1808,6 @@
icn= [HW,ISDN]
Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
ide-core.nodma= [HW] (E)IDE subsystem
Format: =0.0 to prevent dma on hda, =0.1 hdb =1.0 hdc
.vlb_clock .pci_clock .noflush .nohpa .noprobe .nowerr
.cdrom .chs .ignore_cable are additional options
See Documentation/ide/ide.rst.
ide-generic.probe-mask= [HW] (E)IDE subsystem
Format: <int>
Probe mask for legacy ISA IDE ports. Depending on
platform up to 6 ports are supported, enabled by
setting corresponding bits in the mask to 1. The
default value is 0x0, which has a special meaning.
On systems that have PCI, it triggers scanning the
PCI bus for the first and the second port, which
are then probed. On systems without PCI the value
of 0x0 enables probing the two first ports as if it
was 0x3.
ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem
Claim all unknown PCI IDE storage controllers.
idle= [X86]
Format: idle=poll, idle=halt, idle=nomwait
@@ -2450,7 +2469,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
@@ -2722,8 +2740,6 @@
If there are multiple matching configurations changing
the same attribute, the last one is used.
memblock=debug [KNL] Enable memblock debug messages.
load_ramdisk= [RAM] [Deprecated]
lockd.nlm_grace_period=P [NFS] Assign grace period.
@@ -2865,7 +2881,7 @@
different yeeloong laptops.
Example: machtype=lemote-yeeloong-2f-7inch
max_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory greater
max_addr=nn[KMG] [KNL,BOOT,IA-64] All physical memory greater
than or equal to this physical address is ignored.
maxcpus= [SMP] Maximum number of processors that an SMP kernel
@@ -2965,6 +2981,8 @@
mem=nopentium [BUGS=X86-32] Disable usage of 4MB pages for kernel
memory.
memblock=debug [KNL] Enable memblock debug messages.
memchunk=nn[KMG]
[KNL,SH] Allow user to override the default size for
per-device physically contiguous DMA buffers.
@@ -3108,7 +3126,7 @@
mga= [HW,DRM]
min_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory below this
min_addr=nn[KMG] [KNL,BOOT,IA-64] All physical memory below this
physical address is ignored.
mini2440= [ARM,HW,KNL]
@@ -3157,6 +3175,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
@@ -3178,6 +3197,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
@@ -3187,6 +3207,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.
@@ -3233,20 +3287,6 @@
mtdparts= [MTD]
See drivers/mtd/parsers/cmdlinepart.c
multitce=off [PPC] This parameter disables the use of the pSeries
firmware feature for updating multiple TCE entries
at a time.
onenand.bdry= [HW,MTD] Flex-OneNAND Boundary Configuration
Format: [die0_boundary][,die0_lock][,die1_boundary][,die1_lock]
boundary - index of last SLC block on Flex-OneNAND.
The remaining blocks are configured as MLC blocks.
lock - Configure if Flex-OneNAND boundary should be locked.
Once locked, the boundary cannot be changed.
1 indicates lock status, 0 indicates unlock status.
mtdset= [ARM]
ARM/S3C2412 JIVE boot control
@@ -3273,6 +3313,10 @@
Used for mtrr cleanup. It is spare mtrr entries number.
Set to 2 or more if your graphical card needs more.
multitce=off [PPC] This parameter disables the use of the pSeries
firmware feature for updating multiple TCE entries
at a time.
n2= [NET] SDL Inc. RISCom/N2 synchronous serial card
netdev= [NET] Network devices parameters
@@ -3282,6 +3326,11 @@
This usage is only documented in each driver source
file if at all.
netpoll.carrier_timeout=
[NET] Specifies amount of time (in seconds) that
netpoll should wait for a carrier. By default netpoll
waits 4 seconds.
nf_conntrack.acct=
[NETFILTER] Enable connection tracking flow accounting
0 to disable accounting
@@ -3432,11 +3481,6 @@
These settings can be accessed at runtime via
the nmi_watchdog and hardlockup_panic sysctls.
netpoll.carrier_timeout=
[NET] Specifies amount of time (in seconds) that
netpoll should wait for a carrier. By default netpoll
waits 4 seconds.
no387 [BUGS=X86-32] Tells the kernel to use the 387 maths
emulation library even if a 387 maths coprocessor
is present.
@@ -3491,8 +3535,6 @@
nocache [ARM]
delayacct [KNL] Enable per-task delay accounting
nodsp [SH] Disable hardware DSP at boot time.
noefi Disable EFI runtime services support.
@@ -3721,20 +3763,6 @@
nox2apic [X86-64,APIC] Do not enable x2APIC mode.
cpu0_hotplug [X86] Turn on CPU0 hotplug feature when
CONFIG_BOOTPARAM_HOTPLUG_CPU0 is off.
Some features depend on CPU0. Known dependencies are:
1. Resume from suspend/hibernate depends on CPU0.
Suspend/hibernate will fail if CPU0 is offline and you
need to online CPU0 before suspend/hibernate.
2. PIC interrupts also depend on CPU0. CPU0 can't be
removed if a PIC interrupt is detected.
It's said poweroff/reboot may depend on CPU0 on some
machines although I haven't seen such issues so far
after CPU0 is offline on a few tested machines.
If the dependencies are under your control, you can
turn on cpu0_hotplug.
nps_mtm_hs_ctr= [KNL,ARC]
This parameter sets the maximum duration, in
cycles, each HW thread of the CTOP can run
@@ -3787,6 +3815,16 @@
For example, to override I2C bus2:
omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100
onenand.bdry= [HW,MTD] Flex-OneNAND Boundary Configuration
Format: [die0_boundary][,die0_lock][,die1_boundary][,die1_lock]
boundary - index of last SLC block on Flex-OneNAND.
The remaining blocks are configured as MLC blocks.
lock - Configure if Flex-OneNAND boundary should be locked.
Once locked, the boundary cannot be changed.
1 indicates lock status, 0 indicates unlock status.
oops=panic Always panic on oopses. Default is to just kill the
process, but there is a small probability of
deadlocking the machine.
@@ -3857,14 +3895,6 @@
panic_on_warn panic() instead of WARN(). Useful to cause kdump
on a WARN().
crash_kexec_post_notifiers
Run kdump after running panic-notifiers and dumping
kmsg. This only for the users who doubt kdump always
succeeds in any situation.
Note that this also increases risks of kdump failure,
because some panic notifiers can make the crashed
kernel more unstable.
parkbd.port= [HW] Parallel port number the keyboard adapter is
connected to, default is 0.
Format: <parport#>
@@ -4109,6 +4139,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,15 +5195,6 @@
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
hibernate= [HIBERNATION]
noresume Don't check if there's a hibernation image
present during boot.
nocompress Don't compress/decompress hibernation images.
no Disable hibernation and resume.
protect_image Turn on image protection during restoration
(that will set all pages holding image data
during restoration read-only).
retain_initrd [RAM] Keep initrd memory after extraction
rfkill.default_state=
@@ -5480,7 +5510,7 @@
1: Fast pin select (default)
2: ATC IRMode
smt [KNL,S390] Set the maximum number of threads (logical
smt= [KNL,S390] Set the maximum number of threads (logical
CPUs) to use per physical CPU on systems capable of
symmetric multithreading (SMT). Will be capped to the
actual hardware limit.
@@ -5867,8 +5897,9 @@
This parameter controls use of the Protected
Execution Facility on pSeries.
swapaccount=[0|1]
[KNL] Enable accounting of swap in memory resource
swapaccount= [KNL]
Format: [0|1]
Enable accounting of swap in memory resource
controller if no parameter or 1 is given or disable
it if 0 is given (See Documentation/admin-guide/cgroup-v1/memory.rst)
@@ -5914,7 +5945,8 @@
tdfx= [HW,DRM]
test_suspend= [SUSPEND][,N]
test_suspend= [SUSPEND]
Format: { "mem" | "standby" | "freeze" }[,N]
Specify "mem" (for Suspend-to-RAM) or "standby" (for
standby suspend) or "freeze" (for suspend type freeze)
as the system sleep state during system startup with
@@ -5998,9 +6030,62 @@
This will guarantee that all the other pcrs
are saved.
tp_printk [FTRACE]
Have the tracepoints sent to printk as well as the
tracing ring buffer. This is useful for early boot up
where the system hangs or reboots and does not give the
option for reading the tracing buffer or performing a
ftrace_dump_on_oops.
To turn off having tracepoints sent to printk,
echo 0 > /proc/sys/kernel/tracepoint_printk
Note, echoing 1 into this file without the
tracepoint_printk kernel cmdline option has no effect.
The tp_printk_stop_on_boot (see below) can also be used
to stop the printing of events to console at
late_initcall_sync.
** CAUTION **
Having tracepoints sent to printk() and activating high
frequency tracepoints such as irq or sched, can cause
the system to live lock.
tp_printk_stop_on_boot [FTRACE]
When tp_printk (above) is set, it can cause a lot of noise
on the console. It may be useful to only include the
printing of events during boot up, as user space may
make the system inoperable.
This command line option will stop the printing of events
to console at the late_initcall_sync() time frame.
trace_buf_size=nn[KMG]
[FTRACE] will set tracing buffer size on each cpu.
trace_clock= [FTRACE] Set the clock used for tracing events
at boot up.
local - Use the per CPU time stamp counter
(converted into nanoseconds). Fast, but
depending on the architecture, may not be
in sync between CPUs.
global - Event time stamps are synchronize across
CPUs. May be slower than the local clock,
but better for some race conditions.
counter - Simple counting of events (1, 2, ..)
note, some counts may be skipped due to the
infrastructure grabbing the clock more than
once per event.
uptime - Use jiffies as the time stamp.
perf - Use the same clock that perf uses.
mono - Use ktime_get_mono_fast_ns() for time stamps.
mono_raw - Use ktime_get_raw_fast_ns() for time
stamps.
boot - Use ktime_get_boot_fast_ns() for time stamps.
Architectures may add more clocks. See
Documentation/trace/ftrace.rst for more details.
trace_event=[event-list]
[FTRACE] Set and start specified trace events in order
to facilitate early boot debugging. The event-list is a
@@ -6023,37 +6108,6 @@
See also Documentation/trace/ftrace.rst "trace options"
section.
tp_printk[FTRACE]
Have the tracepoints sent to printk as well as the
tracing ring buffer. This is useful for early boot up
where the system hangs or reboots and does not give the
option for reading the tracing buffer or performing a
ftrace_dump_on_oops.
To turn off having tracepoints sent to printk,
echo 0 > /proc/sys/kernel/tracepoint_printk
Note, echoing 1 into this file without the
tracepoint_printk kernel cmdline option has no effect.
The tp_printk_stop_on_boot (see below) can also be used
to stop the printing of events to console at
late_initcall_sync.
** CAUTION **
Having tracepoints sent to printk() and activating high
frequency tracepoints such as irq or sched, can cause
the system to live lock.
tp_printk_stop_on_boot[FTRACE]
When tp_printk (above) is set, it can cause a lot of noise
on the console. It may be useful to only include the
printing of events during boot up, as user space may
make the system inoperable.
This command line option will stop the printing of events
to console at the late_initcall_sync() time frame.
traceoff_on_warning
[FTRACE] enable this option to disable tracing when a
warning is hit. This turns off "tracing_on". Tracing can
@@ -6405,7 +6459,7 @@
HIGHMEM regardless of setting
of CONFIG_HIGHPTE.
vdso= [X86,SH]
vdso= [X86,SH,SPARC]
On X86_32, this is an alias for vdso32=. Otherwise:
vdso=1: enable VDSO (the default)
@@ -6431,11 +6485,12 @@
video= [FB] Frame buffer configuration
See Documentation/fb/modedb.rst.
video.brightness_switch_enabled= [0,1]
video.brightness_switch_enabled= [ACPI]
Format: [0|1]
If set to 1, on receiving an ACPI notify event
generated by hotkey, video driver will adjust brightness
level and then send out the event to user space through
the allocated input device; If set to 0, video driver
the allocated input device. If set to 0, video driver
will only send out the event without touching backlight
brightness level.
default: 1

11
Documentation/admin-guide/mm/damon/reclaim.rst
View File

@@ -66,6 +66,17 @@ Setting it as ``N`` disables DAMON_RECLAIM. Note that DAMON_RECLAIM could do
no real monitoring and reclamation due to the watermarks-based activation
condition. Refer to below descriptions for the watermarks parameter for this.
commit_inputs
-------------
Make DAMON_RECLAIM reads the input parameters again, except ``enabled``.
Input parameters that updated while DAMON_RECLAIM is running are not applied
by default. Once this parameter is set as ``Y``, DAMON_RECLAIM reads values
of parametrs except ``enabled`` again. Once the re-reading is done, this
parameter is set as ``N``. If invalid parameters are found while the
re-reading, DAMON_RECLAIM will be disabled.
min_age
-------

41
Documentation/admin-guide/mm/damon/usage.rst
View File

@@ -68,7 +68,7 @@ comma (","). ::
│ kdamonds/nr_kdamonds
│ │ 0/state,pid
│ │ │ contexts/nr_contexts
│ │ │ │ 0/operations
│ │ │ │ 0/avail_operations,operations
│ │ │ │ │ monitoring_attrs/
│ │ │ │ │ │ intervals/sample_us,aggr_us,update_us
│ │ │ │ │ │ nr_regions/min,max
@@ -121,10 +121,11 @@ In each kdamond directory, two files (``state`` and ``pid``) and one directory
Reading ``state`` returns ``on`` if the kdamond is currently running, or
``off`` if it is not running. Writing ``on`` or ``off`` makes the kdamond be
in the state. Writing ``update_schemes_stats`` to ``state`` file updates the
contents of stats files for each DAMON-based operation scheme of the kdamond.
For details of the stats, please refer to :ref:`stats section
<sysfs_schemes_stats>`.
in the state. Writing ``commit`` to the ``state`` file makes kdamond reads the
user inputs in the sysfs files except ``state`` file again. Writing
``update_schemes_stats`` to ``state`` file updates the contents of stats files
for each DAMON-based operation scheme of the kdamond. For details of the
stats, please refer to :ref:`stats section <sysfs_schemes_stats>`.
If the state is ``on``, reading ``pid`` shows the pid of the kdamond thread.
@@ -143,17 +144,28 @@ be written to the file.
contexts/<N>/
-------------
In each context directory, one file (``operations``) and three directories
(``monitoring_attrs``, ``targets``, and ``schemes``) exist.
In each context directory, two files (``avail_operations`` and ``operations``)
and three directories (``monitoring_attrs``, ``targets``, and ``schemes``)
exist.
DAMON supports multiple types of monitoring operations, including those for
virtual address space and the physical address space. You can set and get what
type of monitoring operations DAMON will use for the context by writing one of
below keywords to, and reading from the file.
virtual address space and the physical address space. You can get the list of
available monitoring operations set on the currently running kernel by reading
``avail_operations`` file. Based on the kernel configuration, the file will
list some or all of below keywords.
- vaddr: Monitor virtual address spaces of specific processes
- fvaddr: Monitor fixed virtual address ranges
- paddr: Monitor the physical address space of the system
Please refer to :ref:`regions sysfs directory <sysfs_regions>` for detailed
differences between the operations sets in terms of the monitoring target
regions.
You can set and get what type of monitoring operations DAMON will use for the
context by writing one of the keywords listed in ``avail_operations`` file and
reading from the ``operations`` file.
contexts/<N>/monitoring_attrs/
------------------------------
@@ -192,6 +204,8 @@ If you wrote ``vaddr`` to the ``contexts/<N>/operations``, each target should
be a process. You can specify the process to DAMON by writing the pid of the
process to the ``pid_target`` file.
.. _sysfs_regions:
targets/<N>/regions
-------------------
@@ -202,9 +216,10 @@ can be covered. However, users could want to set the initial monitoring region
to specific address ranges.
In contrast, DAMON do not automatically sets and updates the monitoring target
regions when ``paddr`` monitoring operations set is being used (``paddr`` is
written to the ``contexts/<N>/operations``). Therefore, users should set the
monitoring target regions by themselves in the case.
regions when ``fvaddr`` or ``paddr`` monitoring operations sets are being used
(``fvaddr`` or ``paddr`` have written to the ``contexts/<N>/operations``).
Therefore, users should set the monitoring target regions by themselves in the
cases.
For such cases, users can explicitly set the initial monitoring target regions
as they want, by writing proper values to the files under this directory.

2
Documentation/admin-guide/mm/hugetlbpage.rst
View File

@@ -164,7 +164,7 @@ default_hugepagesz
will all result in 256 2M huge pages being allocated. Valid default
huge page size is architecture dependent.
hugetlb_free_vmemmap
When CONFIG_HUGETLB_PAGE_FREE_VMEMMAP is set, this enables freeing
When CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP is set, this enables optimizing
unused vmemmap pages associated with each HugeTLB page.
When multiple huge page sizes are supported, ``/proc/sys/vm/nr_hugepages``

18
Documentation/admin-guide/mm/ksm.rst
View File

@@ -184,6 +184,24 @@ The maximum possible ``pages_sharing/pages_shared`` ratio is limited by the
``max_page_sharing`` tunable. To increase the ratio ``max_page_sharing`` must
be increased accordingly.
Monitoring KSM events
=====================
There are some counters in /proc/vmstat that may be used to monitor KSM events.
KSM might help save memory, it's a tradeoff by may suffering delay on KSM COW
or on swapping in copy. Those events could help users evaluate whether or how
to use KSM. For example, if cow_ksm increases too fast, user may decrease the
range of madvise(, , MADV_MERGEABLE).
cow_ksm
is incremented every time a KSM page triggers copy on write (COW)
when users try to write to a KSM page, we have to make a copy.
ksm_swpin_copy
is incremented every time a KSM page is copied when swapping in
note that KSM page might be copied when swapping in because do_swap_page()
cannot do all the locking needed to reconstitute a cross-anon_vma KSM page.
--
Izik Eidus,
Hugh Dickins, 17 Nov 2009

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
---------------------------------------------

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

@@ -783,6 +783,13 @@ is useful to define the root cause of RCU stalls using a vmcore.
1 panic() after printing RCU stall messages.
= ============================================================
max_rcu_stall_to_panic
======================
When ``panic_on_rcu_stall`` is set to 1, this value determines the
number of times that RCU can stall before panic() is called.
When ``panic_on_rcu_stall`` is set to 0, this value is has no effect.
perf_cpu_time_max_percent
=========================

17
Documentation/admin-guide/sysctl/net.rst
View File

@@ -322,6 +322,14 @@ a leaked reference faster. A larger value may be useful to prevent false
warnings on slow/loaded systems.
Default value is 10, minimum 1, maximum 3600.
skb_defer_max
-------------
Max size (in skbs) of the per-cpu list of skbs being freed
by the cpu which allocated them. Used by TCP stack so far.
Default: 64
optmem_max
----------
@@ -374,6 +382,15 @@ option is set to SOCK_TXREHASH_DEFAULT (i. e. not overridden by setsockopt).
If set to 1 (default), hash rethink is performed on listening socket.
If set to 0, hash rethink is not performed.
gro_normal_batch
----------------
Maximum number of the segments to batch up on output of GRO. When a packet
exits GRO, either as a coalesced superframe or as an original packet which
GRO has decided not to coalesce, it is placed on a per-NAPI list. This
list is then passed to the stack when the number of segments reaches the
gro_normal_batch limit.
2. /proc/sys/net/unix - Parameters for Unix domain sockets
----------------------------------------------------------

48
Documentation/admin-guide/sysctl/vm.rst
View File

@@ -62,6 +62,7 @@ Currently, these files are in /proc/sys/vm:
- overcommit_memory
- overcommit_ratio
- page-cluster
- page_lock_unfairness
- panic_on_oom
- percpu_pagelist_high_fraction
- stat_interval
@@ -561,6 +562,45 @@ Change the minimum size of the hugepage pool.
See Documentation/admin-guide/mm/hugetlbpage.rst
hugetlb_optimize_vmemmap
========================
This knob is not available when memory_hotplug.memmap_on_memory (kernel parameter)
is configured or the size of 'struct page' (a structure defined in
include/linux/mm_types.h) is not power of two (an unusual system config could
result in this).
Enable (set to 1) or disable (set to 0) the feature of optimizing vmemmap pages
associated with each HugeTLB page.
Once enabled, the vmemmap pages of subsequent allocation of HugeTLB pages from
buddy allocator will be optimized (7 pages per 2MB HugeTLB page and 4095 pages
per 1GB HugeTLB page), whereas already allocated HugeTLB pages will not be
optimized. When those optimized HugeTLB pages are freed from the HugeTLB pool
to the buddy allocator, the vmemmap pages representing that range needs to be
remapped again and the vmemmap pages discarded earlier need to be rellocated
again. If your use case is that HugeTLB pages are allocated 'on the fly' (e.g.
never explicitly allocating HugeTLB pages with 'nr_hugepages' but only set
'nr_overcommit_hugepages', those overcommitted HugeTLB pages are allocated 'on
the fly') instead of being pulled from the HugeTLB pool, you should weigh the
benefits of memory savings against the more overhead (~2x slower than before)
of allocation or freeing HugeTLB pages between the HugeTLB pool and the buddy
allocator. Another behavior to note is that if the system is under heavy memory
pressure, it could prevent the user from freeing HugeTLB pages from the HugeTLB
pool to the buddy allocator since the allocation of vmemmap pages could be
failed, you have to retry later if your system encounter this situation.
Once disabled, the vmemmap pages of subsequent allocation of HugeTLB pages from
buddy allocator will not be optimized meaning the extra overhead at allocation
time from buddy allocator disappears, whereas already optimized HugeTLB pages
will not be affected. If you want to make sure there are no optimized HugeTLB
pages, you can set "nr_hugepages" to 0 first and then disable this. Note that
writing 0 to nr_hugepages will make any "in use" HugeTLB pages become surplus
pages. So, those surplus pages are still optimized until they are no longer
in use. You would need to wait for those surplus pages to be released before
there are no optimized pages in the system.
nr_hugepages_mempolicy
======================
@@ -754,6 +794,14 @@ extra faults and I/O delays for following faults if they would have been part of
that consecutive pages readahead would have brought in.
page_lock_unfairness
====================
This value determines the number of times that the page lock can be
stolen from under a waiter. After the lock is stolen the number of times
specified in this file (default is 5), the "fair lock handoff" semantics
will apply, and the waiter will only be awakened if the lock can be taken.
panic_on_oom
============

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/cpu-feature-registers.rst
View File

@@ -290,6 +290,8 @@ infrastructure:
+------------------------------+---------+---------+
| RPRES | [7-4] | y |
+------------------------------+---------+---------+
| WFXT | [3-0] | y |
+------------------------------+---------+---------+
Appendix I: Example

4
Documentation/arm64/elf_hwcaps.rst
View File

@@ -297,6 +297,10 @@ HWCAP2_SME_FA64
Functionality implied by ID_AA64SMFR0_EL1.FA64 == 0b1.
HWCAP2_WFXT
Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010.
4. Unused AT_HWCAP bits
-----------------------

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

4
Documentation/bpf/instruction-set.rst
View File

@@ -130,7 +130,7 @@ Byte swap instructions
The byte swap instructions use an instruction class of ``BFP_ALU`` and a 4-bit
code field of ``BPF_END``.
The byte swap instructions instructions operate on the destination register
The byte swap instructions operate on the destination register
only and do not use a separate source register or immediate value.
The 1-bit source operand field in the opcode is used to to select what byte
@@ -157,7 +157,7 @@ Examples:
dst_reg = htobe64(dst_reg)
``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and
``BPF_TO_LE`` respetively.
``BPF_TO_BE`` respectively.
Jump instructions

3
Documentation/bpf/libbpf/index.rst
View File

@@ -6,14 +6,13 @@ libbpf
.. toctree::
:maxdepth: 1
API Documentation <https://libbpf.readthedocs.io/en/latest/api.html>
libbpf_naming_convention
libbpf_build
This is documentation for libbpf, a userspace library for loading and
interacting with bpf programs.
For API documentation see the `versioned API documentation site <https://libbpf.readthedocs.io/en/latest/api.html>`_.
All general BPF questions, including kernel functionality, libbpf APIs and
their application, should be sent to bpf@vger.kernel.org mailing list.
You can `subscribe <http://vger.kernel.org/vger-lists.html#bpf>`_ to the

538
Documentation/cdrom/ide-cd.rst
View File

@@ -1,538 +0,0 @@
IDE-CD driver documentation
===========================
:Originally by: scott snyder <snyder@fnald0.fnal.gov> (19 May 1996)
:Carrying on the torch is: Erik Andersen <andersee@debian.org>
:New maintainers (19 Oct 1998): Jens Axboe <axboe@image.dk>
1. Introduction
---------------
The ide-cd driver should work with all ATAPI ver 1.2 to ATAPI 2.6 compliant
CDROM drives which attach to an IDE interface. Note that some CDROM vendors
(including Mitsumi, Sony, Creative, Aztech, and Goldstar) have made
both ATAPI-compliant drives and drives which use a proprietary
interface. If your drive uses one of those proprietary interfaces,
this driver will not work with it (but one of the other CDROM drivers
probably will). This driver will not work with `ATAPI` drives which
attach to the parallel port. In addition, there is at least one drive
(CyCDROM CR520ie) which attaches to the IDE port but is not ATAPI;
this driver will not work with drives like that either (but see the
aztcd driver).
This driver provides the following features:
- Reading from data tracks, and mounting ISO 9660 filesystems.
- Playing audio tracks. Most of the CDROM player programs floating
around should work; I usually use Workman.
- Multisession support.
- On drives which support it, reading digital audio data directly
from audio tracks. The program cdda2wav can be used for this.
Note, however, that only some drives actually support this.
- There is now support for CDROM changers which comply with the
ATAPI 2.6 draft standard (such as the NEC CDR-251). This additional
functionality includes a function call to query which slot is the
currently selected slot, a function call to query which slots contain
CDs, etc. A sample program which demonstrates this functionality is
appended to the end of this file. The Sanyo 3-disc changer
(which does not conform to the standard) is also now supported.
Please note the driver refers to the first CD as slot # 0.
2. Installation
---------------
0. The ide-cd relies on the ide disk driver. See
Documentation/ide/ide.rst for up-to-date information on the ide
driver.
1. Make sure that the ide and ide-cd drivers are compiled into the
kernel you're using. When configuring the kernel, in the section
entitled "Floppy, IDE, and other block devices", say either `Y`
(which will compile the support directly into the kernel) or `M`
(to compile support as a module which can be loaded and unloaded)
to the options::
ATA/ATAPI/MFM/RLL support
Include IDE/ATAPI CDROM support
Depending on what type of IDE interface you have, you may need to
specify additional configuration options. See
Documentation/ide/ide.rst.
2. You should also ensure that the iso9660 filesystem is either
compiled into the kernel or available as a loadable module. You
can see if a filesystem is known to the kernel by catting
/proc/filesystems.
3. The CDROM drive should be connected to the host on an IDE
interface. Each interface on a system is defined by an I/O port
address and an IRQ number, the standard assignments being
0x1f0 and 14 for the primary interface and 0x170 and 15 for the
secondary interface. Each interface can control up to two devices,
where each device can be a hard drive, a CDROM drive, a floppy drive,
or a tape drive. The two devices on an interface are called `master`
and `slave`; this is usually selectable via a jumper on the drive.
Linux names these devices as follows. The master and slave devices
on the primary IDE interface are called `hda` and `hdb`,
respectively. The drives on the secondary interface are called
`hdc` and `hdd`. (Interfaces at other locations get other letters
in the third position; see Documentation/ide/ide.rst.)
If you want your CDROM drive to be found automatically by the
driver, you should make sure your IDE interface uses either the
primary or secondary addresses mentioned above. In addition, if
the CDROM drive is the only device on the IDE interface, it should
be jumpered as `master`. (If for some reason you cannot configure
your system in this manner, you can probably still use the driver.
You may have to pass extra configuration information to the kernel
when you boot, however. See Documentation/ide/ide.rst for more
information.)
4. Boot the system. If the drive is recognized, you should see a
message which looks like::
hdb: NEC CD-ROM DRIVE:260, ATAPI CDROM drive
If you do not see this, see section 5 below.
5. You may want to create a symbolic link /dev/cdrom pointing to the
actual device. You can do this with the command::
ln -s /dev/hdX /dev/cdrom
where X should be replaced by the letter indicating where your
drive is installed.
6. You should be able to see any error messages from the driver with
the `dmesg` command.
3. Basic usage
--------------
An ISO 9660 CDROM can be mounted by putting the disc in the drive and
typing (as root)::
mount -t iso9660 /dev/cdrom /mnt/cdrom
where it is assumed that /dev/cdrom is a link pointing to the actual
device (as described in step 5 of the last section) and /mnt/cdrom is
an empty directory. You should now be able to see the contents of the
CDROM under the /mnt/cdrom directory. If you want to eject the CDROM,
you must first dismount it with a command like::
umount /mnt/cdrom
Note that audio CDs cannot be mounted.
Some distributions set up /etc/fstab to always try to mount a CDROM
filesystem on bootup. It is not required to mount the CDROM in this
manner, though, and it may be a nuisance if you change CDROMs often.
You should feel free to remove the cdrom line from /etc/fstab and
mount CDROMs manually if that suits you better.
Multisession and photocd discs should work with no special handling.
The hpcdtoppm package (ftp.gwdg.de:/pub/linux/hpcdtoppm/) may be
useful for reading photocds.
To play an audio CD, you should first unmount and remove any data
CDROM. Any of the CDROM player programs should then work (workman,
workbone, cdplayer, etc.).
On a few drives, you can read digital audio directly using a program
such as cdda2wav. The only types of drive which I've heard support
this are Sony and Toshiba drives. You will get errors if you try to
use this function on a drive which does not support it.
For supported changers, you can use the `cdchange` program (appended to
the end of this file) to switch between changer slots. Note that the
drive should be unmounted before attempting this. The program takes
two arguments: the CDROM device, and the slot number to which you wish
to change. If the slot number is -1, the drive is unloaded.
4. Common problems
------------------
This section discusses some common problems encountered when trying to
use the driver, and some possible solutions. Note that if you are
experiencing problems, you should probably also review
Documentation/ide/ide.rst for current information about the underlying
IDE support code. Some of these items apply only to earlier versions
of the driver, but are mentioned here for completeness.
In most cases, you should probably check with `dmesg` for any errors
from the driver.
a. Drive is not detected during booting.
- Review the configuration instructions above and in
Documentation/ide/ide.rst, and check how your hardware is
configured.
- If your drive is the only device on an IDE interface, it should
be jumpered as master, if at all possible.
- If your IDE interface is not at the standard addresses of 0x170
or 0x1f0, you'll need to explicitly inform the driver using a
lilo option. See Documentation/ide/ide.rst. (This feature was
added around kernel version 1.3.30.)
- If the autoprobing is not finding your drive, you can tell the
driver to assume that one exists by using a lilo option of the
form `hdX=cdrom`, where X is the drive letter corresponding to
where your drive is installed. Note that if you do this and you
see a boot message like::
hdX: ATAPI cdrom (?)
this does _not_ mean that the driver has successfully detected
the drive; rather, it means that the driver has not detected a
drive, but is assuming there's one there anyway because you told
it so. If you actually try to do I/O to a drive defined at a
nonexistent or nonresponding I/O address, you'll probably get
errors with a status value of 0xff.
- Some IDE adapters require a nonstandard initialization sequence
before they'll function properly. (If this is the case, there
will often be a separate MS-DOS driver just for the controller.)
IDE interfaces on sound cards often fall into this category.
Support for some interfaces needing extra initialization is
provided in later 1.3.x kernels. You may need to turn on
additional kernel configuration options to get them to work;
see Documentation/ide/ide.rst.
Even if support is not available for your interface, you may be
able to get it to work with the following procedure. First boot
MS-DOS and load the appropriate drivers. Then warm-boot linux
(i.e., without powering off). If this works, it can be automated
by running loadlin from the MS-DOS autoexec.
b. Timeout/IRQ errors.
- If you always get timeout errors, interrupts from the drive are
probably not making it to the host.
- IRQ problems may also be indicated by the message
`IRQ probe failed (<n>)` while booting. If <n> is zero, that
means that the system did not see an interrupt from the drive when
it was expecting one (on any feasible IRQ). If <n> is negative,
that means the system saw interrupts on multiple IRQ lines, when
it was expecting to receive just one from the CDROM drive.
- Double-check your hardware configuration to make sure that the IRQ
number of your IDE interface matches what the driver expects.
(The usual assignments are 14 for the primary (0x1f0) interface
and 15 for the secondary (0x170) interface.) Also be sure that
you don't have some other hardware which might be conflicting with
the IRQ you're using. Also check the BIOS setup for your system;
some have the ability to disable individual IRQ levels, and I've
had one report of a system which was shipped with IRQ 15 disabled
by default.
- Note that many MS-DOS CDROM drivers will still function even if
there are hardware problems with the interrupt setup; they
apparently don't use interrupts.
- If you own a Pioneer DR-A24X, you _will_ get nasty error messages
on boot such as "irq timeout: status=0x50 { DriveReady SeekComplete }"
The Pioneer DR-A24X CDROM drives are fairly popular these days.
Unfortunately, these drives seem to become very confused when we perform
the standard Linux ATA disk drive probe. If you own one of these drives,
you can bypass the ATA probing which confuses these CDROM drives, by
adding `append="hdX=noprobe hdX=cdrom"` to your lilo.conf file and running
lilo (again where X is the drive letter corresponding to where your drive
is installed.)
c. System hangups.
- If the system locks up when you try to access the CDROM, the most
likely cause is that you have a buggy IDE adapter which doesn't
properly handle simultaneous transactions on multiple interfaces.
The most notorious of these is the CMD640B chip. This problem can
be worked around by specifying the `serialize` option when
booting. Recent kernels should be able to detect the need for
this automatically in most cases, but the detection is not
foolproof. See Documentation/ide/ide.rst for more information
about the `serialize` option and the CMD640B.
- Note that many MS-DOS CDROM drivers will work with such buggy
hardware, apparently because they never attempt to overlap CDROM
operations with other disk activity.
d. Can't mount a CDROM.
- If you get errors from mount, it may help to check `dmesg` to see
if there are any more specific errors from the driver or from the
filesystem.
- Make sure there's a CDROM loaded in the drive, and that's it's an
ISO 9660 disc. You can't mount an audio CD.
- With the CDROM in the drive and unmounted, try something like::
cat /dev/cdrom | od | more
If you see a dump, then the drive and driver are probably working
OK, and the problem is at the filesystem level (i.e., the CDROM is
not ISO 9660 or has errors in the filesystem structure).
- If you see `not a block device` errors, check that the definitions
of the device special files are correct. They should be as
follows::
brw-rw---- 1 root disk 3, 0 Nov 11 18:48 /dev/hda
brw-rw---- 1 root disk 3, 64 Nov 11 18:48 /dev/hdb
brw-rw---- 1 root disk 22, 0 Nov 11 18:48 /dev/hdc
brw-rw---- 1 root disk 22, 64 Nov 11 18:48 /dev/hdd
Some early Slackware releases had these defined incorrectly. If
these are wrong, you can remake them by running the script
scripts/MAKEDEV.ide. (You may have to make it executable
with chmod first.)
If you have a /dev/cdrom symbolic link, check that it is pointing
to the correct device file.
If you hear people talking of the devices `hd1a` and `hd1b`, these
were old names for what are now called hdc and hdd. Those names
should be considered obsolete.
- If mount is complaining that the iso9660 filesystem is not
available, but you know it is (check /proc/filesystems), you
probably need a newer version of mount. Early versions would not
always give meaningful error messages.
e. Directory listings are unpredictably truncated, and `dmesg` shows
`buffer botch` error messages from the driver.
- There was a bug in the version of the driver in 1.2.x kernels
which could cause this. It was fixed in 1.3.0. If you can't
upgrade, you can probably work around the problem by specifying a
blocksize of 2048 when mounting. (Note that you won't be able to
directly execute binaries off the CDROM in that case.)
If you see this in kernels later than 1.3.0, please report it as a
bug.
f. Data corruption.
- Random data corruption was occasionally observed with the Hitachi
CDR-7730 CDROM. If you experience data corruption, using "hdx=slow"
as a command line parameter may work around the problem, at the
expense of low system performance.
5. cdchange.c
-------------
::
/*
* cdchange.c [-v] <device> [<slot>]
*
* This loads a CDROM from a specified slot in a changer, and displays
* information about the changer status. The drive should be unmounted before
* using this program.
*
* Changer information is displayed if either the -v flag is specified
* or no slot was specified.
*
* Based on code originally from Gerhard Zuber <zuber@berlin.snafu.de>.
* Changer status information, and rewrite for the new Uniform CDROM driver
* interface by Erik Andersen <andersee@debian.org>.
*/
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/cdrom.h>
int
main (int argc, char **argv)
{
char *program;
char *device;
int fd; /* file descriptor for CD-ROM device */
int status; /* return status for system calls */
int verbose = 0;
int slot=-1, x_slot;
int total_slots_available;
program = argv[0];
++argv;
--argc;
if (argc < 1 || argc > 3) {
fprintf (stderr, "usage: %s [-v] <device> [<slot>]\n",
program);
fprintf (stderr, " Slots are numbered 1 -- n.\n");
exit (1);
}
if (strcmp (argv[0], "-v") == 0) {
verbose = 1;
++argv;
--argc;
}
device = argv[0];
if (argc == 2)
slot = atoi (argv[1]) - 1;
/* open device */
fd = open(device, O_RDONLY | O_NONBLOCK);
if (fd < 0) {
fprintf (stderr, "%s: open failed for `%s`: %s\n",
program, device, strerror (errno));
exit (1);
}
/* Check CD player status */
total_slots_available = ioctl (fd, CDROM_CHANGER_NSLOTS);
if (total_slots_available <= 1 ) {
fprintf (stderr, "%s: Device `%s` is not an ATAPI "
"compliant CD changer.\n", program, device);
exit (1);
}
if (slot >= 0) {
if (slot >= total_slots_available) {
fprintf (stderr, "Bad slot number. "
"Should be 1 -- %d.\n",
total_slots_available);
exit (1);
}
/* load */
slot=ioctl (fd, CDROM_SELECT_DISC, slot);
if (slot<0) {
fflush(stdout);
perror ("CDROM_SELECT_DISC ");
exit(1);
}
}
if (slot < 0 || verbose) {
status=ioctl (fd, CDROM_SELECT_DISC, CDSL_CURRENT);
if (status<0) {
fflush(stdout);
perror (" CDROM_SELECT_DISC");
exit(1);
}
slot=status;
printf ("Current slot: %d\n", slot+1);
printf ("Total slots available: %d\n",
total_slots_available);
printf ("Drive status: ");
status = ioctl (fd, CDROM_DRIVE_STATUS, CDSL_CURRENT);
if (status<0) {
perror(" CDROM_DRIVE_STATUS");
} else switch(status) {
case CDS_DISC_OK:
printf ("Ready.\n");
break;
case CDS_TRAY_OPEN:
printf ("Tray Open.\n");
break;
case CDS_DRIVE_NOT_READY:
printf ("Drive Not Ready.\n");
break;
default:
printf ("This Should not happen!\n");
break;
}
for (x_slot=0; x_slot<total_slots_available; x_slot++) {
printf ("Slot %2d: ", x_slot+1);
status = ioctl (fd, CDROM_DRIVE_STATUS, x_slot);
if (status<0) {
perror(" CDROM_DRIVE_STATUS");
} else switch(status) {
case CDS_DISC_OK:
printf ("Disc present.");
break;
case CDS_NO_DISC:
printf ("Empty slot.");
break;
case CDS_TRAY_OPEN:
printf ("CD-ROM tray open.\n");
break;
case CDS_DRIVE_NOT_READY:
printf ("CD-ROM drive not ready.\n");
break;
case CDS_NO_INFO:
printf ("No Information available.");
break;
default:
printf ("This Should not happen!\n");
break;
}
if (slot == x_slot) {
status = ioctl (fd, CDROM_DISC_STATUS);
if (status<0) {
perror(" CDROM_DISC_STATUS");
}
switch (status) {
case CDS_AUDIO:
printf ("\tAudio disc.\t");
break;
case CDS_DATA_1:
case CDS_DATA_2:
printf ("\tData disc type %d.\t", status-CDS_DATA_1+1);
break;
case CDS_XA_2_1:
case CDS_XA_2_2:
printf ("\tXA data disc type %d.\t", status-CDS_XA_2_1+1);
break;
default:
printf ("\tUnknown disc type 0x%x!\t", status);
break;
}
}
status = ioctl (fd, CDROM_MEDIA_CHANGED, x_slot);
if (status<0) {
perror(" CDROM_MEDIA_CHANGED");
}
switch (status) {
case 1:
printf ("Changed.\n");
break;
default:
printf ("\n");
break;
}
}
}
/* close device */
status = close (fd);
if (status != 0) {
fprintf (stderr, "%s: close failed for `%s`: %s\n",
program, device, strerror (errno));
exit (1);
}
exit (0);
}

1
Documentation/cdrom/index.rst
View File

@@ -8,7 +8,6 @@ cdrom
:maxdepth: 1
cdrom-standard
ide-cd
packet-writing
.. only:: subproject and html

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/index.rst
View File

@@ -18,8 +18,10 @@ it.
kernel-api
workqueue
watch_queue
printk-basics
printk-formats
printk-index
symbol-namespaces
Data structures and low-level utilities

137
Documentation/core-api/printk-index.rst Normal file
View File

@@ -0,0 +1,137 @@
.. SPDX-License-Identifier: GPL-2.0
============
Printk Index
============
There are many ways how to monitor the state of the system. One important
source of information is the system log. It provides a lot of information,
including more or less important warnings and error messages.
There are monitoring tools that filter and take action based on messages
logged.
The kernel messages are evolving together with the code. As a result,
particular kernel messages are not KABI and never will be!
It is a huge challenge for maintaining the system log monitors. It requires
knowing what messages were updated in a particular kernel version and why.
Finding these changes in the sources would require non-trivial parsers.
Also it would require matching the sources with the binary kernel which
is not always trivial. Various changes might be backported. Various kernel
versions might be used on different monitored systems.
This is where the printk index feature might become useful. It provides
a dump of printk formats used all over the source code used for the kernel
and modules on the running system. It is accessible at runtime via debugfs.
The printk index helps to find changes in the message formats. Also it helps
to track the strings back to the kernel sources and the related commit.
User Interface
==============
The index of printk formats are split in into separate files. The files are
named according to the binaries where the printk formats are built-in. There
is always "vmlinux" and optionally also modules, for example::
/sys/kernel/debug/printk/index/vmlinux
/sys/kernel/debug/printk/index/ext4
/sys/kernel/debug/printk/index/scsi_mod
Note that only loaded modules are shown. Also printk formats from a module
might appear in "vmlinux" when the module is built-in.
The content is inspired by the dynamic debug interface and looks like::
$> head -1 /sys/kernel/debug/printk/index/vmlinux; shuf -n 5 vmlinux
# <level[,flags]> filename:line function "format"
<5> block/blk-settings.c:661 disk_stack_limits "%s: Warning: Device %s is misaligned\n"
<4> kernel/trace/trace.c:8296 trace_create_file "Could not create tracefs '%s' entry\n"
<6> arch/x86/kernel/hpet.c:144 _hpet_print_config "hpet: %s(%d):\n"
<6> init/do_mounts.c:605 prepare_namespace "Waiting for root device %s...\n"
<6> drivers/acpi/osl.c:1410 acpi_no_auto_serialize_setup "ACPI: auto-serialization disabled\n"
, where the meaning is:
- :level: log level value: 0-7 for particular severity, -1 as default,
'c' as continuous line without an explicit log level
- :flags: optional flags: currently only 'c' for KERN_CONT
- :filename\:line: source filename and line number of the related
printk() call. Note that there are many wrappers, for example,
pr_warn(), pr_warn_once(), dev_warn().
- :function: function name where the printk() call is used.
- :format: format string
The extra information makes it a bit harder to find differences
between various kernels. Especially the line number might change
very often. On the other hand, it helps a lot to confirm that
it is the same string or find the commit that is responsible
for eventual changes.
printk() Is Not a Stable KABI
=============================
Several developers are afraid that exporting all these implementation
details into the user space will transform particular printk() calls
into KABI.
But it is exactly the opposite. printk() calls must _not_ be KABI.
And the printk index helps user space tools to deal with this.
Subsystem specific printk wrappers
==================================
The printk index is generated using extra metadata that are stored in
a dedicated .elf section ".printk_index". It is achieved using macro
wrappers doing __printk_index_emit() together with the real printk()
call. The same technique is used also for the metadata used by
the dynamic debug feature.
The metadata are stored for a particular message only when it is printed
using these special wrappers. It is implemented for the commonly
used printk() calls, including, for example, pr_warn(), or pr_once().
Additional changes are necessary for various subsystem specific wrappers
that call the original printk() via a common helper function. These needs
their own wrappers adding __printk_index_emit().
Only few subsystem specific wrappers have been updated so far,
for example, dev_printk(). As a result, the printk formats from
some subsystes can be missing in the printk index.
Subsystem specific prefix
=========================
The macro pr_fmt() macro allows to define a prefix that is printed
before the string generated by the related printk() calls.
Subsystem specific wrappers usually add even more complicated
prefixes.
These prefixes can be stored into the printk index metadata
by an optional parameter of __printk_index_emit(). The debugfs
interface might then show the printk formats including these prefixes.
For example, drivers/acpi/osl.c contains::
#define pr_fmt(fmt) "ACPI: OSL: " fmt
static int __init acpi_no_auto_serialize_setup(char *str)
{
acpi_gbl_auto_serialize_methods = FALSE;
pr_info("Auto-serialization disabled\n");
return 1;
}
This results in the following printk index entry::
<6> drivers/acpi/osl.c:1410 acpi_no_auto_serialize_setup "ACPI: auto-serialization disabled\n"
It helps matching messages from the real log with printk index.
Then the source file name, line number, and function name can
be used to match the string with the source code.

0
Documentation/watch_queue.rst → Documentation/core-api/watch_queue.rst
View File

228
Documentation/dev-tools/kasan.rst
View File

@@ -4,39 +4,76 @@ The Kernel Address Sanitizer (KASAN)
Overview
--------
KernelAddressSANitizer (KASAN) is a dynamic memory safety error detector
designed to find out-of-bound and use-after-free bugs. KASAN has three modes:
Kernel Address Sanitizer (KASAN) is a dynamic memory safety error detector
designed to find out-of-bounds and use-after-free bugs.
1. generic KASAN (similar to userspace ASan),
2. software tag-based KASAN (similar to userspace HWASan),
3. hardware tag-based KASAN (based on hardware memory tagging).
KASAN has three modes:
Generic KASAN is mainly used for debugging due to a large memory overhead.
Software tag-based KASAN can be used for dogfood testing as it has a lower
memory overhead that allows using it with real workloads. Hardware tag-based
KASAN comes with low memory and performance overheads and, therefore, can be
used in production. Either as an in-field memory bug detector or as a security
mitigation.
1. Generic KASAN
2. Software Tag-Based KASAN
3. Hardware Tag-Based KASAN
Software KASAN modes (#1 and #2) use compile-time instrumentation to insert
validity checks before every memory access and, therefore, require a compiler
version that supports that.
Generic KASAN, enabled with CONFIG_KASAN_GENERIC, is the mode intended for
debugging, similar to userspace ASan. This mode is supported on many CPU
architectures, but it has significant performance and memory overheads.
Generic KASAN is supported in GCC and Clang. With GCC, it requires version
8.3.0 or later. Any supported Clang version is compatible, but detection of
out-of-bounds accesses for global variables is only supported since Clang 11.
Software Tag-Based KASAN or SW_TAGS KASAN, enabled with CONFIG_KASAN_SW_TAGS,
can be used for both debugging and dogfood testing, similar to userspace HWASan.
This mode is only supported for arm64, but its moderate memory overhead allows
using it for testing on memory-restricted devices with real workloads.
Software tag-based KASAN mode is only supported in Clang.
Hardware Tag-Based KASAN or HW_TAGS KASAN, enabled with CONFIG_KASAN_HW_TAGS,
is the mode intended to be used as an in-field memory bug detector or as a
security mitigation. This mode only works on arm64 CPUs that support MTE
(Memory Tagging Extension), but it has low memory and performance overheads and
thus can be used in production.
The hardware KASAN mode (#3) relies on hardware to perform the checks but
still requires a compiler version that supports memory tagging instructions.
This mode is supported in GCC 10+ and Clang 12+.
For details about the memory and performance impact of each KASAN mode, see the
descriptions of the corresponding Kconfig options.
Both software KASAN modes work with SLUB and SLAB memory allocators,
while the hardware tag-based KASAN currently only supports SLUB.
The Generic and the Software Tag-Based modes are commonly referred to as the
software modes. The Software Tag-Based and the Hardware Tag-Based modes are
referred to as the tag-based modes.
Currently, generic KASAN is supported for the x86_64, arm, arm64, xtensa, s390,
and riscv architectures, and tag-based KASAN modes are supported only for arm64.
Support
-------
Architectures
~~~~~~~~~~~~~
Generic KASAN is supported on x86_64, arm, arm64, powerpc, riscv, s390, and
xtensa, and the tag-based KASAN modes are supported only on arm64.
Compilers
~~~~~~~~~
Software KASAN modes use compile-time instrumentation to insert validity checks
before every memory access and thus require a compiler version that provides
support for that. The Hardware Tag-Based mode relies on hardware to perform
these checks but still requires a compiler version that supports the memory
tagging instructions.
Generic KASAN requires GCC version 8.3.0 or later
or any Clang version supported by the kernel.
Software Tag-Based KASAN requires GCC 11+
or any Clang version supported by the kernel.
Hardware Tag-Based KASAN requires GCC 10+ or Clang 12+.
Memory types
~~~~~~~~~~~~
Generic KASAN supports finding bugs in all of slab, page_alloc, vmap, vmalloc,
stack, and global memory.
Software Tag-Based KASAN supports slab, page_alloc, vmalloc, and stack memory.
Hardware Tag-Based KASAN supports slab, page_alloc, and non-executable vmalloc
memory.
For slab, both software KASAN modes support SLUB and SLAB allocators, while
Hardware Tag-Based KASAN only supports SLUB.
Usage
-----
@@ -45,18 +82,59 @@ To enable KASAN, configure the kernel with::
CONFIG_KASAN=y
and choose between ``CONFIG_KASAN_GENERIC`` (to enable generic KASAN),
``CONFIG_KASAN_SW_TAGS`` (to enable software tag-based KASAN), and
``CONFIG_KASAN_HW_TAGS`` (to enable hardware tag-based KASAN).
and choose between ``CONFIG_KASAN_GENERIC`` (to enable Generic KASAN),
``CONFIG_KASAN_SW_TAGS`` (to enable Software Tag-Based KASAN), and
``CONFIG_KASAN_HW_TAGS`` (to enable Hardware Tag-Based KASAN).
For software modes, also choose between ``CONFIG_KASAN_OUTLINE`` and
For the software modes, also choose between ``CONFIG_KASAN_OUTLINE`` and
``CONFIG_KASAN_INLINE``. Outline and inline are compiler instrumentation types.
The former produces a smaller binary while the latter is 1.1-2 times faster.
The former produces a smaller binary while the latter is up to 2 times faster.
To include alloc and free stack traces of affected slab objects into reports,
enable ``CONFIG_STACKTRACE``. To include alloc and free stack traces of affected
physical pages, enable ``CONFIG_PAGE_OWNER`` and boot with ``page_owner=on``.
Boot parameters
~~~~~~~~~~~~~~~
KASAN is affected by the generic ``panic_on_warn`` command line parameter.
When it is enabled, KASAN panics the kernel after printing a bug report.
By default, KASAN prints a bug report only for the first invalid memory access.
With ``kasan_multi_shot``, KASAN prints a report on every invalid access. This
effectively disables ``panic_on_warn`` for KASAN reports.
Alternatively, independent of ``panic_on_warn``, the ``kasan.fault=`` boot
parameter can be used to control panic and reporting behaviour:
- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN
report or also panic the kernel (default: ``report``). The panic happens even
if ``kasan_multi_shot`` is enabled.
Hardware Tag-Based KASAN mode (see the section about various modes below) is
intended for use in production as a security mitigation. Therefore, it supports
additional boot parameters that allow disabling KASAN or controlling features:
- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``).
- ``kasan.mode=sync``, ``=async`` or ``=asymm`` controls whether KASAN
is configured in synchronous, asynchronous or asymmetric mode of
execution (default: ``sync``).
Synchronous mode: a bad access is detected immediately when a tag
check fault occurs.
Asynchronous mode: a bad access detection is delayed. When a tag check
fault occurs, the information is stored in hardware (in the TFSR_EL1
register for arm64). The kernel periodically checks the hardware and
only reports tag faults during these checks.
Asymmetric mode: a bad access is detected synchronously on reads and
asynchronously on writes.
- ``kasan.vmalloc=off`` or ``=on`` disables or enables tagging of vmalloc
allocations (default: ``on``).
- ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack
traces collection (default: ``on``).
Error reports
~~~~~~~~~~~~~
@@ -146,7 +224,7 @@ is either 8 or 16 aligned bytes depending on KASAN mode. Each number in the
memory state section of the report shows the state of one of the memory
granules that surround the accessed address.
For generic KASAN, the size of each memory granule is 8. The state of each
For Generic KASAN, the size of each memory granule is 8. The state of each
granule is encoded in one shadow byte. Those 8 bytes can be accessible,
partially accessible, freed, or be a part of a redzone. KASAN uses the following
encoding for each shadow byte: 00 means that all 8 bytes of the corresponding
@@ -171,47 +249,6 @@ traces point to places in code that interacted with the object but that are not
directly present in the bad access stack trace. Currently, this includes
call_rcu() and workqueue queuing.
Boot parameters
~~~~~~~~~~~~~~~
KASAN is affected by the generic ``panic_on_warn`` command line parameter.
When it is enabled, KASAN panics the kernel after printing a bug report.
By default, KASAN prints a bug report only for the first invalid memory access.
With ``kasan_multi_shot``, KASAN prints a report on every invalid access. This
effectively disables ``panic_on_warn`` for KASAN reports.
Alternatively, independent of ``panic_on_warn`` the ``kasan.fault=`` boot
parameter can be used to control panic and reporting behaviour:
- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN
report or also panic the kernel (default: ``report``). The panic happens even
if ``kasan_multi_shot`` is enabled.
Hardware tag-based KASAN mode (see the section about various modes below) is
intended for use in production as a security mitigation. Therefore, it supports
additional boot parameters that allow disabling KASAN or controlling features:
- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``).
- ``kasan.mode=sync``, ``=async`` or ``=asymm`` controls whether KASAN
is configured in synchronous, asynchronous or asymmetric mode of
execution (default: ``sync``).
Synchronous mode: a bad access is detected immediately when a tag
check fault occurs.
Asynchronous mode: a bad access detection is delayed. When a tag check
fault occurs, the information is stored in hardware (in the TFSR_EL1
register for arm64). The kernel periodically checks the hardware and
only reports tag faults during these checks.
Asymmetric mode: a bad access is detected synchronously on reads and
asynchronously on writes.
- ``kasan.vmalloc=off`` or ``=on`` disables or enables tagging of vmalloc
allocations (default: ``on``).
- ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack
traces collection (default: ``on``).
Implementation details
----------------------
@@ -250,49 +287,46 @@ outline-instrumented kernel.
Generic KASAN is the only mode that delays the reuse of freed objects via
quarantine (see mm/kasan/quarantine.c for implementation).
Software tag-based KASAN
Software Tag-Based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
Software tag-based KASAN uses a software memory tagging approach to checking
Software Tag-Based KASAN uses a software memory tagging approach to checking
access validity. It is currently only implemented for the arm64 architecture.
Software tag-based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs
Software Tag-Based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs
to store a pointer tag in the top byte of kernel pointers. It uses shadow memory
to store memory tags associated with each 16-byte memory cell (therefore, it
dedicates 1/16th of the kernel memory for shadow memory).
On each memory allocation, software tag-based KASAN generates a random tag, tags
On each memory allocation, Software Tag-Based KASAN generates a random tag, tags
the allocated memory with this tag, and embeds the same tag into the returned
pointer.
Software tag-based KASAN uses compile-time instrumentation to insert checks
Software Tag-Based KASAN uses compile-time instrumentation to insert checks
before each memory access. These checks make sure that the tag of the memory
that is being accessed is equal to the tag of the pointer that is used to access
this memory. In case of a tag mismatch, software tag-based KASAN prints a bug
this memory. In case of a tag mismatch, Software Tag-Based KASAN prints a bug
report.
Software tag-based KASAN also has two instrumentation modes (outline, which
Software Tag-Based KASAN also has two instrumentation modes (outline, which
emits callbacks to check memory accesses; and inline, which performs the shadow
memory checks inline). With outline instrumentation mode, a bug report is
printed from the function that performs the access check. With inline
instrumentation, a ``brk`` instruction is emitted by the compiler, and a
dedicated ``brk`` handler is used to print bug reports.
Software tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through
Software Tag-Based KASAN uses 0xFF as a match-all pointer tag (accesses through
pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
reserved to tag freed memory regions.
Software tag-based KASAN currently only supports tagging of slab, page_alloc,
and vmalloc memory.
Hardware tag-based KASAN
Hardware Tag-Based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
Hardware tag-based KASAN is similar to the software mode in concept but uses
Hardware Tag-Based KASAN is similar to the software mode in concept but uses
hardware memory tagging support instead of compiler instrumentation and
shadow memory.
Hardware tag-based KASAN is currently only implemented for arm64 architecture
Hardware Tag-Based KASAN is currently only implemented for arm64 architecture
and based on both arm64 Memory Tagging Extension (MTE) introduced in ARMv8.5
Instruction Set Architecture and Top Byte Ignore (TBI).
@@ -302,21 +336,18 @@ access, hardware makes sure that the tag of the memory that is being accessed is
equal to the tag of the pointer that is used to access this memory. In case of a
tag mismatch, a fault is generated, and a report is printed.
Hardware tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through
Hardware Tag-Based KASAN uses 0xFF as a match-all pointer tag (accesses through
pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
reserved to tag freed memory regions.
Hardware tag-based KASAN currently only supports tagging of slab, page_alloc,
and VM_ALLOC-based vmalloc memory.
If the hardware does not support MTE (pre ARMv8.5), hardware tag-based KASAN
If the hardware does not support MTE (pre ARMv8.5), Hardware Tag-Based KASAN
will not be enabled. In this case, all KASAN boot parameters are ignored.
Note that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
enabled. Even when ``kasan.mode=off`` is provided or when the hardware does not
support MTE (but supports TBI).
Hardware tag-based KASAN only reports the first found bug. After that, MTE tag
Hardware Tag-Based KASAN only reports the first found bug. After that, MTE tag
checking gets disabled.
Shadow memory
@@ -414,19 +445,18 @@ generic ``noinstr`` one.
Note that disabling compiler instrumentation (either on a per-file or a
per-function basis) makes KASAN ignore the accesses that happen directly in
that code for software KASAN modes. It does not help when the accesses happen
indirectly (through calls to instrumented functions) or with the hardware
tag-based mode that does not use compiler instrumentation.
indirectly (through calls to instrumented functions) or with Hardware
Tag-Based KASAN, which does not use compiler instrumentation.
For software KASAN modes, to disable KASAN reports in a part of the kernel code
for the current task, annotate this part of the code with a
``kasan_disable_current()``/``kasan_enable_current()`` section. This also
disables the reports for indirect accesses that happen through function calls.
For tag-based KASAN modes (include the hardware one), to disable access
checking, use ``kasan_reset_tag()`` or ``page_kasan_tag_reset()``. Note that
temporarily disabling access checking via ``page_kasan_tag_reset()`` requires
saving and restoring the per-page KASAN tag via
``page_kasan_tag``/``page_kasan_tag_set``.
For tag-based KASAN modes, to disable access checking, use
``kasan_reset_tag()`` or ``page_kasan_tag_reset()``. Note that temporarily
disabling access checking via ``page_kasan_tag_reset()`` requires saving and
restoring the per-page KASAN tag via ``page_kasan_tag``/``page_kasan_tag_set``.
Tests
~~~~~

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

@@ -115,34 +115,32 @@ The diagnostic data field is optional, and results which have neither a
directive nor any diagnostic data do not need to include the "#" field
separator.
Example result lines include:
.. code-block:: none
Example result lines include::
ok 1 test_case_name
The test "test_case_name" passed.
.. code-block:: none
::
not ok 1 test_case_name
The test "test_case_name" failed.
.. code-block:: none
::
ok 1 test # SKIP necessary dependency unavailable
The test "test" was SKIPPED with the diagnostic message "necessary dependency
unavailable".
.. code-block:: none
::
not ok 1 test # TIMEOUT 30 seconds
The test "test" timed out, with diagnostic data "30 seconds".
.. code-block:: none
::
ok 5 check return code # rcode=0
@@ -202,7 +200,7 @@ allowed to be either indented or not indented.
An example of a test with two nested subtests:
.. code-block:: none
::
KTAP version 1
1..1
@@ -215,7 +213,7 @@ An example of a test with two nested subtests:
An example format with multiple levels of nested testing:
.. code-block:: none
::
KTAP version 1
1..2
@@ -250,7 +248,7 @@ nested version line, uses a line of the form
Example KTAP output
--------------------
.. code-block:: none
::
KTAP version 1
1..1

5
Documentation/dev-tools/kunit/api/index.rst
View File

@@ -6,6 +6,7 @@ API Reference
.. toctree::
test
resource
This section documents the KUnit kernel testing API. It is divided into the
following sections:
@@ -13,3 +14,7 @@ following sections:
Documentation/dev-tools/kunit/api/test.rst
- documents all of the standard testing API
Documentation/dev-tools/kunit/api/resource.rst
- documents the KUnit resource API

13
Documentation/dev-tools/kunit/api/resource.rst Normal file
View File

@@ -0,0 +1,13 @@
.. SPDX-License-Identifier: GPL-2.0
============
Resource API
============
This file documents the KUnit resource API.
Most users won't need to use this API directly, power users can use it to store
state on a per-test basis, register custom cleanup actions, and more.
.. kernel-doc:: include/kunit/resource.h
:internal:

2
Documentation/dev-tools/kunit/architecture.rst
View File

@@ -125,7 +125,7 @@ All expectations/assertions are formatted as:
``void __noreturn kunit_try_catch_throw(struct kunit_try_catch *try_catch)``.
- ``kunit_try_catch_throw`` calls function:
``void complete_and_exit(struct completion *, long) __noreturn;``
``void kthread_complete_and_exit(struct completion *, long) __noreturn;``
and terminates the special thread context.
- ``<op>`` denotes a check with options: ``TRUE`` (supplied property

3
Documentation/dev-tools/kunit/running_tips.rst
View File

@@ -114,6 +114,7 @@ Instead of enabling ``CONFIG_GCOV_KERNEL=y``, we can set these options:
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
CONFIG_GCOV=y
@@ -122,7 +123,7 @@ Putting it together into a copy-pastable sequence of commands:
.. code-block:: bash
# Append coverage options to the current config
$ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig
$ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig
$ ./tools/testing/kunit/kunit.py run
# Extract the coverage information from the build dir (.kunit/)
$ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/

19
Documentation/dev-tools/kunit/usage.rst
View File

@@ -125,8 +125,8 @@ We need many test cases covering all the unit's behaviors. It is common to have
many similar tests. In order to reduce duplication in these closely related
tests, most unit testing frameworks (including KUnit) provide the concept of a
*test suite*. A test suite is a collection of test cases for a unit of code
with a setup function that gets invoked before every test case and then a tear
down function that gets invoked after every test case completes. For example:
with optional setup and teardown functions that run before/after the whole
suite and/or every test case. For example:
.. code-block:: c
@@ -141,16 +141,19 @@ down function that gets invoked after every test case completes. For example:
.name = "example",
.init = example_test_init,
.exit = example_test_exit,
.suite_init = example_suite_init,
.suite_exit = example_suite_exit,
.test_cases = example_test_cases,
};
kunit_test_suite(example_test_suite);
In the above example, the test suite ``example_test_suite`` would run the test
cases ``example_test_foo``, ``example_test_bar``, and ``example_test_baz``. Each
would have ``example_test_init`` called immediately before it and
``example_test_exit`` called immediately after it.
``kunit_test_suite(example_test_suite)`` registers the test suite with the
KUnit test framework.
In the above example, the test suite ``example_test_suite`` would first run
``example_suite_init``, then run the test cases ``example_test_foo``,
``example_test_bar``, and ``example_test_baz``. Each would have
``example_test_init`` called immediately before it and ``example_test_exit``
called immediately after it. Finally, ``example_suite_exit`` would be called
after everything else. ``kunit_test_suite(example_test_suite)`` registers the
test suite with the KUnit test framework.
.. note::
A test case will only run if it is associated with a test suite.

63
Documentation/dev-tools/testing-overview.rst
View File

@@ -115,3 +115,66 @@ that none of these errors are occurring during the test.
Some of these tools integrate with KUnit or kselftest and will
automatically fail tests if an issue is detected.
Static Analysis Tools
=====================
In addition to testing a running kernel, one can also analyze kernel source code
directly (**at compile time**) using **static analysis** tools. The tools
commonly used in the kernel allow one to inspect the whole source tree or just
specific files within it. They make it easier to detect and fix problems during
the development process.
Sparse can help test the kernel by performing type-checking, lock checking,
value range checking, in addition to reporting various errors and warnings while
examining the code. See the Documentation/dev-tools/sparse.rst documentation
page for details on how to use it.
Smatch extends Sparse and provides additional checks for programming logic
mistakes such as missing breaks in switch statements, unused return values on
error checking, forgetting to set an error code in the return of an error path,
etc. Smatch also has tests against more serious issues such as integer
overflows, null pointer dereferences, and memory leaks. See the project page at
http://smatch.sourceforge.net/.
Coccinelle is another static analyzer at our disposal. Coccinelle is often used
to aid refactoring and collateral evolution of source code, but it can also help
to avoid certain bugs that occur in common code patterns. The types of tests
available include API tests, tests for correct usage of kernel iterators, checks
for the soundness of free operations, analysis of locking behavior, and further
tests known to help keep consistent kernel usage. See the
Documentation/dev-tools/coccinelle.rst documentation page for details.
Beware, though, that static analysis tools suffer from **false positives**.
Errors and warns need to be evaluated carefully before attempting to fix them.
When to use Sparse and Smatch
-----------------------------
Sparse does type checking, such as verifying that annotated variables do not
cause endianness bugs, detecting places that use ``__user`` pointers improperly,
and analyzing the compatibility of symbol initializers.
Smatch does flow analysis and, if allowed to build the function database, it
also does cross function analysis. Smatch tries to answer questions like where
is this buffer allocated? How big is it? Can this index be controlled by the
user? Is this variable larger than that variable?
It's generally easier to write checks in Smatch than it is to write checks in
Sparse. Nevertheless, there are some overlaps between Sparse and Smatch checks.
Strong points of Smatch and Coccinelle
--------------------------------------
Coccinelle is probably the easiest for writing checks. It works before the
pre-processor so it's easier to check for bugs in macros using Coccinelle.
Coccinelle also creates patches for you, which no other tool does.
For example, with Coccinelle you can do a mass conversion from
``kmalloc(x * size, GFP_KERNEL)`` to ``kmalloc_array(x, size, GFP_KERNEL)``, and
that's really useful. If you just created a Smatch warning and try to push the
work of converting on to the maintainers they would be annoyed. You'd have to
argue about each warning if can really overflow or not.
Coccinelle does no analysis of variable values, which is the strong point of
Smatch. On the other hand, Coccinelle allows you to do simple things in a simple
way.

45
Documentation/devicetree/bindings/arm/arm,corstone1000.yaml Normal file
View File

@@ -0,0 +1,45 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,corstone1000.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Corstone1000 Device Tree Bindings
maintainers:
- Vishnu Banavath <vishnu.banavath@arm.com>
- Rui Miguel Silva <rui.silva@linaro.org>
description: |+
ARM's Corstone1000 includes pre-verified Corstone SSE-710 subsystem that
provides a flexible compute architecture that combines Cortex‑A and Cortex‑M
processors.
Support for Cortex‑A32, Cortex‑A35 and Cortex‑A53 processors. Two expansion
systems for M-Class (or other) processors for adding sensors, connectivity,
video, audio and machine learning at the edge System and security IPs to build
a secure SoC for a range of rich IoT applications, for example gateways, smart
cameras and embedded systems.
Integrated Secure Enclave providing hardware Root of Trust and supporting
seamless integration of the optional CryptoCell™-312 cryptographic
accelerator.
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: Corstone1000 MPS3 it has 1 Cortex-A35 CPU core in a FPGA
implementation of the Corstone1000 in the MPS3 prototyping board. See
ARM document DAI0550.
items:
- const: arm,corstone1000-mps3
- description: Corstone1000 FVP is the Fixed Virtual Platform
implementation of this system. See ARM ecosystems FVP's.
items:
- const: arm,corstone1000-fvp
additionalProperties: true
...

10
Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml
View File

@@ -64,6 +64,7 @@ properties:
- description: BCM47094 based boards
items:
- enum:
- asus,rt-ac88u
- dlink,dir-885l
- linksys,panamera
- luxul,abr-4500-v1
@@ -83,9 +84,14 @@ properties:
- brcm,bcm953012er
- brcm,bcm953012hr
- brcm,bcm953012k
- const: brcm,bcm53012
- const: brcm,bcm4708
- description: BCM53016 based boards
items:
- enum:
- meraki,mr32
- const: brcm,brcm53012
- const: brcm,brcm53016
- const: brcm,bcm53016
- const: brcm,bcm4708
additionalProperties: true

2
Documentation/devicetree/bindings/arm/bcm/brcm,bcm63138.txt
View File

@@ -30,7 +30,7 @@ Example:
cpus {
cpu@0 {
compatible = "arm,cotex-a9";
compatible = "arm,cortex-a9";
reg = <0>;
...
enable-method = "brcm,bcm63138";

33
Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml Normal file
View File

@@ -0,0 +1,33 @@
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcmbca.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Broadband SoC device tree bindings
description:
Broadcom Broadband SoCs include family of high performance DSL/PON/Wireless
chips that can be used as home gateway, router and WLAN AP for residential,
enterprise and carrier applications.
maintainers:
- William Zhang <william.zhang@broadcom.com>
- Anand Gore <anand.gore@broadcom.com>
- Kursad Oney <kursad.oney@broadcom.com>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: BCM47622 based boards
items:
- enum:
- brcm,bcm947622
- const: brcm,bcm47622
- const: brcm,bcmbca
additionalProperties: true
...

19
Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt
View File

@@ -1,19 +0,0 @@
Freescale DCFG
DCFG is the device configuration unit, that provides general purpose
configuration and status for the device. Such as setting the secondary
core start address and release the secondary core from holdoff and startup.
Required properties:
- compatible: Should contain a chip-specific compatible string,
Chip-specific strings are of the form "fsl,<chip>-dcfg",
The following <chip>s are known to be supported:
ls1012a, ls1021a, ls1043a, ls1046a, ls2080a, lx2160a
- reg : should contain base address and length of DCFG memory-mapped registers
Example:
dcfg: dcfg@1ee0000 {
compatible = "fsl,ls1021a-dcfg";
reg = <0x0 0x1ee0000 0x0 0x10000>;
};

19
Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt
View File

@@ -1,19 +0,0 @@
Freescale SCFG
SCFG is the supplemental configuration unit, that provides SoC specific
configuration and status registers for the chip. Such as getting PEX port
status.
Required properties:
- compatible: Should contain a chip-specific compatible string,
Chip-specific strings are of the form "fsl,<chip>-scfg",
The following <chip>s are known to be supported:
ls1012a, ls1021a, ls1043a, ls1046a, ls2080a.
- reg: should contain base address and length of SCFG memory-mapped registers
Example:
scfg: scfg@1570000 {
compatible = "fsl,ls1021a-scfg";
reg = <0x0 0x1570000 0x0 0x10000>;
};

119
Documentation/devicetree/bindings/arm/fsl.yaml
View File

@@ -172,7 +172,7 @@ properties:
- karo,tx53 # Ka-Ro electronics TX53 module
- kiebackpeter,imx53-ddc # K+P imx53 DDC
- kiebackpeter,imx53-hsc # K+P imx53 HSC
- menlo,m53menlo
- menlo,m53menlo # i.MX53 Menlo board
- voipac,imx53-dmm-668 # Voipac i.MX53 X53-DMM-668
- const: fsl,imx53
@@ -192,6 +192,7 @@ properties:
items:
- enum:
- auvidea,h100 # Auvidea H100
- bosch,imx6q-acc # Bosch ACC i.MX6 Dual
- boundary,imx6q-nitrogen6_max
- boundary,imx6q-nitrogen6_som2
- boundary,imx6q-nitrogen6x
@@ -411,7 +412,6 @@ properties:
- technologic,imx6dl-ts4900
- technologic,imx6dl-ts7970
- toradex,colibri_imx6dl # Colibri iMX6 Modules
- toradex,colibri_imx6dl-v1_1 # Colibri iMX6 V1.1 Modules
- udoo,imx6dl-udoo # Udoo i.MX6 Dual-lite Board
- vdl,lanmcu # Van der Laan LANMCU board
- wand,imx6dl-wandboard # Wandboard i.MX6 Dual Lite Board
@@ -488,17 +488,13 @@ properties:
- description: i.MX6DL Boards with Toradex Colibri iMX6DL/S Modules
items:
- enum:
- toradex,colibri_imx6dl-aster # Colibri iMX6DL/S Module on Aster Board
- toradex,colibri_imx6dl-eval-v3 # Colibri iMX6DL/S Module on Colibri Evaluation Board V3
- toradex,colibri_imx6dl-iris # Colibri iMX6DL/S Module on Iris Board
- toradex,colibri_imx6dl-iris-v2 # Colibri iMX6DL/S Module on Iris Board V2
- const: toradex,colibri_imx6dl # Colibri iMX6DL/S Module
- const: fsl,imx6dl
- description: i.MX6DL Boards with Toradex Colibri iMX6DL/S V1.1 Modules
items:
- enum:
- toradex,colibri_imx6dl-v1_1-eval-v3 # Colibri iMX6DL/S V1.1 M. on Colibri Evaluation Board V3
- const: toradex,colibri_imx6dl-v1_1 # Colibri iMX6DL/S V1.1 Module
- const: fsl,imx6dl
- description: i.MX6S DHCOM DRC02 Board
items:
- const: dh,imx6s-dhcom-drc02
@@ -613,6 +609,28 @@ properties:
- const: kontron,imx6ul-n6310-som
- const: fsl,imx6ul
- description: TQ-Systems TQMa6UL1 SoM on MBa6ULx board
items:
- enum:
- tq,imx6ul-tqma6ul1-mba6ulx
- const: tq,imx6ul-tqma6ul1 # MCIMX6G1
- const: fsl,imx6ul
- description: TQ-Systems TQMa6UL2 SoM on MBa6ULx board
items:
- enum:
- tq,imx6ul-tqma6ul2-mba6ulx
- const: tq,imx6ul-tqma6ul2 # MCIMX6G2
- const: fsl,imx6ul
- description: TQ-Systems TQMa6ULxL SoM on MBa6ULx[L] board
items:
- enum:
- tq,imx6ul-tqma6ul2l-mba6ulx # using LGA adapter
- tq,imx6ul-tqma6ul2l-mba6ulxl
- const: tq,imx6ul-tqma6ul2l # MCIMX6G2, LGA SoM variant
- const: fsl,imx6ul
- description: i.MX6ULL based Boards
items:
- enum:
@@ -640,26 +658,44 @@ properties:
- const: phytec,imx6ull-pcl063 # PHYTEC phyCORE-i.MX 6ULL
- const: fsl,imx6ull
- description: i.MX6ULL PHYTEC phyGATE-Tauri
items:
- enum:
- phytec,imx6ull-phygate-tauri-emmc
- phytec,imx6ull-phygate-tauri-nand
- const: phytec,imx6ull-phygate-tauri # PHYTEC phyGATE-Tauri with i.MX6 ULL
- const: phytec,imx6ull-pcl063 # PHYTEC phyCORE-i.MX 6ULL
- const: fsl,imx6ull
- description: i.MX6ULL Boards with Toradex Colibri iMX6ULL Modules
items:
- enum:
- toradex,colibri-imx6ull-eval # Colibri iMX6ULL Module on Colibri Evaluation Board
- toradex,colibri-imx6ull-aster # Colibri iMX6ULL Module on Aster Carrier Board
- toradex,colibri-imx6ull-eval # Colibri iMX6ULL Module on Colibri Evaluation Board V3
- toradex,colibri-imx6ull-iris # Colibri iMX6ULL Module on Iris Carrier Board
- toradex,colibri-imx6ull-iris-v2 # Colibri iMX6ULL Module on Iris V2 Carrier Board
- const: toradex,colibri-imx6ull # Colibri iMX6ULL Module
- const: fsl,imx6dl
- const: fsl,imx6ull
- description: i.MX6ULL Boards with Toradex Colibri iMX6ULL 1GB (eMMC) Module
items:
- enum:
- toradex,colibri-imx6ull-emmc-eval # Colibri iMX6ULL 1GB (eMMC) M. on Colibri Evaluation Board
- const: toradex,colibri-imx6ull-emmc # Colibri iMX6ULL 1GB (eMMC) Module
- const: fsl,imx6dl
- toradex,colibri-imx6ull-emmc-aster # Colibri iMX6ULL 1G (eMMC) on Aster Carrier Board
- toradex,colibri-imx6ull-emmc-eval # Colibri iMX6ULL 1G (eMMC) on Colibri Evaluation B. V3
- toradex,colibri-imx6ull-emmc-iris # Colibri iMX6ULL 1G (eMMC) on Iris Carrier Board
- toradex,colibri-imx6ull-emmc-iris-v2 # Colibri iMX6ULL 1G (eMMC) on Iris V2 Carrier Board
- const: toradex,colibri-imx6ull-emmc # Colibri iMX6ULL 1GB (eMMC) Module
- const: fsl,imx6ull
- description: i.MX6ULL Boards with Toradex Colibri iMX6ULL Wi-Fi / BT Modules
items:
- enum:
- toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / BT M. on Colibri Evaluation Board
- const: toradex,colibri-imx6ull-wifi # Colibri iMX6ULL Wi-Fi / BT Module
- const: fsl,imx6dl
- toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / BT M. on Colibri Eval. B. V3
- toradex,colibri-imx6ull-wifi-aster # Colibri iMX6ULL Wi-Fi / BT M. on Aster Carrier Board
- toradex,colibri-imx6ull-wifi-iris # Colibri iMX6ULL Wi-Fi / BT M. on Iris Carrier Board
- toradex,colibri-imx6ull-wifi-iris-v2 # Colibri iMX6ULL Wi-Fi / BT M. on Iris V2 Carrier Board
- const: toradex,colibri-imx6ull-wifi # Colibri iMX6ULL Wi-Fi / BT Module
- const: fsl,imx6ull
- description: Kontron N6411 S Board
items:
@@ -667,6 +703,21 @@ properties:
- const: kontron,imx6ull-n6411-som
- const: fsl,imx6ull
- description: TQ Systems TQMa6ULLx SoM on MBa6ULx board
items:
- enum:
- tq,imx6ull-tqma6ull2-mba6ulx
- const: tq,imx6ull-tqma6ull2 # MCIMX6Y2
- const: fsl,imx6ull
- description: TQ Systems TQMa6ULLxL SoM on MBa6ULx[L] board
items:
- enum:
- tq,imx6ull-tqma6ull2l-mba6ulx # using LGA adapter
- tq,imx6ull-tqma6ull2l-mba6ulxl
- const: tq,imx6ull-tqma6ull2l # MCIMX6Y2, LGA SoM variant
- const: fsl,imx6ull
- description: i.MX6ULZ based Boards
items:
- enum:
@@ -707,6 +758,7 @@ properties:
- kam,imx7d-flex-concentrator-mfg # Kamstrup OMNIA Flex Concentrator in manufacturing mode
- novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board
- remarkable,imx7d-remarkable2 # i.MX7D ReMarkable 2 E-Ink Tablet
- storopack,imx7d-smegw01 # Storopack i.MX7D SMEGW01
- technexion,imx7d-pico-dwarf # TechNexion i.MX7D Pico-Dwarf
- technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit
- technexion,imx7d-pico-nymph # TechNexion i.MX7D Pico-Nymph
@@ -762,6 +814,7 @@ properties:
- enum:
- beacon,imx8mm-beacon-kit # i.MX8MM Beacon Development Kit
- boundary,imx8mm-nitrogen8mm # i.MX8MM Nitrogen Board
- dmo,imx8mm-data-modul-edm-sbc # i.MX8MM eDM SBC
- emtrion,emcon-mx8mm-avari # emCON-MX8MM SoM on Avari Base
- fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board
- fsl,imx8mm-evk # i.MX8MM EVK Board
@@ -772,6 +825,7 @@ properties:
- gw,imx8mm-gw7902 # i.MX8MM Gateworks Board
- gw,imx8mm-gw7903 # i.MX8MM Gateworks Board
- kontron,imx8mm-n801x-som # i.MX8MM Kontron SL (N801X) SOM
- menlo,mx8menlo # i.MX8MM Menlo board with Verdin SoM
- toradex,verdin-imx8mm # Verdin iMX8M Mini Modules
- toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Modules without Wi-Fi / BT
- toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Modules
@@ -834,6 +888,7 @@ properties:
- beacon,imx8mn-beacon-kit # i.MX8MN Beacon Development Kit
- bsh,imx8mn-bsh-smm-s2 # i.MX8MN BSH SystemMaster S2
- bsh,imx8mn-bsh-smm-s2pro # i.MX8MN BSH SystemMaster S2 PRO
- fsl,imx8mn-ddr3l-evk # i.MX8MN DDR3L EVK Board
- fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board
- fsl,imx8mn-evk # i.MX8MN LPDDR4 EVK Board
- gw,imx8mn-gw7902 # i.MX8MM Gateworks Board
@@ -860,6 +915,17 @@ properties:
items:
- enum:
- fsl,imx8mp-evk # i.MX8MP EVK Board
- gateworks,imx8mp-gw74xx # i.MX8MP Gateworks Board
- toradex,verdin-imx8mp # Verdin iMX8M Plus Modules
- toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Modules without Wi-Fi / BT
- toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Modules
- const: fsl,imx8mp
- description: Engicam i.Core MX8M Plus SoM based boards
items:
- enum:
- engicam,icore-mx8mp-edimm2.2 # i.MX8MP Engicam i.Core MX8M Plus EDIMM2.2 Starter Kit
- const: engicam,icore-mx8mp # i.MX8MP Engicam i.Core MX8M Plus SoM
- const: fsl,imx8mp
- description: PHYTEC phyCORE-i.MX8MP SoM based boards
@@ -868,6 +934,24 @@ properties:
- const: phytec,imx8mp-phycore-som # phyCORE-i.MX8MP SoM
- const: fsl,imx8mp
- description: Toradex Boards with Verdin iMX8M Plus Modules
items:
- enum:
- toradex,verdin-imx8mp-nonwifi-dahlia # Verdin iMX8M Plus Module on Dahlia
- toradex,verdin-imx8mp-nonwifi-dev # Verdin iMX8M Plus Module on Verdin Development Board
- const: toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Module without Wi-Fi / BT
- const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
- const: fsl,imx8mp
- description: Toradex Boards with Verdin iMX8M Plus Wi-Fi / BT Modules
items:
- enum:
- toradex,verdin-imx8mp-wifi-dahlia # Verdin iMX8M Plus Wi-Fi / BT Module on Dahlia
- toradex,verdin-imx8mp-wifi-dev # Verdin iMX8M Plus Wi-Fi / BT M. on Verdin Development B.
- const: toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Module
- const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
- const: fsl,imx8mp
- description: i.MX8MQ based Boards
items:
- enum:
@@ -999,6 +1083,7 @@ properties:
- description: LS1021A based Boards
items:
- enum:
- fsl,ls1021a-iot
- fsl,ls1021a-moxa-uc-8410a
- fsl,ls1021a-qds
- fsl,ls1021a-tsn

5
Documentation/devicetree/bindings/arm/hisilicon/controller/hip04-bootwrapper.yaml
View File

@@ -17,14 +17,15 @@ properties:
- const: hisilicon,hip04-bootwrapper
boot-method:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Address and size of boot method.
[0]: bootwrapper physical address
[1]: bootwrapper size
[2]: relocation physical address
[3]: relocation size
minItems: 1
maxItems: 2
minItems: 2
maxItems: 4
required:
- compatible

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

5
Documentation/devicetree/bindings/arm/mediatek.yaml
View File

@@ -133,6 +133,11 @@ properties:
- const: mediatek,mt8183
- items:
- enum:
- mediatek,mt8192-evb
- const: mediatek,mt8192
- items:
- enum:
- mediatek,mt8195-demo
- mediatek,mt8195-evb
- const: mediatek,mt8195
- description: Google Burnet (HP Chromebook x360 11MK G3 EE)

35
Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
View File

@@ -1,35 +0,0 @@
Mediatek apmixedsys controller
==============================
The Mediatek apmixedsys controller provides the PLLs to the system.
Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-apmixedsys"
- "mediatek,mt2712-apmixedsys", "syscon"
- "mediatek,mt6765-apmixedsys", "syscon"
- "mediatek,mt6779-apmixedsys", "syscon"
- "mediatek,mt6797-apmixedsys"
- "mediatek,mt7622-apmixedsys"
- "mediatek,mt7623-apmixedsys", "mediatek,mt2701-apmixedsys"
- "mediatek,mt7629-apmixedsys"
- "mediatek,mt7986-apmixedsys"
- "mediatek,mt8135-apmixedsys"
- "mediatek,mt8167-apmixedsys", "syscon"
- "mediatek,mt8173-apmixedsys"
- "mediatek,mt8183-apmixedsys", "syscon"
- "mediatek,mt8516-apmixedsys"
- #clock-cells: Must be 1
The apmixedsys controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
Example:
apmixedsys: clock-controller@10209000 {
compatible = "mediatek,mt8173-apmixedsys";
reg = <0 0x10209000 0 0x1000>;
#clock-cells = <1>;
};

42
Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
View File

@@ -1,42 +0,0 @@
Mediatek infracfg controller
============================
The Mediatek infracfg controller provides various clocks and reset
outputs to the system.
Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-infracfg", "syscon"
- "mediatek,mt2712-infracfg", "syscon"
- "mediatek,mt6765-infracfg", "syscon"
- "mediatek,mt6779-infracfg_ao", "syscon"
- "mediatek,mt6797-infracfg", "syscon"
- "mediatek,mt7622-infracfg", "syscon"
- "mediatek,mt7623-infracfg", "mediatek,mt2701-infracfg", "syscon"
- "mediatek,mt7629-infracfg", "syscon"
- "mediatek,mt7986-infracfg", "syscon"
- "mediatek,mt8135-infracfg", "syscon"
- "mediatek,mt8167-infracfg", "syscon"
- "mediatek,mt8173-infracfg", "syscon"
- "mediatek,mt8183-infracfg", "syscon"
- "mediatek,mt8516-infracfg", "syscon"
- #clock-cells: Must be 1
- #reset-cells: Must be 1
The infracfg controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
Also it uses the common reset controller binding from
Documentation/devicetree/bindings/reset/reset.txt.
The available reset outputs are defined in
dt-bindings/reset/mt*-resets.h
Example:
infracfg: power-controller@10001000 {
compatible = "mediatek,mt8173-infracfg", "syscon";
reg = <0 0x10001000 0 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};

81
Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml Normal file
View File

@@ -0,0 +1,81 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MediaTek Infrastructure System Configuration Controller
maintainers:
- Matthias Brugger <matthias.bgg@gmail.com>
description:
The Mediatek infracfg controller provides various clocks and reset outputs
to the system. The clock values can be found in <dt-bindings/clock/mt*-clk.h>,
and reset values in <dt-bindings/reset/mt*-reset.h> and
<dt-bindings/reset/mt*-resets.h>.
properties:
compatible:
oneOf:
- items:
- enum:
- mediatek,mt2701-infracfg
- mediatek,mt2712-infracfg
- mediatek,mt6765-infracfg
- mediatek,mt6779-infracfg_ao
- mediatek,mt6797-infracfg
- mediatek,mt7622-infracfg
- mediatek,mt7629-infracfg
- mediatek,mt7986-infracfg
- mediatek,mt8135-infracfg
- mediatek,mt8167-infracfg
- mediatek,mt8173-infracfg
- mediatek,mt8183-infracfg
- mediatek,mt8516-infracfg
- const: syscon
- items:
- const: mediatek,mt7623-infracfg
- const: mediatek,mt2701-infracfg
- const: syscon
reg:
maxItems: 1
'#clock-cells':
const: 1
'#reset-cells':
const: 1
required:
- compatible
- reg
- '#clock-cells'
if:
properties:
compatible:
contains:
enum:
- mediatek,mt2701-infracfg
- mediatek,mt2712-infracfg
- mediatek,mt7622-infracfg
- mediatek,mt7986-infracfg
- mediatek,mt8135-infracfg
- mediatek,mt8173-infracfg
- mediatek,mt8183-infracfg
then:
required:
- '#reset-cells'
additionalProperties: false
examples:
- |
infracfg: clock-controller@10001000 {
compatible = "mediatek,mt8173-infracfg", "syscon";
reg = <0x10001000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};

32
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
View File

@@ -31,6 +31,7 @@ properties:
- mediatek,mt8183-mmsys
- mediatek,mt8186-mmsys
- mediatek,mt8192-mmsys
- mediatek,mt8195-mmsys
- mediatek,mt8365-mmsys
- const: syscon
- items:
@@ -41,6 +42,30 @@ properties:
reg:
maxItems: 1
power-domains:
description:
A phandle and PM domain specifier as defined by bindings
of the power controller specified by phandle. See
Documentation/devicetree/bindings/power/power-domain.yaml for details.
mboxes:
description:
Using mailbox to communicate with GCE, it should have this
property and list of phandle, mailbox specifiers. See
Documentation/devicetree/bindings/mailbox/mtk-gce.txt for details.
$ref: /schemas/types.yaml#/definitions/phandle-array
mediatek,gce-client-reg:
description:
The register of client driver can be configured by gce with 4 arguments
defined in this property, such as phandle of gce, subsys id,
register offset and size.
Each subsys id is mapping to a base address of display function blocks
register which is defined in the gce header
include/dt-bindings/gce/<chip>-gce.h.
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
"#clock-cells":
const: 1
@@ -56,9 +81,16 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/power/mt8173-power.h>
#include <dt-bindings/gce/mt8173-gce.h>
mmsys: syscon@14000000 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0x14000000 0x1000>;
power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
#clock-cells = <1>;
#reset-cells = <1>;
mboxes = <&gce 0 CMDQ_THR_PRIO_HIGHEST>,
<&gce 1 CMDQ_THR_PRIO_HIGHEST>;
mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0 0x1000>;
};

42
Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml Normal file
View File

@@ -0,0 +1,42 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MediaTek PCIE Mirror Controller for MT7622
maintainers:
- Lorenzo Bianconi <lorenzo@kernel.org>
- Felix Fietkau <nbd@nbd.name>
description:
The mediatek PCIE mirror provides a configuration interface for PCIE
controller on MT7622 soc.
properties:
compatible:
items:
- enum:
- mediatek,mt7622-pcie-mirror
- const: syscon
reg:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
soc {
#address-cells = <2>;
#size-cells = <2>;
pcie_mirror: pcie-mirror@10000400 {
compatible = "mediatek,mt7622-pcie-mirror", "syscon";
reg = <0 0x10000400 0 0x10>;
};
};

50
Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml Normal file
View File

@@ -0,0 +1,50 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-wed.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MediaTek Wireless Ethernet Dispatch Controller for MT7622
maintainers:
- Lorenzo Bianconi <lorenzo@kernel.org>
- Felix Fietkau <nbd@nbd.name>
description:
The mediatek wireless ethernet dispatch controller can be configured to
intercept and handle access to the WLAN DMA queues and PCIe interrupts
and implement hardware flow offloading from ethernet to WLAN.
properties:
compatible:
items:
- enum:
- mediatek,mt7622-wed
- const: syscon
reg:
maxItems: 1
interrupts:
maxItems: 1
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
soc {
#address-cells = <2>;
#size-cells = <2>;
wed0: wed@1020a000 {
compatible = "mediatek,mt7622-wed","syscon";
reg = <0 0x1020a000 0 0x1000>;
interrupts = <GIC_SPI 214 IRQ_TYPE_LEVEL_LOW>;
};
};

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>;
};

1
Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
View File

@@ -26,6 +26,7 @@ properties:
- mediatek,mt8135-pericfg
- mediatek,mt8173-pericfg
- mediatek,mt8183-pericfg
- mediatek,mt8195-pericfg
- mediatek,mt8516-pericfg
- const: syscon
- items:

35
Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
View File

@@ -1,35 +0,0 @@
Mediatek topckgen controller
============================
The Mediatek topckgen controller provides various clocks to the system.
Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-topckgen"
- "mediatek,mt2712-topckgen", "syscon"
- "mediatek,mt6765-topckgen", "syscon"
- "mediatek,mt6779-topckgen", "syscon"
- "mediatek,mt6797-topckgen"
- "mediatek,mt7622-topckgen"
- "mediatek,mt7623-topckgen", "mediatek,mt2701-topckgen"
- "mediatek,mt7629-topckgen"
- "mediatek,mt7986-topckgen", "syscon"
- "mediatek,mt8135-topckgen"
- "mediatek,mt8167-topckgen", "syscon"
- "mediatek,mt8173-topckgen"
- "mediatek,mt8183-topckgen", "syscon"
- "mediatek,mt8516-topckgen"
- #clock-cells: Must be 1
The topckgen controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
Example:
topckgen: power-controller@10000000 {
compatible = "mediatek,mt8173-topckgen";
reg = <0 0x10000000 0 0x1000>;
#clock-cells = <1>;
};

2
Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
View File

@@ -23,6 +23,8 @@ properties:
enum:
- qcom,sc7180-llcc
- qcom,sc7280-llcc
- qcom,sc8180x-llcc
- qcom,sc8280xp-llcc
- qcom,sdm845-llcc
- qcom,sm6350-llcc
- qcom,sm8150-llcc

7
Documentation/devicetree/bindings/arm/omap/prcm.txt
View File

@@ -31,12 +31,17 @@ Required properties:
(base address and length)
- clocks: clocks for this module
- clockdomains: clockdomains for this module
- #clock-cells: From common clock binding
- clock-output-names: From common clock binding
Example:
cm: cm@48004000 {
cm: clock@48004000 {
compatible = "ti,omap3-cm";
reg = <0x48004000 0x4000>;
#clock-cells = <0>;
clock-output-names = "cm";
cm_clocks: clocks {
#address-cells = <1>;

21
Documentation/devicetree/bindings/arm/qcom.yaml
View File

@@ -39,8 +39,11 @@ description: |
msm8994
msm8996
sa8155p
sa8540p
sc7180
sc7280
sc8180x
sc8280xp
sdm630
sdm632
sdm660
@@ -99,6 +102,7 @@ properties:
- items:
- enum:
- asus,sparrow
- lg,lenok
- const: qcom,apq8026
@@ -225,6 +229,18 @@ properties:
- google,senor
- const: qcom,sc7280
- items:
- enum:
- lenovo,flex-5g
- microsoft,surface-prox
- qcom,sc8180x-primus
- const: qcom,sc8180x
- items:
- enum:
- qcom,sc8280xp-qrd
- const: qcom,sc8280xp
- items:
- enum:
- fairphone,fp3
@@ -258,6 +274,11 @@ properties:
- qcom,sa8155p-adp
- const: qcom,sa8155p
- items:
- enum:
- qcom,sa8295p-adp
- const: qcom,sa8540p
- items:
- enum:
- fairphone,fp4

20
Documentation/devicetree/bindings/arm/renesas.yaml
View File

@@ -327,6 +327,18 @@ properties:
- const: renesas,spider-cpu
- const: renesas,r8a779f0
- description: R-Car V4H (R8A779G0)
items:
- enum:
- renesas,white-hawk-cpu # White Hawk CPU board (RTP8A779G0ASKB0FC0SA000)
- const: renesas,r8a779g0
- items:
- enum:
- renesas,white-hawk-breakout # White Hawk BreakOut board (RTP8A779G0ASKB0SB0SA000)
- const: renesas,white-hawk-cpu
- const: renesas,r8a779g0
- description: R-Car H3e (R8A779M0)
items:
- enum:
@@ -405,6 +417,8 @@ properties:
- description: RZ/G2UL (R9A07G043)
items:
- enum:
- renesas,smarc-evk # SMARC EVK
- enum:
- renesas,r9a07g043u11 # RZ/G2UL Type-1
- renesas,r9a07g043u12 # RZ/G2UL Type-2
@@ -430,6 +444,12 @@ properties:
- renesas,r9a07g054l2 # Dual Cortex-A55 RZ/V2L
- const: renesas,r9a07g054
- description: RZ/V2M (R9A09G011)
items:
- enum:
- renesas,rzv2mevk2 # RZ/V2M Eval Board v2.0
- const: renesas,r9a09g011
additionalProperties: true
...

23
Documentation/devicetree/bindings/arm/rockchip.yaml
View File

@@ -133,6 +133,11 @@ properties:
- firefly,roc-rk3399-pc-plus
- const: rockchip,rk3399
- description: Firefly Station M2
items:
- const: firefly,rk3566-roc-pc
- const: rockchip,rk3566
- description: FriendlyElec NanoPi R2S
items:
- const: friendlyarm,nanopi-r2s
@@ -502,9 +507,18 @@ properties:
- const: pine64,rockpro64
- const: rockchip,rk3399
- description: Pine64 Quartz64 Model A
- description: Pine64 Quartz64 Model A/B
items:
- const: pine64,quartz64-a
- enum:
- pine64,quartz64-a
- pine64,quartz64-b
- const: rockchip,rk3566
- description: Pine64 SoQuartz SoM
items:
- enum:
- pine64,soquartz-cm4io
- const: pine64,soquartz
- const: rockchip,rk3566
- description: Radxa Rock
@@ -545,6 +559,11 @@ properties:
- const: radxa,rock2-square
- const: rockchip,rk3288
- description: Radxa ROCK3 Model A
items:
- const: radxa,rock3a
- const: rockchip,rk3568
- description: Rikomagic MK808 v1
items:
- const: rikomagic,mk808

46
Documentation/devicetree/bindings/arm/sp810.txt
View File

@@ -1,46 +0,0 @@
SP810 System Controller
-----------------------
Required properties:
- compatible: standard compatible string for a Primecell peripheral,
see Documentation/devicetree/bindings/arm/primecell.yaml
for more details
should be: "arm,sp810", "arm,primecell"
- reg: standard registers property, physical address and size
of the control registers
- clock-names: from the common clock bindings, for more details see
Documentation/devicetree/bindings/clock/clock-bindings.txt;
should be: "refclk", "timclk", "apb_pclk"
- clocks: from the common clock bindings, phandle and clock
specifier pairs for the entries of clock-names property
- #clock-cells: from the common clock bindings;
should be: <1>
- clock-output-names: from the common clock bindings;
should be: "timerclken0", "timerclken1", "timerclken2", "timerclken3"
- assigned-clocks: from the common clock binding;
should be: clock specifier for each output clock of this
provider node
- assigned-clock-parents: from the common clock binding;
should be: phandle of input clock listed in clocks
property with the highest frequency
Example:
v2m_sysctl: sysctl@20000 {
compatible = "arm,sp810", "arm,primecell";
reg = <0x020000 0x1000>;
clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&smbclk>;
clock-names = "refclk", "timclk", "apb_pclk";
#clock-cells = <1>;
clock-output-names = "timerclken0", "timerclken1", "timerclken2", "timerclken3";
assigned-clocks = <&v2m_sysctl 0>, <&v2m_sysctl 1>, <&v2m_sysctl 3>, <&v2m_sysctl 3>;
assigned-clock-parents = <&v2m_refclk1mhz>, <&v2m_refclk1mhz>, <&v2m_refclk1mhz>, <&v2m_refclk1mhz>;
};

80
Documentation/devicetree/bindings/arm/sp810.yaml Normal file
View File

@@ -0,0 +1,80 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/sp810.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Express SP810 System Controller bindings
maintainers:
- Andre Przywara <andre.przywara@arm.com>
description:
The Arm SP810 system controller provides clocks, timers and a watchdog.
# We need a select here so we don't match all nodes with 'arm,primecell'
select:
properties:
compatible:
contains:
const: arm,sp810
required:
- compatible
properties:
compatible:
items:
- const: arm,sp810
- const: arm,primecell
reg:
maxItems: 1
clock-names:
items:
- const: refclk
- const: timclk
- const: apb_pclk
clocks:
items:
- description: reference clock
- description: timer clock
- description: APB register access clock
"#clock-cells":
const: 1
clock-output-names:
maxItems: 4
assigned-clocks:
maxItems: 4
assigned-clock-parents:
maxItems: 4
additionalProperties: false
required:
- compatible
- reg
- clocks
- clock-names
- "#clock-cells"
examples:
- |
sysctl@20000 {
compatible = "arm,sp810", "arm,primecell";
reg = <0x020000 0x1000>;
clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&smbclk>;
clock-names = "refclk", "timclk", "apb_pclk";
#clock-cells = <1>;
clock-output-names = "timerclken0", "timerclken1",
"timerclken2", "timerclken3";
assigned-clocks = <&v2m_sysctl 0>, <&v2m_sysctl 1>,
<&v2m_sysctl 3>, <&v2m_sysctl 3>;
assigned-clock-parents = <&v2m_refclk1mhz>, <&v2m_refclk1mhz>,
<&v2m_refclk1mhz>, <&v2m_refclk1mhz>;
};

20
Documentation/devicetree/bindings/arm/spe-pmu.txt
View File

@@ -1,20 +0,0 @@
* ARMv8.2 Statistical Profiling Extension (SPE) Performance Monitor Units (PMU)
ARMv8.2 introduces the optional Statistical Profiling Extension for collecting
performance sample data using an in-memory trace buffer.
** SPE Required properties:
- compatible : should be one of:
"arm,statistical-profiling-extension-v1"
- interrupts : Exactly 1 PPI must be listed. For heterogeneous systems where
SPE is only supported on a subset of the CPUs, please consult
the arm,gic-v3 binding for details on describing a PPI partition.
** Example:
spe-pmu {
compatible = "arm,statistical-profiling-extension-v1";
interrupts = <GIC_PPI 05 IRQ_TYPE_LEVEL_HIGH &part1>;
};

63
Documentation/devicetree/bindings/arm/stm32/stm32.yaml
View File

@@ -14,21 +14,6 @@ properties:
const: "/"
compatible:
oneOf:
- description: DH STM32MP1 SoM based Boards
items:
- enum:
- arrow,stm32mp157a-avenger96 # Avenger96
- dh,stm32mp153c-dhcom-drc02
- dh,stm32mp157c-dhcom-pdk2
- dh,stm32mp157c-dhcom-picoitx
- enum:
- dh,stm32mp153c-dhcom-som
- dh,stm32mp157a-dhcor-som
- dh,stm32mp157c-dhcom-som
- enum:
- st,stm32mp153
- st,stm32mp157
- description: emtrion STM32MP1 Argon based Boards
items:
- const: emtrion,stm32mp157c-emsbc-argon
@@ -65,6 +50,21 @@ properties:
- enum:
- st,stm32mp135f-dk
- const: st,stm32mp135
- description: ST STM32MP151 based Boards
items:
- enum:
- prt,prtt1a # Protonic PRTT1A
- prt,prtt1c # Protonic PRTT1C
- prt,prtt1s # Protonic PRTT1S
- const: st,stm32mp151
- description: DH STM32MP153 SoM based Boards
items:
- const: dh,stm32mp153c-dhcom-drc02
- const: dh,stm32mp153c-dhcom-som
- const: st,stm32mp153
- items:
- enum:
- shiratech,stm32mp157a-iot-box # IoT Box
@@ -72,12 +72,44 @@ properties:
- st,stm32mp157c-ed1
- st,stm32mp157a-dk1
- st,stm32mp157c-dk2
- const: st,stm32mp157
- items:
- const: st,stm32mp157a-dk1-scmi
- const: st,stm32mp157a-dk1
- const: st,stm32mp157
- items:
- const: st,stm32mp157c-dk2-scmi
- const: st,stm32mp157c-dk2
- const: st,stm32mp157
- items:
- const: st,stm32mp157c-ed1-scmi
- const: st,stm32mp157c-ed1
- const: st,stm32mp157
- items:
- const: st,stm32mp157c-ev1
- const: st,stm32mp157c-ed1
- const: st,stm32mp157
- items:
- const: st,stm32mp157c-ev1-scmi
- const: st,stm32mp157c-ev1
- const: st,stm32mp157c-ed1
- const: st,stm32mp157
- description: DH STM32MP1 SoM based Boards
items:
- enum:
- arrow,stm32mp157a-avenger96 # Avenger96
- const: dh,stm32mp157a-dhcor-som
- const: st,stm32mp157
- description: DH STM32MP1 SoM based Boards
items:
- enum:
- dh,stm32mp157c-dhcom-pdk2
- dh,stm32mp157c-dhcom-picoitx
- const: dh,stm32mp157c-dhcom-som
- const: st,stm32mp157
- description: Engicam i.Core STM32MP1 SoM based Boards
items:
@@ -103,6 +135,7 @@ properties:
- const: oct,stm32mp15xx-osd32
- enum:
- st,stm32mp157
- description: Odyssey STM32MP1 SoM based Boards
items:
- enum:

5
Documentation/devicetree/bindings/arm/sunxi.yaml
View File

@@ -391,6 +391,11 @@ properties:
- const: libretech,all-h5-cc-h5
- const: allwinner,sun50i-h5
- description: Lichee Pi Nano
items:
- const: licheepi,licheepi-nano
- const: allwinner,suniv-f1c100s
- description: Lichee Pi One
items:
- const: licheepi,licheepi-one

4
Documentation/devicetree/bindings/arm/syna.txt
View File

@@ -18,10 +18,6 @@ stable binding/ABI.
---------------------------------------------------------------
Boards with the Synaptics AS370 SoC shall have the following properties:
Required root node property:
compatible: "syna,as370"
Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500
shall have the following properties:

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";
};

5
Documentation/devicetree/bindings/arm/ux500.yaml
View File

@@ -40,6 +40,11 @@ properties:
- const: samsung,codina
- const: st-ericsson,u8500
- description: Samsung Galaxy Exhibit (SGH-T599)
items:
- const: samsung,codina-tmo
- const: st-ericsson,u8500
- description: Samsung Galaxy Beam (GT-I8530)
items:
- const: samsung,gavini

285
Documentation/devicetree/bindings/arm/vexpress-config.yaml Normal file
View File

@@ -0,0 +1,285 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/vexpress-config.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Express configuration bus bindings
maintainers:
- Andre Przywara <andre.przywara@arm.com>
description:
This is a system control register block, acting as a bridge to the
platform's configuration bus via "system control" interface, addressing
devices with site number, position in the board stack, config controller,
function and device numbers - see motherboard's TRM for more details.
properties:
compatible:
const: arm,vexpress,config-bus
arm,vexpress,config-bridge:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the sysreg node.
muxfpga:
type: object
properties:
compatible:
const: arm,vexpress-muxfpga
arm,vexpress-sysreg,func:
description: FPGA specifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 7
- description: device number
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
shutdown:
type: object
properties:
compatible:
const: arm,vexpress-shutdown
arm,vexpress-sysreg,func:
description: shutdown identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 8
- description: device number
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
reboot:
type: object
properties:
compatible:
const: arm,vexpress-reboot
arm,vexpress-sysreg,func:
description: reboot identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 9
- description: device number
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
dvimode:
type: object
properties:
compatible:
const: arm,vexpress-dvimode
arm,vexpress-sysreg,func:
description: DVI mode identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 11
- description: device number
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
additionalProperties: false
required:
- compatible
- arm,vexpress,config-bridge
patternProperties:
'clk[0-9]*$':
type: object
description:
clocks
properties:
compatible:
const: arm,vexpress-osc
arm,vexpress-sysreg,func:
description: clock specifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 1
- description: clock number
freq-range:
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- description: minimal clock frequency
- description: maximum clock frequency
"#clock-cells":
const: 0
clock-output-names:
maxItems: 1
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
- "#clock-cells"
"^volt-.+$":
$ref: /schemas/regulator/regulator.yaml#
properties:
compatible:
const: arm,vexpress-volt
arm,vexpress-sysreg,func:
description: regulator specifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 2
- description: device number
label:
maxItems: 1
unevaluatedProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
"^amp-.+$":
type: object
properties:
compatible:
const: arm,vexpress-amp
arm,vexpress-sysreg,func:
description: current sensor identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 3
- description: device number
label:
maxItems: 1
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
"^temp-.+$":
type: object
properties:
compatible:
const: arm,vexpress-temp
arm,vexpress-sysreg,func:
description: temperature sensor identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 4
- description: device number
label:
maxItems: 1
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
"^reset[0-9]*$":
type: object
properties:
compatible:
const: arm,vexpress-reset
arm,vexpress-sysreg,func:
description: reset specifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 5
- description: reset device number
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
"^power-.+$":
type: object
properties:
compatible:
const: arm,vexpress-power
arm,vexpress-sysreg,func:
description: power sensor identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 12
- description: device number
label:
maxItems: 1
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
"^energy(-.+)?$":
type: object
properties:
compatible:
const: arm,vexpress-energy
arm,vexpress-sysreg,func:
description: energy sensor identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
oneOf:
- items:
- const: 13
- description: device number
- items:
- const: 13
- description: device number
- const: 13
- description: second device number
label:
maxItems: 1
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
examples:
- |
mcc {
compatible = "arm,vexpress,config-bus";
arm,vexpress,config-bridge = <&v2m_sysreg>;
clk0 {
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 0>;
#clock-cells = <0>;
};
energy {
compatible = "arm,vexpress-energy";
arm,vexpress-sysreg,func = <13 0>, <13 1>;
};
};

103
Documentation/devicetree/bindings/arm/vexpress-sysreg.txt
View File

@@ -1,103 +0,0 @@
ARM Versatile Express system registers
--------------------------------------
This is a system control registers block, providing multiple low level
platform functions like board detection and identification, software
interrupt generation, MMC and NOR Flash control etc.
Required node properties:
- compatible value : = "arm,vexpress,sysreg";
- reg : physical base address and the size of the registers window
Deprecated properties, replaced by GPIO subnodes (see below):
- gpio-controller : specifies that the node is a GPIO controller
- #gpio-cells : size of the GPIO specifier, should be 2:
- first cell is the pseudo-GPIO line number:
0 - MMC CARDIN
1 - MMC WPROT
2 - NOR FLASH WPn
- second cell can take standard GPIO flags (currently ignored).
Control registers providing pseudo-GPIO lines must be represented
by subnodes, each of them requiring the following properties:
- compatible value : one of
"arm,vexpress-sysreg,sys_led"
"arm,vexpress-sysreg,sys_mci"
"arm,vexpress-sysreg,sys_flash"
- gpio-controller : makes the node a GPIO controller
- #gpio-cells : size of the GPIO specifier, must be 2:
- first cell is the function number:
- for sys_led : 0..7 = LED 0..7
- for sys_mci : 0 = MMC CARDIN, 1 = MMC WPROT
- for sys_flash : 0 = NOR FLASH WPn
- second cell can take standard GPIO flags (currently ignored).
Example:
v2m_sysreg: sysreg@10000000 {
compatible = "arm,vexpress-sysreg";
reg = <0x10000000 0x1000>;
v2m_led_gpios: sys_led@8 {
compatible = "arm,vexpress-sysreg,sys_led";
gpio-controller;
#gpio-cells = <2>;
};
v2m_mmc_gpios: sys_mci@48 {
compatible = "arm,vexpress-sysreg,sys_mci";
gpio-controller;
#gpio-cells = <2>;
};
v2m_flash_gpios: sys_flash@4c {
compatible = "arm,vexpress-sysreg,sys_flash";
gpio-controller;
#gpio-cells = <2>;
};
};
This block also can also act a bridge to the platform's configuration
bus via "system control" interface, addressing devices with site number,
position in the board stack, config controller, function and device
numbers - see motherboard's TRM for more details. All configuration
controller accessible via this interface must reference the sysreg
node via "arm,vexpress,config-bridge" phandle and define appropriate
topology properties - see main vexpress node documentation for more
details. Each child of such node describes one function and must
define the following properties:
- compatible value : must be one of (corresponding to the TRM):
"arm,vexpress-amp"
"arm,vexpress-dvimode"
"arm,vexpress-energy"
"arm,vexpress-muxfpga"
"arm,vexpress-osc"
"arm,vexpress-power"
"arm,vexpress-reboot"
"arm,vexpress-reset"
"arm,vexpress-scc"
"arm,vexpress-shutdown"
"arm,vexpress-temp"
"arm,vexpress-volt"
- arm,vexpress-sysreg,func : must contain a set of two cells long groups:
- first cell of each group defines the function number
(eg. 1 for clock generator, 2 for voltage regulators etc.)
- second cell of each group defines device number (eg. osc 0,
osc 1 etc.)
- some functions (eg. energy meter, with its 64 bit long counter)
are using more than one function/device number pair
Example:
mcc {
compatible = "arm,vexpress,config-bus";
arm,vexpress,config-bridge = <&v2m_sysreg>;
osc@0 {
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 0>;
};
energy@0 {
compatible = "arm,vexpress-energy";
arm,vexpress-sysreg,func = <13 0>, <13 1>;
};
};

90
Documentation/devicetree/bindings/arm/vexpress-sysreg.yaml Normal file
View File

@@ -0,0 +1,90 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/vexpress-sysreg.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Express system registers bindings
maintainers:
- Andre Przywara <andre.przywara@arm.com>
description:
This is a system control registers block, providing multiple low level
platform functions like board detection and identification, software
interrupt generation, MMC and NOR Flash control, etc.
properties:
compatible:
const: arm,vexpress-sysreg
reg:
maxItems: 1
"#address-cells":
const: 1
"#size-cells":
const: 1
ranges: true
additionalProperties: false
patternProperties:
'^gpio@[0-9a-f]+$':
type: object
additionalProperties: false
description:
GPIO children
properties:
compatible:
enum:
- arm,vexpress-sysreg,sys_led
- arm,vexpress-sysreg,sys_mci
- arm,vexpress-sysreg,sys_flash
gpio-controller: true
"#gpio-cells":
const: 2
description: |
The first cell is the function number:
for sys_led : 0..7 = LED 0..7
for sys_mci : 0 = MMC CARDIN, 1 = MMC WPROT
for sys_flash : 0 = NOR FLASH WPn
The second cell can take standard GPIO flags.
reg:
maxItems: 1
required:
- compatible
- reg
- gpio-controller
- "#gpio-cells"
required:
- compatible
- "#address-cells"
- "#size-cells"
examples:
- |
sysreg@0 {
compatible = "arm,vexpress-sysreg";
reg = <0x00000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x1000>;
v2m_led_gpios: gpio@8 {
compatible = "arm,vexpress-sysreg,sys_led";
reg = <0x008 4>;
gpio-controller;
#gpio-cells = <2>;
};
};
...

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