Compare commits
154 commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
f54c5a81d5 | ||
|
|
c201f7d26b | ||
|
|
680f1d767f | ||
|
|
fd75235407 | ||
|
|
8d776b6bac | ||
|
|
173c4490d8 | ||
|
|
a7034253a6 | ||
|
|
a783ac0fc4 | ||
|
|
d004d65932 | ||
|
|
b9e6959f24 | ||
|
|
7006984173 | ||
|
|
81a6a3d1bf | ||
|
|
a49ab17ef3 | ||
|
|
8e7009c6a4 | ||
|
|
36188aab1f | ||
|
|
79b8204136 | ||
|
|
1d1e07f6b2 | ||
|
|
9d8a4cd664 | ||
|
|
318a800f50 | ||
|
|
fb500c1463 | ||
|
|
51a255f60c | ||
|
|
9543d37c57 | ||
|
|
1cc9b8629e | ||
|
|
aa70e83fb2 | ||
|
|
2f2877c67d | ||
|
|
1e8ea2a6f8 | ||
|
|
9be0b9b432 | ||
|
|
36a4f8b5ab | ||
|
|
9d74954c83 | ||
|
|
375e601b0f | ||
|
|
14240e555b | ||
|
|
3b731c58f7 | ||
|
|
32955e5311 | ||
|
|
e6fe8a2939 | ||
|
|
a9d8059e3b | ||
|
|
bd3638e5f0 | ||
|
|
e5c0aa04db | ||
|
|
bb71e33188 | ||
|
|
c049527d36 | ||
|
|
0dae5b9129 | ||
|
|
528a4b5597 | ||
|
|
f971394e75 | ||
|
|
a4158002db | ||
|
|
85f736137c | ||
|
|
89dc9c799f | ||
|
|
9127f7a0d2 | ||
|
|
073b2ec6c5 | ||
|
|
ab0646be5b | ||
|
|
cc6ae8f741 | ||
|
|
b35fa76ebe | ||
|
|
a93aa446f0 | ||
|
|
8c162c7b1d | ||
|
|
6446c2488c | ||
|
|
2404fb068e | ||
|
|
24031dc19e | ||
|
|
fca28b5db3 | ||
|
|
7c7e9fa734 | ||
|
|
c9d78cf41e | ||
|
|
95a3ce8e8d | ||
|
|
1078cd7bd2 | ||
|
|
c7a4d28052 | ||
|
|
781749a1d5 | ||
|
|
b3ed1c0268 | ||
|
|
8c70dec901 | ||
|
|
66839f23bc | ||
|
|
ba9b32de5c | ||
|
|
82d44416f3 | ||
|
|
3cfa2d8875 | ||
|
|
f705e0eaf0 | ||
|
|
fd25347f1d | ||
|
|
4056ae0297 | ||
|
|
e816b8fe88 | ||
|
|
3ff7a942b0 | ||
|
|
22b8d2d562 | ||
|
|
834ad221c2 | ||
|
|
6aa60af1f4 | ||
|
|
86e498bd27 | ||
|
|
7a76735a1a | ||
|
|
bdc340aad6 | ||
|
|
325f8f089c | ||
|
|
b6c62f87c2 | ||
|
|
b82d6a0281 | ||
|
|
12f9b8d9f0 | ||
|
|
ff3115b481 | ||
|
|
f0a8b6e89a | ||
|
|
a26d1cd582 | ||
|
|
2f3388b57f | ||
|
|
b6058d4b69 | ||
|
|
116e690ea9 | ||
|
|
0a29c0b89a | ||
|
|
4bce98942e | ||
|
|
1831d80a62 | ||
|
|
3d14a424f6 | ||
|
|
2e4e748dfb | ||
|
|
8be99e829f | ||
|
|
6efcd7b899 | ||
|
|
7e06fc2d18 | ||
|
|
2b8f96aa93 | ||
|
|
e0d2636522 | ||
|
|
aca5fb15f3 | ||
|
|
9581fa8de1 | ||
|
|
99c850a614 | ||
|
|
91e8d0a7e3 | ||
|
|
133ad65952 | ||
|
|
92f004b0d6 | ||
|
|
145a93bd75 | ||
|
|
c46a614b94 | ||
|
|
7e8c1242b9 | ||
|
|
e9876801a4 | ||
|
|
135f4581f9 | ||
|
|
e69696c619 | ||
|
|
074aaa8473 | ||
|
|
f54f240f0e | ||
|
|
be43e65b09 | ||
|
|
b054c98322 | ||
|
|
4892231a0b | ||
|
|
03528b4dc3 | ||
|
|
102e20cf5c | ||
|
|
d91a158c48 | ||
|
|
6ed7bb6ccb | ||
|
|
eb4cf9f26d | ||
|
|
13c726e975 | ||
|
|
d13bca386e | ||
|
|
64b3b43c82 | ||
|
|
3b742fd91f | ||
|
|
25a4d55178 | ||
|
|
aa37efa24a | ||
|
|
db192abed8 | ||
|
|
b30d89fb02 | ||
|
|
b674c37b7f | ||
|
|
59db3b27f9 | ||
|
|
4b558a6f1f | ||
|
|
736fe764a9 | ||
|
|
0e2dd49587 | ||
|
|
04c84d9bd6 | ||
|
|
796be4147b | ||
|
|
0eadc9da26 | ||
|
|
abe7a81ddb | ||
|
|
d8e6ee7aae | ||
|
|
002609b104 | ||
|
|
f7c470d02b | ||
|
|
8fe59fda3f | ||
|
|
9a1c992448 | ||
|
|
4825848801 | ||
|
|
0d6a88c0dd | ||
|
|
6577ea59d0 | ||
|
|
712bb69209 | ||
|
|
4a5043f59c | ||
|
|
634f4b6e01 | ||
|
|
4e202034f9 | ||
|
|
7819576b3a | ||
|
|
04e0752bfc | ||
|
|
19299a38ca | ||
|
|
64131e0549 |
28442 changed files with 758251 additions and 3062787 deletions
219
.clang-format
219
.clang-format
|
|
@ -1,6 +1,6 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
#
|
||||
# clang-format configuration file. Intended for clang-format >= 11.
|
||||
# clang-format configuration file. Intended for clang-format >= 4.
|
||||
#
|
||||
# For more information, see:
|
||||
#
|
||||
|
|
@ -13,7 +13,7 @@ AccessModifierOffset: -4
|
|||
AlignAfterOpenBracket: Align
|
||||
AlignConsecutiveAssignments: false
|
||||
AlignConsecutiveDeclarations: false
|
||||
AlignEscapedNewlines: Left
|
||||
#AlignEscapedNewlines: Left # Unknown to clang-format-4.0
|
||||
AlignOperands: true
|
||||
AlignTrailingComments: false
|
||||
AllowAllParametersOfDeclarationOnNextLine: false
|
||||
|
|
@ -37,24 +37,24 @@ BraceWrapping:
|
|||
AfterObjCDeclaration: false
|
||||
AfterStruct: false
|
||||
AfterUnion: false
|
||||
AfterExternBlock: false
|
||||
#AfterExternBlock: false # Unknown to clang-format-5.0
|
||||
BeforeCatch: false
|
||||
BeforeElse: false
|
||||
IndentBraces: false
|
||||
SplitEmptyFunction: true
|
||||
SplitEmptyRecord: true
|
||||
SplitEmptyNamespace: true
|
||||
#SplitEmptyFunction: true # Unknown to clang-format-4.0
|
||||
#SplitEmptyRecord: true # Unknown to clang-format-4.0
|
||||
#SplitEmptyNamespace: true # Unknown to clang-format-4.0
|
||||
BreakBeforeBinaryOperators: None
|
||||
BreakBeforeBraces: Custom
|
||||
BreakBeforeInheritanceComma: false
|
||||
#BreakBeforeInheritanceComma: false # Unknown to clang-format-4.0
|
||||
BreakBeforeTernaryOperators: false
|
||||
BreakConstructorInitializersBeforeComma: false
|
||||
BreakConstructorInitializers: BeforeComma
|
||||
#BreakConstructorInitializers: BeforeComma # Unknown to clang-format-4.0
|
||||
BreakAfterJavaFieldAnnotations: false
|
||||
BreakStringLiterals: false
|
||||
ColumnLimit: 80
|
||||
CommentPragmas: '^ IWYU pragma:'
|
||||
CompactNamespaces: false
|
||||
#CompactNamespaces: false # Unknown to clang-format-4.0
|
||||
ConstructorInitializerAllOnOneLineOrOnePerLine: false
|
||||
ConstructorInitializerIndentWidth: 8
|
||||
ContinuationIndentWidth: 8
|
||||
|
|
@ -62,56 +62,39 @@ Cpp11BracedListStyle: false
|
|||
DerivePointerAlignment: false
|
||||
DisableFormat: false
|
||||
ExperimentalAutoDetectBinPacking: false
|
||||
FixNamespaceComments: false
|
||||
#FixNamespaceComments: false # Unknown to clang-format-4.0
|
||||
|
||||
# Taken from:
|
||||
# git grep -h '^#define [^[:space:]]*for_each[^[:space:]]*(' include/ tools/ \
|
||||
# git grep -h '^#define [^[:space:]]*for_each[^[:space:]]*(' include/ \
|
||||
# | sed "s,^#define \([^[:space:]]*for_each[^[:space:]]*\)(.*$, - '\1'," \
|
||||
# | LC_ALL=C sort -u
|
||||
# | sort | uniq
|
||||
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'
|
||||
|
|
@ -119,7 +102,6 @@ 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'
|
||||
|
|
@ -127,22 +109,9 @@ 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'
|
||||
|
|
@ -166,25 +135,6 @@ 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'
|
||||
|
|
@ -192,11 +142,8 @@ 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'
|
||||
|
|
@ -212,22 +159,17 @@ 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'
|
||||
|
|
@ -237,14 +179,13 @@ 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'
|
||||
|
|
@ -253,35 +194,30 @@ 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_missing_reg'
|
||||
- 'for_each_msi_entry'
|
||||
- 'for_each_msi_entry_safe'
|
||||
- 'for_each_net'
|
||||
- 'for_each_net_continue_reverse'
|
||||
- 'for_each_net_rcu'
|
||||
- 'for_each_netdev'
|
||||
- 'for_each_netdev_continue'
|
||||
- 'for_each_netdev_continue_rcu'
|
||||
|
|
@ -291,13 +227,12 @@ 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'
|
||||
|
|
@ -313,20 +248,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'
|
||||
|
|
@ -334,7 +269,6 @@ 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'
|
||||
|
|
@ -344,8 +278,6 @@ 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'
|
||||
|
|
@ -355,12 +287,8 @@ 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'
|
||||
|
|
@ -369,25 +297,18 @@ 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_sublist'
|
||||
- 'for_each_subsystem'
|
||||
- 'for_each_supported_activate_fn'
|
||||
- 'for_each_supported_inject_fn'
|
||||
- 'for_each_test'
|
||||
- '__for_each_thread'
|
||||
- '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'
|
||||
|
|
@ -401,13 +322,7 @@ 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'
|
||||
|
|
@ -423,6 +338,7 @@ 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'
|
||||
|
|
@ -430,6 +346,9 @@ 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'
|
||||
|
|
@ -437,12 +356,7 @@ 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'
|
||||
|
|
@ -453,9 +367,7 @@ 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'
|
||||
|
|
@ -475,7 +387,6 @@ 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'
|
||||
|
|
@ -483,18 +394,11 @@ 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'
|
||||
|
|
@ -516,24 +420,9 @@ ForEachMacros:
|
|||
- 'of_property_for_each_string'
|
||||
- 'of_property_for_each_u32'
|
||||
- 'pci_bus_for_each_resource'
|
||||
- 'pci_doe_for_each_off'
|
||||
- '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'
|
||||
|
|
@ -553,7 +442,6 @@ 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'
|
||||
|
|
@ -567,18 +455,15 @@ 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'
|
||||
|
|
@ -595,13 +480,7 @@ 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'
|
||||
|
|
@ -625,17 +504,15 @@ 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
|
||||
#IncludeBlocks: Preserve # Unknown to clang-format-5.0
|
||||
IncludeCategories:
|
||||
- Regex: '.*'
|
||||
Priority: 1
|
||||
IncludeIsMainRegex: '(Test)?$'
|
||||
IndentCaseLabels: false
|
||||
IndentGotoLabels: false
|
||||
IndentPPDirectives: None
|
||||
#IndentPPDirectives: None # Unknown to clang-format-5.0
|
||||
IndentWidth: 8
|
||||
IndentWrappedFunctionNames: false
|
||||
JavaScriptQuotes: Leave
|
||||
|
|
@ -645,13 +522,13 @@ MacroBlockBegin: ''
|
|||
MacroBlockEnd: ''
|
||||
MaxEmptyLinesToKeep: 1
|
||||
NamespaceIndentation: None
|
||||
ObjCBinPackProtocolList: Auto
|
||||
#ObjCBinPackProtocolList: Auto # Unknown to clang-format-5.0
|
||||
ObjCBlockIndentWidth: 8
|
||||
ObjCSpaceAfterProperty: true
|
||||
ObjCSpaceBeforeProtocolList: true
|
||||
|
||||
# Taken from git's rules
|
||||
PenaltyBreakAssignment: 10
|
||||
#PenaltyBreakAssignment: 10 # Unknown to clang-format-4.0
|
||||
PenaltyBreakBeforeFirstCallParameter: 30
|
||||
PenaltyBreakComment: 10
|
||||
PenaltyBreakFirstLessLess: 0
|
||||
|
|
@ -662,14 +539,14 @@ PenaltyReturnTypeOnItsOwnLine: 60
|
|||
PointerAlignment: Right
|
||||
ReflowComments: false
|
||||
SortIncludes: false
|
||||
SortUsingDeclarations: false
|
||||
#SortUsingDeclarations: false # Unknown to clang-format-4.0
|
||||
SpaceAfterCStyleCast: false
|
||||
SpaceAfterTemplateKeyword: true
|
||||
SpaceBeforeAssignmentOperators: true
|
||||
SpaceBeforeCtorInitializerColon: true
|
||||
SpaceBeforeInheritanceColon: true
|
||||
SpaceBeforeParens: ControlStatementsExceptForEachMacros
|
||||
SpaceBeforeRangeBasedForLoopColon: 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
|
||||
SpaceInEmptyParentheses: false
|
||||
SpacesBeforeTrailingComments: 1
|
||||
SpacesInAngles: false
|
||||
|
|
|
|||
|
|
@ -1,4 +1,2 @@
|
|||
Alan Cox <alan@lxorguk.ukuu.org.uk>
|
||||
Alan Cox <root@hraefn.swansea.linux.org.uk>
|
||||
Christoph Hellwig <hch@lst.de>
|
||||
Marc Gonzalez <marc.w.gonzalez@free.fr>
|
||||
|
|
|
|||
7
.gitignore
vendored
7
.gitignore
vendored
|
|
@ -37,8 +37,6 @@
|
|||
*.o
|
||||
*.o.*
|
||||
*.patch
|
||||
*.rmeta
|
||||
*.rsi
|
||||
*.s
|
||||
*.so
|
||||
*.so.dbg
|
||||
|
|
@ -47,7 +45,6 @@
|
|||
*.symversions
|
||||
*.tab.[ch]
|
||||
*.tar
|
||||
*.usyms
|
||||
*.xz
|
||||
*.zst
|
||||
Module.symvers
|
||||
|
|
@ -99,7 +96,6 @@ modules.order
|
|||
!.gitattributes
|
||||
!.gitignore
|
||||
!.mailmap
|
||||
!.rustfmt.toml
|
||||
|
||||
#
|
||||
# Generated include files
|
||||
|
|
@ -165,6 +161,3 @@ x509.genkey
|
|||
|
||||
# Documentation toolchain
|
||||
sphinx_*/
|
||||
|
||||
# Rust analyzer configuration
|
||||
/rust-project.json
|
||||
|
|
|
|||
37
.mailmap
37
.mailmap
|
|
@ -10,8 +10,6 @@
|
|||
# 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>
|
||||
|
|
@ -60,20 +58,10 @@ Arnd Bergmann <arnd@arndb.de>
|
|||
Atish Patra <atishp@atishpatra.org> <atish.patra@wdc.com>
|
||||
Axel Dyks <xl@xlsigned.net>
|
||||
Axel Lin <axel.lin@gmail.com>
|
||||
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@linaro.org>
|
||||
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@spreadtrum.com>
|
||||
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@unisoc.com>
|
||||
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang7@gmail.com>
|
||||
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@sandisk.com>
|
||||
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
|
||||
Ben Gardner <bgardner@wabtec.com>
|
||||
Ben M Cahill <ben.m.cahill@intel.com>
|
||||
Ben Widawsky <bwidawsk@kernel.org> <ben@bwidawsk.net>
|
||||
Ben Widawsky <bwidawsk@kernel.org> <ben.widawsky@intel.com>
|
||||
Ben Widawsky <bwidawsk@kernel.org> <benjamin.widawsky@intel.com>
|
||||
Bjorn Andersson <andersson@kernel.org> <bjorn@kryo.se>
|
||||
Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@linaro.org>
|
||||
Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@sonymobile.com>
|
||||
Björn Steinbrink <B.Steinbrink@gmx.de>
|
||||
Björn Töpel <bjorn@kernel.org> <bjorn.topel@gmail.com>
|
||||
Björn Töpel <bjorn@kernel.org> <bjorn.topel@intel.com>
|
||||
|
|
@ -81,7 +69,6 @@ Boris Brezillon <bbrezillon@kernel.org> <b.brezillon.dev@gmail.com>
|
|||
Boris Brezillon <bbrezillon@kernel.org> <b.brezillon@overkiz.com>
|
||||
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@bootlin.com>
|
||||
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@free-electrons.com>
|
||||
Brendan Higgins <brendan.higgins@linux.dev> <brendanhiggins@google.com>
|
||||
Brian Avery <b.avery@hp.com>
|
||||
Brian King <brking@us.ibm.com>
|
||||
Brian Silverman <bsilver16384@gmail.com> <brian.silverman@bluerivertech.com>
|
||||
|
|
@ -98,13 +85,12 @@ 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.i.king@gmail.com> <colin.king@canonical.com>
|
||||
Colin Ian King <colin.king@intel.com> <colin.king@canonical.com>
|
||||
Colin Ian King <colin.king@intel.com> <colin.i.king@gmail.com>
|
||||
Corey Minyard <minyard@acm.org>
|
||||
Damian Hobson-Garcia <dhobsong@igel.co.jp>
|
||||
Dan Carpenter <error27@gmail.com> <dan.carpenter@oracle.com>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@googlemail.com>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@iogearbox.net>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <daniel.borkmann@tik.ee.ethz.ch>
|
||||
|
|
@ -138,14 +124,11 @@ Filipe Lautert <filipe@icewall.org>
|
|||
Finn Thain <fthain@linux-m68k.org> <fthain@telegraphics.com.au>
|
||||
Franck Bui-Huu <vagabon.xyz@gmail.com>
|
||||
Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com>
|
||||
Frank Rowand <frowand.list@gmail.com> <frank.rowand@sony.com>
|
||||
Frank Rowand <frowand.list@gmail.com> <frank.rowand@sonymobile.com>
|
||||
Frank Rowand <frowand.list@gmail.com> <frowand@mvista.com>
|
||||
Frank Zago <fzago@systemfabricworks.com>
|
||||
Gao Xiang <xiang@kernel.org> <gaoxiang25@huawei.com>
|
||||
Gao Xiang <xiang@kernel.org> <hsiangkao@aol.com>
|
||||
Gao Xiang <xiang@kernel.org> <hsiangkao@linux.alibaba.com>
|
||||
Gao Xiang <xiang@kernel.org> <hsiangkao@redhat.com>
|
||||
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <geraldsc@de.ibm.com>
|
||||
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <gerald.schaefer@de.ibm.com>
|
||||
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <geraldsc@linux.vnet.ibm.com>
|
||||
|
|
@ -154,8 +137,6 @@ Greg Kroah-Hartman <gregkh@suse.de>
|
|||
Greg Kroah-Hartman <greg@kroah.com>
|
||||
Greg Kurz <groug@kaod.org> <gkurz@linux.vnet.ibm.com>
|
||||
Gregory CLEMENT <gregory.clement@bootlin.com> <gregory.clement@free-electrons.com>
|
||||
Guilherme G. Piccoli <kernel@gpiccoli.net> <gpiccoli@linux.vnet.ibm.com>
|
||||
Guilherme G. Piccoli <kernel@gpiccoli.net> <gpiccoli@canonical.com>
|
||||
Guo Ren <guoren@kernel.org> <guoren@linux.alibaba.com>
|
||||
Guo Ren <guoren@kernel.org> <ren_guo@c-sky.com>
|
||||
Gustavo Padovan <gustavo@las.ic.unicamp.br>
|
||||
|
|
@ -184,7 +165,6 @@ 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>
|
||||
|
|
@ -221,8 +201,6 @@ 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>
|
||||
|
|
@ -237,7 +215,7 @@ Kees Cook <keescook@chromium.org> <kees@ubuntu.com>
|
|||
Keith Busch <kbusch@kernel.org> <keith.busch@intel.com>
|
||||
Keith Busch <kbusch@kernel.org> <keith.busch@linux.intel.com>
|
||||
Kenneth W Chen <kenneth.w.chen@intel.com>
|
||||
Kirill Tkhai <tkhai@ya.ru> <ktkhai@virtuozzo.com>
|
||||
Kirill Tkhai <kirill.tkhai@openvz.org> <ktkhai@virtuozzo.com>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
|
||||
Koushik <raghavendra.koushik@neterion.com>
|
||||
|
|
@ -258,8 +236,6 @@ 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>
|
||||
Luca Ceresoli <luca.ceresoli@bootlin.com> <luca@lucaceresoli.net>
|
||||
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>
|
||||
|
|
@ -320,7 +296,6 @@ Morten Welinder <welinder@troll.com>
|
|||
Mythri P K <mythripk@ti.com>
|
||||
Nadia Yvette Chambers <nyc@holomorphy.com> William Lee Irwin III <wli@holomorphy.com>
|
||||
Nathan Chancellor <nathan@kernel.org> <natechancellor@gmail.com>
|
||||
Neil Armstrong <neil.armstrong@linaro.org> <narmstrong@baylibre.com>
|
||||
Nguyen Anh Quynh <aquynh@gmail.com>
|
||||
Nicholas Piggin <npiggin@gmail.com> <npiggen@suse.de>
|
||||
Nicholas Piggin <npiggin@gmail.com> <npiggin@kernel.dk>
|
||||
|
|
@ -338,7 +313,6 @@ Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com>
|
|||
Oleksij Rempel <linux@rempel-privat.de> <fixed-term.Oleksij.Rempel@de.bosch.com>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <o.rempel@pengutronix.de>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <ore@pengutronix.de>
|
||||
Oliver Upton <oliver.upton@linux.dev> <oupton@google.com>
|
||||
Pali Rohár <pali@kernel.org> <pali.rohar@gmail.com>
|
||||
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
|
||||
Patrick Mochel <mochel@digitalimplant.org>
|
||||
|
|
@ -354,8 +328,7 @@ Peter Oruba <peter@oruba.de>
|
|||
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
|
||||
Praveen BP <praveenbp@ti.com>
|
||||
Punit Agrawal <punitagrawal@gmail.com> <punit.agrawal@arm.com>
|
||||
Qais Yousef <qyousef@layalina.io> <qais.yousef@imgtec.com>
|
||||
Qais Yousef <qyousef@layalina.io> <qais.yousef@arm.com>
|
||||
Qais Yousef <qsyousef@gmail.com> <qais.yousef@imgtec.com>
|
||||
Quentin Monnet <quentin@isovalent.com> <quentin.monnet@netronome.com>
|
||||
Quentin Perret <qperret@qperret.net> <quentin.perret@arm.com>
|
||||
Rafael J. Wysocki <rjw@rjwysocki.net> <rjw@sisk.pl>
|
||||
|
|
@ -388,7 +361,6 @@ Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk>
|
|||
Sebastian Reichel <sre@kernel.org> <sebastian.reichel@collabora.co.uk>
|
||||
Sebastian Reichel <sre@kernel.org> <sre@debian.org>
|
||||
Sedat Dilek <sedat.dilek@gmail.com> <sedat.dilek@credativ.de>
|
||||
Seth Forshee <sforshee@kernel.org> <seth.forshee@canonical.com>
|
||||
Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>
|
||||
Shuah Khan <shuah@kernel.org> <shuahkhan@gmail.com>
|
||||
Shuah Khan <shuah@kernel.org> <shuah.khan@hp.com>
|
||||
|
|
@ -426,7 +398,6 @@ Vasily Averin <vasily.averin@linux.dev> <vvs@virtuozzo.com>
|
|||
Vasily Averin <vasily.averin@linux.dev> <vvs@openvz.org>
|
||||
Vasily Averin <vasily.averin@linux.dev> <vvs@parallels.com>
|
||||
Vasily Averin <vasily.averin@linux.dev> <vvs@sw.ru>
|
||||
Valentin Schneider <vschneid@redhat.com> <valentin.schneider@arm.com>
|
||||
Vinod Koul <vkoul@kernel.org> <vinod.koul@intel.com>
|
||||
Vinod Koul <vkoul@kernel.org> <vinod.koul@linux.intel.com>
|
||||
Vinod Koul <vkoul@kernel.org> <vkoul@infradead.org>
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
edition = "2021"
|
||||
newline_style = "Unix"
|
||||
|
||||
# Unstable options that help catching some mistakes in formatting and that we may want to enable
|
||||
# when they become stable.
|
||||
#
|
||||
# They are kept here since they are useful to run from time to time.
|
||||
#format_code_in_doc_comments = true
|
||||
#reorder_impl_items = true
|
||||
#comment_width = 100
|
||||
#wrap_comments = true
|
||||
#normalize_comments = true
|
||||
8
CREDITS
8
CREDITS
|
|
@ -627,10 +627,6 @@ S: 48287 Sawleaf
|
|||
S: Fremont, California 94539
|
||||
S: USA
|
||||
|
||||
N: Tomas Cech
|
||||
E: sleep_walker@suse.com
|
||||
D: arm/palm treo support
|
||||
|
||||
N: Florent Chabaud
|
||||
E: florent.chabaud@polytechnique.org
|
||||
D: software suspend
|
||||
|
|
@ -3495,10 +3491,6 @@ D: wd33c93 SCSI driver (linux-m68k)
|
|||
S: San Jose, California
|
||||
S: USA
|
||||
|
||||
N: Joonyoung Shim
|
||||
E: y0922.shim@samsung.com
|
||||
D: Samsung Exynos DRM drivers
|
||||
|
||||
N: Robert Siemer
|
||||
E: Robert.Siemer@gmx.de
|
||||
P: 2048/C99A4289 2F DC 17 2E 56 62 01 C8 3D F2 AC 09 F2 E5 DD EE
|
||||
|
|
|
|||
|
|
@ -260,15 +260,6 @@ Description:
|
|||
for discards, and don't read this file.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/dma_alignment
|
||||
Date: May 2022
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
Reports the alignment that user space addresses must have to be
|
||||
used for raw block device access with O_DIRECT and other driver
|
||||
specific passthrough mechanisms.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/fua
|
||||
Date: May 2018
|
||||
Contact: linux-block@vger.kernel.org
|
||||
|
|
|
|||
|
|
@ -19,13 +19,3 @@ 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.
|
||||
|
|
|
|||
|
|
@ -227,17 +227,6 @@ Contact: dmaengine@vger.kernel.org
|
|||
Description: Indicate the number of retires for an enqcmds submission on a sharedwq.
|
||||
A max value to set attribute is capped at 64.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/op_config
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.0.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Shows the operation capability bits displayed in bitmap format
|
||||
presented by %*pb printk() output format specifier.
|
||||
The attribute can be configured when the WQ is disabled in
|
||||
order to configure the WQ to accept specific bits that
|
||||
correlates to the operations allowed. It's visible only
|
||||
on platforms that support the capability.
|
||||
|
||||
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
|
|
@ -266,27 +255,3 @@ Contact: dmaengine@vger.kernel.org
|
|||
Description: Indicates the number of Read Buffers reserved for the use of
|
||||
engines in the group. See DSA spec v1.2 9.2.18 GRPCFG Read Buffers
|
||||
Reserved.
|
||||
|
||||
What: /sys/bus/dsa/devices/group<m>.<n>/desc_progress_limit
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.0.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Allows control of the number of work descriptors that can be
|
||||
concurrently processed by an engine in the group as a fraction
|
||||
of the Maximum Work Descriptors in Progress value specified in
|
||||
the ENGCAP register. The acceptable values are 0 (default),
|
||||
1 (1/2 of max value), 2 (1/4 of the max value), and 3 (1/8 of
|
||||
the max value). It's visible only on platforms that support
|
||||
the capability.
|
||||
|
||||
What: /sys/bus/dsa/devices/group<m>.<n>/batch_progress_limit
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.0.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Allows control of the number of batch descriptors that can be
|
||||
concurrently processed by an engine in the group as a fraction
|
||||
of the Maximum Batch Descriptors in Progress value specified in
|
||||
the ENGCAP register. The acceptable values are 0 (default),
|
||||
1 (1/2 of max value), 2 (1/4 of the max value), and 3 (1/8 of
|
||||
the max value). It's visible only on platforms that support
|
||||
the capability.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic_health
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: This file shows ASIC health status. The possible values are:
|
||||
0 - health failed, 2 - health OK, 3 - ASIC in booting state.
|
||||
|
||||
|
|
@ -11,7 +11,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld1_version
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld2_version
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show with which CPLD versions have been burned
|
||||
on carrier and switch boards.
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ Description: These files show with which CPLD versions have been burned
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/fan_dir
|
||||
Date: December 2018
|
||||
KernelVersion: 5.0
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: This file shows the system fans direction:
|
||||
forward direction - relevant bit is set 0;
|
||||
reversed direction - relevant bit is set 1.
|
||||
|
|
@ -30,7 +30,7 @@ Description: This file shows the system fans direction:
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_version
|
||||
Date: November 2018
|
||||
KernelVersion: 5.0
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show with which CPLD versions have been burned
|
||||
on LED or Gearbox board.
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ Description: These files show with which CPLD versions have been burned
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/jtag_enable
|
||||
Date: November 2018
|
||||
KernelVersion: 5.0
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files enable and disable the access to the JTAG domain.
|
||||
By default access to the JTAG domain is disabled.
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ Description: These files enable and disable the access to the JTAG domain.
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/select_iio
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: This file allows iio devices selection.
|
||||
|
||||
Attribute select_iio can be written with 0 or with 1. It
|
||||
|
|
@ -62,7 +62,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu1_on
|
|||
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_down
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files allow asserting system power cycling, switching
|
||||
power supply units on and off and system's main power domain
|
||||
shutdown.
|
||||
|
|
@ -89,7 +89,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_short_pb
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_sw_reset
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show the system reset cause, as following: power
|
||||
auxiliary outage or power refresh, ASIC thermal shutdown, halt,
|
||||
hotswap, watchdog, firmware reset, long press power button,
|
||||
|
|
@ -106,7 +106,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_system
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_voltmon_upgrade_fail
|
||||
Date: November 2018
|
||||
KernelVersion: 5.0
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show the system reset cause, as following: ComEx
|
||||
power fail, reset from ComEx, system platform reset, reset
|
||||
due to voltage monitor devices upgrade failure,
|
||||
|
|
@ -119,7 +119,7 @@ Description: These files show the system reset cause, as following: ComEx
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_version
|
||||
Date: November 2018
|
||||
KernelVersion: 5.0
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show with which CPLD versions have been burned
|
||||
on LED board.
|
||||
|
||||
|
|
@ -133,7 +133,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_sff_wd
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_swb_wd
|
||||
Date: June 2019
|
||||
KernelVersion: 5.3
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show the system reset cause, as following:
|
||||
COMEX thermal shutdown; wathchdog power off or reset was derived
|
||||
by one of the next components: COMEX, switch board or by Small Form
|
||||
|
|
@ -148,7 +148,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/config1
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/config2
|
||||
Date: January 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show system static topology identification
|
||||
like system's static I2C topology, number and type of FPGA
|
||||
devices within the system and so on.
|
||||
|
|
@ -161,7 +161,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_soc
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_sw_pwr_off
|
||||
Date: January 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show the system reset causes, as following: reset
|
||||
due to AC power failure, reset invoked from software by
|
||||
assertion reset signal through CPLD. reset caused by signal
|
||||
|
|
@ -173,7 +173,7 @@ Description: These files show the system reset causes, as following: reset
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pcie_asic_reset_dis
|
||||
Date: January 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: This file allows to retain ASIC up during PCIe root complex
|
||||
reset, when attribute is set 1.
|
||||
|
||||
|
|
@ -182,7 +182,7 @@ Description: This file allows to retain ASIC up during PCIe root complex
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/vpd_wp
|
||||
Date: January 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: This file allows to overwrite system VPD hardware write
|
||||
protection when attribute is set 1.
|
||||
|
||||
|
|
@ -191,7 +191,7 @@ Description: This file allows to overwrite system VPD hardware write
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/voltreg_update_status
|
||||
Date: January 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: This file exposes the configuration update status of burnable
|
||||
voltage regulator devices. The status values are as following:
|
||||
0 - OK; 1 - CRC failure; 2 = I2C failure; 3 - in progress.
|
||||
|
|
@ -201,7 +201,7 @@ Description: This file exposes the configuration update status of burnable
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ufm_version
|
||||
Date: January 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: This file exposes the firmware version of burnable voltage
|
||||
regulator devices.
|
||||
|
||||
|
|
@ -217,7 +217,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_version_min
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_version_min
|
||||
Date: July 2020
|
||||
KernelVersion: 5.9
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show with which CPLD part numbers and minor
|
||||
versions have been burned CPLD devices equipped on a
|
||||
system.
|
||||
|
|
@ -467,78 +467,3 @@ Description: These files provide the maximum powered required for line card
|
|||
feeding and line card configuration Id.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/phy_reset
|
||||
Date: May 2022
|
||||
KernelVersion: 5.19
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file allows to reset PHY 88E1548 when attribute is set 0
|
||||
due to some abnormal PHY behavior.
|
||||
Expected behavior:
|
||||
When phy_reset is written 1, all PHY 88E1548 are released
|
||||
from the reset state, when 0 - are hold in reset state.
|
||||
|
||||
The files are read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/mac_reset
|
||||
Date: May 2022
|
||||
KernelVersion: 5.19
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file allows to reset ASIC MT52132 when attribute is set 0
|
||||
due to some abnormal ASIC behavior.
|
||||
Expected behavior:
|
||||
When mac_reset is written 1, the ASIC MT52132 is released
|
||||
from the reset state, when 0 - is hold in reset state.
|
||||
|
||||
The files are read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/qsfp_pwr_good
|
||||
Date: May 2022
|
||||
KernelVersion: 5.19
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file shows QSFP ports power status. The value is set to 0
|
||||
when one of any QSFP ports is plugged. The value is set to 1 when
|
||||
there are no any QSFP ports are plugged.
|
||||
The possible values are:
|
||||
0 - Power good, 1 - Not power good.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic2_health
|
||||
Date: July 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file shows 2-nd ASIC health status. The possible values are:
|
||||
0 - health failed, 2 - health OK, 3 - ASIC in booting state.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic_reset
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic2_reset
|
||||
Date: July 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files allow to each of ASICs by writing 1.
|
||||
|
||||
The files are write only.
|
||||
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/comm_chnl_ready
|
||||
Date: July 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file is used to indicate remote end (for example BMC) that system
|
||||
host CPU is ready for sending telemetry data to remote end.
|
||||
For indication the file should be written 1.
|
||||
|
||||
The file is write only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/config3
|
||||
Date: January 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: The file indicates COME module hardware configuration.
|
||||
The value is pushed by hardware through GPIO pins.
|
||||
The purpose is to expose some minor BOM changes for the same system SKU.
|
||||
|
||||
The file is read only.
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ What: /sys/module/<MODULENAME>/srcversion
|
|||
Date: Jun 2005
|
||||
Description:
|
||||
If the module source has MODULE_VERSION, this file will contain
|
||||
the checksum of the source code.
|
||||
the checksum of the the source code.
|
||||
|
||||
What: /sys/module/<MODULENAME>/version
|
||||
Date: Jun 2005
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ KernelVersion: 3.13
|
|||
Description:
|
||||
The attributes:
|
||||
|
||||
============ ==============================================
|
||||
=========== ==============================================
|
||||
file The path to the backing file for the LUN.
|
||||
Required if LUN is not marked as removable.
|
||||
ro Flag specifying access to the LUN shall be
|
||||
|
|
@ -32,10 +32,4 @@ Description:
|
|||
being a CD-ROM.
|
||||
nofua Flag specifying that FUA flag
|
||||
in SCSI WRITE(10,12)
|
||||
forced_eject This write-only file is useful only when
|
||||
the function is active. It causes the backing
|
||||
file to be forcibly detached from the LUN,
|
||||
regardless of whether the host has allowed it.
|
||||
Any non-zero number of bytes written will
|
||||
result in ejection.
|
||||
============ ==============================================
|
||||
=========== ==============================================
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@ 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
|
||||
|
|
|
|||
|
|
@ -54,25 +54,3 @@ Description:
|
|||
this feature.
|
||||
|
||||
Output will be in the format: "0x%08x\n".
|
||||
|
||||
What: /sys/kernel/debug/<cros-ec-device>/suspend_timeout_ms
|
||||
Date: August 2022
|
||||
KernelVersion: 6.1
|
||||
Description:
|
||||
Some ECs have a feature where they will track transitions of
|
||||
a hardware-controlled sleep line, such as Intel's SLP_S0 line,
|
||||
in order to detect cases where a system failed to go into deep
|
||||
sleep states. The suspend_timeout_ms file controls the amount of
|
||||
time in milliseconds the EC will wait before declaring a sleep
|
||||
timeout event and attempting to wake the system.
|
||||
|
||||
Supply 0 to use the default value coded into EC firmware. Supply
|
||||
65535 (EC_HOST_SLEEP_TIMEOUT_INFINITE) to disable the EC sleep
|
||||
failure detection mechanism. Values in between 0 and 65535
|
||||
indicate the number of milliseconds the EC should wait after a
|
||||
sleep transition before declaring a timeout. This includes both
|
||||
the duration after a sleep command was received but before the
|
||||
hardware line changed, as well as the duration between when the
|
||||
hardware line changed and the kernel sent an EC resume command.
|
||||
|
||||
Output will be in the format: "%u\n".
|
||||
|
|
|
|||
|
|
@ -101,15 +101,6 @@ Description: Specify the size of the DMA transaction when using DMA to read
|
|||
When the write is finished, the user can read the "data_dma"
|
||||
blob
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/dump_razwi_events
|
||||
Date: Aug 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: fkassabri@habana.ai
|
||||
Description: Dumps all razwi events to dmesg if exist.
|
||||
After reading the status register of an existing event
|
||||
the routine will clear the status register.
|
||||
Usage: cat dump_razwi_events
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/dump_security_violations
|
||||
Date: Jan 2021
|
||||
KernelVersion: 5.12
|
||||
|
|
@ -130,16 +121,14 @@ Date: Jan 2019
|
|||
KernelVersion: 5.1
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets I2C device address for I2C transaction that is generated
|
||||
by the device's CPU, Not available when device is loaded with secured
|
||||
firmware
|
||||
by the device's CPU
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_bus
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets I2C bus address for I2C transaction that is generated by
|
||||
the device's CPU, Not available when device is loaded with secured
|
||||
firmware
|
||||
the device's CPU
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_data
|
||||
Date: Jan 2019
|
||||
|
|
@ -147,60 +136,39 @@ KernelVersion: 5.1
|
|||
Contact: ogabbay@kernel.org
|
||||
Description: Triggers an I2C transaction that is generated by the device's
|
||||
CPU. Writing to this file generates a write transaction while
|
||||
reading from the file generates a read transaction, Not available
|
||||
when device is loaded with secured firmware
|
||||
reading from the file generates a read transaction
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_len
|
||||
Date: Dec 2021
|
||||
KernelVersion: 5.17
|
||||
Contact: obitton@habana.ai
|
||||
Description: Sets I2C length in bytes for I2C transaction that is generated by
|
||||
the device's CPU, Not available when device is loaded with secured
|
||||
firmware
|
||||
the device's CPU
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_reg
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets I2C register id for I2C transaction that is generated by
|
||||
the device's CPU, Not available when device is loaded with secured
|
||||
firmware
|
||||
the device's CPU
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/led0
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets the state of the first S/W led on the device, Not available
|
||||
when device is loaded with secured firmware
|
||||
Description: Sets the state of the first S/W led on the device
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/led1
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets the state of the second S/W led on the device, Not available
|
||||
when device is loaded with secured firmware
|
||||
Description: Sets the state of the second S/W led on the device
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/led2
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Sets the state of the third S/W led on the device, Not available
|
||||
when device is loaded with secured firmware
|
||||
|
||||
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 and
|
||||
the scrubbing value when using module param 'memory_scrub'
|
||||
Description: Sets the state of the third S/W led on the device
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/mmu
|
||||
Date: Jan 2019
|
||||
|
|
@ -222,30 +190,6 @@ 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
|
||||
|
|
@ -295,7 +239,7 @@ Description: Displays a list with information about the currently user
|
|||
to DMA addresses
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/userptr_lookup
|
||||
Date: Oct 2021
|
||||
Date: Aug 2021
|
||||
KernelVersion: 5.15
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Allows to search for specific user pointers (user virtual
|
||||
|
|
|
|||
|
|
@ -104,20 +104,6 @@ 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
|
||||
|
|
|
|||
|
|
@ -84,20 +84,6 @@ 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
|
||||
|
|
|
|||
|
|
@ -97,20 +97,6 @@ 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
|
||||
|
|
|
|||
|
|
@ -27,9 +27,8 @@ Description:
|
|||
[fowner=] [fgroup=]]
|
||||
lsm: [[subj_user=] [subj_role=] [subj_type=]
|
||||
[obj_user=] [obj_role=] [obj_type=]]
|
||||
option: [digest_type=] [template=] [permit_directio]
|
||||
[appraise_type=] [appraise_flag=]
|
||||
[appraise_algos=] [keyrings=]
|
||||
option: [[appraise_type=]] [template=] [permit_directio]
|
||||
[appraise_flag=] [appraise_algos=] [keyrings=]
|
||||
base:
|
||||
func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK]
|
||||
[FIRMWARE_CHECK]
|
||||
|
|
@ -48,21 +47,10 @@ Description:
|
|||
fgroup:= decimal value
|
||||
lsm: are LSM specific
|
||||
option:
|
||||
appraise_type:= [imasig] | [imasig|modsig] | [sigv3]
|
||||
where 'imasig' is the original or the signature
|
||||
format v2.
|
||||
where 'modsig' is an appended signature,
|
||||
where 'sigv3' is the signature format v3. (Currently
|
||||
limited to fsverity digest based signatures
|
||||
stored in security.ima xattr. Requires
|
||||
specifying "digest_type=verity" first.)
|
||||
|
||||
appraise_type:= [imasig] [imasig|modsig]
|
||||
appraise_flag:= [check_blacklist]
|
||||
Currently, blacklist check is only for files signed with appended
|
||||
signature.
|
||||
digest_type:= verity
|
||||
Require fs-verity's file digest instead of the
|
||||
regular IMA file hash.
|
||||
keyrings:= list of keyrings
|
||||
(eg, .builtin_trusted_keys|.ima). Only valid
|
||||
when action is "measure" and func is KEY_CHECK.
|
||||
|
|
@ -161,30 +149,3 @@ Description:
|
|||
security.ima xattr of a file:
|
||||
|
||||
appraise func=SETXATTR_CHECK appraise_algos=sha256,sha384,sha512
|
||||
|
||||
Example of a 'measure' rule requiring fs-verity's digests
|
||||
with indication of type of digest in the measurement list.
|
||||
|
||||
measure func=FILE_CHECK digest_type=verity \
|
||||
template=ima-ngv2
|
||||
|
||||
Example of 'measure' and 'appraise' rules requiring fs-verity
|
||||
signatures (format version 3) stored in security.ima xattr.
|
||||
|
||||
The 'measure' rule specifies the 'ima-sigv3' template option,
|
||||
which includes the indication of type of digest and the file
|
||||
signature in the measurement list.
|
||||
|
||||
measure func=BPRM_CHECK digest_type=verity \
|
||||
template=ima-sigv3
|
||||
|
||||
|
||||
The 'appraise' rule specifies the type and signature format
|
||||
version (sigv3) required.
|
||||
|
||||
appraise func=BPRM_CHECK digest_type=verity \
|
||||
appraise_type=sigv3
|
||||
|
||||
All of these policy rules could, for example, be constrained
|
||||
either based on a filesystem's UUID (fsuuid) or based on LSM
|
||||
labels.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,6 @@ Description:
|
|||
MMUPageSize: 4 kB
|
||||
Rss: 884 kB
|
||||
Pss: 385 kB
|
||||
Pss_Dirty: 68 kB
|
||||
Pss_Anon: 301 kB
|
||||
Pss_File: 80 kB
|
||||
Pss_Shmem: 4 kB
|
||||
|
|
|
|||
|
|
@ -1,51 +0,0 @@
|
|||
What: security/secrets/coco
|
||||
Date: February 2022
|
||||
Contact: Dov Murik <dovmurik@linux.ibm.com>
|
||||
Description:
|
||||
Exposes confidential computing (coco) EFI secrets to
|
||||
userspace via securityfs.
|
||||
|
||||
EFI can declare memory area used by confidential computing
|
||||
platforms (such as AMD SEV and SEV-ES) for secret injection by
|
||||
the Guest Owner during VM's launch. The secrets are encrypted
|
||||
by the Guest Owner and decrypted inside the trusted enclave,
|
||||
and therefore are not readable by the untrusted host.
|
||||
|
||||
The efi_secret module exposes the secrets to userspace. Each
|
||||
secret appears as a file under <securityfs>/secrets/coco,
|
||||
where the filename is the GUID of the entry in the secrets
|
||||
table. This module is loaded automatically by the EFI driver
|
||||
if the EFI secret area is populated.
|
||||
|
||||
Two operations are supported for the files: read and unlink.
|
||||
Reading the file returns the content of secret entry.
|
||||
Unlinking the file overwrites the secret data with zeroes and
|
||||
removes the entry from the filesystem. A secret cannot be read
|
||||
after it has been unlinked.
|
||||
|
||||
For example, listing the available secrets::
|
||||
|
||||
# modprobe efi_secret
|
||||
# ls -l /sys/kernel/security/secrets/coco
|
||||
-r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b
|
||||
-r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6
|
||||
-r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2
|
||||
-r--r----- 1 root root 0 Jun 28 11:54 e6f5a162-d67f-4750-a67c-5d065f2a9910
|
||||
|
||||
Reading the secret data by reading a file::
|
||||
|
||||
# cat /sys/kernel/security/secrets/coco/e6f5a162-d67f-4750-a67c-5d065f2a9910
|
||||
the-content-of-the-secret-data
|
||||
|
||||
Wiping a secret by unlinking a file::
|
||||
|
||||
# rm /sys/kernel/security/secrets/coco/e6f5a162-d67f-4750-a67c-5d065f2a9910
|
||||
# ls -l /sys/kernel/security/secrets/coco
|
||||
-r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b
|
||||
-r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6
|
||||
-r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2
|
||||
|
||||
Note: The binary format of the secrets table injected by the
|
||||
Guest Owner is described in
|
||||
drivers/virt/coco/efi_secret/efi_secret.c under "Structure of
|
||||
the EFI secret area".
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
What: /sys/bus/platform/drivers/amd_pmc/*/smu_fw_version
|
||||
Date: October 2022
|
||||
Contact: Mario Limonciello <mario.limonciello@amd.com>
|
||||
Description: Reading this file reports the version of the firmware loaded to
|
||||
System Management Unit (SMU) contained in AMD CPUs and
|
||||
APUs.
|
||||
|
||||
What: /sys/bus/platform/drivers/amd_pmc/*/smu_program
|
||||
Date: October 2022
|
||||
Contact: Mario Limonciello <mario.limonciello@amd.com>
|
||||
Description: Reading this file reports the program corresponding to the SMU
|
||||
firmware version. The program field is used to disambiguate two
|
||||
APU/CPU models that can share the same firmware binary.
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
What: /sys/devices/platform/*/cnqf_enable
|
||||
Date: September 2022
|
||||
Contact: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
|
||||
Description: Reading this file tells if the AMD Platform Management(PMF)
|
||||
Cool n Quiet Framework(CnQF) feature is enabled or not.
|
||||
|
||||
This feature is not enabled by default and gets only turned on
|
||||
if OEM BIOS passes a "flag" to PMF ACPI function (index 11 or 12)
|
||||
or in case the user writes "on".
|
||||
|
||||
To turn off CnQF user can write "off" to the sysfs node.
|
||||
Note: Systems that support auto mode will not have this sysfs file
|
||||
available.
|
||||
|
|
@ -107,14 +107,13 @@ Description:
|
|||
described in ATA8 7.16 and 7.17. Only valid if
|
||||
the device is not a PM.
|
||||
|
||||
pio_mode: (RO) PIO transfer mode used by the device.
|
||||
Mostly used by PATA devices.
|
||||
pio_mode: (RO) Transfer modes supported by the device when
|
||||
in PIO mode. Mostly used by PATA device.
|
||||
|
||||
xfer_mode: (RO) Current transfer mode. Mostly used by
|
||||
PATA devices.
|
||||
xfer_mode: (RO) Current transfer mode
|
||||
|
||||
dma_mode: (RO) DMA transfer mode used by the device.
|
||||
Mostly used by PATA devices.
|
||||
dma_mode: (RO) Transfer modes supported by the device when
|
||||
in DMA mode. Mostly used by PATA device.
|
||||
|
||||
class: (RO) Device class. Can be "ata" for disk,
|
||||
"atapi" for packet device, "pmp" for PM, or
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Date: May 2011
|
|||
KernelVersion: 3.0
|
||||
Contact: Rafał Miłecki <zajec5@gmail.com>
|
||||
Description:
|
||||
Each BCMA core has its manufacturer id. See
|
||||
Each BCMA core has it's manufacturer id. See
|
||||
include/linux/bcma/bcma.h for possible values.
|
||||
|
||||
What: /sys/bus/bcma/devices/.../id
|
||||
|
|
|
|||
|
|
@ -516,11 +516,3 @@ Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|||
Description: (Read) Returns the number of special conditional P1 right-hand keys
|
||||
that the trace unit can use (0x194). The value is taken
|
||||
directly from the HW.
|
||||
|
||||
What: /sys/bus/coresight/devices/etm<N>/ts_source
|
||||
Date: October 2022
|
||||
KernelVersion: 6.1
|
||||
Contact: Mathieu Poirier <mathieu.poirier@linaro.org> or Suzuki K Poulose <suzuki.poulose@arm.com>
|
||||
Description: (Read) When FEAT_TRF is implemented, value of TRFCR_ELx.TS used for
|
||||
trace session. Otherwise -1 indicates an unknown time source. Check
|
||||
trcidr0.tssize to see if a global timestamp is available.
|
||||
|
|
|
|||
|
|
@ -4,12 +4,6 @@ Contact: linux-iio@vger.kernel.org
|
|||
Description:
|
||||
Count data of Count Y represented as a string.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/countY/capture
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Historical capture of the Count Y count data.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/countY/ceiling
|
||||
KernelVersion: 5.2
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
|
|
@ -209,13 +203,6 @@ Description:
|
|||
both edges:
|
||||
Any state transition.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/countY/num_overflows
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
This attribute indicates the number of overflows of count Y.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/countY/capture_component_id
|
||||
What: /sys/bus/counter/devices/counterX/countY/ceiling_component_id
|
||||
What: /sys/bus/counter/devices/counterX/countY/floor_component_id
|
||||
What: /sys/bus/counter/devices/counterX/countY/count_mode_component_id
|
||||
|
|
@ -226,14 +213,11 @@ What: /sys/bus/counter/devices/counterX/countY/prescaler_component_id
|
|||
What: /sys/bus/counter/devices/counterX/countY/preset_component_id
|
||||
What: /sys/bus/counter/devices/counterX/countY/preset_enable_component_id
|
||||
What: /sys/bus/counter/devices/counterX/countY/signalZ_action_component_id
|
||||
What: /sys/bus/counter/devices/counterX/countY/num_overflows_component_id
|
||||
What: /sys/bus/counter/devices/counterX/signalY/cable_fault_component_id
|
||||
What: /sys/bus/counter/devices/counterX/signalY/cable_fault_enable_component_id
|
||||
What: /sys/bus/counter/devices/counterX/signalY/filter_clock_prescaler_component_id
|
||||
What: /sys/bus/counter/devices/counterX/signalY/index_polarity_component_id
|
||||
What: /sys/bus/counter/devices/counterX/signalY/polarity_component_id
|
||||
What: /sys/bus/counter/devices/counterX/signalY/synchronous_mode_component_id
|
||||
What: /sys/bus/counter/devices/counterX/signalY/frequency_component_id
|
||||
KernelVersion: 5.16
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
|
|
@ -319,19 +303,6 @@ Description:
|
|||
Discrete set of available values for the respective Signal Y
|
||||
configuration are listed in this file.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/signalY/polarity
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Active level of Signal Y. The following polarity values are
|
||||
available:
|
||||
|
||||
positive:
|
||||
Signal high state considered active level (rising edge).
|
||||
|
||||
negative:
|
||||
Signal low state considered active level (falling edge).
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/signalY/name
|
||||
KernelVersion: 5.2
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
|
|
@ -374,9 +345,3 @@ Description:
|
|||
via index_polarity. The index function (as enabled via
|
||||
preset_enable) is performed synchronously with the
|
||||
quadrature clock on the active level of the index input.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/signalY/frequency
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Read-only attribute that indicates the signal Y frequency, in Hz.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@ Description:
|
|||
all descendant memdevs for unbind. Writing '1' to this attribute
|
||||
flushes that work.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/memX/firmware_version
|
||||
Date: December, 2020
|
||||
KernelVersion: v5.12
|
||||
|
|
@ -17,7 +16,6 @@ Description:
|
|||
Memory Device Output Payload in the CXL-2.0
|
||||
specification.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/memX/ram/size
|
||||
Date: December, 2020
|
||||
KernelVersion: v5.12
|
||||
|
|
@ -27,7 +25,6 @@ Description:
|
|||
identically named field in the Identify Memory Device Output
|
||||
Payload in the CXL-2.0 specification.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/memX/pmem/size
|
||||
Date: December, 2020
|
||||
KernelVersion: v5.12
|
||||
|
|
@ -37,7 +34,6 @@ Description:
|
|||
identically named field in the Identify Memory Device Output
|
||||
Payload in the CXL-2.0 specification.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/memX/serial
|
||||
Date: January, 2022
|
||||
KernelVersion: v5.18
|
||||
|
|
@ -47,7 +43,6 @@ Description:
|
|||
capability. Mandatory for CXL devices, see CXL 2.0 8.1.12.2
|
||||
Memory Device PCIe Capabilities and Extended Capabilities.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/memX/numa_node
|
||||
Date: January, 2022
|
||||
KernelVersion: v5.18
|
||||
|
|
@ -57,334 +52,114 @@ Description:
|
|||
host PCI device for this memory device, emit the CPU node
|
||||
affinity for this device.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/*/devtype
|
||||
Date: June, 2021
|
||||
KernelVersion: v5.14
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) CXL device objects export the devtype attribute which
|
||||
mirrors the same value communicated in the DEVTYPE environment
|
||||
variable for uevents for devices on the "cxl" bus.
|
||||
|
||||
CXL device objects export the devtype attribute which mirrors
|
||||
the same value communicated in the DEVTYPE environment variable
|
||||
for uevents for devices on the "cxl" bus.
|
||||
|
||||
What: /sys/bus/cxl/devices/*/modalias
|
||||
Date: December, 2021
|
||||
KernelVersion: v5.18
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) CXL device objects export the modalias attribute which
|
||||
mirrors the same value communicated in the MODALIAS environment
|
||||
variable for uevents for devices on the "cxl" bus.
|
||||
|
||||
CXL device objects export the modalias attribute which mirrors
|
||||
the same value communicated in the MODALIAS environment variable
|
||||
for uevents for devices on the "cxl" bus.
|
||||
|
||||
What: /sys/bus/cxl/devices/portX/uport
|
||||
Date: June, 2021
|
||||
KernelVersion: v5.14
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) CXL port objects are enumerated from either a platform
|
||||
firmware device (ACPI0017 and ACPI0016) or PCIe switch upstream
|
||||
port with CXL component registers. The 'uport' symlink connects
|
||||
the CXL portX object to the device that published the CXL port
|
||||
CXL port objects are enumerated from either a platform firmware
|
||||
device (ACPI0017 and ACPI0016) or PCIe switch upstream port with
|
||||
CXL component registers. The 'uport' symlink connects the CXL
|
||||
portX object to the device that published the CXL port
|
||||
capability.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/portX/dportY
|
||||
Date: June, 2021
|
||||
KernelVersion: v5.14
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) CXL port objects are enumerated from either a platform
|
||||
firmware device (ACPI0017 and ACPI0016) or PCIe switch upstream
|
||||
port with CXL component registers. The 'dportY' symlink
|
||||
identifies one or more downstream ports that the upstream port
|
||||
may target in its decode of CXL memory resources. The 'Y'
|
||||
integer reflects the hardware port unique-id used in the
|
||||
hardware decoder target list.
|
||||
|
||||
CXL port objects are enumerated from either a platform firmware
|
||||
device (ACPI0017 and ACPI0016) or PCIe switch upstream port with
|
||||
CXL component registers. The 'dportY' symlink identifies one or
|
||||
more downstream ports that the upstream port may target in its
|
||||
decode of CXL memory resources. The 'Y' integer reflects the
|
||||
hardware port unique-id used in the hardware decoder target
|
||||
list.
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y
|
||||
Date: June, 2021
|
||||
KernelVersion: v5.14
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) CXL decoder objects are enumerated from either a platform
|
||||
CXL decoder objects are enumerated from either a platform
|
||||
firmware description, or a CXL HDM decoder register set in a
|
||||
PCIe device (see CXL 2.0 section 8.2.5.12 CXL HDM Decoder
|
||||
Capability Structure). The 'X' in decoderX.Y represents the
|
||||
cxl_port container of this decoder, and 'Y' represents the
|
||||
instance id of a given decoder resource.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y/{start,size}
|
||||
Date: June, 2021
|
||||
KernelVersion: v5.14
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) The 'start' and 'size' attributes together convey the
|
||||
physical address base and number of bytes mapped in the
|
||||
decoder's decode window. For decoders of devtype
|
||||
"cxl_decoder_root" the address range is fixed. For decoders of
|
||||
devtype "cxl_decoder_switch" the address is bounded by the
|
||||
decode range of the cxl_port ancestor of the decoder's cxl_port,
|
||||
and dynamically updates based on the active memory regions in
|
||||
that address space.
|
||||
|
||||
The 'start' and 'size' attributes together convey the physical
|
||||
address base and number of bytes mapped in the decoder's decode
|
||||
window. For decoders of devtype "cxl_decoder_root" the address
|
||||
range is fixed. For decoders of devtype "cxl_decoder_switch" the
|
||||
address is bounded by the decode range of the cxl_port ancestor
|
||||
of the decoder's cxl_port, and dynamically updates based on the
|
||||
active memory regions in that address space.
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y/locked
|
||||
Date: June, 2021
|
||||
KernelVersion: v5.14
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) CXL HDM decoders have the capability to lock the
|
||||
configuration until the next device reset. For decoders of
|
||||
devtype "cxl_decoder_root" there is no standard facility to
|
||||
unlock them. For decoders of devtype "cxl_decoder_switch" a
|
||||
secondary bus reset, of the PCIe bridge that provides the bus
|
||||
for this decoders uport, unlocks / resets the decoder.
|
||||
|
||||
CXL HDM decoders have the capability to lock the configuration
|
||||
until the next device reset. For decoders of devtype
|
||||
"cxl_decoder_root" there is no standard facility to unlock them.
|
||||
For decoders of devtype "cxl_decoder_switch" a secondary bus
|
||||
reset, of the PCIe bridge that provides the bus for this
|
||||
decoders uport, unlocks / resets the decoder.
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y/target_list
|
||||
Date: June, 2021
|
||||
KernelVersion: v5.14
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) Display a comma separated list of the current decoder
|
||||
target configuration. The list is ordered by the current
|
||||
configured interleave order of the decoder's dport instances.
|
||||
Each entry in the list is a dport id.
|
||||
|
||||
Display a comma separated list of the current decoder target
|
||||
configuration. The list is ordered by the current configured
|
||||
interleave order of the decoder's dport instances. Each entry in
|
||||
the list is a dport id.
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y/cap_{pmem,ram,type2,type3}
|
||||
Date: June, 2021
|
||||
KernelVersion: v5.14
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) When a CXL decoder is of devtype "cxl_decoder_root", it
|
||||
When a CXL decoder is of devtype "cxl_decoder_root", it
|
||||
represents a fixed memory window identified by platform
|
||||
firmware. A fixed window may only support a subset of memory
|
||||
types. The 'cap_*' attributes indicate whether persistent
|
||||
memory, volatile memory, accelerator memory, and / or expander
|
||||
memory may be mapped behind this decoder's memory window.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y/target_type
|
||||
Date: June, 2021
|
||||
KernelVersion: v5.14
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) When a CXL decoder is of devtype "cxl_decoder_switch", it
|
||||
can optionally decode either accelerator memory (type-2) or
|
||||
expander memory (type-3). The 'target_type' attribute indicates
|
||||
the current setting which may dynamically change based on what
|
||||
When a CXL decoder is of devtype "cxl_decoder_switch", it can
|
||||
optionally decode either accelerator memory (type-2) or expander
|
||||
memory (type-3). The 'target_type' attribute indicates the
|
||||
current setting which may dynamically change based on what
|
||||
memory regions are activated in this decode hierarchy.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/endpointX/CDAT
|
||||
Date: July, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) If this sysfs entry is not present no DOE mailbox was
|
||||
found to support CDAT data. If it is present and the length of
|
||||
the data is 0 reading the CDAT data failed. Otherwise the CDAT
|
||||
data is reported.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y/mode
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RW) When a CXL decoder is of devtype "cxl_decoder_endpoint" it
|
||||
translates from a host physical address range, to a device local
|
||||
address range. Device-local address ranges are further split
|
||||
into a 'ram' (volatile memory) range and 'pmem' (persistent
|
||||
memory) range. The 'mode' attribute emits one of 'ram', 'pmem',
|
||||
'mixed', or 'none'. The 'mixed' indication is for error cases
|
||||
when a decoder straddles the volatile/persistent partition
|
||||
boundary, and 'none' indicates the decoder is not actively
|
||||
decoding, or no DPA allocation policy has been set.
|
||||
|
||||
'mode' can be written, when the decoder is in the 'disabled'
|
||||
state, with either 'ram' or 'pmem' to set the boundaries for the
|
||||
next allocation.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y/dpa_resource
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) When a CXL decoder is of devtype "cxl_decoder_endpoint",
|
||||
and its 'dpa_size' attribute is non-zero, this attribute
|
||||
indicates the device physical address (DPA) base address of the
|
||||
allocation.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y/dpa_size
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RW) When a CXL decoder is of devtype "cxl_decoder_endpoint" it
|
||||
translates from a host physical address range, to a device local
|
||||
address range. The range, base address plus length in bytes, of
|
||||
DPA allocated to this decoder is conveyed in these 2 attributes.
|
||||
Allocations can be mutated as long as the decoder is in the
|
||||
disabled state. A write to 'dpa_size' releases the previous DPA
|
||||
allocation and then attempts to allocate from the free capacity
|
||||
in the device partition referred to by 'decoderX.Y/mode'.
|
||||
Allocate and free requests can only be performed on the highest
|
||||
instance number disabled decoder with non-zero size. I.e.
|
||||
allocations are enforced to occur in increasing 'decoderX.Y/id'
|
||||
order and frees are enforced to occur in decreasing
|
||||
'decoderX.Y/id' order.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y/interleave_ways
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) The number of targets across which this decoder's host
|
||||
physical address (HPA) memory range is interleaved. The device
|
||||
maps every Nth block of HPA (of size ==
|
||||
'interleave_granularity') to consecutive DPA addresses. The
|
||||
decoder's position in the interleave is determined by the
|
||||
device's (endpoint or switch) switch ancestry. For root
|
||||
decoders their interleave is specified by platform firmware and
|
||||
they only specify a downstream target order for host bridges.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y/interleave_granularity
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) The number of consecutive bytes of host physical address
|
||||
space this decoder claims at address N before the decode rotates
|
||||
to the next target in the interleave at address N +
|
||||
interleave_granularity (assuming N is aligned to
|
||||
interleave_granularity).
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y/create_pmem_region
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RW) Write a string in the form 'regionZ' to start the process
|
||||
of defining a new persistent memory region (interleave-set)
|
||||
within the decode range bounded by root decoder 'decoderX.Y'.
|
||||
The value written must match the current value returned from
|
||||
reading this attribute. An atomic compare exchange operation is
|
||||
done on write to assign the requested id to a region and
|
||||
allocate the region-id for the next creation attempt. EBUSY is
|
||||
returned if the region name written does not match the current
|
||||
cached value.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y/delete_region
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(WO) Write a string in the form 'regionZ' to delete that region,
|
||||
provided it is currently idle / not bound to a driver.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/regionZ/uuid
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RW) Write a unique identifier for the region. This field must
|
||||
be set for persistent regions and it must not conflict with the
|
||||
UUID of another region.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/regionZ/interleave_granularity
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RW) Set the number of consecutive bytes each device in the
|
||||
interleave set will claim. The possible interleave granularity
|
||||
values are determined by the CXL spec and the participating
|
||||
devices.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/regionZ/interleave_ways
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RW) Configures the number of devices participating in the
|
||||
region is set by writing this value. Each device will provide
|
||||
1/interleave_ways of storage for the region.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/regionZ/size
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RW) System physical address space to be consumed by the region.
|
||||
When written trigger the driver to allocate space out of the
|
||||
parent root decoder's address space. When read the size of the
|
||||
address space is reported and should match the span of the
|
||||
region's resource attribute. Size shall be set after the
|
||||
interleave configuration parameters. Once set it cannot be
|
||||
changed, only freed by writing 0. The kernel makes no guarantees
|
||||
that data is maintained over an address space freeing event, and
|
||||
there is no guarantee that a free followed by an allocate
|
||||
results in the same address being allocated.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/regionZ/resource
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) A region is a contiguous partition of a CXL root decoder
|
||||
address space. Region capacity is allocated by writing to the
|
||||
size attribute, the resulting physical address space determined
|
||||
by the driver is reflected here. It is therefore not useful to
|
||||
read this before writing a value to the size attribute.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/regionZ/target[0..N]
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RW) Write an endpoint decoder object name to 'targetX' where X
|
||||
is the intended position of the endpoint device in the region
|
||||
interleave and N is the 'interleave_ways' setting for the
|
||||
region. ENXIO is returned if the write results in an impossible
|
||||
to map decode scenario, like the endpoint is unreachable at that
|
||||
position relative to the root decoder interleave. EBUSY is
|
||||
returned if the position in the region is already occupied, or
|
||||
if the region is not in a state to accept interleave
|
||||
configuration changes. EINVAL is returned if the object name is
|
||||
not an endpoint decoder. Once all positions have been
|
||||
successfully written a final validation for decode conflicts is
|
||||
performed before activating the region.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/regionZ/commit
|
||||
Date: May, 2022
|
||||
KernelVersion: v5.20
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RW) Write a boolean 'true' string value to this attribute to
|
||||
trigger the region to transition from the software programmed
|
||||
state to the actively decoding in hardware state. The commit
|
||||
operation in addition to validating that the region is in proper
|
||||
configured state, validates that the decoders are being
|
||||
committed in spec mandated order (last committed decoder id +
|
||||
1), and checks that the hardware accepts the commit request.
|
||||
Reading this value indicates whether the region is committed or
|
||||
not.
|
||||
|
|
|
|||
|
|
@ -1,18 +0,0 @@
|
|||
What: /sys/bus/event_source/devices/<dev>/caps
|
||||
Date: May 2022
|
||||
KernelVersion: 5.19
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description:
|
||||
Attribute group to describe the capabilities exposed
|
||||
for a particular pmu. Each attribute of this group can
|
||||
expose information specific to a PMU, say pmu_name, so that
|
||||
userspace can understand some of the feature which the
|
||||
platform specific PMU supports.
|
||||
|
||||
One of the example available capability in supported platform
|
||||
like Intel is pmu_name, which exposes underlying CPU name known
|
||||
to the PMU driver.
|
||||
|
||||
Example output in powerpc:
|
||||
grep . /sys/bus/event_source/devices/cpu/caps/*
|
||||
/sys/bus/event_source/devices/cpu/caps/pmu_name:POWER9
|
||||
|
|
@ -31,7 +31,7 @@ Description: 'FCoE Controller' instances on the fcoe bus.
|
|||
1) Write interface name to ctlr_create 2) Configure the FCoE
|
||||
Controller (ctlr_X) 3) Enable the FCoE Controller to begin
|
||||
discovery and login. The FCoE Controller is destroyed by
|
||||
writing its name, i.e. ctlr_X to the ctlr_delete file.
|
||||
writing it's name, i.e. ctlr_X to the ctlr_delete file.
|
||||
|
||||
Attributes:
|
||||
|
||||
|
|
|
|||
|
|
@ -79,11 +79,6 @@ Description:
|
|||
* "accel-base"
|
||||
* "accel-display"
|
||||
|
||||
For devices where an accelerometer is housed in the swivel camera subassembly
|
||||
(for AR application), the following standardized label is used:
|
||||
|
||||
* "accel-camera"
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/current_timestamp_clock
|
||||
KernelVersion: 4.5
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
|
|
@ -107,9 +102,6 @@ Description:
|
|||
relevant directories. If it affects all of the above
|
||||
then it is to be found in the base device directory.
|
||||
|
||||
The stm32-timer-trigger has the additional characteristic that
|
||||
a sampling_frequency of 0 is defined to stop sampling.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/sampling_frequency_available
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_sampling_frequency_available
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_proximity_sampling_frequency_available
|
||||
|
|
@ -196,7 +188,7 @@ Description:
|
|||
Raw capacitance measurement from channel Y. Units after
|
||||
application of scale and offset are nanofarads.
|
||||
|
||||
What: /sys/.../iio:deviceX/in_capacitanceY-capacitanceZ_raw
|
||||
What: /sys/.../iio:deviceX/in_capacitanceY-in_capacitanceZ_raw
|
||||
KernelVersion: 3.2
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
|
|
@ -207,25 +199,6 @@ Description:
|
|||
is required is a consistent labeling. Units after application
|
||||
of scale and offset are nanofarads.
|
||||
|
||||
What: /sys/.../iio:deviceX/in_capacitanceY-capacitanceZ_zeropoint
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
For differential channels, this an offset that is applied
|
||||
equally to both inputs. As the reading is of the difference
|
||||
between the two inputs, this should not be applied to the _raw
|
||||
reading by userspace (unlike _offset) and unlike calibbias
|
||||
it does not affect the differential value measured because
|
||||
the effect of _zeropoint cancels out across the two inputs
|
||||
that make up the differential pair. It's purpose is to bring
|
||||
the individual signals, before the differential is measured,
|
||||
within the measurement range of the device. The naming is
|
||||
chosen because if the separate inputs that make the
|
||||
differential pair are drawn on a graph in their
|
||||
_raw units, this is the value that the zero point on the
|
||||
measurement axis represents. It is expressed with the
|
||||
same scaling as _raw.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_temp_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_tempX_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_temp_x_raw
|
||||
|
|
@ -260,15 +233,6 @@ Description:
|
|||
Has all of the equivalent parameters as per voltageY. Units
|
||||
after application of scale and offset are m/s^2.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_linear_x_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_linear_y_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_linear_z_raw
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
As per in_accel_X_raw attributes, but minus the
|
||||
acceleration due to gravity.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_gravity_x_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_gravity_y_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_gravity_z_raw
|
||||
|
|
@ -2066,99 +2030,3 @@ Description:
|
|||
Available range for the forced calibration value, expressed as:
|
||||
|
||||
- a range specified as "[min step max]"
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_voltageX_sampling_frequency
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_powerY_sampling_frequency
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_currentZ_sampling_frequency
|
||||
KernelVersion: 5.20
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Some devices have separate controls of sampling frequency for
|
||||
individual channels. If multiple channels are enabled in a scan,
|
||||
then the sampling_frequency of the scan may be computed from the
|
||||
per channel sampling frequencies.
|
||||
|
||||
What: /sys/.../events/in_accel_gesture_singletap_en
|
||||
What: /sys/.../events/in_accel_gesture_doubletap_en
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Device generates an event on a single or double tap.
|
||||
|
||||
What: /sys/.../events/in_accel_gesture_singletap_value
|
||||
What: /sys/.../events/in_accel_gesture_doubletap_value
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Specifies the threshold value that the device is comparing
|
||||
against to generate the tap gesture event. The lower
|
||||
threshold value increases the sensitivity of tap detection.
|
||||
Units and the exact meaning of value are device-specific.
|
||||
|
||||
What: /sys/.../events/in_accel_gesture_tap_value_available
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Lists all available threshold values which can be used to
|
||||
modify the sensitivity of the tap detection.
|
||||
|
||||
What: /sys/.../events/in_accel_gesture_singletap_reset_timeout
|
||||
What: /sys/.../events/in_accel_gesture_doubletap_reset_timeout
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Specifies the timeout value in seconds for the tap detector
|
||||
to not to look for another tap event after the event as
|
||||
occurred. Basically the minimum quiet time between the two
|
||||
single-tap's or two double-tap's.
|
||||
|
||||
What: /sys/.../events/in_accel_gesture_tap_reset_timeout_available
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Lists all available tap reset timeout values. Units in seconds.
|
||||
|
||||
What: /sys/.../events/in_accel_gesture_doubletap_tap2_min_delay
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Specifies the minimum quiet time in seconds between the two
|
||||
taps of a double tap.
|
||||
|
||||
What: /sys/.../events/in_accel_gesture_doubletap_tap2_min_delay_available
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Lists all available delay values between two taps in the double
|
||||
tap. Units in seconds.
|
||||
|
||||
What: /sys/.../events/in_accel_gesture_tap_maxtomin_time
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Specifies the maximum time difference allowed between upper
|
||||
and lower peak of tap to consider it as the valid tap event.
|
||||
Units in seconds.
|
||||
|
||||
What: /sys/.../events/in_accel_gesture_tap_maxtomin_time_available
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Lists all available time values between upper peak to lower
|
||||
peak. Units in seconds.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_rot_yaw_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_rot_pitch_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_rot_roll_raw
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw (unscaled) euler angles readings. Units after
|
||||
application of scale are deg.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/serialnumber
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
An example format is 16-bytes, 2-digits-per-byte, HEX-string
|
||||
representing the sensor unique ID number.
|
||||
|
|
|
|||
|
|
@ -1,81 +0,0 @@
|
|||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_raw_range
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw (unscaled) range for acceleration readings. Unit after
|
||||
application of scale is m/s^2. Note that this doesn't affects
|
||||
the scale (which should be used when changing the maximum and
|
||||
minimum readable value affects also the reading scaling factor).
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_raw_range
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Range for angular velocity readings in radians per second. Note
|
||||
that this does not affects the scale (which should be used when
|
||||
changing the maximum and minimum readable value affects also the
|
||||
reading scaling factor).
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_raw_range_available
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
List of allowed values for in_accel_raw_range attribute
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_raw_range_available
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
List of allowed values for in_anglvel_raw_range attribute
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_magn_calibration_fast_enable
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Can be 1 or 0. Enables/disables the "Fast Magnetometer
|
||||
Calibration" HW function.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/fusion_enable
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Can be 1 or 0. Enables/disables the "sensor fusion" (a.k.a.
|
||||
NDOF) HW function.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/calibration_data
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Reports the binary calibration data blob for the IMU sensors.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_calibration_auto_status
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Reports the autocalibration status for the accelerometer sensor.
|
||||
Can be 0 (calibration non even enabled) or 1 to 5 where the greater
|
||||
the number, the better the calibration status.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_gyro_calibration_auto_status
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Reports the autocalibration status for the gyroscope sensor.
|
||||
Can be 0 (calibration non even enabled) or 1 to 5 where the greater
|
||||
the number, the better the calibration status.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_magn_calibration_auto_status
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Reports the autocalibration status for the magnetometer sensor.
|
||||
Can be 0 (calibration non even enabled) or 1 to 5 where the greater
|
||||
the number, the better the calibration status.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/sys_calibration_auto_status
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Reports the status for the IMU overall autocalibration.
|
||||
Can be 0 (calibration non even enabled) or 1 to 5 where the greater
|
||||
the number, the better the calibration status.
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
What: /sys/.../iio:deviceX/in_capacitableY_calibbias_calibration
|
||||
What: /sys/.../iio:deviceX/in_capacitableY_calibscale_calibration
|
||||
KernelVersion: 6.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Write 1 to trigger a calibration of the calibbias or
|
||||
calibscale. For calibscale, a full scale capacitance should
|
||||
be connected to the capacitance input and a
|
||||
calibscale_calibration then started. For calibbias see
|
||||
the device datasheet section on "capacitive system offset
|
||||
calibration".
|
||||
|
|
@ -18,7 +18,7 @@ Description:
|
|||
on the signal from which time of flight measurements are
|
||||
taken.
|
||||
The appropriate values to take is dependent on both the
|
||||
sensor and its operating environment:
|
||||
sensor and it's operating environment:
|
||||
* as3935 (0-31 range)
|
||||
18 = indoors (default)
|
||||
14 = outdoors
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ Contact: Gwendal Grignou <gwendal@chromium.org>
|
|||
Description:
|
||||
SX9324 has 3 inputs, CS0, CS1 and CS2. Hardware layout
|
||||
defines if the input is
|
||||
|
||||
+ not connected (HZ),
|
||||
+ grounded (GD),
|
||||
+ connected to an antenna where it can act as a base
|
||||
|
|
|
|||
31
Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856
Normal file
31
Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
What: /sys/bus/iio/devices/iio:deviceX/fault_oc
|
||||
KernelVersion: 5.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Open-circuit fault. The detection of open-circuit faults,
|
||||
such as those caused by broken thermocouple wires.
|
||||
Reading returns either '1' or '0'.
|
||||
|
||||
=== =======================================================
|
||||
'1' An open circuit such as broken thermocouple wires
|
||||
has been detected.
|
||||
'0' No open circuit or broken thermocouple wires are detected
|
||||
=== =======================================================
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/fault_ovuv
|
||||
KernelVersion: 5.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Overvoltage or Undervoltage Input Fault. The internal circuitry
|
||||
is protected from excessive voltages applied to the thermocouple
|
||||
cables by integrated MOSFETs at the T+ and T- inputs, and the
|
||||
BIAS output. These MOSFETs turn off when the input voltage is
|
||||
negative or greater than VDD.
|
||||
|
||||
Reading returns either '1' or '0'.
|
||||
|
||||
=== =======================================================
|
||||
'1' The input voltage is negative or greater than VDD.
|
||||
'0' The input voltage is positive and less than VDD (normal
|
||||
state).
|
||||
=== =======================================================
|
||||
20
Documentation/ABI/testing/sysfs-bus-iio-temperature-max31865
Normal file
20
Documentation/ABI/testing/sysfs-bus-iio-temperature-max31865
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
What: /sys/bus/iio/devices/iio:deviceX/fault_ovuv
|
||||
KernelVersion: 5.11
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Overvoltage or Undervoltage Input fault. The internal circuitry
|
||||
is protected from excessive voltages applied to the thermocouple
|
||||
cables at FORCE+, FORCE2, RTDIN+ & RTDIN-. This circuitry turn
|
||||
off when the input voltage is negative or greater than VDD.
|
||||
|
||||
Reading returns '1' if input voltage is negative or greater
|
||||
than VDD, otherwise '0'.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_filter_notch_center_frequency
|
||||
KernelVersion: 5.11
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Notch frequency in Hz for a noise rejection filter. Used i.e for
|
||||
line noise rejection.
|
||||
|
||||
Valid notch filter values are 50 Hz and 60 Hz.
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
What: /sys/bus/iio/devices/iio:deviceX/fault_ovuv
|
||||
KernelVersion: 5.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Overvoltage or Undervoltage Input Fault. The internal circuitry
|
||||
is protected from excessive voltages applied to the thermocouple
|
||||
cables. The device can also detect if such a condition occurs.
|
||||
|
||||
Reading returns '1' if input voltage is negative or greater
|
||||
than VDD, otherwise '0'.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/fault_oc
|
||||
KernelVersion: 5.1
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Open-circuit fault. The detection of open-circuit faults,
|
||||
such as those caused by broken thermocouple wires.
|
||||
Reading returns '1' if fault, '0' otherwise.
|
||||
|
|
@ -90,6 +90,14 @@ Description:
|
|||
Reading returns the current master modes.
|
||||
Writing set the master mode
|
||||
|
||||
What: /sys/bus/iio/devices/triggerX/sampling_frequency
|
||||
KernelVersion: 4.11
|
||||
Contact: benjamin.gaignard@st.com
|
||||
Description:
|
||||
Reading returns the current sampling frequency.
|
||||
Writing an value different of 0 set and start sampling.
|
||||
Writing 0 stop sampling.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_count0_preset
|
||||
KernelVersion: 4.12
|
||||
Contact: benjamin.gaignard@st.com
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
What: /sys/bus/iio/devices/iio:deviceX/in_conversion_mode
|
||||
What: /sys/bus/iio/devices/iio:deviceX/conversion_mode
|
||||
KernelVersion: 4.2
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
|
|
|
|||
|
|
@ -457,36 +457,3 @@ Description:
|
|||
|
||||
The file is writable if the PF is bound to a driver that
|
||||
implements ->sriov_set_msix_vec_count().
|
||||
|
||||
What: /sys/bus/pci/devices/.../resourceN_resize
|
||||
Date: September 2022
|
||||
Contact: Alex Williamson <alex.williamson@redhat.com>
|
||||
Description:
|
||||
These files provide an interface to PCIe Resizable BAR support.
|
||||
A file is created for each BAR resource (N) supported by the
|
||||
PCIe Resizable BAR extended capability of the device. Reading
|
||||
each file exposes the bitmap of available resource sizes:
|
||||
|
||||
# cat resource1_resize
|
||||
00000000000001c0
|
||||
|
||||
The bitmap represents supported resource sizes for the BAR,
|
||||
where bit0 = 1MB, bit1 = 2MB, bit2 = 4MB, etc. In the above
|
||||
example the device supports 64MB, 128MB, and 256MB BAR sizes.
|
||||
|
||||
When writing the file, the user provides the bit position of
|
||||
the desired resource size, for example:
|
||||
|
||||
# echo 7 > resource1_resize
|
||||
|
||||
This indicates to set the size value corresponding to bit 7,
|
||||
128MB. The resulting size is 2 ^ (bit# + 20). This definition
|
||||
matches the PCIe specification of this capability.
|
||||
|
||||
In order to make use of resource resizing, all PCI drivers must
|
||||
be unbound from the device and peer devices under the same
|
||||
parent bridge may need to be soft removed. In the case of
|
||||
VGA devices, writing a resize value will remove low level
|
||||
console drivers from the device. Raw users of pci-sysfs
|
||||
resourceN attributes must be terminated prior to resizing.
|
||||
Success of the resizing operation is not guaranteed.
|
||||
|
|
|
|||
|
|
@ -1,8 +0,0 @@
|
|||
What: /sys/bus/platform/devices/<dev>/always_powered_in_suspend
|
||||
Date: June 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: Matthias Kaehlcke <matthias@kaehlcke.net>
|
||||
linux-usb@vger.kernel.org
|
||||
Description:
|
||||
(RW) Controls whether the USB hub remains always powered
|
||||
during system suspend or not.
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
What: /sys/bus/surface_aggregator/devices/01:0e:01:00:01/state
|
||||
Date: July 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: Maximilian Luz <luzmaximilian@gmail.com>
|
||||
Description:
|
||||
This attribute returns a string with the current type-cover
|
||||
or device posture, as indicated by the embedded controller.
|
||||
Currently returned posture states are:
|
||||
|
||||
- "disconnected": The type-cover has been disconnected.
|
||||
|
||||
- "closed": The type-cover has been folded closed and lies on
|
||||
top of the display.
|
||||
|
||||
- "laptop": The type-cover is open and in laptop-mode, i.e.,
|
||||
ready for normal use.
|
||||
|
||||
- "folded-canvas": The type-cover has been folded back
|
||||
part-ways, but does not lie flush with the back side of the
|
||||
device. In general, this means that the kick-stand is used
|
||||
and extended atop of the cover.
|
||||
|
||||
- "folded-back": The type cover has been fully folded back and
|
||||
lies flush with the back side of the device.
|
||||
|
||||
- "<unknown>": The current state is unknown to the driver, for
|
||||
example due to newer as-of-yet unsupported hardware.
|
||||
|
||||
New states may be introduced with new hardware. Users therefore
|
||||
must not rely on this list of states being exhaustive and
|
||||
gracefully handle unknown states.
|
||||
|
||||
What: /sys/bus/surface_aggregator/devices/01:26:01:00:01/state
|
||||
Date: July 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: Maximilian Luz <luzmaximilian@gmail.com>
|
||||
Description:
|
||||
This attribute returns a string with the current device posture, as indicated by the embedded controller. Currently
|
||||
returned posture states are:
|
||||
|
||||
- "closed": The lid of the device is closed.
|
||||
|
||||
- "laptop": The lid of the device is opened and the device
|
||||
operates as a normal laptop.
|
||||
|
||||
- "slate": The screen covers the keyboard or has been flipped
|
||||
back and the device operates mainly based on touch input.
|
||||
|
||||
- "tablet": The device operates as tablet and exclusively
|
||||
relies on touch input (or external peripherals).
|
||||
|
||||
- "<unknown>": The current state is unknown to the driver, for
|
||||
example due to newer as-of-yet unsupported hardware.
|
||||
|
||||
New states may be introduced with new hardware. Users therefore
|
||||
must not rely on this list of states being exhaustive and
|
||||
gracefully handle unknown states.
|
||||
|
|
@ -153,7 +153,7 @@ Date: Jan 2020
|
|||
KernelVersion: 5.5
|
||||
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
|
||||
Description: This attribute reports number of RX lanes the device is
|
||||
using simultaneously through its upstream port.
|
||||
using simultaneusly through its upstream port.
|
||||
|
||||
What: /sys/bus/thunderbolt/devices/.../tx_speed
|
||||
Date: Jan 2020
|
||||
|
|
@ -167,7 +167,7 @@ Date: Jan 2020
|
|||
KernelVersion: 5.5
|
||||
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
|
||||
Description: This attribute reports number of TX lanes the device is
|
||||
using simultaneously through its upstream port.
|
||||
using simultaneusly through its upstream port.
|
||||
|
||||
What: /sys/bus/thunderbolt/devices/.../vendor
|
||||
Date: Sep 2017
|
||||
|
|
@ -293,16 +293,6 @@ 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
|
||||
|
|
|
|||
|
|
@ -253,17 +253,6 @@ Description:
|
|||
only if the system firmware is capable of describing the
|
||||
connection between a port and its connector.
|
||||
|
||||
What: /sys/bus/usb/devices/.../<hub_interface>/port<X>/disable
|
||||
Date: June 2022
|
||||
Contact: Michael Grzeschik <m.grzeschik@pengutronix.de>
|
||||
Description:
|
||||
This file controls the state of a USB port, including
|
||||
Vbus power output (but only on hubs that support
|
||||
power switching -- most hubs don't support it). If
|
||||
a port is disabled, the port is unusable: Devices
|
||||
attached to the port will not be detected, initialized,
|
||||
or enumerated.
|
||||
|
||||
What: /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout
|
||||
Date: May 2013
|
||||
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
|
||||
|
|
|
|||
|
|
@ -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 lowest version of the userspace API
|
||||
this kernel supports.
|
||||
Decimal value of the the lowest version of the userspace API
|
||||
this this kernel supports.
|
||||
Users: https://github.com/ibm-capi/libcxl
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,77 +0,0 @@
|
|||
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.
|
||||
|
|
@ -938,12 +938,3 @@ Description:
|
|||
- 1: enable
|
||||
|
||||
RW
|
||||
|
||||
What: /sys/class/hwmon/hwmonX/device/pec
|
||||
Description:
|
||||
PEC support on I2C devices
|
||||
|
||||
- 0, off, n: disable
|
||||
- 1, on, y: enable
|
||||
|
||||
RW
|
||||
|
|
|
|||
|
|
@ -364,10 +364,7 @@ Date: April 2019
|
|||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Represents a battery percentage level, above which charging will
|
||||
stop. Not all hardware is capable of setting this to an arbitrary
|
||||
percentage. Drivers will round written values to the nearest
|
||||
supported value. Reading back the value will show the actual
|
||||
threshold set by the driver.
|
||||
stop.
|
||||
|
||||
Access: Read, Write
|
||||
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ Description:
|
|||
What: /sys/class/pwm/pwmchip<N>/pwmX/capture
|
||||
Date: June 2016
|
||||
KernelVersion: 4.8
|
||||
Contact: Lee Jones <lee@kernel.org>
|
||||
Contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Capture information about a PWM signal. The output format is a
|
||||
pair unsigned integers (period and duty cycle), separated by a
|
||||
|
|
|
|||
|
|
@ -370,84 +370,3 @@ Description:
|
|||
|
||||
'unknown' means software cannot determine the state, or
|
||||
the reported state is invalid.
|
||||
|
||||
What: /sys/class/regulator/.../under_voltage
|
||||
Date: April 2022
|
||||
KernelVersion: 5.18
|
||||
Contact: Zev Weiss <zev@bewilderbeest.net>
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
under_voltage. This indicates if the device reports an
|
||||
under-voltage fault (1) or not (0).
|
||||
|
||||
What: /sys/class/regulator/.../over_current
|
||||
Date: April 2022
|
||||
KernelVersion: 5.18
|
||||
Contact: Zev Weiss <zev@bewilderbeest.net>
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
over_current. This indicates if the device reports an
|
||||
over-current fault (1) or not (0).
|
||||
|
||||
What: /sys/class/regulator/.../regulation_out
|
||||
Date: April 2022
|
||||
KernelVersion: 5.18
|
||||
Contact: Zev Weiss <zev@bewilderbeest.net>
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
regulation_out. This indicates if the device reports an
|
||||
out-of-regulation fault (1) or not (0).
|
||||
|
||||
What: /sys/class/regulator/.../fail
|
||||
Date: April 2022
|
||||
KernelVersion: 5.18
|
||||
Contact: Zev Weiss <zev@bewilderbeest.net>
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
fail. This indicates if the device reports an output failure
|
||||
(1) or not (0).
|
||||
|
||||
What: /sys/class/regulator/.../over_temp
|
||||
Date: April 2022
|
||||
KernelVersion: 5.18
|
||||
Contact: Zev Weiss <zev@bewilderbeest.net>
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
over_temp. This indicates if the device reports an
|
||||
over-temperature fault (1) or not (0).
|
||||
|
||||
What: /sys/class/regulator/.../under_voltage_warn
|
||||
Date: April 2022
|
||||
KernelVersion: 5.18
|
||||
Contact: Zev Weiss <zev@bewilderbeest.net>
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
under_voltage_warn. This indicates if the device reports an
|
||||
under-voltage warning (1) or not (0).
|
||||
|
||||
What: /sys/class/regulator/.../over_current_warn
|
||||
Date: April 2022
|
||||
KernelVersion: 5.18
|
||||
Contact: Zev Weiss <zev@bewilderbeest.net>
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
over_current_warn. This indicates if the device reports an
|
||||
over-current warning (1) or not (0).
|
||||
|
||||
What: /sys/class/regulator/.../over_voltage_warn
|
||||
Date: April 2022
|
||||
KernelVersion: 5.18
|
||||
Contact: Zev Weiss <zev@bewilderbeest.net>
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
over_voltage_warn. This indicates if the device reports an
|
||||
over-voltage warning (1) or not (0).
|
||||
|
||||
What: /sys/class/regulator/.../over_temp_warn
|
||||
Date: April 2022
|
||||
KernelVersion: 5.18
|
||||
Contact: Zev Weiss <zev@bewilderbeest.net>
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
over_temp_warn. This indicates if the device reports an
|
||||
over-temperature warning (1) or not (0).
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/hca_name
|
|||
Date: Feb 2020
|
||||
KernelVersion: 5.7
|
||||
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
|
||||
Description: RO, Contains the name of HCA the connection established on.
|
||||
Description: RO, Contains the the name of HCA the connection established on.
|
||||
|
||||
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/hca_port
|
||||
Date: Feb 2020
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/hca_name
|
|||
Date: Feb 2020
|
||||
KernelVersion: 5.7
|
||||
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
|
||||
Description: RO, Contains the name of HCA the connection established on.
|
||||
Description: RO, Contains the the name of HCA the connection established on.
|
||||
|
||||
What: /sys/class/rtrs-server/<session-name>/paths/<src@dst>/hca_port
|
||||
Date: Feb 2020
|
||||
|
|
|
|||
|
|
@ -141,14 +141,6 @@ Description:
|
|||
- "reverse": CC2 orientation
|
||||
- "unknown": Orientation cannot be determined.
|
||||
|
||||
What: /sys/class/typec/<port>/select_usb_power_delivery
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Lists the USB Power Delivery Capabilities that the port can
|
||||
advertise to the partner. The currently used capabilities are in
|
||||
brackets. Selection happens by writing to the file.
|
||||
|
||||
USB Type-C partner devices (eg. /sys/class/typec/port0-partner/)
|
||||
|
||||
What: /sys/class/typec/<port>-partner/accessory_mode
|
||||
|
|
|
|||
|
|
@ -1,240 +0,0 @@
|
|||
What: /sys/class/usb_power_delivery
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Directory for USB Power Delivery devices.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../revision
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
File showing the USB Power Delivery Specification Revision used
|
||||
in communication.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../version
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
This is an optional attribute file showing the version of the
|
||||
specific revision of the USB Power Delivery Specification. In
|
||||
most cases the specification version is not known and the file
|
||||
is not available.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../source-capabilities
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
The source capabilities message "Source_Capabilities" contains a
|
||||
set of Power Data Objects (PDO), each representing a type of
|
||||
power supply. The order of the PDO objects is defined in the USB
|
||||
Power Delivery Specification. Each PDO - power supply - will
|
||||
have its own device, and the PDO device name will start with the
|
||||
object position number as the first character followed by the
|
||||
power supply type name (":" as delimiter).
|
||||
|
||||
/sys/class/usb_power_delivery/.../source_capabilities/<position>:<type>
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../sink-capabilities
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
The sink capability message "Sink_Capabilities" contains a set
|
||||
of Power Data Objects (PDO) just like with source capabilities,
|
||||
but instead of describing the power capabilities, these objects
|
||||
describe the power requirements.
|
||||
|
||||
The order of the objects in the sink capability message is the
|
||||
same as with the source capabilities message.
|
||||
|
||||
Fixed Supplies
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:fixed_supply
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Devices containing the attributes (the bit fields) defined for
|
||||
Fixed Supplies.
|
||||
|
||||
The device "1:fixed_supply" is special. USB Power Delivery
|
||||
Specification dictates that the first PDO (at object position
|
||||
1), and the only mandatory PDO, is always the vSafe5V Fixed
|
||||
Supply Object. vSafe5V Object has additional fields defined for
|
||||
it that the other Fixed Supply Objects do not have and that are
|
||||
related to the USB capabilities rather than power capabilities.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/dual_role_power
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
This file contains boolean value that tells does the device
|
||||
support both source and sink power roles.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/usb_suspend_supported
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
This file shows the value of the USB Suspend Supported bit in
|
||||
vSafe5V Fixed Supply Object. If the bit is set then the device
|
||||
will follow the USB 2.0 and USB 3.2 rules for suspend and
|
||||
resume.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/unconstrained_power
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
This file shows the value of the Unconstrained Power bit in
|
||||
vSafe5V Fixed Supply Object. The bit is set when an external
|
||||
source of power, powerful enough to power the entire system on
|
||||
its own, is available for the device.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/usb_communication_capable
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
This file shows the value of the USB Communication Capable bit in
|
||||
vSafe5V Fixed Supply Object.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/dual_role_data
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
This file shows the value of the Dual-Role Data bit in vSafe5V
|
||||
Fixed Supply Object. Dual role data means ability act as both
|
||||
USB host and USB device.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/unchunked_extended_messages_supported
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
This file shows the value of the Unchunked Extended Messages
|
||||
Supported bit in vSafe5V Fixed Supply Object.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:fixed_supply/voltage
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
The voltage the supply supports in millivolts.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:fixed_supply/maximum_current
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Maximum current of the fixed source supply in milliamperes.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../sink-capabilities/<position>:fixed_supply/operational_current
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Operational current of the sink in milliamperes.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../sink-capabilities/<position>:fixed_supply/fast_role_swap_current
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
This file contains the value of the "Fast Role Swap USB Type-C
|
||||
Current" field that tells the current level the sink requires
|
||||
after a Fast Role Swap.
|
||||
0 - Fast Swap not supported"
|
||||
1 - Default USB Power"
|
||||
2 - 1.5A@5V"
|
||||
3 - 3.0A@5V"
|
||||
|
||||
Variable Supplies
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:variable_supply
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Variable Power Supply PDO.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:variable_supply/maximum_voltage
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Maximum Voltage in millivolts.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:variable_supply/minimum_voltage
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Minimum Voltage in millivolts.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:variable_supply/maximum_current
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
The maximum current in milliamperes that the source can supply
|
||||
at the given Voltage range.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../sink-capabilities/<position>:variable_supply/operational_current
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
The operational current in milliamperes that the sink requires
|
||||
at the given Voltage range.
|
||||
|
||||
Battery Supplies
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:battery
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Battery PDO.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:battery/maximum_voltage
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Maximum Voltage in millivolts.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:battery/minimum_voltage
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Minimum Voltage in millivolts.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:battery/maximum_power
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Maximum allowable Power in milliwatts.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../sink-capabilities/<position>:battery/operational_power
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
The operational power that the sink requires at the given
|
||||
voltage range.
|
||||
|
||||
Standard Power Range (SPR) Programmable Power Supplies
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Programmable Power Supply (PPS) Augmented PDO (APDO).
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply/maximum_voltage
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Maximum Voltage in millivolts.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply/minimum_voltage
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Minimum Voltage in millivolts.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply/maximum_current
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Maximum Current in milliamperes.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:programmable_supply/pps_power_limited
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
The PPS Power Limited bit indicates whether or not the source
|
||||
supply will exceed the rated output power if requested.
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
What: /sys/class/vduse/
|
||||
Date: Oct 2021
|
||||
KernelVersion: 5.15
|
||||
Contact: Yongji Xie <xieyongji@bytedance.com>
|
||||
Description:
|
||||
The vduse/ class sub-directory belongs to the VDUSE
|
||||
framework and provides a sysfs interface for configuring
|
||||
VDUSE devices.
|
||||
|
||||
What: /sys/class/vduse/control/
|
||||
Date: Oct 2021
|
||||
KernelVersion: 5.15
|
||||
Contact: Yongji Xie <xieyongji@bytedance.com>
|
||||
Description:
|
||||
This directory entry is created for the control device
|
||||
of VDUSE framework.
|
||||
|
||||
What: /sys/class/vduse/<device-name>/
|
||||
Date: Oct 2021
|
||||
KernelVersion: 5.15
|
||||
Contact: Yongji Xie <xieyongji@bytedance.com>
|
||||
Description:
|
||||
This directory entry is created when a VDUSE device is
|
||||
created via the control device.
|
||||
|
||||
What: /sys/class/vduse/<device-name>/msg_timeout
|
||||
Date: Oct 2021
|
||||
KernelVersion: 5.15
|
||||
Contact: Yongji Xie <xieyongji@bytedance.com>
|
||||
Description:
|
||||
(RW) The timeout (in seconds) for waiting for the control
|
||||
message's response from userspace. Default value is 30s.
|
||||
Writing a '0' to the file means to disable the timeout.
|
||||
|
|
@ -1,61 +0,0 @@
|
|||
What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune
|
||||
Date: October 2022
|
||||
KernelVersion: 6.1
|
||||
Contact: Yicong Yang <yangyicong@hisilicon.com>
|
||||
Description: This directory contains files for tuning the PCIe link
|
||||
parameters(events). Each file is named after the event
|
||||
of the PCIe link.
|
||||
|
||||
See Documentation/trace/hisi-ptt.rst for more information.
|
||||
|
||||
What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_cpl
|
||||
Date: October 2022
|
||||
KernelVersion: 6.1
|
||||
Contact: Yicong Yang <yangyicong@hisilicon.com>
|
||||
Description: (RW) Controls the weight of Tx completion TLPs, which influence
|
||||
the proportion of outbound completion TLPs on the PCIe link.
|
||||
The available tune data is [0, 1, 2]. Writing a negative value
|
||||
will return an error, and out of range values will be converted
|
||||
to 2. The value indicates a probable level of the event.
|
||||
|
||||
What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_np
|
||||
Date: October 2022
|
||||
KernelVersion: 6.1
|
||||
Contact: Yicong Yang <yangyicong@hisilicon.com>
|
||||
Description: (RW) Controls the weight of Tx non-posted TLPs, which influence
|
||||
the proportion of outbound non-posted TLPs on the PCIe link.
|
||||
The available tune data is [0, 1, 2]. Writing a negative value
|
||||
will return an error, and out of range values will be converted
|
||||
to 2. The value indicates a probable level of the event.
|
||||
|
||||
What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_p
|
||||
Date: October 2022
|
||||
KernelVersion: 6.1
|
||||
Contact: Yicong Yang <yangyicong@hisilicon.com>
|
||||
Description: (RW) Controls the weight of Tx posted TLPs, which influence the
|
||||
proportion of outbound posted TLPs on the PCIe link.
|
||||
The available tune data is [0, 1, 2]. Writing a negative value
|
||||
will return an error, and out of range values will be converted
|
||||
to 2. The value indicates a probable level of the event.
|
||||
|
||||
What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/rx_alloc_buf_level
|
||||
Date: October 2022
|
||||
KernelVersion: 6.1
|
||||
Contact: Yicong Yang <yangyicong@hisilicon.com>
|
||||
Description: (RW) Control the allocated buffer watermark for inbound packets.
|
||||
The packets will be stored in the buffer first and then transmitted
|
||||
either when the watermark reached or when timed out.
|
||||
The available tune data is [0, 1, 2]. Writing a negative value
|
||||
will return an error, and out of range values will be converted
|
||||
to 2. The value indicates a probable level of the event.
|
||||
|
||||
What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/tx_alloc_buf_level
|
||||
Date: October 2022
|
||||
KernelVersion: 6.1
|
||||
Contact: Yicong Yang <yangyicong@hisilicon.com>
|
||||
Description: (RW) Control the allocated buffer watermark of outbound packets.
|
||||
The packets will be stored in the buffer first and then transmitted
|
||||
either when the watermark reached or when timed out.
|
||||
The available tune data is [0, 1, 2]. Writing a negative value
|
||||
will return an error, and out of range values will be converted
|
||||
to 2. The value indicates a probable level of the event.
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
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.
|
||||
|
|
@ -74,7 +74,7 @@ Description:
|
|||
|
||||
Reads also cause the AC alarm timer status to be reset.
|
||||
|
||||
Another way to reset the status of the AC alarm timer is to
|
||||
Another way to reset the the status of the AC alarm timer is to
|
||||
write (the number) 0 to this file.
|
||||
|
||||
If the status return value indicates that the timer has expired,
|
||||
|
|
|
|||
|
|
@ -46,69 +46,33 @@ Description:
|
|||
that is supported by the hardware. The possible values
|
||||
are "MAPv4" or "MAPv5".
|
||||
|
||||
What: .../XXXXXXX.ipa/endpoint_id/
|
||||
Date: July 2022
|
||||
KernelVersion: v5.19
|
||||
Contact: Alex Elder <elder@kernel.org>
|
||||
Description:
|
||||
The .../XXXXXXX.ipa/endpoint_id/ directory contains
|
||||
attributes that define IDs associated with IPA
|
||||
endpoints. The "rx" or "tx" in an endpoint name is
|
||||
from the perspective of the AP. An endpoint ID is a
|
||||
small unsigned integer.
|
||||
|
||||
What: .../XXXXXXX.ipa/endpoint_id/modem_rx
|
||||
Date: July 2022
|
||||
KernelVersion: v5.19
|
||||
Contact: Alex Elder <elder@kernel.org>
|
||||
Description:
|
||||
The .../XXXXXXX.ipa/endpoint_id/modem_rx file contains
|
||||
the ID of the AP endpoint on which packets originating
|
||||
from the embedded modem are received.
|
||||
|
||||
What: .../XXXXXXX.ipa/endpoint_id/modem_tx
|
||||
Date: July 2022
|
||||
KernelVersion: v5.19
|
||||
Contact: Alex Elder <elder@kernel.org>
|
||||
Description:
|
||||
The .../XXXXXXX.ipa/endpoint_id/modem_tx file contains
|
||||
the ID of the AP endpoint on which packets destined
|
||||
for the embedded modem are sent.
|
||||
|
||||
What: .../XXXXXXX.ipa/endpoint_id/monitor_rx
|
||||
Date: July 2022
|
||||
KernelVersion: v5.19
|
||||
Contact: Alex Elder <elder@kernel.org>
|
||||
Description:
|
||||
The .../XXXXXXX.ipa/endpoint_id/monitor_rx file contains
|
||||
the ID of the AP endpoint on which IPA "monitor" data is
|
||||
received. The monitor endpoint supplies replicas of
|
||||
packets that enter the IPA hardware for processing.
|
||||
Each replicated packet is preceded by a fixed-size "ODL"
|
||||
header (see .../XXXXXXX.ipa/feature/monitor, above).
|
||||
Large packets are truncated, to reduce the bandwidth
|
||||
required to provide the monitor function.
|
||||
|
||||
What: .../XXXXXXX.ipa/modem/
|
||||
Date: June 2021
|
||||
KernelVersion: v5.14
|
||||
Contact: Alex Elder <elder@kernel.org>
|
||||
Description:
|
||||
The .../XXXXXXX.ipa/modem/ directory contains attributes
|
||||
describing properties of the modem embedded in the SoC.
|
||||
The .../XXXXXXX.ipa/modem/ directory contains a set of
|
||||
attributes describing properties of the modem execution
|
||||
environment reachable by the IPA hardware.
|
||||
|
||||
What: .../XXXXXXX.ipa/modem/rx_endpoint_id
|
||||
Date: June 2021
|
||||
KernelVersion: v5.14
|
||||
Contact: Alex Elder <elder@kernel.org>
|
||||
Description:
|
||||
The .../XXXXXXX.ipa/modem/rx_endpoint_id file duplicates
|
||||
the value found in .../XXXXXXX.ipa/endpoint_id/modem_rx.
|
||||
The .../XXXXXXX.ipa/feature/rx_endpoint_id file contains
|
||||
the AP endpoint ID that receives packets originating from
|
||||
the modem execution environment. The "rx" is from the
|
||||
perspective of the AP; this endpoint is considered an "IPA
|
||||
producer". An endpoint ID is a small unsigned integer.
|
||||
|
||||
What: .../XXXXXXX.ipa/modem/tx_endpoint_id
|
||||
Date: June 2021
|
||||
KernelVersion: v5.14
|
||||
Contact: Alex Elder <elder@kernel.org>
|
||||
Description:
|
||||
The .../XXXXXXX.ipa/modem/tx_endpoint_id file duplicates
|
||||
the value found in .../XXXXXXX.ipa/endpoint_id/modem_tx.
|
||||
The .../XXXXXXX.ipa/feature/tx_endpoint_id file contains
|
||||
the AP endpoint ID used to transmit packets destined for
|
||||
the modem execution environment. The "tx" is from the
|
||||
perspective of the AP; this endpoint is considered an "IPA
|
||||
consumer". An endpoint ID is a small unsigned integer.
|
||||
|
|
|
|||
|
|
@ -303,5 +303,5 @@ Date: Apr 2010
|
|||
Contact: Dominik Brodowski <linux@dominikbrodowski.net>
|
||||
Description:
|
||||
Reports the runtime PM children usage count of a device, or
|
||||
0 if the children will be ignored.
|
||||
0 if the the children will be ignored.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
What: /sys/devices/socX
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee@kernel.org>
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
The /sys/devices/ directory contains a sub-directory for each
|
||||
System-on-Chip (SoC) device on a running platform. Information
|
||||
|
|
@ -14,14 +14,14 @@ Description:
|
|||
|
||||
What: /sys/devices/socX/machine
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee@kernel.org>
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute common to all SoCs. Contains the SoC machine
|
||||
name (e.g. Ux500).
|
||||
|
||||
What: /sys/devices/socX/family
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee@kernel.org>
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute common to all SoCs. Contains SoC family name
|
||||
(e.g. DB8500).
|
||||
|
|
@ -59,7 +59,7 @@ Description:
|
|||
|
||||
What: /sys/devices/socX/soc_id
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee@kernel.org>
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute supported by most SoCs. In the case of
|
||||
ST-Ericsson's chips this contains the SoC serial number.
|
||||
|
|
@ -72,21 +72,21 @@ Description:
|
|||
|
||||
What: /sys/devices/socX/revision
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee@kernel.org>
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute supported by most SoCs. Contains the SoC's
|
||||
manufacturing revision number.
|
||||
|
||||
What: /sys/devices/socX/process
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee@kernel.org>
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
Read-only attribute supported ST-Ericsson's silicon. Contains the
|
||||
the process by which the silicon chip was manufactured.
|
||||
|
||||
What: /sys/bus/soc
|
||||
Date: January 2012
|
||||
contact: Lee Jones <lee@kernel.org>
|
||||
contact: Lee Jones <lee.jones@linaro.org>
|
||||
Description:
|
||||
The /sys/bus/soc/ directory contains the usual sub-folders
|
||||
expected under most buses. /sys/bus/soc/devices is of particular
|
||||
|
|
|
|||
|
|
@ -67,7 +67,8 @@ Description: Discover NUMA node a CPU belongs to
|
|||
/sys/devices/system/cpu/cpu42/node2 -> ../../node/node2
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/core_siblings
|
||||
What: /sys/devices/system/cpu/cpuX/topology/core_id
|
||||
/sys/devices/system/cpu/cpuX/topology/core_siblings
|
||||
/sys/devices/system/cpu/cpuX/topology/core_siblings_list
|
||||
/sys/devices/system/cpu/cpuX/topology/physical_package_id
|
||||
/sys/devices/system/cpu/cpuX/topology/thread_siblings
|
||||
|
|
@ -83,6 +84,10 @@ Description: CPU topology files that describe a logical CPU's relationship
|
|||
|
||||
Briefly, the files above are:
|
||||
|
||||
core_id: the CPU core ID of cpuX. Typically it is the
|
||||
hardware platform's identifier (rather than the kernel's).
|
||||
The actual value is architecture and platform dependent.
|
||||
|
||||
core_siblings: internal kernel map of cpuX's hardware threads
|
||||
within the same physical_package_id.
|
||||
|
||||
|
|
@ -296,7 +301,7 @@ Description: Processor frequency boosting control
|
|||
|
||||
This switch controls the boost setting for the whole system.
|
||||
Boosting allows the CPU and the firmware to run at a frequency
|
||||
beyond its nominal limit.
|
||||
beyond it's nominal limit.
|
||||
|
||||
More details can be found in
|
||||
Documentation/admin-guide/pm/cpufreq.rst
|
||||
|
|
@ -488,13 +493,12 @@ What: /sys/devices/system/cpu/cpuX/regs/
|
|||
/sys/devices/system/cpu/cpuX/regs/identification/
|
||||
/sys/devices/system/cpu/cpuX/regs/identification/midr_el1
|
||||
/sys/devices/system/cpu/cpuX/regs/identification/revidr_el1
|
||||
/sys/devices/system/cpu/cpuX/regs/identification/smidr_el1
|
||||
Date: June 2016
|
||||
Contact: Linux ARM Kernel Mailing list <linux-arm-kernel@lists.infradead.org>
|
||||
Description: AArch64 CPU registers
|
||||
|
||||
'identification' directory exposes the CPU ID registers for
|
||||
identifying model and revision of the CPU and SMCU.
|
||||
identifying model and revision of the CPU.
|
||||
|
||||
What: /sys/devices/system/cpu/aarch32_el0
|
||||
Date: May 2021
|
||||
|
|
@ -522,8 +526,6 @@ 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
|
||||
/sys/devices/system/cpu/vulnerabilities/retbleed
|
||||
Date: January 2018
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Information about CPU vulnerabilities
|
||||
|
|
|
|||
|
|
@ -1,8 +0,0 @@
|
|||
What: /sys/.../<device>/vfio-dev/vfioX/
|
||||
Date: September 2022
|
||||
Contact: Yi Liu <yi.l.liu@intel.com>
|
||||
Description:
|
||||
This directory is created when the device is bound to a
|
||||
vfio driver. The layout under this directory matches what
|
||||
exists for a standard 'struct device'. 'X' is a unique
|
||||
index marking this device in vfio.
|
||||
|
|
@ -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/rohm,bd9571mwv.yaml.
|
||||
See also Documentation/devicetree/bindings/mfd/bd9571mwv.txt.
|
||||
Users: User space applications for embedded boards equipped with a
|
||||
BD9571MWV PMIC.
|
||||
|
|
|
|||
|
|
@ -1,87 +0,0 @@
|
|||
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
|
||||
|
|
@ -1,137 +0,0 @@
|
|||
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).
|
||||
|
|
@ -16,7 +16,7 @@ Description: Version of the application running on the device's CPU
|
|||
|
||||
What: /sys/class/habanalabs/hl<n>/clk_max_freq_mhz
|
||||
Date: Jun 2019
|
||||
KernelVersion: 5.7
|
||||
KernelVersion: not yet upstreamed
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Allows the user to set the maximum clock frequency, in MHz.
|
||||
The device clock might be set to lower value than the maximum.
|
||||
|
|
@ -26,7 +26,7 @@ Description: Allows the user to set the maximum clock frequency, in MHz.
|
|||
|
||||
What: /sys/class/habanalabs/hl<n>/clk_cur_freq_mhz
|
||||
Date: Jun 2019
|
||||
KernelVersion: 5.7
|
||||
KernelVersion: not yet upstreamed
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Displays the current frequency, in MHz, of the device clock.
|
||||
This property is valid only for the Gaudi ASIC family
|
||||
|
|
@ -176,12 +176,6 @@ KernelVersion: 5.1
|
|||
Contact: ogabbay@kernel.org
|
||||
Description: Version of the device's preboot F/W code
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/security_enabled
|
||||
Date: Oct 2022
|
||||
KernelVersion: 6.1
|
||||
Contact: obitton@habana.ai
|
||||
Description: Displays the device's security status
|
||||
|
||||
What: /sys/class/habanalabs/hl<n>/soft_reset
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
|
|
@ -236,6 +230,6 @@ Description: Version of the u-boot running on the device's CPU
|
|||
|
||||
What: /sys/class/habanalabs/hl<n>/vrm_ver
|
||||
Date: Jan 2022
|
||||
KernelVersion: 5.17
|
||||
KernelVersion: not yet upstreamed
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Version of the Device's Voltage Regulator Monitor F/W code. N/A to GOYA and GAUDI
|
||||
|
|
|
|||
|
|
@ -1,61 +0,0 @@
|
|||
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/sr_root_entry_hash
|
||||
Date: Sep 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: Russ Weight <russell.h.weight@intel.com>
|
||||
Description: Read only. Returns the root entry hash for the static
|
||||
region if one is programmed, else it returns the
|
||||
string: "hash not programmed". This file is only
|
||||
visible if the underlying device supports it.
|
||||
Format: string.
|
||||
|
||||
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/pr_root_entry_hash
|
||||
Date: Sep 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: Russ Weight <russell.h.weight@intel.com>
|
||||
Description: Read only. Returns the root entry hash for the partial
|
||||
reconfiguration region if one is programmed, else it
|
||||
returns the string: "hash not programmed". This file
|
||||
is only visible if the underlying device supports it.
|
||||
Format: string.
|
||||
|
||||
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/bmc_root_entry_hash
|
||||
Date: Sep 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: Russ Weight <russell.h.weight@intel.com>
|
||||
Description: Read only. Returns the root entry hash for the BMC image
|
||||
if one is programmed, else it returns the string:
|
||||
"hash not programmed". This file is only visible if the
|
||||
underlying device supports it.
|
||||
Format: string.
|
||||
|
||||
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/sr_canceled_csks
|
||||
Date: Sep 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: Russ Weight <russell.h.weight@intel.com>
|
||||
Description: Read only. Returns a list of indices for canceled code
|
||||
signing keys for the static region. The standard bitmap
|
||||
list format is used (e.g. "1,2-6,9").
|
||||
|
||||
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/pr_canceled_csks
|
||||
Date: Sep 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: Russ Weight <russell.h.weight@intel.com>
|
||||
Description: Read only. Returns a list of indices for canceled code
|
||||
signing keys for the partial reconfiguration region. The
|
||||
standard bitmap list format is used (e.g. "1,2-6,9").
|
||||
|
||||
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/bmc_canceled_csks
|
||||
Date: Sep 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: Russ Weight <russell.h.weight@intel.com>
|
||||
Description: Read only. Returns a list of indices for canceled code
|
||||
signing keys for the BMC. The standard bitmap list format
|
||||
is used (e.g. "1,2-6,9").
|
||||
|
||||
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/flash_count
|
||||
Date: Sep 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: Russ Weight <russell.h.weight@intel.com>
|
||||
Description: Read only. Returns number of times the secure update
|
||||
staging area has been flashed.
|
||||
Format: "%u".
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
What: /sys/bus/pci/devices/<BDF>/qat/state
|
||||
Date: June 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: qat-linux@intel.com
|
||||
Description: (RW) Reports the current state of the QAT device. Write to
|
||||
the file to start or stop the device.
|
||||
|
||||
The values are:
|
||||
|
||||
* up: the device is up and running
|
||||
* down: the device is down
|
||||
|
||||
|
||||
It is possible to transition the device from up to down only
|
||||
if the device is up and vice versa.
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat/cfg_services
|
||||
Date: June 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: qat-linux@intel.com
|
||||
Description: (RW) Reports the current configuration of the QAT device.
|
||||
Write to the file to change the configured services.
|
||||
|
||||
The values are:
|
||||
|
||||
* sym;asym: the device is configured for running crypto
|
||||
services
|
||||
* dc: the device is configured for running compression services
|
||||
|
||||
It is possible to set the configuration only if the device
|
||||
is in the `down` state (see /sys/bus/pci/devices/<BDF>/qat/state)
|
||||
|
||||
The following example shows how to change the configuration of
|
||||
a device configured for running crypto services in order to
|
||||
run data compression::
|
||||
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat/state
|
||||
up
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat/cfg_services
|
||||
sym;asym
|
||||
# echo down > /sys/bus/pci/devices/<BDF>/qat/state
|
||||
# echo dc > /sys/bus/pci/devices/<BDF>/qat/cfg_services
|
||||
# echo up > /sys/bus/pci/devices/<BDF>/qat/state
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat/cfg_services
|
||||
dc
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
|
@ -1417,15 +1417,6 @@ Description: This node is used to set or display whether UFS WriteBooster is
|
|||
platform that doesn't support UFSHCD_CAP_CLK_SCALING, we can
|
||||
disable/enable WriteBooster through this sysfs node.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/enable_wb_buf_flush
|
||||
What: /sys/bus/platform/devices/*.ufs/enable_wb_buf_flush
|
||||
Date: July 2022
|
||||
Contact: Jinyoung Choi <j-young.choi@samsung.com>
|
||||
Description: This entry shows the status of WriteBooster buffer flushing
|
||||
and it can be used to enable or disable the flushing.
|
||||
If flushing is enabled, the device executes the flush
|
||||
operation when the command queue is empty.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version
|
||||
What: /sys/bus/platform/devices/*.ufs/device_descriptor/hpb_version
|
||||
Date: June 2021
|
||||
|
|
@ -1527,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/rcmd_noti_cnt
|
||||
What: /sys/class/scsi_device/*/device/hpb_stats/rb_noti_cnt
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the number of response UPIUs that has
|
||||
|
|
@ -1535,23 +1526,19 @@ Description: This entry shows the number of response UPIUs that has
|
|||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_active_cnt
|
||||
What: /sys/class/scsi_device/*/device/hpb_stats/rb_active_cnt
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
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.
|
||||
Description: This entry shows the number of active sub-regions recommended by
|
||||
response UPIUs.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_inactive_cnt
|
||||
What: /sys/class/scsi_device/*/device/hpb_stats/rb_inactive_cnt
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
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.
|
||||
Description: This entry shows the number of inactive regions recommended by
|
||||
response UPIUs.
|
||||
|
||||
The file is read only.
|
||||
|
||||
|
|
@ -1600,43 +1587,6 @@ Description: This entry shows the status of HPB.
|
|||
|
||||
The file is read only.
|
||||
|
||||
Contact: Daniil Lunev <dlunev@chromium.org>
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/capabilities/
|
||||
What: /sys/bus/platform/devices/*.ufs/capabilities/
|
||||
Date: August 2022
|
||||
Description: The group represents the effective capabilities of the
|
||||
host-device pair. i.e. the capabilities which are enabled in the
|
||||
driver for the specific host controller, supported by the host
|
||||
controller and are supported and/or have compatible
|
||||
configuration on the device side.
|
||||
|
||||
Contact: Daniil Lunev <dlunev@chromium.org>
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/capabilities/clock_scaling
|
||||
What: /sys/bus/platform/devices/*.ufs/capabilities/clock_scaling
|
||||
Date: August 2022
|
||||
Contact: Daniil Lunev <dlunev@chromium.org>
|
||||
Description: Indicates status of clock scaling.
|
||||
|
||||
== ============================
|
||||
0 Clock scaling is not supported.
|
||||
1 Clock scaling is supported.
|
||||
== ============================
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/capabilities/write_booster
|
||||
What: /sys/bus/platform/devices/*.ufs/capabilities/write_booster
|
||||
Date: August 2022
|
||||
Contact: Daniil Lunev <dlunev@chromium.org>
|
||||
Description: Indicates status of Write Booster.
|
||||
|
||||
== ============================
|
||||
0 Write Booster can not be enabled.
|
||||
1 Write Booster can be enabled.
|
||||
== ============================
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/activation_thld
|
||||
Date: February 2021
|
||||
Contact: Avri Altman <avri.altman@wdc.com>
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Description:
|
|||
What: /sys/module/xen_blkback/parameters/buffer_squeeze_duration_ms
|
||||
Date: December 2019
|
||||
KernelVersion: 5.6
|
||||
Contact: Maximilian Heyne <mheyne@amazon.de>
|
||||
Contact: SeongJae Park <sj@kernel.org>
|
||||
Description:
|
||||
When memory pressure is reported to blkback this option
|
||||
controls the duration in milliseconds that blkback will not
|
||||
|
|
@ -39,8 +39,8 @@ Description:
|
|||
What: /sys/module/xen_blkback/parameters/feature_persistent
|
||||
Date: September 2020
|
||||
KernelVersion: 5.10
|
||||
Contact: Maximilian Heyne <mheyne@amazon.de>
|
||||
Contact: SeongJae Park <sj@kernel.org>
|
||||
Description:
|
||||
Whether to enable the persistent grants feature or not. Note
|
||||
that this option only takes effect on newly connected backends.
|
||||
that this option only takes effect on newly created backends.
|
||||
The default is Y (enable).
|
||||
|
|
|
|||
|
|
@ -12,8 +12,8 @@ Description:
|
|||
What: /sys/module/xen_blkfront/parameters/feature_persistent
|
||||
Date: September 2020
|
||||
KernelVersion: 5.10
|
||||
Contact: Maximilian Heyne <mheyne@amazon.de>
|
||||
Contact: SeongJae Park <sj@kernel.org>
|
||||
Description:
|
||||
Whether to enable the persistent grants feature or not. Note
|
||||
that this option only takes effect on newly connected frontends.
|
||||
that this option only takes effect on newly created frontends.
|
||||
The default is Y (enable).
|
||||
|
|
|
|||
|
|
@ -12,9 +12,8 @@ Description:
|
|||
configuration data to the guest userspace.
|
||||
|
||||
The authoritative guest-side hardware interface documentation
|
||||
to the fw_cfg device can be found in "docs/specs/fw_cfg.rst"
|
||||
in the QEMU source tree, or online at:
|
||||
https://qemu-project.gitlab.io/qemu/specs/fw_cfg.html
|
||||
to the fw_cfg device can be found in "docs/specs/fw_cfg.txt"
|
||||
in the QEMU source tree.
|
||||
|
||||
**SysFS fw_cfg Interface**
|
||||
|
||||
|
|
|
|||
|
|
@ -466,30 +466,6 @@ Description: Show status of f2fs superblock in real time.
|
|||
0x4000 SBI_IS_FREEZING freefs is in process
|
||||
====== ===================== =================================
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/stat/cp_status
|
||||
Date: September 2022
|
||||
Contact: "Chao Yu" <chao.yu@oppo.com>
|
||||
Description: Show status of f2fs checkpoint in real time.
|
||||
|
||||
=============================== ==============================
|
||||
cp flag value
|
||||
CP_UMOUNT_FLAG 0x00000001
|
||||
CP_ORPHAN_PRESENT_FLAG 0x00000002
|
||||
CP_COMPACT_SUM_FLAG 0x00000004
|
||||
CP_ERROR_FLAG 0x00000008
|
||||
CP_FSCK_FLAG 0x00000010
|
||||
CP_FASTBOOT_FLAG 0x00000020
|
||||
CP_CRC_RECOVERY_FLAG 0x00000040
|
||||
CP_NAT_BITS_FLAG 0x00000080
|
||||
CP_TRIMMED_FLAG 0x00000100
|
||||
CP_NOCRC_RECOVERY_FLAG 0x00000200
|
||||
CP_LARGE_NAT_BITMAP_FLAG 0x00000400
|
||||
CP_QUOTA_NEED_FSCK_FLAG 0x00000800
|
||||
CP_DISABLED_FLAG 0x00001000
|
||||
CP_DISABLED_QUICK_FLAG 0x00002000
|
||||
CP_RESIZEFS_FLAG 0x00004000
|
||||
=============================== ==============================
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/ckpt_thread_ioprio
|
||||
Date: January 2021
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
|
|
@ -604,33 +580,3 @@ Date: January 2022
|
|||
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
|
||||
Description: Controls max # of node block writes to be used for roll forward
|
||||
recovery. This can limit the roll forward recovery time.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/unusable_blocks_per_sec
|
||||
Date: June 2022
|
||||
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
|
||||
Description: Shows the number of unusable blocks in a section which was defined by
|
||||
the zone capacity reported by underlying zoned device.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/current_atomic_write
|
||||
Date: July 2022
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
Description: Show the total current atomic write block count, which is not committed yet.
|
||||
This is a read-only entry.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/peak_atomic_write
|
||||
Date: July 2022
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
Description: Show the peak value of total current atomic write block count after boot.
|
||||
If you write "0" here, you can initialize to "0".
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/committed_atomic_block
|
||||
Date: July 2022
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
Description: Show the accumulated total committed atomic write block count after boot.
|
||||
If you write "0" here, you can initialize to "0".
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/revoked_atomic_block
|
||||
Date: July 2022
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
Description: Show the accumulated total revoked atomic write block count after boot.
|
||||
If you write "0" here, you can initialize to "0".
|
||||
|
|
|
|||
|
|
@ -55,14 +55,6 @@ Description:
|
|||
The object directory contains subdirectories for each function
|
||||
that is patched within the object.
|
||||
|
||||
What: /sys/kernel/livepatch/<patch>/<object>/patched
|
||||
Date: August 2022
|
||||
KernelVersion: 6.1.0
|
||||
Contact: live-patching@vger.kernel.org
|
||||
Description:
|
||||
An attribute which indicates whether the object is currently
|
||||
patched.
|
||||
|
||||
What: /sys/kernel/livepatch/<patch>/<object>/<function,sympos>
|
||||
Date: Nov 2014
|
||||
KernelVersion: 3.19.0
|
||||
|
|
|
|||
|
|
@ -23,10 +23,9 @@ 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 '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.
|
||||
based on the current status. 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
|
||||
|
|
@ -41,24 +40,14 @@ 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, '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.
|
||||
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.
|
||||
|
||||
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/sample_us
|
||||
Date: Mar 2022
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ Description: Kernel Samepage Merging daemon sysfs interface
|
|||
sleep_millisecs: how many milliseconds ksm should sleep between
|
||||
scans.
|
||||
|
||||
See Documentation/mm/ksm.rst for more information.
|
||||
See Documentation/vm/ksm.rst for more information.
|
||||
|
||||
What: /sys/kernel/mm/ksm/merge_across_nodes
|
||||
Date: January 2013
|
||||
|
|
|
|||
|
|
@ -1,25 +0,0 @@
|
|||
What: /sys/devices/virtual/memory_tiering/
|
||||
Date: August 2022
|
||||
Contact: Linux memory management mailing list <linux-mm@kvack.org>
|
||||
Description: A collection of all the memory tiers allocated.
|
||||
|
||||
Individual memory tier details are contained in subdirectories
|
||||
named by the abstract distance of the memory tier.
|
||||
|
||||
/sys/devices/virtual/memory_tiering/memory_tierN/
|
||||
|
||||
|
||||
What: /sys/devices/virtual/memory_tiering/memory_tierN/
|
||||
/sys/devices/virtual/memory_tiering/memory_tierN/nodelist
|
||||
Date: August 2022
|
||||
Contact: Linux memory management mailing list <linux-mm@kvack.org>
|
||||
Description: Directory with details of a specific memory tier
|
||||
|
||||
This is the directory containing information about a particular
|
||||
memory tier, memtierN, where N is derived based on abstract distance.
|
||||
|
||||
A smaller value of N implies a higher (faster) memory tier in the
|
||||
hierarchy.
|
||||
|
||||
nodelist: NUMA nodes that are part of this memory tier.
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ Description:
|
|||
The alloc_calls file is read-only and lists the kernel code
|
||||
locations from which allocations for this cache were performed.
|
||||
The alloc_calls file only contains information if debugging is
|
||||
enabled for that cache (see Documentation/mm/slub.rst).
|
||||
enabled for that cache (see Documentation/vm/slub.rst).
|
||||
|
||||
What: /sys/kernel/slab/<cache>/alloc_fastpath
|
||||
Date: February 2008
|
||||
|
|
@ -219,7 +219,7 @@ Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
|
|||
Description:
|
||||
The free_calls file is read-only and lists the locations of
|
||||
object frees if slab debugging is enabled (see
|
||||
Documentation/mm/slub.rst).
|
||||
Documentation/vm/slub.rst).
|
||||
|
||||
What: /sys/kernel/slab/<cache>/free_fastpath
|
||||
Date: February 2008
|
||||
|
|
|
|||
|
|
@ -57,44 +57,3 @@ Description:
|
|||
* 0 - default,
|
||||
* 1 - overboost,
|
||||
* 2 - silent
|
||||
|
||||
What: /sys/devices/platform/<platform>/gpu_mux_mode
|
||||
Date: Aug 2022
|
||||
KernelVersion: 6.1
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
Switch the GPU hardware MUX mode. Laptops with this feature can
|
||||
can be toggled to boot with only the dGPU (discrete mode) or in
|
||||
standard Optimus/Hybrid mode. On switch a reboot is required:
|
||||
|
||||
* 0 - Discrete GPU,
|
||||
* 1 - Optimus/Hybrid,
|
||||
|
||||
What: /sys/devices/platform/<platform>/dgpu_disable
|
||||
Date: Aug 2022
|
||||
KernelVersion: 5.17
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
Disable discrete GPU:
|
||||
* 0 - Enable dGPU,
|
||||
* 1 - Disable dGPU
|
||||
|
||||
What: /sys/devices/platform/<platform>/egpu_enable
|
||||
Date: Aug 2022
|
||||
KernelVersion: 5.17
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
Enable the external GPU paired with ROG X-Flow laptops.
|
||||
Toggling this setting will also trigger ACPI to disable the dGPU:
|
||||
|
||||
* 0 - Disable,
|
||||
* 1 - Enable
|
||||
|
||||
What: /sys/devices/platform/<platform>/panel_od
|
||||
Date: Aug 2022
|
||||
KernelVersion: 5.17
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
Enable an LCD response-time boost to reduce or remove ghosting:
|
||||
* 0 - Disable,
|
||||
* 1 - Enable
|
||||
|
|
|
|||
|
|
@ -1,15 +0,0 @@
|
|||
What: /sys/bus/platform/devices/*/srpd
|
||||
Date: July 2022
|
||||
KernelVersion: 5.21
|
||||
Contact: Florian Fainelli <f.fainelli@gmail.com>
|
||||
Description:
|
||||
Self Refresh Power Down (SRPD) inactivity timeout counted in
|
||||
internal DDR controller clock cycles. Possible values range
|
||||
from 0 (disable inactivity timeout) to 65535 (0xffff).
|
||||
|
||||
What: /sys/bus/platform/devices/*/frequency
|
||||
Date: July 2022
|
||||
KernelVersion: 5.21
|
||||
Contact: Florian Fainelli <f.fainelli@gmail.com>
|
||||
Description:
|
||||
DDR PHY frequency in Hz.
|
||||
|
|
@ -2,8 +2,8 @@ What: /sys/bus/platform/devices/ci_hdrc.0/role
|
|||
Date: Mar 2017
|
||||
Contact: Peter Chen <peter.chen@nxp.com>
|
||||
Description:
|
||||
When read, it returns string "gadget" or "host", indicating
|
||||
the current controller role.
|
||||
It returns string "gadget" or "host" when read it, it indicates
|
||||
current controller role.
|
||||
|
||||
It will do role switch when "gadget" or "host" is written to it.
|
||||
It will do role switch when write "gadget" or "host" to it.
|
||||
Only controller at dual-role configuration supports writing.
|
||||
|
|
|
|||
|
|
@ -1,39 +0,0 @@
|
|||
What: /sys/devices/virtual/misc/intel_ifs_<N>/run_test
|
||||
Date: April 21 2022
|
||||
KernelVersion: 5.19
|
||||
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
|
||||
Description: Write <cpu#> to trigger IFS test for one online core.
|
||||
Note that the test is per core. The cpu# can be
|
||||
for any thread on the core. Running on one thread
|
||||
completes the test for the core containing that thread.
|
||||
Example: to test the core containing cpu5: echo 5 >
|
||||
/sys/devices/platform/intel_ifs.<N>/run_test
|
||||
|
||||
What: /sys/devices/virtual/misc/intel_ifs_<N>/status
|
||||
Date: April 21 2022
|
||||
KernelVersion: 5.19
|
||||
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
|
||||
Description: The status of the last test. It can be one of "pass", "fail"
|
||||
or "untested".
|
||||
|
||||
What: /sys/devices/virtual/misc/intel_ifs_<N>/details
|
||||
Date: April 21 2022
|
||||
KernelVersion: 5.19
|
||||
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
|
||||
Description: Additional information regarding the last test. The details file reports
|
||||
the hex value of the SCAN_STATUS MSR. Note that the error_code field
|
||||
may contain driver defined software code not defined in the Intel SDM.
|
||||
|
||||
What: /sys/devices/virtual/misc/intel_ifs_<N>/image_version
|
||||
Date: April 21 2022
|
||||
KernelVersion: 5.19
|
||||
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
|
||||
Description: Version (hexadecimal) of loaded IFS binary image. If no scan image
|
||||
is loaded reports "none".
|
||||
|
||||
What: /sys/devices/virtual/misc/intel_ifs_<N>/reload
|
||||
Date: April 21 2022
|
||||
KernelVersion: 5.19
|
||||
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
|
||||
Description: Write "1" (or "y" or "Y") to reload the IFS image from
|
||||
/lib/firmware/intel/ifs/ff-mm-ss.scan.
|
||||
|
|
@ -152,7 +152,7 @@ Description:
|
|||
case further investigation is required to determine which
|
||||
device is causing the problem. Note that genuine RTC clock
|
||||
values (such as when pm_trace has not been used), can still
|
||||
match a device and output its name here.
|
||||
match a device and output it's name here.
|
||||
|
||||
What: /sys/power/pm_async
|
||||
Date: January 2009
|
||||
|
|
|
|||
13
Documentation/COPYING-logo
Normal file
13
Documentation/COPYING-logo
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
This is the full-colour version of the currently unofficial Linux logo
|
||||
("currently unofficial" just means that there has been no paperwork and
|
||||
that I have not really announced it yet). It was created by Larry Ewing,
|
||||
and is freely usable as long as you acknowledge Larry as the original
|
||||
artist.
|
||||
|
||||
Note that there are black-and-white versions of this available that
|
||||
scale down to smaller sizes and are better for letterheads or whatever
|
||||
you want to use it for: for the full range of logos take a look at
|
||||
Larry's web-page:
|
||||
|
||||
https://www.isc.tamu.edu/~lewing/linux/
|
||||
|
||||
|
|
@ -1,22 +1,23 @@
|
|||
config WARN_MISSING_DOCUMENTS
|
||||
|
||||
bool "Warn if there's a missing documentation file"
|
||||
depends on COMPILE_TEST
|
||||
help
|
||||
It is not uncommon that a document gets renamed.
|
||||
This option makes the Kernel to check for missing dependencies,
|
||||
warning when something is missing. Works only if the Kernel
|
||||
is built from a git tree.
|
||||
It is not uncommon that a document gets renamed.
|
||||
This option makes the Kernel to check for missing dependencies,
|
||||
warning when something is missing. Works only if the Kernel
|
||||
is built from a git tree.
|
||||
|
||||
If unsure, select 'N'.
|
||||
If unsure, select 'N'.
|
||||
|
||||
config WARN_ABI_ERRORS
|
||||
bool "Warn if there are errors at ABI files"
|
||||
depends on COMPILE_TEST
|
||||
help
|
||||
The files under Documentation/ABI should follow what's
|
||||
described at Documentation/ABI/README. Yet, as they're manually
|
||||
written, it would be possible that some of those files would
|
||||
have errors that would break them for being parsed by
|
||||
scripts/get_abi.pl. Add a check to verify them.
|
||||
The files under Documentation/ABI should follow what's
|
||||
described at Documentation/ABI/README. Yet, as they're manually
|
||||
written, it would be possible that some of those files would
|
||||
have errors that would break them for being parsed by
|
||||
scripts/get_abi.pl. Add a check to verify them.
|
||||
|
||||
If unsure, select 'N'.
|
||||
If unsure, select 'N'.
|
||||
|
|
|
|||
|
|
@ -13,8 +13,6 @@ PCI Endpoint Framework
|
|||
pci-test-howto
|
||||
pci-ntb-function
|
||||
pci-ntb-howto
|
||||
pci-vntb-function
|
||||
pci-vntb-howto
|
||||
|
||||
function/binding/pci-test
|
||||
function/binding/pci-ntb
|
||||
|
|
|
|||
|
|
@ -1,129 +0,0 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=================
|
||||
PCI vNTB Function
|
||||
=================
|
||||
|
||||
:Author: Frank Li <Frank.Li@nxp.com>
|
||||
|
||||
The difference between PCI NTB function and PCI vNTB function is
|
||||
|
||||
PCI NTB function need at two endpoint instances and connect HOST1
|
||||
and HOST2.
|
||||
|
||||
PCI vNTB function only use one host and one endpoint(EP), use NTB
|
||||
connect EP and PCI host
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
|
||||
+------------+ +---------------------------------------+
|
||||
| | | |
|
||||
+------------+ | +--------------+
|
||||
| NTB | | | NTB |
|
||||
| NetDev | | | NetDev |
|
||||
+------------+ | +--------------+
|
||||
| NTB | | | NTB |
|
||||
| Transfer | | | Transfer |
|
||||
+------------+ | +--------------+
|
||||
| | | | |
|
||||
| PCI NTB | | | |
|
||||
| EPF | | | |
|
||||
| Driver | | | PCI Virtual |
|
||||
| | +---------------+ | NTB Driver |
|
||||
| | | PCI EP NTB |<------>| |
|
||||
| | | FN Driver | | |
|
||||
+------------+ +---------------+ +--------------+
|
||||
| | | | | |
|
||||
| PCI BUS | <-----> | PCI EP BUS | | Virtual PCI |
|
||||
| | PCI | | | BUS |
|
||||
+------------+ +---------------+--------+--------------+
|
||||
PCI RC PCI EP
|
||||
|
||||
Constructs used for Implementing vNTB
|
||||
=====================================
|
||||
|
||||
1) Config Region
|
||||
2) Self Scratchpad Registers
|
||||
3) Peer Scratchpad Registers
|
||||
4) Doorbell (DB) Registers
|
||||
5) Memory Window (MW)
|
||||
|
||||
|
||||
Config Region:
|
||||
--------------
|
||||
|
||||
It is same as PCI NTB Function driver
|
||||
|
||||
Scratchpad Registers:
|
||||
---------------------
|
||||
|
||||
It is appended after Config region.
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
|
||||
+--------------------------------------------------+ Base
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| Common Config Register |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
+-----------------------+--------------------------+ Base + span_offset
|
||||
| | |
|
||||
| Peer Span Space | Span Space |
|
||||
| | |
|
||||
| | |
|
||||
+-----------------------+--------------------------+ Base + span_offset
|
||||
| | | + span_count * 4
|
||||
| | |
|
||||
| Span Space | Peer Span Space |
|
||||
| | |
|
||||
+-----------------------+--------------------------+
|
||||
Virtual PCI Pcie Endpoint
|
||||
NTB Driver NTB Driver
|
||||
|
||||
|
||||
Doorbell Registers:
|
||||
-------------------
|
||||
|
||||
Doorbell Registers are used by the hosts to interrupt each other.
|
||||
|
||||
Memory Window:
|
||||
--------------
|
||||
|
||||
Actual transfer of data between the two hosts will happen using the
|
||||
memory window.
|
||||
|
||||
Modeling Constructs:
|
||||
====================
|
||||
|
||||
32-bit BARs.
|
||||
|
||||
====== ===============
|
||||
BAR NO CONSTRUCTS USED
|
||||
====== ===============
|
||||
BAR0 Config Region
|
||||
BAR1 Doorbell
|
||||
BAR2 Memory Window 1
|
||||
BAR3 Memory Window 2
|
||||
BAR4 Memory Window 3
|
||||
BAR5 Memory Window 4
|
||||
====== ===============
|
||||
|
||||
64-bit BARs.
|
||||
|
||||
====== ===============================
|
||||
BAR NO CONSTRUCTS USED
|
||||
====== ===============================
|
||||
BAR0 Config Region + Scratchpad
|
||||
BAR1
|
||||
BAR2 Doorbell
|
||||
BAR3
|
||||
BAR4 Memory Window 1
|
||||
BAR5
|
||||
====== ===============================
|
||||
|
||||
|
||||
|
|
@ -1,167 +0,0 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===================================================================
|
||||
PCI Non-Transparent Bridge (NTB) Endpoint Function (EPF) User Guide
|
||||
===================================================================
|
||||
|
||||
:Author: Frank Li <Frank.Li@nxp.com>
|
||||
|
||||
This document is a guide to help users use pci-epf-vntb function driver
|
||||
and ntb_hw_epf host driver for NTB functionality. The list of steps to
|
||||
be followed in the host side and EP side is given below. For the hardware
|
||||
configuration and internals of NTB using configurable endpoints see
|
||||
Documentation/PCI/endpoint/pci-vntb-function.rst
|
||||
|
||||
Endpoint Device
|
||||
===============
|
||||
|
||||
Endpoint Controller Devices
|
||||
---------------------------
|
||||
|
||||
To find the list of endpoint controller devices in the system::
|
||||
|
||||
# ls /sys/class/pci_epc/
|
||||
5f010000.pcie_ep
|
||||
|
||||
If PCI_ENDPOINT_CONFIGFS is enabled::
|
||||
|
||||
# ls /sys/kernel/config/pci_ep/controllers
|
||||
5f010000.pcie_ep
|
||||
|
||||
Endpoint Function Drivers
|
||||
-------------------------
|
||||
|
||||
To find the list of endpoint function drivers in the system::
|
||||
|
||||
# ls /sys/bus/pci-epf/drivers
|
||||
pci_epf_ntb pci_epf_test pci_epf_vntb
|
||||
|
||||
If PCI_ENDPOINT_CONFIGFS is enabled::
|
||||
|
||||
# ls /sys/kernel/config/pci_ep/functions
|
||||
pci_epf_ntb pci_epf_test pci_epf_vntb
|
||||
|
||||
|
||||
Creating pci-epf-vntb Device
|
||||
----------------------------
|
||||
|
||||
PCI endpoint function device can be created using the configfs. To create
|
||||
pci-epf-vntb device, the following commands can be used::
|
||||
|
||||
# mount -t configfs none /sys/kernel/config
|
||||
# cd /sys/kernel/config/pci_ep/
|
||||
# mkdir functions/pci_epf_vntb/func1
|
||||
|
||||
The "mkdir func1" above creates the pci-epf-ntb function device that will
|
||||
be probed by pci_epf_vntb driver.
|
||||
|
||||
The PCI endpoint framework populates the directory with the following
|
||||
configurable fields::
|
||||
|
||||
# ls functions/pci_epf_ntb/func1
|
||||
baseclass_code deviceid msi_interrupts pci-epf-ntb.0
|
||||
progif_code secondary subsys_id vendorid
|
||||
cache_line_size interrupt_pin msix_interrupts primary
|
||||
revid subclass_code subsys_vendor_id
|
||||
|
||||
The PCI endpoint function driver populates these entries with default values
|
||||
when the device is bound to the driver. The pci-epf-vntb driver populates
|
||||
vendorid with 0xffff and interrupt_pin with 0x0001::
|
||||
|
||||
# cat functions/pci_epf_vntb/func1/vendorid
|
||||
0xffff
|
||||
# cat functions/pci_epf_vntb/func1/interrupt_pin
|
||||
0x0001
|
||||
|
||||
|
||||
Configuring pci-epf-vntb Device
|
||||
-------------------------------
|
||||
|
||||
The user can configure the pci-epf-vntb device using its configfs entry. In order
|
||||
to change the vendorid and the deviceid, the following
|
||||
commands can be used::
|
||||
|
||||
# echo 0x1957 > functions/pci_epf_vntb/func1/vendorid
|
||||
# echo 0x0809 > functions/pci_epf_vntb/func1/deviceid
|
||||
|
||||
In order to configure NTB specific attributes, a new sub-directory to func1
|
||||
should be created::
|
||||
|
||||
# mkdir functions/pci_epf_vntb/func1/pci_epf_vntb.0/
|
||||
|
||||
The NTB function driver will populate this directory with various attributes
|
||||
that can be configured by the user::
|
||||
|
||||
# ls functions/pci_epf_vntb/func1/pci_epf_vntb.0/
|
||||
db_count mw1 mw2 mw3 mw4 num_mws
|
||||
spad_count
|
||||
|
||||
A sample configuration for NTB function is given below::
|
||||
|
||||
# echo 4 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/db_count
|
||||
# echo 128 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/spad_count
|
||||
# echo 1 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/num_mws
|
||||
# echo 0x100000 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/mw1
|
||||
|
||||
A sample configuration for virtual NTB driver for virutal PCI bus::
|
||||
|
||||
# echo 0x1957 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_vid
|
||||
# echo 0x080A > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_pid
|
||||
# echo 0x10 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vbus_number
|
||||
|
||||
Binding pci-epf-ntb Device to EP Controller
|
||||
--------------------------------------------
|
||||
|
||||
NTB function device should be attached to PCI endpoint controllers
|
||||
connected to the host.
|
||||
|
||||
# ln -s controllers/5f010000.pcie_ep functions/pci-epf-ntb/func1/primary
|
||||
|
||||
Once the above step is completed, the PCI endpoint controllers are ready to
|
||||
establish a link with the host.
|
||||
|
||||
|
||||
Start the Link
|
||||
--------------
|
||||
|
||||
In order for the endpoint device to establish a link with the host, the _start_
|
||||
field should be populated with '1'. For NTB, both the PCI endpoint controllers
|
||||
should establish link with the host (imx8 don't need this steps)::
|
||||
|
||||
# echo 1 > controllers/5f010000.pcie_ep/start
|
||||
|
||||
RootComplex Device
|
||||
==================
|
||||
|
||||
lspci Output at Host side
|
||||
-------------------------
|
||||
|
||||
Note that the devices listed here correspond to the values populated in
|
||||
"Creating pci-epf-ntb Device" section above::
|
||||
|
||||
# lspci
|
||||
00:00.0 PCI bridge: Freescale Semiconductor Inc Device 0000 (rev 01)
|
||||
01:00.0 RAM memory: Freescale Semiconductor Inc Device 0809
|
||||
|
||||
Endpoint Device / Virtual PCI bus
|
||||
=================================
|
||||
|
||||
lspci Output at EP Side / Virtual PCI bus
|
||||
-----------------------------------------
|
||||
|
||||
Note that the devices listed here correspond to the values populated in
|
||||
"Creating pci-epf-ntb Device" section above::
|
||||
|
||||
# lspci
|
||||
10:00.0 Unassigned class [ffff]: Dawicontrol Computersysteme GmbH Device 1234 (rev ff)
|
||||
|
||||
Using ntb_hw_epf Device
|
||||
-----------------------
|
||||
|
||||
The host side software follows the standard NTB software architecture in Linux.
|
||||
All the existing client side NTB utilities like NTB Transport Client and NTB
|
||||
Netdev, NTB Ping Pong Test Client and NTB Tool Test Client can be used with NTB
|
||||
function device.
|
||||
|
||||
For more information on NTB see
|
||||
:doc:`Non-Transparent Bridge <../../driver-api/ntb>`
|
||||
|
|
@ -125,14 +125,14 @@ Following piece of code illustrates the usage of the SR-IOV API.
|
|||
...
|
||||
}
|
||||
|
||||
static int dev_suspend(struct device *dev)
|
||||
static int dev_suspend(struct pci_dev *dev, pm_message_t state)
|
||||
{
|
||||
...
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static int dev_resume(struct device *dev)
|
||||
static int dev_resume(struct pci_dev *dev)
|
||||
{
|
||||
...
|
||||
|
||||
|
|
@ -165,7 +165,8 @@ Following piece of code illustrates the usage of the SR-IOV API.
|
|||
.id_table = dev_id_table,
|
||||
.probe = dev_probe,
|
||||
.remove = dev_remove,
|
||||
.driver.pm = &dev_pm_ops,
|
||||
.suspend = dev_suspend,
|
||||
.resume = dev_resume,
|
||||
.shutdown = dev_shutdown,
|
||||
.sriov_configure = dev_sriov_configure,
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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 dma_set_mask() with
|
||||
to "register" this capability by calling pci_set_dma_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
|
||||
dma_set_mask() as they are 64-bit DMA devices.
|
||||
set_dma_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
|
||||
|
|
|
|||
|
|
@ -125,7 +125,7 @@ implementation of that functionality. To support the historical interface of
|
|||
mmap() through files in /proc/bus/pci, platforms may also set HAVE_PCI_MMAP.
|
||||
|
||||
Alternatively, platforms which set HAVE_PCI_MMAP may provide their own
|
||||
implementation of pci_mmap_resource_range() instead of defining
|
||||
implementation of pci_mmap_page_range() instead of defining
|
||||
ARCH_GENERIC_PCI_MMAP_RESOURCE.
|
||||
|
||||
Platforms which support write-combining maps of PCI resources must define
|
||||
|
|
|
|||
|
|
@ -973,7 +973,7 @@ The ``->dynticks`` field counts the corresponding CPU's transitions to
|
|||
and from either dyntick-idle or user mode, so that this counter has an
|
||||
even value when the CPU is in dyntick-idle mode or user mode and an odd
|
||||
value otherwise. The transitions to/from user mode need to be counted
|
||||
for user mode adaptive-ticks support (see Documentation/timers/no_hz.rst).
|
||||
for user mode adaptive-ticks support (see timers/NO_HZ.txt).
|
||||
|
||||
The ``->rcu_need_heavy_qs`` field is used to record the fact that the
|
||||
RCU core code would really like to see a quiescent state from the
|
||||
|
|
|
|||
|
|
@ -406,7 +406,7 @@ In earlier implementations, the task requesting the expedited grace
|
|||
period also drove it to completion. This straightforward approach had
|
||||
the disadvantage of needing to account for POSIX signals sent to user
|
||||
tasks, so more recent implemementations use the Linux kernel's
|
||||
workqueues (see Documentation/core-api/workqueue.rst).
|
||||
`workqueues <https://www.kernel.org/doc/Documentation/core-api/workqueue.rst>`__.
|
||||
|
||||
The requesting task still does counter snapshotting and funnel-lock
|
||||
processing, but the task reaching the top of the funnel lock does a
|
||||
|
|
|
|||
|
|
@ -370,8 +370,8 @@ pointer fetched by rcu_dereference() may not be used outside of the
|
|||
outermost RCU read-side critical section containing that
|
||||
rcu_dereference(), unless protection of the corresponding data
|
||||
element has been passed from RCU to some other synchronization
|
||||
mechanism, most commonly locking or reference counting
|
||||
(see ../../rcuref.rst).
|
||||
mechanism, most commonly locking or `reference
|
||||
counting <https://www.kernel.org/doc/Documentation/RCU/rcuref.txt>`__.
|
||||
|
||||
.. |high-quality implementation of C11 memory_order_consume [PDF]| replace:: high-quality implementation of C11 ``memory_order_consume`` [PDF]
|
||||
.. _high-quality implementation of C11 memory_order_consume [PDF]: http://www.rdrop.com/users/paulmck/RCU/consume.2015.07.13a.pdf
|
||||
|
|
@ -1844,10 +1844,10 @@ that meets this requirement.
|
|||
|
||||
Furthermore, NMI handlers can be interrupted by what appear to RCU to be
|
||||
normal interrupts. One way that this can happen is for code that
|
||||
directly invokes ct_irq_enter() and ct_irq_exit() to be called
|
||||
directly invokes rcu_irq_enter() and rcu_irq_exit() to be called
|
||||
from an NMI handler. This astonishing fact of life prompted the current
|
||||
code structure, which has ct_irq_enter() invoking
|
||||
ct_nmi_enter() and ct_irq_exit() invoking ct_nmi_exit().
|
||||
code structure, which has rcu_irq_enter() invoking
|
||||
rcu_nmi_enter() and rcu_irq_exit() invoking rcu_nmi_exit().
|
||||
And yes, I also learned of this requirement the hard way.
|
||||
|
||||
Loadable Modules
|
||||
|
|
@ -2195,7 +2195,7 @@ scheduling-clock interrupt be enabled when RCU needs it to be:
|
|||
sections, and RCU believes this CPU to be idle, no problem. This
|
||||
sort of thing is used by some architectures for light-weight
|
||||
exception handlers, which can then avoid the overhead of
|
||||
ct_irq_enter() and ct_irq_exit() at exception entry and
|
||||
rcu_irq_enter() and rcu_irq_exit() at exception entry and
|
||||
exit, respectively. Some go further and avoid the entireties of
|
||||
irq_enter() and irq_exit().
|
||||
Just make very sure you are running some of your tests with
|
||||
|
|
@ -2226,7 +2226,7 @@ scheduling-clock interrupt be enabled when RCU needs it to be:
|
|||
+-----------------------------------------------------------------------+
|
||||
| **Answer**: |
|
||||
+-----------------------------------------------------------------------+
|
||||
| One approach is to do ``ct_irq_exit();ct_irq_enter();`` every so |
|
||||
| One approach is to do ``rcu_irq_exit();rcu_irq_enter();`` every so |
|
||||
| often. But given that long-running interrupt handlers can cause other |
|
||||
| problems, not least for response time, shouldn't you work to keep |
|
||||
| your interrupt handler's runtime within reasonable bounds? |
|
||||
|
|
@ -2654,38 +2654,6 @@ synchronize_rcu(), and rcu_barrier(), respectively. In
|
|||
three APIs are therefore implemented by separate functions that check
|
||||
for voluntary context switches.
|
||||
|
||||
Tasks Rude RCU
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Some forms of tracing need to wait for all preemption-disabled regions
|
||||
of code running on any online CPU, including those executed when RCU is
|
||||
not watching. This means that synchronize_rcu() is insufficient, and
|
||||
Tasks Rude RCU must be used instead. This flavor of RCU does its work by
|
||||
forcing a workqueue to be scheduled on each online CPU, hence the "Rude"
|
||||
moniker. And this operation is considered to be quite rude by real-time
|
||||
workloads that don't want their ``nohz_full`` CPUs receiving IPIs and
|
||||
by battery-powered systems that don't want their idle CPUs to be awakened.
|
||||
|
||||
The tasks-rude-RCU API is also reader-marking-free and thus quite compact,
|
||||
consisting of call_rcu_tasks_rude(), synchronize_rcu_tasks_rude(),
|
||||
and rcu_barrier_tasks_rude().
|
||||
|
||||
Tasks Trace RCU
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Some forms of tracing need to sleep in readers, but cannot tolerate
|
||||
SRCU's read-side overhead, which includes a full memory barrier in both
|
||||
srcu_read_lock() and srcu_read_unlock(). This need is handled by a
|
||||
Tasks Trace RCU that uses scheduler locking and IPIs to synchronize with
|
||||
readers. Real-time systems that cannot tolerate IPIs may build their
|
||||
kernels with ``CONFIG_TASKS_TRACE_RCU_READ_MB=y``, which avoids the IPIs at
|
||||
the expense of adding full memory barriers to the read-side primitives.
|
||||
|
||||
The tasks-trace-RCU API is also reasonably compact,
|
||||
consisting of rcu_read_lock_trace(), rcu_read_unlock_trace(),
|
||||
rcu_read_lock_trace_held(), call_rcu_tasks_trace(),
|
||||
synchronize_rcu_tasks_trace(), and rcu_barrier_tasks_trace().
|
||||
|
||||
Possible Future Changes
|
||||
-----------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -33,8 +33,8 @@ Situation 1: Hash Tables
|
|||
|
||||
Hash tables are often implemented as an array, where each array entry
|
||||
has a linked-list hash chain. Each hash chain can be protected by RCU
|
||||
as described in listRCU.rst. This approach also applies to other
|
||||
array-of-list situations, such as radix trees.
|
||||
as described in the listRCU.txt document. This approach also applies
|
||||
to other array-of-list situations, such as radix trees.
|
||||
|
||||
.. _static_arrays:
|
||||
|
||||
|
|
|
|||
|
|
@ -66,13 +66,8 @@ over a rather long period of time, but improvements are always welcome!
|
|||
As a rough rule of thumb, any dereference of an RCU-protected
|
||||
pointer must be covered by rcu_read_lock(), rcu_read_lock_bh(),
|
||||
rcu_read_lock_sched(), or by the appropriate update-side lock.
|
||||
Explicit disabling of preemption (preempt_disable(), for example)
|
||||
can serve as rcu_read_lock_sched(), but is less readable and
|
||||
prevents lockdep from detecting locking issues.
|
||||
|
||||
Please not that you *cannot* rely on code known to be built
|
||||
only in non-preemptible kernels. Such code can and will break,
|
||||
especially in kernels built with CONFIG_PREEMPT_COUNT=y.
|
||||
Disabling of preemption can serve as rcu_read_lock_sched(), but
|
||||
is less readable and prevents lockdep from detecting locking issues.
|
||||
|
||||
Letting RCU-protected pointers "leak" out of an RCU read-side
|
||||
critical section is every bit as bad as letting them leak out
|
||||
|
|
@ -145,7 +140,8 @@ over a rather long period of time, but improvements are always welcome!
|
|||
prevents destructive compiler optimizations. However,
|
||||
with a bit of devious creativity, it is possible to
|
||||
mishandle the return value from rcu_dereference().
|
||||
Please see rcu_dereference.rst for more information.
|
||||
Please see rcu_dereference.txt in this directory for
|
||||
more information.
|
||||
|
||||
The rcu_dereference() primitive is used by the
|
||||
various "_rcu()" list-traversal primitives, such
|
||||
|
|
@ -155,7 +151,7 @@ over a rather long period of time, but improvements are always welcome!
|
|||
primitives. This is particularly useful in code that
|
||||
is common to readers and updaters. However, lockdep
|
||||
will complain if you access rcu_dereference() outside
|
||||
of an RCU read-side critical section. See lockdep.rst
|
||||
of an RCU read-side critical section. See lockdep.txt
|
||||
to learn what to do about this.
|
||||
|
||||
Of course, neither rcu_dereference() nor the "_rcu()"
|
||||
|
|
@ -190,9 +186,6 @@ over a rather long period of time, but improvements are always welcome!
|
|||
|
||||
5. If call_rcu() or call_srcu() is used, the callback function will
|
||||
be called from softirq context. In particular, it cannot block.
|
||||
If you need the callback to block, run that code in a workqueue
|
||||
handler scheduled from the callback. The queue_rcu_work()
|
||||
function does this for you in the case of call_rcu().
|
||||
|
||||
6. Since synchronize_rcu() can block, it cannot be called
|
||||
from any sort of irq context. The same rule applies
|
||||
|
|
@ -305,8 +298,7 @@ over a rather long period of time, but improvements are always welcome!
|
|||
the machine.
|
||||
|
||||
d. Periodically invoke synchronize_rcu(), permitting a limited
|
||||
number of updates per grace period. Better yet, periodically
|
||||
invoke rcu_barrier() to wait for all outstanding callbacks.
|
||||
number of updates per grace period.
|
||||
|
||||
The same cautions apply to call_srcu() and kfree_rcu().
|
||||
|
||||
|
|
@ -331,7 +323,7 @@ over a rather long period of time, but improvements are always welcome!
|
|||
primitives when the update-side lock is held is that doing so
|
||||
can be quite helpful in reducing code bloat when common code is
|
||||
shared between readers and updaters. Additional primitives
|
||||
are provided for this case, as discussed in lockdep.rst.
|
||||
are provided for this case, as discussed in lockdep.txt.
|
||||
|
||||
One exception to this rule is when data is only ever added to
|
||||
the linked data structure, and is never removed during any
|
||||
|
|
@ -486,6 +478,6 @@ over a rather long period of time, but improvements are always welcome!
|
|||
So if you need to wait for both an RCU grace period and for
|
||||
all pre-existing call_rcu() callbacks, you will need to execute
|
||||
both rcu_barrier() and synchronize_rcu(), if necessary, using
|
||||
something like workqueues to execute them concurrently.
|
||||
something like workqueues to to execute them concurrently.
|
||||
|
||||
See rcubarrier.rst for more information.
|
||||
See rcubarrier.txt for more information.
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ checking of rcu_dereference() primitives:
|
|||
rcu_access_pointer(p):
|
||||
Return the value of the pointer and omit all barriers,
|
||||
but retain the compiler constraints that prevent duplicating
|
||||
or coalescsing. This is useful when testing the
|
||||
or coalescsing. This is useful when when testing the
|
||||
value of the pointer itself, for example, against NULL.
|
||||
|
||||
The rcu_dereference_check() check expression can be any boolean
|
||||
|
|
|
|||
|
|
@ -10,8 +10,9 @@ A "grace period" must elapse between the two parts, and this grace period
|
|||
must be long enough that any readers accessing the item being deleted have
|
||||
since dropped their references. For example, an RCU-protected deletion
|
||||
from a linked list would first remove the item from the list, wait for
|
||||
a grace period to elapse, then free the element. See listRCU.rst for more
|
||||
information on using RCU with linked lists.
|
||||
a grace period to elapse, then free the element. See the
|
||||
:ref:`Documentation/RCU/listRCU.rst <list_rcu_doc>` for more information on
|
||||
using RCU with linked lists.
|
||||
|
||||
Frequently Asked Questions
|
||||
--------------------------
|
||||
|
|
@ -49,7 +50,7 @@ Frequently Asked Questions
|
|||
- If I am running on a uniprocessor kernel, which can only do one
|
||||
thing at a time, why should I wait for a grace period?
|
||||
|
||||
See UP.rst for more information.
|
||||
See :ref:`Documentation/RCU/UP.rst <up_doc>` for more information.
|
||||
|
||||
- How can I see where RCU is currently used in the Linux kernel?
|
||||
|
||||
|
|
@ -63,13 +64,13 @@ Frequently Asked Questions
|
|||
|
||||
- What guidelines should I follow when writing code that uses RCU?
|
||||
|
||||
See checklist.rst.
|
||||
See the checklist.txt file in this directory.
|
||||
|
||||
- Why the name "RCU"?
|
||||
|
||||
"RCU" stands for "read-copy update".
|
||||
listRCU.rst has more information on where this name came from, search
|
||||
for "read-copy update" to find it.
|
||||
:ref:`Documentation/RCU/listRCU.rst <list_rcu_doc>` has more information on where
|
||||
this name came from, search for "read-copy update" to find it.
|
||||
|
||||
- I hear that RCU is patented? What is with that?
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue