initial uploader
This commit is contained in:
commit
8a4d594bbd
README.md
linux-schizos
.clang-format.cocciconfig.editorconfig.get_maintainer.ignore.gitattributes.gitignore.mailmap.rustfmt.tomlCOPYINGCREDITS
Documentation
.gitignore
ABI
README
obsolete
o2cbprocfs-i8ksysfs-bus-iiosysfs-bus-usbsysfs-class-typecsysfs-cpuidlesysfs-driver-hid-roccat-arvosysfs-driver-hid-roccat-iskusysfs-driver-hid-roccat-koneplussysfs-driver-hid-roccat-konepuresysfs-driver-hid-roccat-kovaplussysfs-driver-hid-roccat-luasysfs-driver-hid-roccat-pyrasysfs-driver-hid-roccat-ryossysfs-driver-hid-roccat-savusysfs-driver-intel_pmc_bxtsysfs-firmware-acpisysfs-gpiosysfs-kernel-fadump_enabledsysfs-kernel-fadump_registeredsysfs-kernel-fadump_release_mem
removed
devfsdv1394ip_queuenet_dmao2cbraw1394sysfs-bus-nfitsysfs-class-rfkillsysfs-kernel-fadump_release_opalcoresysfs-kernel-uidssysfs-mcesysfs-selinux-checkreqprotsysfs-selinux-disablevideo1394
stable
firewire-cdevo2cbprocfs-audit_loginuidsyscallssysfs-acpi-pmprofilesysfs-blocksysfs-bus-firewiresysfs-bus-fsl-mcsysfs-bus-mhisysfs-bus-nvmemsysfs-bus-usbsysfs-bus-vmbussysfs-bus-w1sysfs-bus-xen-backendsysfs-class-backlightsysfs-class-infinibandsysfs-class-rfkillsysfs-class-tpmsysfs-class-ubisysfs-class-udcsysfs-devicessysfs-devices-nodesysfs-devices-system-cpusysfs-devices-system-xen_memorysysfs-driver-aspeed-vuartsysfs-driver-dma-idxdsysfs-driver-dma-ioatdmasysfs-driver-firmware-zynqmpsysfs-driver-ib_srpsysfs-driver-mlxreg-iosysfs-driver-qla2xxxsysfs-driver-speakupsysfs-driver-usb-usbtmcsysfs-driver-w1_ds2438sysfs-driver-w1_ds28e04sysfs-driver-w1_ds28ea00sysfs-firmware-efi-varssysfs-firmware-opal-dumpsysfs-firmware-opal-elogsysfs-fs-orangefssysfs-hypervisor-xensysfs-kernel-notessysfs-modulesysfs-platform-wmi-bmofsysfs-transport-srpthermal-notificationvdso
testing
|
|
@ -0,0 +1,2 @@
|
|||
# SchizOS project files
|
||||
This is so pre alpha im not even going to publish it
|
||||
|
|
@ -0,0 +1,743 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
#
|
||||
# clang-format configuration file. Intended for clang-format >= 11.
|
||||
#
|
||||
# For more information, see:
|
||||
#
|
||||
# Documentation/process/clang-format.rst
|
||||
# https://clang.llvm.org/docs/ClangFormat.html
|
||||
# https://clang.llvm.org/docs/ClangFormatStyleOptions.html
|
||||
#
|
||||
---
|
||||
AccessModifierOffset: -4
|
||||
AlignAfterOpenBracket: Align
|
||||
AlignConsecutiveAssignments: false
|
||||
AlignConsecutiveDeclarations: false
|
||||
AlignEscapedNewlines: Left
|
||||
AlignOperands: true
|
||||
AlignTrailingComments: false
|
||||
AllowAllParametersOfDeclarationOnNextLine: false
|
||||
AllowShortBlocksOnASingleLine: false
|
||||
AllowShortCaseLabelsOnASingleLine: false
|
||||
AllowShortFunctionsOnASingleLine: None
|
||||
AllowShortIfStatementsOnASingleLine: false
|
||||
AllowShortLoopsOnASingleLine: false
|
||||
AlwaysBreakAfterDefinitionReturnType: None
|
||||
AlwaysBreakAfterReturnType: None
|
||||
AlwaysBreakBeforeMultilineStrings: false
|
||||
AlwaysBreakTemplateDeclarations: false
|
||||
BinPackArguments: true
|
||||
BinPackParameters: true
|
||||
BraceWrapping:
|
||||
AfterClass: false
|
||||
AfterControlStatement: false
|
||||
AfterEnum: false
|
||||
AfterFunction: true
|
||||
AfterNamespace: true
|
||||
AfterObjCDeclaration: false
|
||||
AfterStruct: false
|
||||
AfterUnion: false
|
||||
AfterExternBlock: false
|
||||
BeforeCatch: false
|
||||
BeforeElse: false
|
||||
IndentBraces: false
|
||||
SplitEmptyFunction: true
|
||||
SplitEmptyRecord: true
|
||||
SplitEmptyNamespace: true
|
||||
BreakBeforeBinaryOperators: None
|
||||
BreakBeforeBraces: Custom
|
||||
BreakBeforeInheritanceComma: false
|
||||
BreakBeforeTernaryOperators: false
|
||||
BreakConstructorInitializersBeforeComma: false
|
||||
BreakConstructorInitializers: BeforeComma
|
||||
BreakAfterJavaFieldAnnotations: false
|
||||
BreakStringLiterals: false
|
||||
ColumnLimit: 80
|
||||
CommentPragmas: '^ IWYU pragma:'
|
||||
CompactNamespaces: false
|
||||
ConstructorInitializerAllOnOneLineOrOnePerLine: false
|
||||
ConstructorInitializerIndentWidth: 8
|
||||
ContinuationIndentWidth: 8
|
||||
Cpp11BracedListStyle: false
|
||||
DerivePointerAlignment: false
|
||||
DisableFormat: false
|
||||
ExperimentalAutoDetectBinPacking: false
|
||||
FixNamespaceComments: false
|
||||
|
||||
# Taken from:
|
||||
# git grep -h '^#define [^[:space:]]*for_each[^[:space:]]*(' include/ tools/ \
|
||||
# | sed "s,^#define \([^[:space:]]*for_each[^[:space:]]*\)(.*$, - '\1'," \
|
||||
# | LC_ALL=C sort -u
|
||||
ForEachMacros:
|
||||
- '__ata_qc_for_each'
|
||||
- '__bio_for_each_bvec'
|
||||
- '__bio_for_each_segment'
|
||||
- '__evlist__for_each_entry'
|
||||
- '__evlist__for_each_entry_continue'
|
||||
- '__evlist__for_each_entry_from'
|
||||
- '__evlist__for_each_entry_reverse'
|
||||
- '__evlist__for_each_entry_safe'
|
||||
- '__for_each_mem_range'
|
||||
- '__for_each_mem_range_rev'
|
||||
- '__for_each_thread'
|
||||
- '__hlist_for_each_rcu'
|
||||
- '__map__for_each_symbol_by_name'
|
||||
- '__pci_bus_for_each_res0'
|
||||
- '__pci_bus_for_each_res1'
|
||||
- '__pci_dev_for_each_res0'
|
||||
- '__pci_dev_for_each_res1'
|
||||
- '__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'
|
||||
- '__sym_for_each'
|
||||
- 'apei_estatus_for_each_section'
|
||||
- 'ata_for_each_dev'
|
||||
- 'ata_for_each_link'
|
||||
- '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_all'
|
||||
- 'bio_for_each_folio_all'
|
||||
- 'bio_for_each_integrity_vec'
|
||||
- 'bio_for_each_segment'
|
||||
- 'bio_for_each_segment_all'
|
||||
- 'bio_list_for_each'
|
||||
- 'bip_for_each_vec'
|
||||
- 'bond_for_each_slave'
|
||||
- 'bond_for_each_slave_rcu'
|
||||
- 'bpf_for_each'
|
||||
- 'bpf_for_each_reg_in_vstate'
|
||||
- 'bpf_for_each_reg_in_vstate_mask'
|
||||
- 'bpf_for_each_spilled_reg'
|
||||
- 'bpf_object__for_each_map'
|
||||
- 'bpf_object__for_each_program'
|
||||
- 'btree_for_each_safe128'
|
||||
- 'btree_for_each_safe32'
|
||||
- 'btree_for_each_safe64'
|
||||
- 'btree_for_each_safel'
|
||||
- 'card_for_each_dev'
|
||||
- 'cgroup_taskset_for_each'
|
||||
- 'cgroup_taskset_for_each_leader'
|
||||
- 'cpu_aggr_map__for_each_idx'
|
||||
- 'cpufreq_for_each_efficient_entry_idx'
|
||||
- 'cpufreq_for_each_entry'
|
||||
- 'cpufreq_for_each_entry_idx'
|
||||
- 'cpufreq_for_each_valid_entry'
|
||||
- 'cpufreq_for_each_valid_entry_idx'
|
||||
- 'css_for_each_child'
|
||||
- 'css_for_each_descendant_post'
|
||||
- 'css_for_each_descendant_pre'
|
||||
- 'damon_for_each_region'
|
||||
- 'damon_for_each_region_from'
|
||||
- 'damon_for_each_region_safe'
|
||||
- 'damon_for_each_scheme'
|
||||
- 'damon_for_each_scheme_safe'
|
||||
- 'damon_for_each_target'
|
||||
- 'damon_for_each_target_safe'
|
||||
- 'damos_for_each_filter'
|
||||
- 'damos_for_each_filter_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'
|
||||
- 'drm_atomic_crtc_state_for_each_plane_state'
|
||||
- 'drm_atomic_for_each_plane_damage'
|
||||
- 'drm_client_for_each_connector_iter'
|
||||
- 'drm_client_for_each_modeset'
|
||||
- 'drm_connector_for_each_possible_encoder'
|
||||
- 'drm_exec_for_each_locked_object'
|
||||
- 'drm_exec_for_each_locked_object_reverse'
|
||||
- 'drm_for_each_bridge_in_chain'
|
||||
- 'drm_for_each_connector_iter'
|
||||
- 'drm_for_each_crtc'
|
||||
- 'drm_for_each_crtc_reverse'
|
||||
- 'drm_for_each_encoder'
|
||||
- 'drm_for_each_encoder_mask'
|
||||
- 'drm_for_each_fb'
|
||||
- 'drm_for_each_legacy_plane'
|
||||
- 'drm_for_each_plane'
|
||||
- 'drm_for_each_plane_mask'
|
||||
- 'drm_for_each_privobj'
|
||||
- 'drm_gem_for_each_gpuva'
|
||||
- 'drm_gem_for_each_gpuva_safe'
|
||||
- 'drm_gpuva_for_each_op'
|
||||
- 'drm_gpuva_for_each_op_from_reverse'
|
||||
- 'drm_gpuva_for_each_op_safe'
|
||||
- 'drm_gpuvm_for_each_va'
|
||||
- 'drm_gpuvm_for_each_va_range'
|
||||
- 'drm_gpuvm_for_each_va_range_safe'
|
||||
- 'drm_gpuvm_for_each_va_safe'
|
||||
- 'drm_mm_for_each_hole'
|
||||
- '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_cpu_port_continue_reverse'
|
||||
- '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_cpu_port'
|
||||
- 'dsa_tree_for_each_user_port'
|
||||
- 'dsa_tree_for_each_user_port_continue_reverse'
|
||||
- 'dso__for_each_symbol'
|
||||
- 'dsos__for_each_with_build_id'
|
||||
- 'elf_hash_for_each_possible'
|
||||
- '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_consumer_dev'
|
||||
- 'for_each_acpi_dev_match'
|
||||
- 'for_each_active_dev_scope'
|
||||
- 'for_each_active_drhd_unit'
|
||||
- 'for_each_active_iommu'
|
||||
- 'for_each_active_route'
|
||||
- 'for_each_aggr_pgid'
|
||||
- 'for_each_and_bit'
|
||||
- 'for_each_andnot_bit'
|
||||
- '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'
|
||||
- 'for_each_card_components'
|
||||
- 'for_each_card_dapms'
|
||||
- 'for_each_card_pre_auxs'
|
||||
- 'for_each_card_prelinks'
|
||||
- 'for_each_card_rtds'
|
||||
- 'for_each_card_rtds_safe'
|
||||
- 'for_each_card_widgets'
|
||||
- 'for_each_card_widgets_safe'
|
||||
- 'for_each_cgroup_storage_type'
|
||||
- 'for_each_child_of_node'
|
||||
- 'for_each_clear_bit'
|
||||
- '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_conduit'
|
||||
- 'for_each_console'
|
||||
- 'for_each_console_srcu'
|
||||
- 'for_each_cpu'
|
||||
- 'for_each_cpu_and'
|
||||
- 'for_each_cpu_andnot'
|
||||
- 'for_each_cpu_or'
|
||||
- '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'
|
||||
- 'for_each_dpcm_be'
|
||||
- 'for_each_dpcm_be_rollback'
|
||||
- 'for_each_dpcm_be_safe'
|
||||
- 'for_each_dpcm_fe'
|
||||
- 'for_each_drhd_unit'
|
||||
- 'for_each_dss_dev'
|
||||
- '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'
|
||||
- 'for_each_free_mem_pfn_range_in_zone'
|
||||
- 'for_each_free_mem_pfn_range_in_zone_from'
|
||||
- 'for_each_free_mem_range'
|
||||
- 'for_each_free_mem_range_reverse'
|
||||
- 'for_each_func_rsrc'
|
||||
- 'for_each_gpiochip_node'
|
||||
- 'for_each_group_evsel'
|
||||
- 'for_each_group_evsel_head'
|
||||
- 'for_each_group_member'
|
||||
- 'for_each_group_member_head'
|
||||
- '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_media_entity_data_link'
|
||||
- 'for_each_mem_pfn_range'
|
||||
- 'for_each_mem_range'
|
||||
- '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_mle_subelement'
|
||||
- 'for_each_mod_mem_type'
|
||||
- 'for_each_net'
|
||||
- 'for_each_net_continue_reverse'
|
||||
- 'for_each_net_rcu'
|
||||
- 'for_each_netdev'
|
||||
- 'for_each_netdev_continue'
|
||||
- 'for_each_netdev_continue_rcu'
|
||||
- 'for_each_netdev_continue_reverse'
|
||||
- 'for_each_netdev_dump'
|
||||
- 'for_each_netdev_feature'
|
||||
- 'for_each_netdev_in_bond_rcu'
|
||||
- 'for_each_netdev_rcu'
|
||||
- 'for_each_netdev_reverse'
|
||||
- 'for_each_netdev_safe'
|
||||
- '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'
|
||||
- 'for_each_node_mask'
|
||||
- 'for_each_node_state'
|
||||
- 'for_each_node_with_cpus'
|
||||
- 'for_each_node_with_property'
|
||||
- 'for_each_nonreserved_multicast_dest_pgid'
|
||||
- 'for_each_numa_hop_mask'
|
||||
- 'for_each_of_allnodes'
|
||||
- 'for_each_of_allnodes_from'
|
||||
- 'for_each_of_cpu_node'
|
||||
- 'for_each_of_pci_range'
|
||||
- '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_online_cpu'
|
||||
- 'for_each_online_node'
|
||||
- 'for_each_online_pgdat'
|
||||
- 'for_each_or_bit'
|
||||
- 'for_each_path'
|
||||
- 'for_each_pci_bridge'
|
||||
- 'for_each_pci_dev'
|
||||
- 'for_each_pcm_streams'
|
||||
- 'for_each_physmem_range'
|
||||
- 'for_each_populated_zone'
|
||||
- 'for_each_possible_cpu'
|
||||
- 'for_each_present_blessed_reg'
|
||||
- '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'
|
||||
- 'for_each_prop_dai_codec'
|
||||
- 'for_each_prop_dai_cpu'
|
||||
- 'for_each_prop_dlc_codecs'
|
||||
- 'for_each_prop_dlc_cpus'
|
||||
- 'for_each_prop_dlc_platforms'
|
||||
- 'for_each_property_of_node'
|
||||
- 'for_each_reg'
|
||||
- 'for_each_reg_filtered'
|
||||
- 'for_each_reloc'
|
||||
- 'for_each_reloc_from'
|
||||
- 'for_each_requested_gpio'
|
||||
- 'for_each_requested_gpio_in_range'
|
||||
- 'for_each_reserved_mem_range'
|
||||
- 'for_each_reserved_mem_region'
|
||||
- 'for_each_rtd_codec_dais'
|
||||
- 'for_each_rtd_components'
|
||||
- 'for_each_rtd_cpu_dais'
|
||||
- 'for_each_rtd_dais'
|
||||
- 'for_each_sband_iftype_data'
|
||||
- 'for_each_script'
|
||||
- 'for_each_sec'
|
||||
- 'for_each_set_bit'
|
||||
- 'for_each_set_bit_from'
|
||||
- 'for_each_set_bit_wrap'
|
||||
- 'for_each_set_bitrange'
|
||||
- 'for_each_set_bitrange_from'
|
||||
- 'for_each_set_clump8'
|
||||
- 'for_each_sg'
|
||||
- 'for_each_sg_dma_page'
|
||||
- 'for_each_sg_page'
|
||||
- 'for_each_sgtable_dma_page'
|
||||
- 'for_each_sgtable_dma_sg'
|
||||
- 'for_each_sgtable_page'
|
||||
- 'for_each_sgtable_sg'
|
||||
- 'for_each_sibling_event'
|
||||
- 'for_each_sta_active_link'
|
||||
- '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_sym'
|
||||
- 'for_each_test'
|
||||
- 'for_each_thread'
|
||||
- 'for_each_token'
|
||||
- 'for_each_unicast_dest_pgid'
|
||||
- 'for_each_valid_link'
|
||||
- 'for_each_vif_active_link'
|
||||
- 'for_each_vma'
|
||||
- 'for_each_vma_range'
|
||||
- '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_for_each_parent_node'
|
||||
- 'fwnode_graph_for_each_endpoint'
|
||||
- 'gadget_for_each_ep'
|
||||
- 'genradix_for_each'
|
||||
- 'genradix_for_each_from'
|
||||
- 'genradix_for_each_reverse'
|
||||
- 'hash_for_each'
|
||||
- 'hash_for_each_possible'
|
||||
- 'hash_for_each_possible_rcu'
|
||||
- 'hash_for_each_possible_rcu_notrace'
|
||||
- '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'
|
||||
- 'hlist_for_each'
|
||||
- 'hlist_for_each_entry'
|
||||
- 'hlist_for_each_entry_continue'
|
||||
- 'hlist_for_each_entry_continue_rcu'
|
||||
- 'hlist_for_each_entry_continue_rcu_bh'
|
||||
- 'hlist_for_each_entry_from'
|
||||
- 'hlist_for_each_entry_from_rcu'
|
||||
- 'hlist_for_each_entry_rcu'
|
||||
- 'hlist_for_each_entry_rcu_bh'
|
||||
- 'hlist_for_each_entry_rcu_notrace'
|
||||
- 'hlist_for_each_entry_safe'
|
||||
- 'hlist_for_each_entry_srcu'
|
||||
- 'hlist_for_each_safe'
|
||||
- 'hlist_nulls_for_each_entry'
|
||||
- 'hlist_nulls_for_each_entry_from'
|
||||
- 'hlist_nulls_for_each_entry_rcu'
|
||||
- 'hlist_nulls_for_each_entry_safe'
|
||||
- 'i3c_bus_for_each_i2cdev'
|
||||
- 'i3c_bus_for_each_i3cdev'
|
||||
- 'idr_for_each_entry'
|
||||
- 'idr_for_each_entry_continue'
|
||||
- 'idr_for_each_entry_continue_ul'
|
||||
- 'idr_for_each_entry_ul'
|
||||
- 'in_dev_for_each_ifa_rcu'
|
||||
- 'in_dev_for_each_ifa_rtnl'
|
||||
- 'inet_bind_bucket_for_each'
|
||||
- 'interval_tree_for_each_span'
|
||||
- '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'
|
||||
- 'klp_for_each_func_safe'
|
||||
- 'klp_for_each_func_static'
|
||||
- 'klp_for_each_object'
|
||||
- 'klp_for_each_object_safe'
|
||||
- 'klp_for_each_object_static'
|
||||
- 'kunit_suite_for_each_test_case'
|
||||
- 'kvm_for_each_memslot'
|
||||
- 'kvm_for_each_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'
|
||||
- 'list_for_each_continue'
|
||||
- 'list_for_each_entry'
|
||||
- 'list_for_each_entry_continue'
|
||||
- 'list_for_each_entry_continue_rcu'
|
||||
- 'list_for_each_entry_continue_reverse'
|
||||
- 'list_for_each_entry_from'
|
||||
- 'list_for_each_entry_from_rcu'
|
||||
- 'list_for_each_entry_from_reverse'
|
||||
- 'list_for_each_entry_lockless'
|
||||
- 'list_for_each_entry_rcu'
|
||||
- 'list_for_each_entry_reverse'
|
||||
- 'list_for_each_entry_safe'
|
||||
- 'list_for_each_entry_safe_continue'
|
||||
- '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_rcu'
|
||||
- 'list_for_each_reverse'
|
||||
- 'list_for_each_safe'
|
||||
- 'llist_for_each'
|
||||
- 'llist_for_each_entry'
|
||||
- 'llist_for_each_entry_safe'
|
||||
- 'llist_for_each_safe'
|
||||
- 'lwq_for_each_safe'
|
||||
- 'map__for_each_symbol'
|
||||
- 'map__for_each_symbol_by_name'
|
||||
- 'maps__for_each_entry'
|
||||
- 'maps__for_each_entry_safe'
|
||||
- 'mas_for_each'
|
||||
- 'mci_for_each_dimm'
|
||||
- 'media_device_for_each_entity'
|
||||
- 'media_device_for_each_intf'
|
||||
- 'media_device_for_each_link'
|
||||
- 'media_device_for_each_pad'
|
||||
- 'media_entity_for_each_pad'
|
||||
- 'media_pipeline_for_each_entity'
|
||||
- 'media_pipeline_for_each_pad'
|
||||
- 'mlx5_lag_for_each_peer_mdev'
|
||||
- 'msi_domain_for_each_desc'
|
||||
- 'msi_for_each_desc'
|
||||
- 'mt_for_each'
|
||||
- 'nanddev_io_for_each_page'
|
||||
- 'netdev_for_each_lower_dev'
|
||||
- 'netdev_for_each_lower_private'
|
||||
- 'netdev_for_each_lower_private_rcu'
|
||||
- 'netdev_for_each_mc_addr'
|
||||
- 'netdev_for_each_synced_mc_addr'
|
||||
- 'netdev_for_each_synced_uc_addr'
|
||||
- 'netdev_for_each_uc_addr'
|
||||
- 'netdev_for_each_upper_dev_rcu'
|
||||
- 'netdev_hw_addr_list_for_each'
|
||||
- 'nft_rule_for_each_expr'
|
||||
- 'nla_for_each_attr'
|
||||
- 'nla_for_each_nested'
|
||||
- 'nlmsg_for_each_attr'
|
||||
- 'nlmsg_for_each_msg'
|
||||
- 'nr_neigh_for_each'
|
||||
- 'nr_neigh_for_each_safe'
|
||||
- 'nr_node_for_each'
|
||||
- 'nr_node_for_each_safe'
|
||||
- 'of_for_each_phandle'
|
||||
- 'of_property_for_each_string'
|
||||
- 'of_property_for_each_u32'
|
||||
- 'pci_bus_for_each_resource'
|
||||
- 'pci_dev_for_each_resource'
|
||||
- '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_cpu_map__for_each_idx'
|
||||
- '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_tool_event__for_each_event'
|
||||
- 'plist_for_each'
|
||||
- 'plist_for_each_continue'
|
||||
- 'plist_for_each_entry'
|
||||
- 'plist_for_each_entry_continue'
|
||||
- 'plist_for_each_entry_safe'
|
||||
- 'plist_for_each_safe'
|
||||
- 'pnp_for_each_card'
|
||||
- 'pnp_for_each_dev'
|
||||
- 'protocol_for_each_card'
|
||||
- 'protocol_for_each_dev'
|
||||
- 'queue_for_each_hw_ctx'
|
||||
- 'radix_tree_for_each_slot'
|
||||
- 'radix_tree_for_each_tagged'
|
||||
- 'rb_for_each'
|
||||
- 'rbtree_postorder_for_each_entry_safe'
|
||||
- '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'
|
||||
- 'rhl_for_each_rcu'
|
||||
- 'rht_for_each'
|
||||
- 'rht_for_each_entry'
|
||||
- 'rht_for_each_entry_from'
|
||||
- 'rht_for_each_entry_rcu'
|
||||
- 'rht_for_each_entry_rcu_from'
|
||||
- 'rht_for_each_entry_safe'
|
||||
- 'rht_for_each_from'
|
||||
- 'rht_for_each_rcu'
|
||||
- 'rht_for_each_rcu_from'
|
||||
- 'rq_for_each_bvec'
|
||||
- 'rq_for_each_segment'
|
||||
- 'rq_list_for_each'
|
||||
- 'rq_list_for_each_safe'
|
||||
- 'sample_read_group__for_each'
|
||||
- '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'
|
||||
- 'sec_for_each_sym'
|
||||
- 'shdma_for_each_chan'
|
||||
- 'shost_for_each_device'
|
||||
- 'sk_for_each'
|
||||
- 'sk_for_each_bound'
|
||||
- 'sk_for_each_bound_bhash2'
|
||||
- 'sk_for_each_entry_offset_rcu'
|
||||
- 'sk_for_each_from'
|
||||
- 'sk_for_each_rcu'
|
||||
- 'sk_for_each_safe'
|
||||
- 'sk_nulls_for_each'
|
||||
- 'sk_nulls_for_each_from'
|
||||
- 'sk_nulls_for_each_rcu'
|
||||
- 'snd_array_for_each'
|
||||
- 'snd_pcm_group_for_each_entry'
|
||||
- 'snd_soc_dapm_widget_for_each_path'
|
||||
- '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'
|
||||
- 'ttm_resource_manager_for_each_res'
|
||||
- 'twsk_for_each_bound_bhash2'
|
||||
- 'udp_portaddr_for_each_entry'
|
||||
- 'udp_portaddr_for_each_entry_rcu'
|
||||
- 'usb_hub_for_each_child'
|
||||
- 'v4l2_device_for_each_subdev'
|
||||
- 'v4l2_m2m_for_each_dst_buf'
|
||||
- 'v4l2_m2m_for_each_dst_buf_safe'
|
||||
- 'v4l2_m2m_for_each_src_buf'
|
||||
- 'v4l2_m2m_for_each_src_buf_safe'
|
||||
- 'virtio_device_for_each_vq'
|
||||
- 'while_for_each_ftrace_op'
|
||||
- 'xa_for_each'
|
||||
- 'xa_for_each_marked'
|
||||
- 'xa_for_each_range'
|
||||
- 'xa_for_each_start'
|
||||
- 'xas_for_each'
|
||||
- 'xas_for_each_conflict'
|
||||
- 'xas_for_each_marked'
|
||||
- 'xbc_array_for_each_value'
|
||||
- 'xbc_for_each_key_value'
|
||||
- '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
|
||||
IncludeCategories:
|
||||
- Regex: '.*'
|
||||
Priority: 1
|
||||
IncludeIsMainRegex: '(Test)?$'
|
||||
IndentCaseLabels: false
|
||||
IndentGotoLabels: false
|
||||
IndentPPDirectives: None
|
||||
IndentWidth: 8
|
||||
IndentWrappedFunctionNames: false
|
||||
JavaScriptQuotes: Leave
|
||||
JavaScriptWrapImports: true
|
||||
KeepEmptyLinesAtTheStartOfBlocks: false
|
||||
MacroBlockBegin: ''
|
||||
MacroBlockEnd: ''
|
||||
MaxEmptyLinesToKeep: 1
|
||||
NamespaceIndentation: None
|
||||
ObjCBinPackProtocolList: Auto
|
||||
ObjCBlockIndentWidth: 8
|
||||
ObjCSpaceAfterProperty: true
|
||||
ObjCSpaceBeforeProtocolList: true
|
||||
|
||||
# Taken from git's rules
|
||||
PenaltyBreakAssignment: 10
|
||||
PenaltyBreakBeforeFirstCallParameter: 30
|
||||
PenaltyBreakComment: 10
|
||||
PenaltyBreakFirstLessLess: 0
|
||||
PenaltyBreakString: 10
|
||||
PenaltyExcessCharacter: 100
|
||||
PenaltyReturnTypeOnItsOwnLine: 60
|
||||
|
||||
PointerAlignment: Right
|
||||
ReflowComments: false
|
||||
SortIncludes: false
|
||||
SortUsingDeclarations: false
|
||||
SpaceAfterCStyleCast: false
|
||||
SpaceAfterTemplateKeyword: true
|
||||
SpaceBeforeAssignmentOperators: true
|
||||
SpaceBeforeCtorInitializerColon: true
|
||||
SpaceBeforeInheritanceColon: true
|
||||
SpaceBeforeParens: ControlStatementsExceptForEachMacros
|
||||
SpaceBeforeRangeBasedForLoopColon: true
|
||||
SpaceInEmptyParentheses: false
|
||||
SpacesBeforeTrailingComments: 1
|
||||
SpacesInAngles: false
|
||||
SpacesInContainerLiterals: false
|
||||
SpacesInCStyleCastParentheses: false
|
||||
SpacesInParentheses: false
|
||||
SpacesInSquareBrackets: false
|
||||
Standard: Cpp03
|
||||
TabWidth: 8
|
||||
UseTab: Always
|
||||
...
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
[spatch]
|
||||
options = --timeout 200
|
||||
options = --use-gitgrep
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
|
||||
root = true
|
||||
|
||||
[{*.{awk,c,dts,dtsi,dtso,h,mk,s,S},Kconfig,Makefile,Makefile.*}]
|
||||
charset = utf-8
|
||||
end_of_line = lf
|
||||
trim_trailing_whitespace = true
|
||||
insert_final_newline = true
|
||||
indent_style = tab
|
||||
indent_size = 8
|
||||
|
||||
[*.{json,py,rs}]
|
||||
charset = utf-8
|
||||
end_of_line = lf
|
||||
trim_trailing_whitespace = true
|
||||
insert_final_newline = true
|
||||
indent_style = space
|
||||
indent_size = 4
|
||||
|
||||
# this must be below the general *.py to overwrite it
|
||||
[tools/{perf,power,rcu,testing/kunit}/**.py,]
|
||||
indent_style = tab
|
||||
indent_size = 8
|
||||
|
||||
[*.yaml]
|
||||
charset = utf-8
|
||||
end_of_line = lf
|
||||
trim_trailing_whitespace = unset
|
||||
insert_final_newline = true
|
||||
indent_style = space
|
||||
indent_size = 2
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
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>
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
*.[ch] diff=cpp
|
||||
*.dts diff=dts
|
||||
*.dts[io] diff=dts
|
||||
*.rs diff=rust
|
||||
|
|
@ -0,0 +1,172 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
#
|
||||
# NOTE! Don't add files that are generated in specific
|
||||
# subdirectories here. Add them in the ".gitignore" file
|
||||
# in that subdirectory instead.
|
||||
#
|
||||
# NOTE! Please use 'git ls-files -i -c --exclude-per-directory=.gitignore'
|
||||
# command after changing this file, to see if there are
|
||||
# any tracked files which get ignored after the change.
|
||||
#
|
||||
# Normal rules (sorted alphabetically)
|
||||
#
|
||||
.*
|
||||
*.a
|
||||
*.asn1.[ch]
|
||||
*.bin
|
||||
*.bz2
|
||||
*.c.[012]*.*
|
||||
*.dt.yaml
|
||||
*.dtb
|
||||
*.dtbo
|
||||
*.dtb.S
|
||||
*.dtbo.S
|
||||
*.dwo
|
||||
*.elf
|
||||
*.gcno
|
||||
*.gz
|
||||
*.i
|
||||
*.ko
|
||||
*.lex.c
|
||||
*.ll
|
||||
*.lst
|
||||
*.lz4
|
||||
*.lzma
|
||||
*.lzo
|
||||
*.mod
|
||||
*.mod.c
|
||||
*.o
|
||||
*.o.*
|
||||
*.patch
|
||||
*.rmeta
|
||||
*.rpm
|
||||
*.rsi
|
||||
*.s
|
||||
*.so
|
||||
*.so.dbg
|
||||
*.su
|
||||
*.symtypes
|
||||
*.symversions
|
||||
*.tab.[ch]
|
||||
*.tar
|
||||
*.xz
|
||||
*.zst
|
||||
Module.symvers
|
||||
modules.order
|
||||
|
||||
#
|
||||
# Top-level generic files
|
||||
#
|
||||
/linux
|
||||
/modules-only.symvers
|
||||
/vmlinux
|
||||
/vmlinux.32
|
||||
/vmlinux.map
|
||||
/vmlinux.symvers
|
||||
/vmlinux-gdb.py
|
||||
/vmlinuz
|
||||
/System.map
|
||||
/Module.markers
|
||||
/modules.builtin
|
||||
/modules.builtin.modinfo
|
||||
/modules.nsdeps
|
||||
|
||||
#
|
||||
# RPM spec file (make rpm-pkg)
|
||||
#
|
||||
/rpmbuild/
|
||||
|
||||
#
|
||||
# Debian directory (make deb-pkg)
|
||||
#
|
||||
/debian/
|
||||
|
||||
#
|
||||
# Snap directory (make snap-pkg)
|
||||
#
|
||||
/snap/
|
||||
|
||||
#
|
||||
# tar directory (make tar*-pkg)
|
||||
#
|
||||
/tar-install/
|
||||
|
||||
#
|
||||
# We don't want to ignore the following even if they are dot-files
|
||||
#
|
||||
!.clang-format
|
||||
!.cocciconfig
|
||||
!.editorconfig
|
||||
!.get_maintainer.ignore
|
||||
!.gitattributes
|
||||
!.gitignore
|
||||
!.kunitconfig
|
||||
!.mailmap
|
||||
!.rustfmt.toml
|
||||
|
||||
#
|
||||
# Generated include files
|
||||
#
|
||||
/include/config/
|
||||
/include/generated/
|
||||
/arch/*/include/generated/
|
||||
|
||||
# stgit generated dirs
|
||||
patches-*
|
||||
|
||||
# quilt's files
|
||||
patches
|
||||
series
|
||||
|
||||
# ctags files
|
||||
tags
|
||||
TAGS
|
||||
|
||||
# cscope files
|
||||
cscope.*
|
||||
ncscope.*
|
||||
|
||||
# gnu global files
|
||||
GPATH
|
||||
GRTAGS
|
||||
GSYMS
|
||||
GTAGS
|
||||
|
||||
# id-utils files
|
||||
ID
|
||||
|
||||
*.orig
|
||||
*~
|
||||
\#*#
|
||||
|
||||
#
|
||||
# Leavings from module signing
|
||||
#
|
||||
extra_certificates
|
||||
signing_key.pem
|
||||
signing_key.priv
|
||||
signing_key.x509
|
||||
x509.genkey
|
||||
|
||||
# Kconfig presets
|
||||
/all.config
|
||||
/alldef.config
|
||||
/allmod.config
|
||||
/allno.config
|
||||
/allrandom.config
|
||||
/allyes.config
|
||||
|
||||
# Kconfig savedefconfig output
|
||||
/defconfig
|
||||
|
||||
# Kdevelop4
|
||||
*.kdev4
|
||||
|
||||
# Clang's compilation database file
|
||||
/compile_commands.json
|
||||
|
||||
# Documentation toolchain
|
||||
sphinx_*/
|
||||
|
||||
# Rust analyzer configuration
|
||||
/rust-project.json
|
||||
|
|
@ -0,0 +1,663 @@
|
|||
#
|
||||
# This list is used by git-shortlog to fix a few botched name translations
|
||||
# in the git archive, either because the author's full name was messed up
|
||||
# and/or not always written the same way, making contributions from the
|
||||
# same person appearing not to be so or badly displayed. Also allows for
|
||||
# old email addresses to map to new email addresses.
|
||||
#
|
||||
# For format details, see "man gitmailmap" or "MAPPING AUTHORS" in
|
||||
# "man git-shortlog" on older systems.
|
||||
#
|
||||
# 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>
|
||||
Abhijeet Dharmapurikar <quic_adharmap@quicinc.com> <adharmap@codeaurora.org>
|
||||
Abhinav Kumar <quic_abhinavk@quicinc.com> <abhinavk@codeaurora.org>
|
||||
Ahmad Masri <quic_amasri@quicinc.com> <amasri@codeaurora.org>
|
||||
Adam Oldham <oldhamca@gmail.com>
|
||||
Adam Radford <aradford@gmail.com>
|
||||
Adriana Reus <adi.reus@gmail.com> <adriana.reus@intel.com>
|
||||
Adrian Bunk <bunk@stusta.de>
|
||||
Akhil P Oommen <quic_akhilpo@quicinc.com> <akhilpo@codeaurora.org>
|
||||
Alan Cox <alan@lxorguk.ukuu.org.uk>
|
||||
Alan Cox <root@hraefn.swansea.linux.org.uk>
|
||||
Aleksandar Markovic <aleksandar.markovic@mips.com> <aleksandar.markovic@imgtec.com>
|
||||
Aleksey Gorelov <aleksey_gorelov@phoenix.com>
|
||||
Alexander Lobakin <alobakin@pm.me> <alobakin@dlink.ru>
|
||||
Alexander Lobakin <alobakin@pm.me> <alobakin@marvell.com>
|
||||
Alexander Lobakin <alobakin@pm.me> <bloodyreaper@yandex.ru>
|
||||
Alexander Mikhalitsyn <alexander@mihalicyn.com> <alexander.mikhalitsyn@virtuozzo.com>
|
||||
Alexander Mikhalitsyn <alexander@mihalicyn.com> <aleksandr.mikhalitsyn@canonical.com>
|
||||
Alexandre Belloni <alexandre.belloni@bootlin.com> <alexandre.belloni@free-electrons.com>
|
||||
Alexandre Ghiti <alex@ghiti.fr> <alexandre.ghiti@canonical.com>
|
||||
Alexei Avshalom Lazar <quic_ailizaro@quicinc.com> <ailizaro@codeaurora.org>
|
||||
Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com>
|
||||
Alexei Starovoitov <ast@kernel.org> <ast@fb.com>
|
||||
Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
|
||||
Alex Hung <alexhung@gmail.com> <alex.hung@canonical.com>
|
||||
Alex Shi <alexs@kernel.org> <alex.shi@intel.com>
|
||||
Alex Shi <alexs@kernel.org> <alex.shi@linaro.org>
|
||||
Alex Shi <alexs@kernel.org> <alex.shi@linux.alibaba.com>
|
||||
Aloka Dixit <quic_alokad@quicinc.com> <alokad@codeaurora.org>
|
||||
Al Viro <viro@ftp.linux.org.uk>
|
||||
Al Viro <viro@zenIV.linux.org.uk>
|
||||
Amit Blay <quic_ablay@quicinc.com> <ablay@codeaurora.org>
|
||||
Amit Nischal <quic_anischal@quicinc.com> <anischal@codeaurora.org>
|
||||
Andi Kleen <ak@linux.intel.com> <ak@suse.de>
|
||||
Andi Shyti <andi@etezian.org> <andi.shyti@samsung.com>
|
||||
Andreas Herrmann <aherrman@de.ibm.com>
|
||||
Andrej Shadura <andrew.shadura@collabora.co.uk>
|
||||
Andrej Shadura <andrew@shadura.me> <andrew@beldisplaytech.com>
|
||||
Andrew Morton <akpm@linux-foundation.org>
|
||||
Andrew Murray <amurray@thegoodpenguin.co.uk> <amurray@embedded-bits.co.uk>
|
||||
Andrew Murray <amurray@thegoodpenguin.co.uk> <andrew.murray@arm.com>
|
||||
Andrew Vasquez <andrew.vasquez@qlogic.com>
|
||||
Andrey Konovalov <andreyknvl@gmail.com> <andreyknvl@google.com>
|
||||
Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
|
||||
Andrey Ryabinin <ryabinin.a.a@gmail.com> <aryabinin@virtuozzo.com>
|
||||
Andrzej Hajda <andrzej.hajda@intel.com> <a.hajda@samsung.com>
|
||||
André Almeida <andrealmeid@igalia.com> <andrealmeid@collabora.com>
|
||||
Andy Adamson <andros@citi.umich.edu>
|
||||
Anilkumar Kolli <quic_akolli@quicinc.com> <akolli@codeaurora.org>
|
||||
Anirudh Ghayal <quic_aghayal@quicinc.com> <aghayal@codeaurora.org>
|
||||
Antoine Tenart <atenart@kernel.org> <antoine.tenart@bootlin.com>
|
||||
Antoine Tenart <atenart@kernel.org> <antoine.tenart@free-electrons.com>
|
||||
Antonio Ospite <ao2@ao2.it> <ao2@amarulasolutions.com>
|
||||
Anup Patel <anup@brainfault.org> <anup.patel@wdc.com>
|
||||
Archit Taneja <archit@ti.com>
|
||||
Ard Biesheuvel <ardb@kernel.org> <ard.biesheuvel@linaro.org>
|
||||
Arnaud Patard <arnaud.patard@rtp-net.org>
|
||||
Arnd Bergmann <arnd@arndb.de>
|
||||
Arun Kumar Neelakantam <quic_aneela@quicinc.com> <aneela@codeaurora.org>
|
||||
Ashok Raj Nagarajan <quic_arnagara@quicinc.com> <arnagara@codeaurora.org>
|
||||
Ashwin Chaugule <quic_ashwinc@quicinc.com> <ashwinc@codeaurora.org>
|
||||
Asutosh Das <quic_asutoshd@quicinc.com> <asutoshd@codeaurora.org>
|
||||
Atish Patra <atishp@atishpatra.org> <atish.patra@wdc.com>
|
||||
Avaneesh Kumar Dwivedi <quic_akdwived@quicinc.com> <akdwived@codeaurora.org>
|
||||
Axel Dyks <xl@xlsigned.net>
|
||||
Axel Lin <axel.lin@gmail.com>
|
||||
Balakrishna Godavarthi <quic_bgodavar@quicinc.com> <bgodavar@codeaurora.org>
|
||||
Banajit Goswami <quic_bgoswami@quicinc.com> <bgoswami@codeaurora.org>
|
||||
Baochen Qiang <quic_bqiang@quicinc.com> <bqiang@codeaurora.org>
|
||||
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>
|
||||
Bartosz Golaszewski <brgl@bgdev.pl> <bgolaszewski@baylibre.com>
|
||||
Ben Dooks <ben-linux@fluff.org> <ben.dooks@simtec.co.uk>
|
||||
Ben Dooks <ben-linux@fluff.org> <ben.dooks@sifive.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>
|
||||
Benjamin Poirier <benjamin.poirier@gmail.com> <bpoirier@suse.de>
|
||||
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>
|
||||
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>
|
||||
Cai Huoqing <cai.huoqing@linux.dev> <caihuoqing@baidu.com>
|
||||
Can Guo <quic_cang@quicinc.com> <cang@codeaurora.org>
|
||||
Carl Huang <quic_cjhuang@quicinc.com> <cjhuang@codeaurora.org>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
|
||||
Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
|
||||
Chao Yu <chao@kernel.org> <yuchao0@huawei.com>
|
||||
Chester Lin <chester62515@gmail.com> <clin@suse.com>
|
||||
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessm.com>
|
||||
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessos.org>
|
||||
Chris Lew <quic_clew@quicinc.com> <clew@codeaurora.org>
|
||||
Christian Borntraeger <borntraeger@linux.ibm.com> <borntraeger@de.ibm.com>
|
||||
Christian Borntraeger <borntraeger@linux.ibm.com> <cborntra@de.ibm.com>
|
||||
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>
|
||||
Claudiu Beznea <claudiu.beznea@tuxon.dev> <claudiu.beznea@microchip.com>
|
||||
Colin Ian King <colin.i.king@gmail.com> <colin.king@canonical.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>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <dborkmann@redhat.com>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <dborkman@redhat.com>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <dxchgb@gmail.com>
|
||||
David Brownell <david-b@pacbell.net>
|
||||
David Collins <quic_collinsd@quicinc.com> <collinsd@codeaurora.org>
|
||||
David Rheinsberg <david@readahead.eu> <dh.herrmann@gmail.com>
|
||||
David Rheinsberg <david@readahead.eu> <dh.herrmann@googlemail.com>
|
||||
David Rheinsberg <david@readahead.eu> <david.rheinsberg@gmail.com>
|
||||
David Woodhouse <dwmw2@shinybook.infradead.org>
|
||||
Dedy Lansky <quic_dlansky@quicinc.com> <dlansky@codeaurora.org>
|
||||
Deepak Kumar Singh <quic_deesin@quicinc.com> <deesin@codeaurora.org>
|
||||
Dengcheng Zhu <dzhu@wavecomp.com> <dczhu@mips.com>
|
||||
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@gmail.com>
|
||||
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@imgtec.com>
|
||||
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@mips.com>
|
||||
<dev.kurt@vandijck-laurijssen.be> <kurt.van.dijck@eia.be>
|
||||
Dikshita Agarwal <quic_dikshita@quicinc.com> <dikshita@codeaurora.org>
|
||||
Dmitry Baryshkov <dbaryshkov@gmail.com>
|
||||
Dmitry Baryshkov <dbaryshkov@gmail.com> <[dbaryshkov@gmail.com]>
|
||||
Dmitry Baryshkov <dbaryshkov@gmail.com> <dmitry_baryshkov@mentor.com>
|
||||
Dmitry Baryshkov <dbaryshkov@gmail.com> <dmitry_eremin@mentor.com>
|
||||
Dmitry Safonov <0x7f454c46@gmail.com> <dima@arista.com>
|
||||
Dmitry Safonov <0x7f454c46@gmail.com> <d.safonov@partner.samsung.com>
|
||||
Dmitry Safonov <0x7f454c46@gmail.com> <dsafonov@virtuozzo.com>
|
||||
Domen Puncer <domen@coderock.org>
|
||||
Douglas Gilbert <dougg@torque.net>
|
||||
Ed L. Cashin <ecashin@coraid.com>
|
||||
Elliot Berman <quic_eberman@quicinc.com> <eberman@codeaurora.org>
|
||||
Enric Balletbo i Serra <eballetbo@kernel.org> <enric.balletbo@collabora.com>
|
||||
Enric Balletbo i Serra <eballetbo@kernel.org> <eballetbo@iseebcn.com>
|
||||
Erik Kaneda <erik.kaneda@intel.com> <erik.schmauss@intel.com>
|
||||
Eugen Hristev <eugen.hristev@collabora.com> <eugen.hristev@microchip.com>
|
||||
Evgeniy Polyakov <johnpol@2ka.mipt.ru>
|
||||
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> <ezequiel@collabora.com>
|
||||
Faith Ekstrand <faith.ekstrand@collabora.com> <jason@jlekstrand.net>
|
||||
Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@intel.com>
|
||||
Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@collabora.com>
|
||||
Felipe W Damasio <felipewd@terra.com.br>
|
||||
Felix Kuhling <fxkuehl@gmx.de>
|
||||
Felix Moeller <felix@derklecks.de>
|
||||
Fenglin Wu <quic_fenglinw@quicinc.com> <fenglinw@codeaurora.org>
|
||||
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>
|
||||
Geliang Tang <geliang@kernel.org> <geliang.tang@linux.dev>
|
||||
Geliang Tang <geliang@kernel.org> <geliang.tang@suse.com>
|
||||
Geliang Tang <geliang@kernel.org> <geliangtang@xiaomi.com>
|
||||
Geliang Tang <geliang@kernel.org> <geliangtang@gmail.com>
|
||||
Geliang Tang <geliang@kernel.org> <geliangtang@163.com>
|
||||
Georgi Djakov <djakov@kernel.org> <georgi.djakov@linaro.org>
|
||||
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>
|
||||
Greg Kroah-Hartman <greg@echidna.(none)>
|
||||
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>
|
||||
Gokul Sriram Palanisamy <quic_gokulsri@quicinc.com> <gokulsri@codeaurora.org>
|
||||
Govindaraj Saminathan <quic_gsamin@quicinc.com> <gsamin@codeaurora.org>
|
||||
Guo Ren <guoren@kernel.org> <guoren@linux.alibaba.com>
|
||||
Guo Ren <guoren@kernel.org> <ren_guo@c-sky.com>
|
||||
Guru Das Srinagesh <quic_gurus@quicinc.com> <gurus@codeaurora.org>
|
||||
Gustavo Padovan <gustavo@las.ic.unicamp.br>
|
||||
Gustavo Padovan <padovan@profusion.mobi>
|
||||
Hanjun Guo <guohanjun@huawei.com> <hanjun.guo@linaro.org>
|
||||
Heiko Carstens <hca@linux.ibm.com> <h.carstens@de.ibm.com>
|
||||
Heiko Carstens <hca@linux.ibm.com> <heiko.carstens@de.ibm.com>
|
||||
Heiko Stuebner <heiko@sntech.de> <heiko.stuebner@bqreaders.com>
|
||||
Heiko Stuebner <heiko@sntech.de> <heiko.stuebner@theobroma-systems.com>
|
||||
Heiko Stuebner <heiko@sntech.de> <heiko.stuebner@vrull.eu>
|
||||
Henk Vergonet <Henk.Vergonet@gmail.com>
|
||||
Henrik Kretzschmar <henne@nachtwindheim.de>
|
||||
Henrik Rydberg <rydberg@bitmath.org>
|
||||
Herbert Xu <herbert@gondor.apana.org.au>
|
||||
Huacai Chen <chenhuacai@kernel.org> <chenhc@lemote.com>
|
||||
Huacai Chen <chenhuacai@kernel.org> <chenhuacai@loongson.cn>
|
||||
J. Bruce Fields <bfields@fieldses.org> <bfields@redhat.com>
|
||||
J. Bruce Fields <bfields@fieldses.org> <bfields@citi.umich.edu>
|
||||
Jacob Shin <Jacob.Shin@amd.com>
|
||||
Jack Pham <quic_jackp@quicinc.com> <jackp@codeaurora.org>
|
||||
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@google.com>
|
||||
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk.kim@samsung.com>
|
||||
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@motorola.com>
|
||||
Jakub Kicinski <kuba@kernel.org> <jakub.kicinski@netronome.com>
|
||||
James Bottomley <jejb@mulgrave.(none)>
|
||||
James Bottomley <jejb@titanic.il.steeleye.com>
|
||||
James E Wilson <wilson@specifix.com>
|
||||
James Hogan <jhogan@kernel.org> <james@albanarts.com>
|
||||
James Hogan <jhogan@kernel.org> <james.hogan@imgtec.com>
|
||||
James Ketrenos <jketreno@io.(none)>
|
||||
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>
|
||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@tuni.fi>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgg@nvidia.com>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
|
||||
<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
|
||||
Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
|
||||
Jayachandran C <c.jayachandran@gmail.com> <jayachandranc@netlogicmicro.com>
|
||||
Jayachandran C <c.jayachandran@gmail.com> <jchandra@broadcom.com>
|
||||
Jayachandran C <c.jayachandran@gmail.com> <jchandra@digeo.com>
|
||||
Jayachandran C <c.jayachandran@gmail.com> <jnair@caviumnetworks.com>
|
||||
<jean-philippe@linaro.org> <jean-philippe.brucker@arm.com>
|
||||
Jean Tourrilhes <jt@hpl.hp.com>
|
||||
Jeevan Shriram <quic_jshriram@quicinc.com> <jshriram@codeaurora.org>
|
||||
Jeff Garzik <jgarzik@pretzel.yyz.us>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
|
||||
Jeffrey Hugo <quic_jhugo@quicinc.com> <jhugo@codeaurora.org>
|
||||
Jens Axboe <axboe@kernel.dk> <axboe@suse.de>
|
||||
Jens Axboe <axboe@kernel.dk> <jens.axboe@oracle.com>
|
||||
Jens Axboe <axboe@kernel.dk> <axboe@fb.com>
|
||||
Jens Axboe <axboe@kernel.dk> <axboe@meta.com>
|
||||
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
||||
Jernej Skrabec <jernej.skrabec@gmail.com> <jernej.skrabec@siol.net>
|
||||
Jessica Zhang <quic_jesszhan@quicinc.com> <jesszhan@codeaurora.org>
|
||||
Jilai Wang <quic_jilaiw@quicinc.com> <jilaiw@codeaurora.org>
|
||||
Jiri Kosina <jikos@kernel.org> <jikos@jikos.cz>
|
||||
Jiri Kosina <jikos@kernel.org> <jkosina@suse.cz>
|
||||
Jiri Kosina <jikos@kernel.org> <jkosina@suse.com>
|
||||
Jiri Pirko <jiri@resnulli.us> <jiri@nvidia.com>
|
||||
Jiri Pirko <jiri@resnulli.us> <jiri@mellanox.com>
|
||||
Jiri Pirko <jiri@resnulli.us> <jpirko@redhat.com>
|
||||
Jiri Slaby <jirislaby@kernel.org> <jirislaby@gmail.com>
|
||||
Jiri Slaby <jirislaby@kernel.org> <jslaby@novell.com>
|
||||
Jiri Slaby <jirislaby@kernel.org> <jslaby@suse.com>
|
||||
Jiri Slaby <jirislaby@kernel.org> <jslaby@suse.cz>
|
||||
Jiri Slaby <jirislaby@kernel.org> <xslaby@fi.muni.cz>
|
||||
Jisheng Zhang <jszhang@kernel.org> <jszhang@marvell.com>
|
||||
Jisheng Zhang <jszhang@kernel.org> <Jisheng.Zhang@synaptics.com>
|
||||
Jishnu Prakash <quic_jprakash@quicinc.com> <jprakash@codeaurora.org>
|
||||
Johan Hovold <johan@kernel.org> <jhovold@gmail.com>
|
||||
Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com>
|
||||
John Crispin <john@phrozen.org> <blogic@openwrt.org>
|
||||
John Fastabend <john.fastabend@gmail.com> <john.r.fastabend@intel.com>
|
||||
John Keeping <john@keeping.me.uk> <john@metanate.com>
|
||||
John Moon <john@jmoon.dev> <quic_johmoo@quicinc.com>
|
||||
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
|
||||
John Stultz <johnstul@us.ibm.com>
|
||||
<jon.toppins+linux@gmail.com> <jtoppins@cumulusnetworks.com>
|
||||
<jon.toppins+linux@gmail.com> <jtoppins@redhat.com>
|
||||
Jonas Gorski <jonas.gorski@gmail.com> <jogo@openwrt.org>
|
||||
Jordan Crouse <jordan@cosmicpenguin.net> <jcrouse@codeaurora.org>
|
||||
<josh@joshtriplett.org> <josh@freedesktop.org>
|
||||
<josh@joshtriplett.org> <josh@kernel.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>
|
||||
Jouni Malinen <quic_jouni@quicinc.com> <jouni@codeaurora.org>
|
||||
Juha Yrjola <at solidboot.com>
|
||||
Juha Yrjola <juha.yrjola@nokia.com>
|
||||
Juha Yrjola <juha.yrjola@solidboot.com>
|
||||
Julien Thierry <julien.thierry.kdev@gmail.com> <julien.thierry@arm.com>
|
||||
Iskren Chernev <me@iskren.info> <iskren.chernev@gmail.com>
|
||||
Kalle Valo <kvalo@kernel.org> <kvalo@codeaurora.org>
|
||||
Kalyan Thota <quic_kalyant@quicinc.com> <kalyan_t@codeaurora.org>
|
||||
Karthikeyan Periyasamy <quic_periyasa@quicinc.com> <periyasa@codeaurora.org>
|
||||
Kathiravan T <quic_kathirav@quicinc.com> <kathirav@codeaurora.org>
|
||||
Kay Sievers <kay.sievers@vrfy.org>
|
||||
Kees Cook <keescook@chromium.org> <kees.cook@canonical.com>
|
||||
Kees Cook <keescook@chromium.org> <keescook@google.com>
|
||||
Kees Cook <keescook@chromium.org> <kees@outflux.net>
|
||||
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>
|
||||
Kenneth Westfield <quic_kwestfie@quicinc.com> <kwestfie@codeaurora.org>
|
||||
Kiran Gunda <quic_kgunda@quicinc.com> <kgunda@codeaurora.org>
|
||||
Kirill Tkhai <tkhai@ya.ru> <ktkhai@virtuozzo.com>
|
||||
Kishon Vijay Abraham I <kishon@kernel.org> <kishon@ti.com>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
|
||||
Koushik <raghavendra.koushik@neterion.com>
|
||||
Krishna Manikandan <quic_mkrishn@quicinc.com> <mkrishn@codeaurora.org>
|
||||
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski.k@gmail.com>
|
||||
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski@samsung.com>
|
||||
Krzysztof Kozlowski <krzk@kernel.org> <krzysztof.kozlowski@canonical.com>
|
||||
Kshitiz Godara <quic_kgodara@quicinc.com> <kgodara@codeaurora.org>
|
||||
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
|
||||
Kuogee Hsieh <quic_khsieh@quicinc.com> <khsieh@codeaurora.org>
|
||||
Lee Jones <lee@kernel.org> <joneslee@google.com>
|
||||
Lee Jones <lee@kernel.org> <lee.jones@canonical.com>
|
||||
Lee Jones <lee@kernel.org> <lee.jones@linaro.org>
|
||||
Lee Jones <lee@kernel.org> <lee@ubuntu.com>
|
||||
Leonard Crestez <leonard.crestez@nxp.com> Leonard Crestez <cdleonard@gmail.com>
|
||||
Leonardo Bras <leobras.c@gmail.com> <leonardo@linux.ibm.com>
|
||||
Leonard Göhrs <l.goehrs@pengutronix.de>
|
||||
Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
||||
Leon Romanovsky <leon@kernel.org> <leon@leon.nu>
|
||||
Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com>
|
||||
Leon Romanovsky <leon@kernel.org> <leonro@nvidia.com>
|
||||
Leo Yan <leo.yan@linux.dev> <leo.yan@linaro.org>
|
||||
Liam Mark <quic_lmark@quicinc.com> <lmark@codeaurora.org>
|
||||
Linas Vepstas <linas@austin.ibm.com>
|
||||
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>
|
||||
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>
|
||||
Lior David <quic_liord@quicinc.com> <liord@codeaurora.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>
|
||||
Luo Jie <quic_luoj@quicinc.com> <luoj@codeaurora.org>
|
||||
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
|
||||
Maciej W. Rozycki <macro@orcam.me.uk> <macro@linux-mips.org>
|
||||
Maharaja Kennadyrajan <quic_mkenna@quicinc.com> <mkenna@codeaurora.org>
|
||||
Maheshwar Ajja <quic_majja@quicinc.com> <majja@codeaurora.org>
|
||||
Malathi Gottam <quic_mgottam@quicinc.com> <mgottam@codeaurora.org>
|
||||
Manikanta Pubbisetty <quic_mpubbise@quicinc.com> <mpubbise@codeaurora.org>
|
||||
Manivannan Sadhasivam <mani@kernel.org> <manivannanece23@gmail.com>
|
||||
Manoj Basapathi <quic_manojbm@quicinc.com> <manojbm@codeaurora.org>
|
||||
Marcin Nowakowski <marcin.nowakowski@mips.com> <marcin.nowakowski@imgtec.com>
|
||||
Marc Zyngier <maz@kernel.org> <marc.zyngier@arm.com>
|
||||
Marek Behún <kabel@kernel.org> <marek.behun@nic.cz>
|
||||
Marek Behún <kabel@kernel.org> Marek Behun <marek.behun@nic.cz>
|
||||
Mark Brown <broonie@sirena.org.uk>
|
||||
Mark Starovoytov <mstarovo@pm.me> <mstarovoitov@marvell.com>
|
||||
Markus Schneider-Pargmann <msp@baylibre.com> <mpa@pengutronix.de>
|
||||
Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com>
|
||||
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@ginzinger.com>
|
||||
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@puri.sm>
|
||||
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>
|
||||
Martyna Szapar-Mudlaw <martyna.szapar-mudlaw@linux.intel.com> <martyna.szapar-mudlaw@intel.com>
|
||||
Mathieu Othacehe <m.othacehe@gmail.com> <othacehe@gnu.org>
|
||||
Mat Martineau <martineau@kernel.org> <mathew.j.martineau@linux.intel.com>
|
||||
Mat Martineau <martineau@kernel.org> <mathewm@codeaurora.org>
|
||||
Matthew Wilcox <willy@infradead.org> <matthew.r.wilcox@intel.com>
|
||||
Matthew Wilcox <willy@infradead.org> <matthew@wil.cx>
|
||||
Matthew Wilcox <willy@infradead.org> <mawilcox@linuxonhyperv.com>
|
||||
Matthew Wilcox <willy@infradead.org> <mawilcox@microsoft.com>
|
||||
Matthew Wilcox <willy@infradead.org> <willy@debian.org>
|
||||
Matthew Wilcox <willy@infradead.org> <willy@linux.intel.com>
|
||||
Matthew Wilcox <willy@infradead.org> <willy@parisc-linux.org>
|
||||
Matthias Fuchs <socketcan@esd.eu> <matthias.fuchs@esd.eu>
|
||||
Matthieu Baerts <matttbe@kernel.org> <matthieu.baerts@tessares.net>
|
||||
Matthieu CASTET <castet.matthieu@free.fr>
|
||||
Matti Vaittinen <mazziesaccount@gmail.com> <matti.vaittinen@fi.rohmeurope.com>
|
||||
Matt Ranostay <matt@ranostay.sg> <matt.ranostay@konsulko.com>
|
||||
Matt Ranostay <matt@ranostay.sg> <matt@ranostay.consulting>
|
||||
Matt Ranostay <matt@ranostay.sg> Matthew Ranostay <mranostay@embeddedalley.com>
|
||||
Matt Ranostay <matt@ranostay.sg> <matt.ranostay@intel.com>
|
||||
Matt Redfearn <matt.redfearn@mips.com> <matt.redfearn@imgtec.com>
|
||||
Maulik Shah <quic_mkshah@quicinc.com> <mkshah@codeaurora.org>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@brturbo.com.br>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@infradead.org>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@osg.samsung.com>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@redhat.com>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <m.chehab@samsung.com>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@s-opensource.com>
|
||||
Maxim Mikityanskiy <maxtram95@gmail.com> <maximmi@mellanox.com>
|
||||
Maxim Mikityanskiy <maxtram95@gmail.com> <maximmi@nvidia.com>
|
||||
Maxime Ripard <mripard@kernel.org> <maxime@cerno.tech>
|
||||
Maxime Ripard <mripard@kernel.org> <maxime.ripard@bootlin.com>
|
||||
Maxime Ripard <mripard@kernel.org> <maxime.ripard@free-electrons.com>
|
||||
Maya Erez <quic_merez@quicinc.com> <merez@codeaurora.org>
|
||||
Mayuresh Janorkar <mayur@ti.com>
|
||||
Md Sadre Alam <quic_mdalam@quicinc.com> <mdalam@codeaurora.org>
|
||||
Miaoqing Pan <quic_miaoqing@quicinc.com> <miaoqing@codeaurora.org>
|
||||
Michael Buesch <m@bues.ch>
|
||||
Michal Simek <michal.simek@amd.com> <michal.simek@xilinx.com>
|
||||
Michel Dänzer <michel@tungstengraphics.com>
|
||||
Michel Lespinasse <michel@lespinasse.org>
|
||||
Michel Lespinasse <michel@lespinasse.org> <walken@google.com>
|
||||
Michel Lespinasse <michel@lespinasse.org> <walken@zoy.org>
|
||||
Miguel Ojeda <ojeda@kernel.org> <miguel.ojeda.sandonis@gmail.com>
|
||||
Mike Rapoport <rppt@kernel.org> <mike@compulab.co.il>
|
||||
Mike Rapoport <rppt@kernel.org> <mike.rapoport@gmail.com>
|
||||
Mike Rapoport <rppt@kernel.org> <rppt@linux.ibm.com>
|
||||
Mike Tipton <quic_mdtipton@quicinc.com> <mdtipton@codeaurora.org>
|
||||
Miodrag Dinic <miodrag.dinic@mips.com> <miodrag.dinic@imgtec.com>
|
||||
Miquel Raynal <miquel.raynal@bootlin.com> <miquel.raynal@free-electrons.com>
|
||||
Mitesh shah <mshah@teja.com>
|
||||
Mohit Kumar <mohit.kumar@st.com> <mohit.kumar.dhaka@gmail.com>
|
||||
Morten Welinder <terra@gnome.org>
|
||||
Morten Welinder <welinder@anemone.rentec.com>
|
||||
Morten Welinder <welinder@darter.rentec.com>
|
||||
Morten Welinder <welinder@troll.com>
|
||||
Mukesh Ojha <quic_mojha@quicinc.com> <mojha@codeaurora.org>
|
||||
Muna Sinada <quic_msinada@quicinc.com> <msinada@codeaurora.org>
|
||||
Murali Nalajala <quic_mnalajal@quicinc.com> <mnalajal@codeaurora.org>
|
||||
Mythri P K <mythripk@ti.com>
|
||||
Nadia Yvette Chambers <nyc@holomorphy.com> William Lee Irwin III <wli@holomorphy.com>
|
||||
Naoya Horiguchi <naoya.horiguchi@nec.com> <n-horiguchi@ah.jp.nec.com>
|
||||
Nathan Chancellor <nathan@kernel.org> <natechancellor@gmail.com>
|
||||
Neeraj Upadhyay <quic_neeraju@quicinc.com> <neeraju@codeaurora.org>
|
||||
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>
|
||||
Nicholas Piggin <npiggin@gmail.com> <npiggin@suse.de>
|
||||
Nicholas Piggin <npiggin@gmail.com> <nickpiggin@yahoo.com.au>
|
||||
Nicholas Piggin <npiggin@gmail.com> <piggin@cyberone.com.au>
|
||||
Nicolas Ferre <nicolas.ferre@microchip.com> <nicolas.ferre@atmel.com>
|
||||
Nicolas Pitre <nico@fluxnic.net> <nicolas.pitre@linaro.org>
|
||||
Nicolas Pitre <nico@fluxnic.net> <nico@linaro.org>
|
||||
Nicolas Saenz Julienne <nsaenz@kernel.org> <nsaenzjulienne@suse.de>
|
||||
Nicolas Saenz Julienne <nsaenz@kernel.org> <nsaenzjulienne@suse.com>
|
||||
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
|
||||
Nikolay Aleksandrov <razor@blackwall.org> <naleksan@redhat.com>
|
||||
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@redhat.com>
|
||||
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@cumulusnetworks.com>
|
||||
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@nvidia.com>
|
||||
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@isovalent.com>
|
||||
Odelu Kukatla <quic_okukatla@quicinc.com> <okukatla@codeaurora.org>
|
||||
Oleksandr Natalenko <oleksandr@natalenko.name> <oleksandr@redhat.com>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <bug-track@fisher-privat.net>
|
||||
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 <o.rempel@pengutronix.de>
|
||||
Oleksij Rempel <o.rempel@pengutronix.de> <ore@pengutronix.de>
|
||||
Oliver Upton <oliver.upton@linux.dev> <oupton@google.com>
|
||||
Ondřej Jirman <megi@xff.cz> <megous@megous.com>
|
||||
Oza Pawandeep <quic_poza@quicinc.com> <poza@codeaurora.org>
|
||||
Pali Rohár <pali@kernel.org> <pali.rohar@gmail.com>
|
||||
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
|
||||
Patrick Mochel <mochel@digitalimplant.org>
|
||||
Paul Burton <paulburton@kernel.org> <paul.burton@imgtec.com>
|
||||
Paul Burton <paulburton@kernel.org> <paul.burton@mips.com>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paul.mckenney@linaro.org>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paulmck@linux.ibm.com>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paulmck@linux.vnet.ibm.com>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paulmck@us.ibm.com>
|
||||
Paul Mackerras <paulus@ozlabs.org> <paulus@samba.org>
|
||||
Paul Mackerras <paulus@ozlabs.org> <paulus@au1.ibm.com>
|
||||
Paul Moore <paul@paul-moore.com> <paul.moore@hp.com>
|
||||
Paul Moore <paul@paul-moore.com> <pmoore@redhat.com>
|
||||
Pavankumar Kondeti <quic_pkondeti@quicinc.com> <pkondeti@codeaurora.org>
|
||||
Peter A Jonsson <pj@ludd.ltu.se>
|
||||
Peter Oruba <peter.oruba@amd.com>
|
||||
Peter Oruba <peter@oruba.de>
|
||||
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
|
||||
Praveen BP <praveenbp@ti.com>
|
||||
Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com> <pradeepc@codeaurora.org>
|
||||
Prasad Sodagudi <quic_psodagud@quicinc.com> <psodagud@codeaurora.org>
|
||||
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>
|
||||
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>
|
||||
Rajeev Nandan <quic_rajeevny@quicinc.com> <rajeevny@codeaurora.org>
|
||||
Rajendra Nayak <quic_rjendra@quicinc.com> <rnayak@codeaurora.org>
|
||||
Rajeshwari Ravindra Kamble <quic_rkambl@quicinc.com> <rkambl@codeaurora.org>
|
||||
Raju P.L.S.S.S.N <quic_rplsssn@quicinc.com> <rplsssn@codeaurora.org>
|
||||
Rajesh Shah <rajesh.shah@intel.com>
|
||||
Rakesh Pillai <quic_pillair@quicinc.com> <pillair@codeaurora.org>
|
||||
Ralf Baechle <ralf@linux-mips.org>
|
||||
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
|
||||
Ram Chandra Jangir <quic_rjangir@quicinc.com> <rjangir@codeaurora.org>
|
||||
Randy Dunlap <rdunlap@infradead.org> <rdunlap@xenotime.net>
|
||||
Randy Dunlap <rdunlap@infradead.org> <randy.dunlap@oracle.com>
|
||||
Randy Dunlap <rdunlap@infradead.org> <rddunlap@osdl.org>
|
||||
Randy Dunlap <rdunlap@infradead.org> <randy.dunlap@intel.com>
|
||||
Ravi Kumar Bokka <quic_rbokka@quicinc.com> <rbokka@codeaurora.org>
|
||||
Ravi Kumar Siddojigari <quic_rsiddoji@quicinc.com> <rsiddoji@codeaurora.org>
|
||||
Rémi Denis-Courmont <rdenis@simphalempin.com>
|
||||
Ricardo Ribalda <ribalda@kernel.org> <ricardo@ribalda.com>
|
||||
Ricardo Ribalda <ribalda@kernel.org> Ricardo Ribalda Delgado <ribalda@kernel.org>
|
||||
Ricardo Ribalda <ribalda@kernel.org> <ricardo.ribalda@gmail.com>
|
||||
Richard Leitner <richard.leitner@linux.dev> <dev@g0hl1n.net>
|
||||
Richard Leitner <richard.leitner@linux.dev> <me@g0hl1n.net>
|
||||
Richard Leitner <richard.leitner@linux.dev> <richard.leitner@skidata.com>
|
||||
Robert Foss <rfoss@kernel.org> <robert.foss@linaro.org>
|
||||
Rocky Liao <quic_rjliao@quicinc.com> <rjliao@codeaurora.org>
|
||||
Roman Gushchin <roman.gushchin@linux.dev> <guro@fb.com>
|
||||
Roman Gushchin <roman.gushchin@linux.dev> <guroan@gmail.com>
|
||||
Roman Gushchin <roman.gushchin@linux.dev> <klamm@yandex-team.ru>
|
||||
Muchun Song <muchun.song@linux.dev> <songmuchun@bytedance.com>
|
||||
Muchun Song <muchun.song@linux.dev> <smuchun@gmail.com>
|
||||
Ross Zwisler <zwisler@kernel.org> <ross.zwisler@linux.intel.com>
|
||||
Rudolf Marek <R.Marek@sh.cvut.cz>
|
||||
Rui Saraiva <rmps@joel.ist.utl.pt>
|
||||
Sachin P Sant <ssant@in.ibm.com>
|
||||
Sai Prakash Ranjan <quic_saipraka@quicinc.com> <saiprakash.ranjan@codeaurora.org>
|
||||
Sakari Ailus <sakari.ailus@linux.intel.com> <sakari.ailus@iki.fi>
|
||||
Sam Ravnborg <sam@mars.ravnborg.org>
|
||||
Sankeerth Billakanti <quic_sbillaka@quicinc.com> <sbillaka@codeaurora.org>
|
||||
Santosh Shilimkar <santosh.shilimkar@oracle.org>
|
||||
Santosh Shilimkar <ssantosh@kernel.org>
|
||||
Sarangdhar Joshi <spjoshi@codeaurora.org>
|
||||
Sascha Hauer <s.hauer@pengutronix.de>
|
||||
Sahitya Tummala <quic_stummala@quicinc.com> <stummala@codeaurora.org>
|
||||
Sathishkumar Muruganandam <quic_murugana@quicinc.com> <murugana@codeaurora.org>
|
||||
Satya Priya <quic_c_skakit@quicinc.com> <skakit@codeaurora.org>
|
||||
S.Çağlar Onur <caglar@pardus.org.tr>
|
||||
Sayali Lokhande <quic_sayalil@quicinc.com> <sayalil@codeaurora.org>
|
||||
Sean Christopherson <seanjc@google.com> <sean.j.christopherson@intel.com>
|
||||
Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk>
|
||||
Sean Tranchetti <quic_stranche@quicinc.com> <stranche@codeaurora.org>
|
||||
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>
|
||||
Senthilkumar N L <quic_snlakshm@quicinc.com> <snlakshm@codeaurora.org>
|
||||
Serge Hallyn <sergeh@kernel.org> <serge.hallyn@canonical.com>
|
||||
Serge Hallyn <sergeh@kernel.org> <serue@us.ibm.com>
|
||||
Seth Forshee <sforshee@kernel.org> <seth.forshee@canonical.com>
|
||||
Shakeel Butt <shakeel.butt@linux.dev> <shakeelb@google.com>
|
||||
Shannon Nelson <shannon.nelson@amd.com> <snelson@pensando.io>
|
||||
Shannon Nelson <shannon.nelson@amd.com> <shannon.nelson@intel.com>
|
||||
Shannon Nelson <shannon.nelson@amd.com> <shannon.nelson@oracle.com>
|
||||
Sharath Chandra Vurukala <quic_sharathv@quicinc.com> <sharathv@codeaurora.org>
|
||||
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>
|
||||
Shuah Khan <shuah@kernel.org> <shuahkh@osg.samsung.com>
|
||||
Shuah Khan <shuah@kernel.org> <shuah.kh@samsung.com>
|
||||
Sibi Sankar <quic_sibis@quicinc.com> <sibis@codeaurora.org>
|
||||
Sid Manning <quic_sidneym@quicinc.com> <sidneym@codeaurora.org>
|
||||
Simon Arlott <simon@octiron.net> <simon@fire.lp0.eu>
|
||||
Simon Horman <horms@kernel.org> <simon.horman@corigine.com>
|
||||
Simon Horman <horms@kernel.org> <simon.horman@netronome.com>
|
||||
Simon Kelley <simon@thekelleys.org.uk>
|
||||
Sricharan Ramabadhran <quic_srichara@quicinc.com> <sricharan@codeaurora.org>
|
||||
Srinivas Ramana <quic_sramana@quicinc.com> <sramana@codeaurora.org>
|
||||
Sriram R <quic_srirrama@quicinc.com> <srirrama@codeaurora.org>
|
||||
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
|
||||
Stephen Hemminger <stephen@networkplumber.org> <shemminger@linux-foundation.org>
|
||||
Stephen Hemminger <stephen@networkplumber.org> <shemminger@osdl.org>
|
||||
Stephen Hemminger <stephen@networkplumber.org> <sthemmin@microsoft.com>
|
||||
Stephen Hemminger <stephen@networkplumber.org> <sthemmin@vyatta.com>
|
||||
Steve Wise <larrystevenwise@gmail.com> <swise@chelsio.com>
|
||||
Steve Wise <larrystevenwise@gmail.com> <swise@opengridcomputing.com>
|
||||
Subash Abhinov Kasiviswanathan <quic_subashab@quicinc.com> <subashab@codeaurora.org>
|
||||
Subbaraman Narayanamurthy <quic_subbaram@quicinc.com> <subbaram@codeaurora.org>
|
||||
Subhash Jadavani <subhashj@codeaurora.org>
|
||||
Sudarshan Rajagopalan <quic_sudaraja@quicinc.com> <sudaraja@codeaurora.org>
|
||||
Sudeep Holla <sudeep.holla@arm.com> Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
|
||||
Sumit Semwal <sumit.semwal@ti.com>
|
||||
Surabhi Vishnoi <quic_svishnoi@quicinc.com> <svishnoi@codeaurora.org>
|
||||
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
|
||||
Tamizh Chelvam Raja <quic_tamizhr@quicinc.com> <tamizhr@codeaurora.org>
|
||||
Taniya Das <quic_tdas@quicinc.com> <tdas@codeaurora.org>
|
||||
Tanzir Hasan <tanzhasanwork@gmail.com> <tanzirh@google.com>
|
||||
Tejun Heo <htejun@gmail.com>
|
||||
Tomeu Vizoso <tomeu@tomeuvizoso.net> <tomeu.vizoso@collabora.com>
|
||||
Thomas Graf <tgraf@suug.ch>
|
||||
Thomas Körper <socketcan@esd.eu> <thomas.koerper@esd.eu>
|
||||
Thomas Pedersen <twp@codeaurora.org>
|
||||
Tiezhu Yang <yangtiezhu@loongson.cn> <kernelpatch@126.com>
|
||||
Tingwei Zhang <quic_tingwei@quicinc.com> <tingwei@codeaurora.org>
|
||||
Tirupathi Reddy <quic_tirupath@quicinc.com> <tirupath@codeaurora.org>
|
||||
Tobias Klauser <tklauser@distanz.ch> <tobias.klauser@gmail.com>
|
||||
Tobias Klauser <tklauser@distanz.ch> <klto@zhaw.ch>
|
||||
Tobias Klauser <tklauser@distanz.ch> <tklauser@nuerscht.ch>
|
||||
Tobias Klauser <tklauser@distanz.ch> <tklauser@xenon.tklauser.home>
|
||||
Todor Tomov <todor.too@gmail.com> <todor.tomov@linaro.org>
|
||||
Tony Luck <tony.luck@intel.com>
|
||||
Trilok Soni <quic_tsoni@quicinc.com> <tsoni@codeaurora.org>
|
||||
TripleX Chung <xxx.phy@gmail.com> <triplex@zh-kernel.org>
|
||||
TripleX Chung <xxx.phy@gmail.com> <zhongyu@18mail.cn>
|
||||
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
|
||||
Tudor Ambarus <tudor.ambarus@linaro.org> <tudor.ambarus@microchip.com>
|
||||
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@intel.com>
|
||||
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@linux.intel.com>
|
||||
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@sophos.com>
|
||||
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@onelan.co.uk>
|
||||
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko@ursulin.net>
|
||||
Tycho Andersen <tycho@tycho.pizza> <tycho@tycho.ws>
|
||||
Tzung-Bi Shih <tzungbi@kernel.org> <tzungbi@google.com>
|
||||
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
|
||||
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
Uwe Kleine-König <ukleinek@strlen.de>
|
||||
Uwe Kleine-König <ukl@pengutronix.de>
|
||||
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
|
||||
Vadim Fedorenko <vadim.fedorenko@linux.dev> <vadfed@fb.com>
|
||||
Vadim Fedorenko <vadim.fedorenko@linux.dev> <vadfed@meta.com>
|
||||
Vadim Fedorenko <vadim.fedorenko@linux.dev> <vfedorenko@novek.ru>
|
||||
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
|
||||
Vara Reddy <quic_varar@quicinc.com> <varar@codeaurora.org>
|
||||
Varadarajan Narayanan <quic_varada@quicinc.com> <varada@codeaurora.org>
|
||||
Vasanthakumar Thiagarajan <quic_vthiagar@quicinc.com> <vthiagar@codeaurora.org>
|
||||
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>
|
||||
Veera Sundaram Sankaran <quic_veeras@quicinc.com> <veeras@codeaurora.org>
|
||||
Veerabhadrarao Badiganti <quic_vbadigan@quicinc.com> <vbadigan@codeaurora.org>
|
||||
Venkateswara Naralasetty <quic_vnaralas@quicinc.com> <vnaralas@codeaurora.org>
|
||||
Vikash Garodia <quic_vgarodia@quicinc.com> <vgarodia@codeaurora.org>
|
||||
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>
|
||||
Viresh Kumar <vireshk@kernel.org> <viresh.kumar2@arm.com>
|
||||
Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com>
|
||||
Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com>
|
||||
Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.org>
|
||||
Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.com>
|
||||
Vivek Aknurwar <quic_viveka@quicinc.com> <viveka@codeaurora.org>
|
||||
Vivien Didelot <vivien.didelot@gmail.com> <vivien.didelot@savoirfairelinux.com>
|
||||
Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com>
|
||||
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@parallels.com>
|
||||
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@virtuozzo.com>
|
||||
WeiXiong Liao <gmpy.liaowx@gmail.com> <liaoweixiong@allwinnertech.com>
|
||||
Wen Gong <quic_wgong@quicinc.com> <wgong@codeaurora.org>
|
||||
Wesley Cheng <quic_wcheng@quicinc.com> <wcheng@codeaurora.org>
|
||||
Will Deacon <will@kernel.org> <will.deacon@arm.com>
|
||||
Wolfram Sang <wsa@kernel.org> <w.sang@pengutronix.de>
|
||||
Wolfram Sang <wsa@kernel.org> <wsa@the-dreams.de>
|
||||
Yakir Yang <kuankuan.y@gmail.com> <ykk@rock-chips.com>
|
||||
Yusuke Goda <goda.yusuke@renesas.com>
|
||||
Zack Rusin <zack.rusin@broadcom.com> <zackr@vmware.com>
|
||||
Zhu Yanjun <zyjzyj2000@gmail.com> <yanjunz@nvidia.com>
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
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
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
The Linux Kernel is provided under:
|
||||
|
||||
SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
|
||||
|
||||
Being under the terms of the GNU General Public License version 2 only,
|
||||
according with:
|
||||
|
||||
LICENSES/preferred/GPL-2.0
|
||||
|
||||
With an explicit syscall exception, as stated at:
|
||||
|
||||
LICENSES/exceptions/Linux-syscall-note
|
||||
|
||||
In addition, other licenses may also apply. Please see:
|
||||
|
||||
Documentation/process/license-rules.rst
|
||||
|
||||
for more details.
|
||||
|
||||
All contributions to the Linux Kernel are subject to this COPYING file.
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,3 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
output
|
||||
*.pyc
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
This directory attempts to document the ABI between the Linux kernel and
|
||||
userspace, and the relative stability of these interfaces. Due to the
|
||||
everchanging nature of Linux, and the differing maturity levels, these
|
||||
interfaces should be used by userspace programs in different ways.
|
||||
|
||||
We have four different levels of ABI stability, as shown by the four
|
||||
different subdirectories in this location. Interfaces may change levels
|
||||
of stability according to the rules described below.
|
||||
|
||||
The different levels of stability are:
|
||||
|
||||
stable/
|
||||
This directory documents the interfaces that the developer has
|
||||
defined to be stable. Userspace programs are free to use these
|
||||
interfaces with no restrictions, and backward compatibility for
|
||||
them will be guaranteed for at least 2 years. Most interfaces
|
||||
(like syscalls) are expected to never change and always be
|
||||
available.
|
||||
|
||||
testing/
|
||||
This directory documents interfaces that are felt to be stable,
|
||||
as the main development of this interface has been completed.
|
||||
The interface can be changed to add new features, but the
|
||||
current interface will not break by doing this, unless grave
|
||||
errors or security problems are found in them. Userspace
|
||||
programs can start to rely on these interfaces, but they must be
|
||||
aware of changes that can occur before these interfaces move to
|
||||
be marked stable. Programs that use these interfaces are
|
||||
strongly encouraged to add their name to the description of
|
||||
these interfaces, so that the kernel developers can easily
|
||||
notify them if any changes occur (see the description of the
|
||||
layout of the files below for details on how to do this.)
|
||||
|
||||
obsolete/
|
||||
This directory documents interfaces that are still remaining in
|
||||
the kernel, but are marked to be removed at some later point in
|
||||
time. The description of the interface will document the reason
|
||||
why it is obsolete and when it can be expected to be removed.
|
||||
|
||||
removed/
|
||||
This directory contains a list of the old interfaces that have
|
||||
been removed from the kernel.
|
||||
|
||||
Every file in these directories will contain the following information:
|
||||
|
||||
What: Short description of the interface
|
||||
Date: Date created
|
||||
KernelVersion: Kernel version this feature first showed up in.
|
||||
Contact: Primary contact for this interface (may be a mailing list)
|
||||
Description: Long description of the interface and how to use it.
|
||||
Users: All users of this interface who wish to be notified when
|
||||
it changes. This is very important for interfaces in
|
||||
the "testing" stage, so that kernel developers can work
|
||||
with userspace developers to ensure that things do not
|
||||
break in ways that are unacceptable. It is also
|
||||
important to get feedback for these interfaces to make
|
||||
sure they are working in a proper way and do not need to
|
||||
be changed further.
|
||||
|
||||
|
||||
Note:
|
||||
The fields should be use a simple notation, compatible with ReST markup.
|
||||
Also, the file **should not** have a top-level index, like::
|
||||
|
||||
===
|
||||
foo
|
||||
===
|
||||
|
||||
How things move between levels:
|
||||
|
||||
Interfaces in stable may move to obsolete, as long as the proper
|
||||
notification is given.
|
||||
|
||||
Interfaces may be removed from obsolete and the kernel as long as the
|
||||
documented amount of time has gone by.
|
||||
|
||||
Interfaces in the testing state can move to the stable state when the
|
||||
developers feel they are finished. They cannot be removed from the
|
||||
kernel tree without going through the obsolete state first.
|
||||
|
||||
It's up to the developer to place their interfaces in the category they
|
||||
wish for it to start out in.
|
||||
|
||||
|
||||
Notable bits of non-ABI, which should not under any circumstances be considered
|
||||
stable:
|
||||
|
||||
- Kconfig. Userspace should not rely on the presence or absence of any
|
||||
particular Kconfig symbol, in /proc/config.gz, in the copy of .config
|
||||
commonly installed to /boot, or in any invocation of the kernel build
|
||||
process.
|
||||
|
||||
- Kernel-internal symbols. Do not rely on the presence, absence, location, or
|
||||
type of any kernel symbol, either in System.map files or the kernel binary
|
||||
itself. See Documentation/process/stable-api-nonsense.rst.
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
What: /sys/o2cb
|
||||
Date: Dec 2005
|
||||
KernelVersion: 2.6.16
|
||||
Contact: ocfs2-devel@lists.linux.dev
|
||||
Description: Ocfs2-tools looks at 'interface-revision' for versioning
|
||||
information. Each logmask/ file controls a set of debug prints
|
||||
and can be written into with the strings "allow", "deny", or
|
||||
"off". Reading the file returns the current state.
|
||||
Was renamed to /sys/fs/u2cb/
|
||||
Users: ocfs2-tools. It's sufficient to mail proposed changes to
|
||||
ocfs2-devel@lists.linux.dev.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
What: /proc/i8k
|
||||
Date: November 2001
|
||||
KernelVersion: 2.4.14
|
||||
Contact: Pali Rohár <pali@kernel.org>
|
||||
Description: Legacy interface for getting/setting sensor information like
|
||||
fan speed, temperature, serial number, hotkey status etc
|
||||
on Dell Laptops.
|
||||
Since the driver is now using the standard hwmon sysfs interface,
|
||||
the procfs interface is deprecated.
|
||||
Users: https://github.com/vitorafsr/i8kutils
|
||||
|
|
@ -0,0 +1,186 @@
|
|||
What: /sys/bus/iio/devices/iio:deviceX/buffer/length
|
||||
KernelVersion: 2.6.35
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Number of scans contained by the buffer.
|
||||
|
||||
Since Kernel 5.11, multiple buffers are supported.
|
||||
so, it is better to use, instead:
|
||||
|
||||
/sys/bus/iio/devices/iio:deviceX/bufferY/length
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/buffer/enable
|
||||
KernelVersion: 2.6.35
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Actually start the buffer capture up. Will start trigger
|
||||
if first device and appropriate.
|
||||
|
||||
Since Kernel 5.11, multiple buffers are supported.
|
||||
so, it is better to use, instead:
|
||||
|
||||
/sys/bus/iio/devices/iio:deviceX/bufferY/enable
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/scan_elements
|
||||
KernelVersion: 2.6.37
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Directory containing interfaces for elements that will be
|
||||
captured for a single triggered sample set in the buffer.
|
||||
|
||||
Since kernel 5.11 the scan_elements attributes are merged into
|
||||
the bufferY directory, to be configurable per buffer.
|
||||
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_accel_x_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_accel_y_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_accel_z_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_magn_x_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_magn_y_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_magn_z_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltageY-voltageZ_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_pressure_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_en
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_proximity_en
|
||||
KernelVersion: 2.6.37
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Scan element control for triggered data capture.
|
||||
|
||||
Since kernel 5.11 the scan_elements attributes are merged into
|
||||
the bufferY directory, to be configurable per buffer.
|
||||
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_accel_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_magn_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_incli_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltage_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_pressure_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_type
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_proximity_type
|
||||
KernelVersion: 2.6.37
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Description of the scan element data storage within the buffer
|
||||
and hence the form in which it is read from user-space.
|
||||
Form is [be|le]:[s|u]bits/storagebits[>>shift].
|
||||
be or le specifies big or little endian. s or u specifies if
|
||||
signed (2's complement) or unsigned. bits is the number of bits
|
||||
of data and storagebits is the space (after padding) that it
|
||||
occupies in the buffer. shift if specified, is the shift that
|
||||
needs to be applied prior to masking out unused bits. Some
|
||||
devices put their data in the middle of the transferred elements
|
||||
with additional information on both sides. Note that some
|
||||
devices will have additional information in the unused bits
|
||||
so to get a clean value, the bits value must be used to mask
|
||||
the buffer output value appropriately. The storagebits value
|
||||
also specifies the data alignment. So s48/64>>2 will be a
|
||||
signed 48 bit integer stored in a 64 bit location aligned to
|
||||
a 64 bit boundary. To obtain the clean value, shift right 2
|
||||
and apply a mask to zero the top 16 bits of the result.
|
||||
For other storage combinations this attribute will be extended
|
||||
appropriately.
|
||||
|
||||
Since kernel 5.11 the scan_elements attributes are merged into
|
||||
the bufferY directory, to be configurable per buffer.
|
||||
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_accel_x_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_accel_y_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_accel_z_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_magn_x_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_magn_y_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_magn_z_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_incli_x_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_pressure_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_index
|
||||
What: /sys/.../iio:deviceX/scan_elements/in_proximity_index
|
||||
KernelVersion: 2.6.37
|
||||
Description:
|
||||
A single positive integer specifying the position of this
|
||||
scan element in the buffer. Note these are not dependent on
|
||||
what is enabled and may not be contiguous. Thus for user-space
|
||||
to establish the full layout these must be used in conjunction
|
||||
with all _en attributes to establish which channels are present,
|
||||
and the relevant _type attributes to establish the data storage
|
||||
format.
|
||||
|
||||
Since kernel 5.11 the scan_elements attributes are merged into
|
||||
the bufferY directory, to be configurable per buffer.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/buffer/watermark
|
||||
KernelVersion: 4.2
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
A single positive integer specifying the maximum number of scan
|
||||
elements to wait for.
|
||||
|
||||
Poll will block until the watermark is reached.
|
||||
|
||||
Blocking read will wait until the minimum between the requested
|
||||
read amount or the low water mark is available.
|
||||
|
||||
Non-blocking read will retrieve the available samples from the
|
||||
buffer even if there are less samples then watermark level. This
|
||||
allows the application to block on poll with a timeout and read
|
||||
the available samples after the timeout expires and thus have a
|
||||
maximum delay guarantee.
|
||||
|
||||
Since Kernel 5.11, multiple buffers are supported.
|
||||
so, it is better to use, instead:
|
||||
|
||||
/sys/bus/iio/devices/iio:deviceX/bufferY/watermark
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/buffer/data_available
|
||||
KernelVersion: 4.16
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
A read-only value indicating the bytes of data available in the
|
||||
buffer. In the case of an output buffer, this indicates the
|
||||
amount of empty space available to write data to. In the case of
|
||||
an input buffer, this indicates the amount of data available for
|
||||
reading.
|
||||
|
||||
Since Kernel 5.11, multiple buffers are supported.
|
||||
so, it is better to use, instead:
|
||||
|
||||
/sys/bus/iio/devices/iio:deviceX/bufferY/data_available
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
What: /sys/bus/usb/devices/.../power/level
|
||||
Date: March 2007
|
||||
KernelVersion: 2.6.21
|
||||
Contact: Alan Stern <stern@rowland.harvard.edu>
|
||||
Description:
|
||||
Each USB device directory will contain a file named
|
||||
power/level. This file holds a power-level setting for
|
||||
the device, either "on" or "auto".
|
||||
|
||||
"on" means that the device is not allowed to autosuspend,
|
||||
although normal suspends for system sleep will still
|
||||
be honored. "auto" means the device will autosuspend
|
||||
and autoresume in the usual manner, according to the
|
||||
capabilities of its driver.
|
||||
|
||||
During normal use, devices should be left in the "auto"
|
||||
level. The "on" level is meant for administrative uses.
|
||||
If you want to suspend a device immediately but leave it
|
||||
free to wake up in response to I/O requests, you should
|
||||
write "0" to power/autosuspend.
|
||||
|
||||
Device not capable of proper suspend and resume should be
|
||||
left in the "on" level. Although the USB spec requires
|
||||
devices to support suspend/resume, many of them do not.
|
||||
In fact so many don't that by default, the USB core
|
||||
initializes all non-hub devices in the "on" level. Some
|
||||
drivers may change this setting when they are bound.
|
||||
|
||||
This file is deprecated and will be removed after 2010.
|
||||
Use the power/control file instead; it does exactly the
|
||||
same thing.
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
These files are deprecated and will be removed. The same files are available
|
||||
under /sys/bus/typec (see Documentation/ABI/testing/sysfs-bus-typec).
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/svid
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
The SVID (Standard or Vendor ID) assigned by USB-IF for this
|
||||
alternate mode.
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Every supported mode will have its own directory. The name of
|
||||
a mode will be "mode<index>" (for example mode1), where <index>
|
||||
is the actual index to the mode VDO returned by Discover Modes
|
||||
USB power delivery command.
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/description
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Shows description of the mode. The description is optional for
|
||||
the drivers, just like with the Billboard Devices.
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/vdo
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Shows the VDO in hexadecimal returned by Discover Modes command
|
||||
for this mode.
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/active
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Shows if the mode is active or not. The attribute can be used
|
||||
for entering/exiting the mode with partners and cable plugs, and
|
||||
with the port alternate modes it can be used for disabling
|
||||
support for specific alternate modes. Entering/exiting modes is
|
||||
supported as synchronous operation so write(2) to the attribute
|
||||
does not return until the enter/exit mode operation has
|
||||
finished. The attribute is notified when the mode is
|
||||
entered/exited so poll(2) on the attribute wakes up.
|
||||
Entering/exiting a mode will also generate uevent KOBJ_CHANGE.
|
||||
|
||||
Valid values: yes, no
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
What: /sys/devices/system/cpu/cpuidle/current_governor_ro
|
||||
Date: April, 2020
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
current_governor_ro shows current using cpuidle governor, but read only.
|
||||
with the update that cpuidle governor can be changed at runtime in default,
|
||||
both current_governor and current_governor_ro co-exist under
|
||||
/sys/devices/system/cpu/cpuidle/ file, it's duplicate so make
|
||||
current_governor_ro obsolete.
|
||||
|
|
@ -0,0 +1,53 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/actual_profile
|
||||
Date: Januar 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 1-5.
|
||||
When read, this attribute returns the number of the actual
|
||||
profile which is also the profile that's active on device startup.
|
||||
When written this attribute activates the selected profile
|
||||
immediately.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/button
|
||||
Date: Januar 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The keyboard can store short macros with consist of 1 button with
|
||||
several modifier keys internally.
|
||||
When written, this file lets one set the sequence for a specific
|
||||
button for a specific profile. Button and profile numbers are
|
||||
included in written data. The data has to be 24 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/info
|
||||
Date: Januar 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns some info about the device like the
|
||||
installed firmware version.
|
||||
The size of the data is 8 bytes in size.
|
||||
This file is readonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/key_mask
|
||||
Date: Januar 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The keyboard lets the user deactivate 5 certain keys like the
|
||||
windows and application keys, to protect the user from the outcome
|
||||
of accidentally pressing them.
|
||||
The integer value of this attribute has bits 0-4 set depending
|
||||
on the state of the corresponding key.
|
||||
When read, this file returns the current state of the buttons.
|
||||
When written, the given buttons are activated/deactivated
|
||||
immediately.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/mode_key
|
||||
Date: Januar 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The keyboard has a condensed layout without num-lock key.
|
||||
Instead it uses a mode-key which activates a gaming mode where
|
||||
the assignment of the number block changes.
|
||||
The integer value of this attribute ranges from 0 (OFF) to 1 (ON).
|
||||
When read, this file returns the actual state of the key.
|
||||
When written, the key is activated/deactivated immediately.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
|
@ -0,0 +1,153 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/actual_profile
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 0-4.
|
||||
When read, this attribute returns the number of the actual
|
||||
profile. This value is persistent, so its equivalent to the
|
||||
profile that's active when the device is powered on next time.
|
||||
When written, this file sets the number of the startup profile
|
||||
and the device activates this profile immediately.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/info
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns general data like firmware version.
|
||||
The data is 6 bytes long.
|
||||
This file is readonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/key_mask
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one deactivate certain keys like
|
||||
windows and application keys, to prevent accidental presses.
|
||||
Profile number for which this settings occur is included in
|
||||
written data. The data has to be 6 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_capslock
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
capslock key for a specific profile. Profile number is included
|
||||
in written data. The data has to be 6 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_easyzone
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
easyzone keys for a specific profile. Profile number is included
|
||||
in written data. The data has to be 65 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_function
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
function keys for a specific profile. Profile number is included
|
||||
in written data. The data has to be 41 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_macro
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the macro
|
||||
keys for a specific profile. Profile number is included in
|
||||
written data. The data has to be 35 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_media
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the media
|
||||
keys for a specific profile. Profile number is included in
|
||||
written data. The data has to be 29 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_thumbster
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
thumbster keys for a specific profile. Profile number is included
|
||||
in written data. The data has to be 23 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/last_set
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the time in secs since
|
||||
epoch in which the last configuration took place.
|
||||
The data has to be 20 bytes long.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/light
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the backlight intensity for
|
||||
a specific profile. Profile number is included in written data.
|
||||
The data has to be 10 bytes long for Isku, IskuFX needs 16 bytes
|
||||
of data.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/macro
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one store macros with max 500
|
||||
keystrokes for a specific button for a specific profile.
|
||||
Button and profile numbers are included in written data.
|
||||
The data has to be 2083 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile and key to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/reset
|
||||
Date: November 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one reset the device.
|
||||
The data has to be 3 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/control
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one select which data from which
|
||||
profile will be read next. The data has to be 3 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/talk
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one trigger easyshift functionality
|
||||
from the host.
|
||||
The data has to be 16 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/talkfx
|
||||
Date: February 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one trigger temporary color schemes
|
||||
from the host.
|
||||
The data has to be 16 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
|
@ -0,0 +1,145 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 0-4.
|
||||
When read, this attribute returns the number of the actual
|
||||
profile. This value is persistent, so its equivalent to the
|
||||
profile that's active when the mouse is powered on next time.
|
||||
When written, this file sets the number of the startup profile
|
||||
and the mouse activates this profile immediately.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 0-4.
|
||||
When read, this attribute returns the number of the actual
|
||||
profile. This value is persistent, so its equivalent to the
|
||||
profile that's active when the mouse is powered on next time.
|
||||
When written, this file sets the number of the startup profile
|
||||
and the mouse activates this profile immediately.
|
||||
Please use actual_profile, it does the same thing.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the raw integer version number of the
|
||||
firmware reported by the mouse. Using the integer value eases
|
||||
further usage in other programs. To receive the real version
|
||||
number the decimal point has to be shifted 2 positions to the
|
||||
left. E.g. a returned value of 121 means 1.21
|
||||
This file is readonly.
|
||||
Please read binary attribute info which contains firmware version.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/info
|
||||
Date: November 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns general data like firmware version.
|
||||
When written, the device can be reset.
|
||||
The data is 8 bytes long.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/macro
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store a macro with max 500 key/button strokes
|
||||
internally.
|
||||
When written, this file lets one set the sequence for a specific
|
||||
button for a specific profile. Button and profile numbers are
|
||||
included in written data. The data has to be 2082 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_buttons
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_buttons holds information about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons back to the mouse. The data has to be 77 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_buttons
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_buttons holds information about button layout.
|
||||
When read, these files return the respective profile buttons.
|
||||
The returned data is 77 bytes in size.
|
||||
This file is readonly.
|
||||
Write control to select profile and read profile_buttons instead.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_settings
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When written, this file lets one write the respective profile
|
||||
settings back to the mouse. The data has to be 43 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_settings
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When read, these files return the respective profile settings.
|
||||
The returned data is 43 bytes in size.
|
||||
This file is readonly.
|
||||
Write control to select profile and read profile_settings instead.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/sensor
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse has a tracking- and a distance-control-unit. These
|
||||
can be activated/deactivated and the lift-off distance can be
|
||||
set. The data has to be 6 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/talk
|
||||
Date: May 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: Used to active some easy* functions of the mouse from outside.
|
||||
The data has to be 16 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written a calibration process for the tracking control unit
|
||||
can be initiated/cancelled. Also lets one read/write sensor
|
||||
registers.
|
||||
The data has to be 4 bytes long.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu_image
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read the mouse returns a 30x30 pixel image of the
|
||||
sampled underground. This works only in the course of a
|
||||
calibration process initiated with tcu.
|
||||
The returned data is 1028 bytes in size.
|
||||
This file is readonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
|
@ -0,0 +1,105 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/actual_profile
|
||||
Date: December 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. actual_profile holds number of actual profile.
|
||||
This value is persistent, so its value determines the profile
|
||||
that's active when the mouse is powered on next time.
|
||||
When written, the mouse activates the set profile immediately.
|
||||
The data has to be 3 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/control
|
||||
Date: December 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one select which data from which
|
||||
profile will be read next. The data has to be 3 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/info
|
||||
Date: December 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns general data like firmware version.
|
||||
When written, the device can be reset.
|
||||
The data is 6 bytes long.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/macro
|
||||
Date: December 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store a macro with max 500 key/button strokes
|
||||
internally.
|
||||
When written, this file lets one set the sequence for a specific
|
||||
button for a specific profile. Button and profile numbers are
|
||||
included in written data. The data has to be 2082 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/profile_buttons
|
||||
Date: December 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_buttons holds information about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons back to the mouse. The data has to be 59 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/profile_settings
|
||||
Date: December 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When written, this file lets one write the respective profile
|
||||
settings back to the mouse. The data has to be 31 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/sensor
|
||||
Date: December 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse has a tracking- and a distance-control-unit. These
|
||||
can be activated/deactivated and the lift-off distance can be
|
||||
set. The data has to be 6 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/talk
|
||||
Date: December 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: Used to active some easy* functions of the mouse from outside.
|
||||
The data has to be 16 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/tcu
|
||||
Date: December 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written a calibration process for the tracking control unit
|
||||
can be initiated/cancelled. Also lets one read/write sensor
|
||||
registers.
|
||||
The data has to be 4 bytes long.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/tcu_image
|
||||
Date: December 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read the mouse returns a 30x30 pixel image of the
|
||||
sampled underground. This works only in the course of a
|
||||
calibration process initiated with tcu.
|
||||
The returned data is 1028 bytes in size.
|
||||
This file is readonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
|
@ -0,0 +1,116 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_cpi
|
||||
Date: January 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 1-4.
|
||||
When read, this attribute returns the number of the active
|
||||
cpi level.
|
||||
This file is readonly.
|
||||
Has never been used. If bookkeeping is done, it's done in userland tools.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_profile
|
||||
Date: January 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 0-4.
|
||||
When read, this attribute returns the number of the active
|
||||
profile.
|
||||
When written, the mouse activates this profile immediately.
|
||||
The profile that's active when powered down is the same that's
|
||||
active when the mouse is powered on.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_x
|
||||
Date: January 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 1-10.
|
||||
When read, this attribute returns the number of the actual
|
||||
sensitivity in x direction.
|
||||
This file is readonly.
|
||||
Has never been used. If bookkeeping is done, it's done in userland tools.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_y
|
||||
Date: January 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 1-10.
|
||||
When read, this attribute returns the number of the actual
|
||||
sensitivity in y direction.
|
||||
This file is readonly.
|
||||
Has never been used. If bookkeeping is done, it's done in userland tools.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/firmware_version
|
||||
Date: January 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the raw integer version number of the
|
||||
firmware reported by the mouse. Using the integer value eases
|
||||
further usage in other programs. To receive the real version
|
||||
number the decimal point has to be shifted 2 positions to the
|
||||
left. E.g. a returned value of 121 means 1.21
|
||||
This file is readonly.
|
||||
Obsoleted by binary sysfs attribute "info".
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/info
|
||||
Date: November 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns general data like firmware version.
|
||||
When written, the device can be reset.
|
||||
The data is 6 bytes long.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_buttons
|
||||
Date: January 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_buttons holds information about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons back to the mouse. The data has to be 23 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_buttons
|
||||
Date: January 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_buttons holds information about button layout.
|
||||
When read, these files return the respective profile buttons.
|
||||
The returned data is 23 bytes in size.
|
||||
This file is readonly.
|
||||
Write control to select profile and read profile_buttons instead.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_settings
|
||||
Date: January 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When written, this file lets one write the respective profile
|
||||
settings back to the mouse. The data has to be 16 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_settings
|
||||
Date: January 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When read, these files return the respective profile settings.
|
||||
The returned data is 16 bytes in size.
|
||||
This file is readonly.
|
||||
Write control to select profile and read profile_settings instead.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/control
|
||||
Date: October 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, cpi, button and light settings can be configured.
|
||||
When read, actual cpi setting and sensor data are returned.
|
||||
The data has to be 8 bytes long.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
|
@ -0,0 +1,126 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_cpi
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: It is possible to switch the cpi setting of the mouse with the
|
||||
press of a button.
|
||||
When read, this file returns the raw number of the actual cpi
|
||||
setting reported by the mouse. This number has to be further
|
||||
processed to receive the real dpi value:
|
||||
|
||||
===== ====
|
||||
VALUE DPI
|
||||
===== ====
|
||||
1 400
|
||||
2 800
|
||||
4 1600
|
||||
===== ====
|
||||
|
||||
This file is readonly.
|
||||
Has never been used. If bookkeeping is done, it's done in userland tools.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_profile
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the number of the actual profile in
|
||||
range 0-4.
|
||||
This file is readonly.
|
||||
Please use binary attribute "settings" which provides this information.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/firmware_version
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the raw integer version number of the
|
||||
firmware reported by the mouse. Using the integer value eases
|
||||
further usage in other programs. To receive the real version
|
||||
number the decimal point has to be shifted 2 positions to the
|
||||
left. E.g. a returned value of 138 means 1.38
|
||||
This file is readonly.
|
||||
Please use binary attribute "info" which provides this information.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/info
|
||||
Date: November 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns general data like firmware version.
|
||||
When written, the device can be reset.
|
||||
The data is 6 bytes long.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_buttons
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_buttons holds information about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons back to the mouse. The data has to be 19 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_buttons
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_buttons holds information about button layout.
|
||||
When read, these files return the respective profile buttons.
|
||||
The returned data is 19 bytes in size.
|
||||
This file is readonly.
|
||||
Write control to select profile and read profile_buttons instead.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_settings
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When written, this file lets one write the respective profile
|
||||
settings back to the mouse. The data has to be 13 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_settings
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When read, these files return the respective profile settings.
|
||||
The returned data is 13 bytes in size.
|
||||
This file is readonly.
|
||||
Write control to select profile and read profile_settings instead.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/settings
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the settings stored in the mouse.
|
||||
The size of the data is 3 bytes and holds information on the
|
||||
startup_profile.
|
||||
When written, this file lets write settings back to the mouse.
|
||||
The data has to be 3 bytes long. The mouse will reject invalid
|
||||
data.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/startup_profile
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 0-4.
|
||||
When read, this attribute returns the number of the profile
|
||||
that's active when the mouse is powered on.
|
||||
This file is readonly.
|
||||
Please use binary attribute "settings" which provides this information.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
|
@ -0,0 +1,178 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/control
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one select which data from which
|
||||
profile will be read next. The data has to be 3 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/profile
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. profile holds index of actual profile.
|
||||
This value is persistent, so its value determines the profile
|
||||
that's active when the device is powered on next time.
|
||||
When written, the device activates the set profile immediately.
|
||||
The data has to be 3 bytes long.
|
||||
The device will reject invalid data.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_primary
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the default of all keys for
|
||||
a specific profile. Profile index is included in written data.
|
||||
The data has to be 125 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_function
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
function keys for a specific profile. Profile index is included
|
||||
in written data. The data has to be 95 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_macro
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the macro
|
||||
keys for a specific profile. Profile index is included in
|
||||
written data. The data has to be 35 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_thumbster
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
thumbster keys for a specific profile. Profile index is included
|
||||
in written data. The data has to be 23 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_extra
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
capslock and function keys for a specific profile. Profile index
|
||||
is included in written data. The data has to be 8 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_easyzone
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
easyzone keys for a specific profile. Profile index is included
|
||||
in written data. The data has to be 294 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/key_mask
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one deactivate certain keys like
|
||||
windows and application keys, to prevent accidental presses.
|
||||
Profile index for which this settings occur is included in
|
||||
written data. The data has to be 6 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/light
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the backlight intensity for
|
||||
a specific profile. Profile index is included in written data.
|
||||
This attribute is only valid for the glow and pro variant.
|
||||
The data has to be 16 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/macro
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one store macros with max 480
|
||||
keystrokes for a specific button for a specific profile.
|
||||
Button and profile indexes are included in written data.
|
||||
The data has to be 2002 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile and key to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/info
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns general data like firmware version.
|
||||
The data is 8 bytes long.
|
||||
This file is readonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/reset
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one reset the device.
|
||||
The data has to be 3 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/talk
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one trigger easyshift functionality
|
||||
from the host.
|
||||
The data has to be 16 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/light_control
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one switch between stored and custom
|
||||
light settings.
|
||||
This attribute is only valid for the pro variant.
|
||||
The data has to be 8 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/stored_lights
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set per-key lighting for different
|
||||
layers.
|
||||
This attribute is only valid for the pro variant.
|
||||
The data has to be 1382 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/custom_lights
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the actual per-key lighting.
|
||||
This attribute is only valid for the pro variant.
|
||||
The data has to be 20 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/light_macro
|
||||
Date: October 2013
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set a light macro that is looped
|
||||
whenever the device gets in dimness mode.
|
||||
This attribute is only valid for the pro variant.
|
||||
The data has to be 2002 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/buttons
|
||||
Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split into general settings and
|
||||
button settings. The buttons variable holds information about
|
||||
button layout. When written, this file lets one write the
|
||||
respective profile buttons to the mouse. The data has to be
|
||||
47 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/control
|
||||
Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one select which data from which
|
||||
profile will be read next. The data has to be 3 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/general
|
||||
Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split into general settings and
|
||||
button settings. A profile holds information like resolution,
|
||||
sensitivity and light effects.
|
||||
When written, this file lets one write the respective profile
|
||||
settings back to the mouse. The data has to be 43 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/info
|
||||
Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns general data like firmware version.
|
||||
When written, the device can be reset.
|
||||
The data is 8 bytes long.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/macro
|
||||
Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one store macros with max 500
|
||||
keystrokes for a specific button for a specific profile.
|
||||
Button and profile numbers are included in written data.
|
||||
The data has to be 2083 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile and key to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/profile
|
||||
Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. profile holds number of actual profile.
|
||||
This value is persistent, so its value determines the profile
|
||||
that's active when the mouse is powered on next time.
|
||||
When written, the mouse activates the set profile immediately.
|
||||
The data has to be 3 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/sensor
|
||||
Date: July 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse has a Avago ADNS-3090 sensor.
|
||||
This file allows reading and writing of the mouse sensors registers.
|
||||
The data has to be 4 bytes long.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
These files allow sending arbitrary IPC commands to the PMC/SCU which
|
||||
may be dangerous. These will be removed eventually and should not be
|
||||
used in any new applications.
|
||||
|
||||
What: /sys/bus/platform/devices/INT34D2:00/simplecmd
|
||||
Date: Jun 2015
|
||||
KernelVersion: 4.1
|
||||
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
|
||||
Description: This interface allows userspace to send an arbitrary
|
||||
IPC command to the PMC/SCU.
|
||||
|
||||
Format: %d %d where first number is command and
|
||||
second number is subcommand.
|
||||
|
||||
What: /sys/bus/platform/devices/INT34D2:00/northpeak
|
||||
Date: Jun 2015
|
||||
KernelVersion: 4.1
|
||||
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
|
||||
Description: This interface allows userspace to enable and disable
|
||||
Northpeak through the PMC/SCU.
|
||||
|
||||
Format: %u.
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
What: /sys/firmware/acpi/hotplug/force_remove
|
||||
Date: Mar 2017
|
||||
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
||||
Description:
|
||||
Since the force_remove is inherently broken and dangerous to
|
||||
use for some hotplugable resources like memory (because ignoring
|
||||
the offline failure might lead to memory corruption and crashes)
|
||||
enabling this knob is not safe and thus unsupported.
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
What: /sys/class/gpio/
|
||||
Date: July 2008
|
||||
KernelVersion: 2.6.27
|
||||
Contact: Linus Walleij <linusw@kernel.org>
|
||||
Description:
|
||||
|
||||
As a Kconfig option, individual GPIO signals may be accessed from
|
||||
userspace. GPIOs are only made available to userspace by an explicit
|
||||
"export" operation. If a given GPIO is not claimed for use by
|
||||
kernel code, it may be exported by userspace (and unexported later).
|
||||
Kernel code may export it for complete or partial access.
|
||||
|
||||
GPIOs are identified as they are inside the kernel, using integers in
|
||||
the range 0..INT_MAX. See Documentation/admin-guide/gpio for more information.
|
||||
|
||||
::
|
||||
|
||||
/sys/class/gpio
|
||||
/export ... asks the kernel to export a GPIO to userspace
|
||||
/unexport ... to return a GPIO to the kernel
|
||||
/gpioN ... for each exported GPIO #N OR
|
||||
/<LINE-NAME> ... for a properly named GPIO line
|
||||
/value ... always readable, writes fail for input GPIOs
|
||||
/direction ... r/w as: in, out (default low); write: high, low
|
||||
/edge ... r/w as: none, falling, rising, both
|
||||
/gpiochipN ... for each gpiochip; #N is its first GPIO
|
||||
/base ... (r/o) same as N
|
||||
/label ... (r/o) descriptive, not necessarily unique
|
||||
/ngpio ... (r/o) number of GPIOs; numbered N to N + (ngpio - 1)
|
||||
|
||||
This ABI is deprecated and will be removed after 2020. It is
|
||||
replaced with the GPIO character device.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
This ABI is renamed and moved to a new location /sys/kernel/fadump/enabled.
|
||||
|
||||
What: /sys/kernel/fadump_enabled
|
||||
Date: Feb 2012
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read only
|
||||
Primarily used to identify whether the FADump is enabled in
|
||||
the kernel or not.
|
||||
User: Kdump service
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
This ABI is renamed and moved to a new location /sys/kernel/fadump/registered.
|
||||
|
||||
What: /sys/kernel/fadump_registered
|
||||
Date: Feb 2012
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read/write
|
||||
Helps to control the dump collect feature from userspace.
|
||||
Setting 1 to this file enables the system to collect the
|
||||
dump and 0 to disable it.
|
||||
User: Kdump service
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
This ABI is renamed and moved to a new location /sys/kernel/fadump/release_mem.
|
||||
|
||||
What: /sys/kernel/fadump_release_mem
|
||||
Date: Feb 2012
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: write only
|
||||
This is a special sysfs file and only available when
|
||||
the system is booted to capture the vmcore using FADump.
|
||||
It is used to release the memory reserved by FADump to
|
||||
save the crash dump.
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
What: devfs
|
||||
Date: July 2005 (scheduled), finally removed in kernel v2.6.18
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
devfs has been unmaintained for a number of years, has unfixable
|
||||
races, contains a naming policy within the kernel that is
|
||||
against the LSB, and can be replaced by using udev.
|
||||
|
||||
The files fs/devfs/*, include/linux/devfs_fs*.h were removed,
|
||||
along with the assorted devfs function calls throughout the
|
||||
kernel tree.
|
||||
|
||||
Users:
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
What: dv1394 (a.k.a. "OHCI-DV I/O support" for FireWire)
|
||||
Date: May 2010 (scheduled), finally removed in kernel v2.6.37
|
||||
Contact: linux1394-devel@lists.sourceforge.net
|
||||
Description:
|
||||
/dev/dv1394/* were character device files, one for each FireWire
|
||||
controller and for NTSC and PAL respectively, from which DV data
|
||||
could be received by read() or transmitted by write(). A few
|
||||
ioctl()s allowed limited control.
|
||||
This special-purpose interface has been superseded by libraw1394 +
|
||||
libiec61883 which are functionally equivalent, support HDV, and
|
||||
transparently work on top of the newer firewire kernel drivers.
|
||||
|
||||
Users:
|
||||
ffmpeg/libavformat (if configured for DV1394)
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
What: ip_queue
|
||||
Date: finally removed in kernel v3.5.0
|
||||
Contact: Pablo Neira Ayuso <pablo@netfilter.org>
|
||||
Description:
|
||||
ip_queue has been replaced by nfnetlink_queue which provides
|
||||
more advanced queueing mechanism to user-space. The ip_queue
|
||||
module was already announced to become obsolete years ago.
|
||||
|
||||
Users:
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
What: tcp_dma_copybreak sysctl
|
||||
Date: Removed in kernel v3.13
|
||||
Contact: Dan Williams <dan.j.williams@intel.com>
|
||||
Description:
|
||||
Formerly the lower limit, in bytes, of the size of socket reads
|
||||
that will be offloaded to a DMA copy engine. Removed due to
|
||||
coherency issues of the cpu potentially touching the buffers
|
||||
while dma is in flight.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
What: /sys/o2cb symlink
|
||||
Date: May 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: ocfs2-devel@lists.linux.dev
|
||||
Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink is
|
||||
removed when new versions of ocfs2-tools which know to look
|
||||
in /sys/fs/o2cb are sufficiently prevalent. Don't code new
|
||||
software to look here, it should try /sys/fs/o2cb instead.
|
||||
Users: ocfs2-tools. It's sufficient to mail proposed changes to
|
||||
ocfs2-devel@lists.linux.dev.
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
What: raw1394 (a.k.a. "Raw IEEE1394 I/O support" for FireWire)
|
||||
Date: May 2010 (scheduled), finally removed in kernel v2.6.37
|
||||
Contact: linux1394-devel@lists.sourceforge.net
|
||||
Description:
|
||||
/dev/raw1394 was a character device file that allowed low-level
|
||||
access to FireWire buses. Its major drawbacks were its inability
|
||||
to implement sensible device security policies, and its low level
|
||||
of abstraction that required userspace clients to duplicate much
|
||||
of the kernel's ieee1394 core functionality.
|
||||
|
||||
Replaced by /dev/fw*, i.e. the <linux/firewire-cdev.h> ABI of
|
||||
firewire-core.
|
||||
|
||||
Users:
|
||||
libraw1394 (works with firewire-cdev too, transparent to library ABI
|
||||
users)
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
What: /sys/bus/nd/devices/regionX/nfit/ecc_unit_size
|
||||
Date: Aug, 2017
|
||||
KernelVersion: v4.14 (Removed v4.18)
|
||||
Contact: nvdimm@lists.linux.dev
|
||||
Description:
|
||||
(RO) Size of a write request to a DIMM that will not incur a
|
||||
read-modify-write cycle at the memory controller.
|
||||
|
||||
When the nfit driver initializes it runs an ARS (Address Range
|
||||
Scrub) operation across every pmem range. Part of that process
|
||||
involves determining the ARS capabilities of a given address
|
||||
range. One of the capabilities that is reported is the 'Clear
|
||||
Uncorrectable Error Range Length Unit Size' (see: ACPI 6.2
|
||||
section 9.20.7.4 Function Index 1 - Query ARS Capabilities).
|
||||
This property indicates the boundary at which the NVDIMM may
|
||||
need to perform read-modify-write cycles to maintain ECC (Error
|
||||
Correcting Code) blocks.
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
rfkill - radio frequency (RF) connector kill switch support
|
||||
|
||||
For details to this subsystem look at Documentation/driver-api/rfkill.rst.
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/claim
|
||||
Date: 09-Jul-2007
|
||||
KernelVersion v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: This file was deprecated because there no longer was a way to
|
||||
claim just control over a single rfkill instance.
|
||||
This file was scheduled to be removed in 2012, and was removed
|
||||
in 2016.
|
||||
Values: 0: Kernel handles events
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
This ABI is moved to /sys/firmware/opal/mpipl/release_core.
|
||||
|
||||
What: /sys/kernel/fadump_release_opalcore
|
||||
Date: Sep 2019
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: write only
|
||||
The sysfs file is available when the system is booted to
|
||||
collect the dump on OPAL based machine. It used to release
|
||||
the memory used to collect the opalcore.
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
What: /sys/kernel/uids/<uid>/cpu_shares
|
||||
Date: December 2007, finally removed in kernel v2.6.34-rc1
|
||||
Contact: Dhaval Giani <dhaval@linux.vnet.ibm.com>
|
||||
Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
|
||||
Description:
|
||||
The /sys/kernel/uids/<uid>/cpu_shares tunable is used
|
||||
to set the cpu bandwidth a user is allowed. This is a
|
||||
proportional value. What that means is that if there
|
||||
are two users logged in, each with an equal number of
|
||||
shares, then they will get equal CPU bandwidth. Another
|
||||
example would be, if User A has shares = 1024 and user
|
||||
B has shares = 2048, User B will get twice the CPU
|
||||
bandwidth user A will. For more details refer
|
||||
Documentation/scheduler/sched-design-CFS.rst
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
What: /sys/devices/system/machinecheck/machinecheckX/tolerant
|
||||
Contact: Borislav Petkov <bp@suse.de>
|
||||
Date: Dec, 2021
|
||||
Description:
|
||||
Unused and obsolete after the advent of recoverable machine
|
||||
checks (see last sentence below) and those are present since
|
||||
2010 (Nehalem).
|
||||
|
||||
Original description:
|
||||
|
||||
The entries appear for each CPU, but they are truly shared
|
||||
between all CPUs.
|
||||
|
||||
Tolerance level. When a machine check exception occurs for a
|
||||
non corrected machine check the kernel can take different
|
||||
actions.
|
||||
|
||||
Since machine check exceptions can happen any time it is
|
||||
sometimes risky for the kernel to kill a process because it
|
||||
defies normal kernel locking rules. The tolerance level
|
||||
configures how hard the kernel tries to recover even at some
|
||||
risk of deadlock. Higher tolerant values trade potentially
|
||||
better uptime with the risk of a crash or even corruption
|
||||
(for tolerant >= 3).
|
||||
|
||||
== ===========================================================
|
||||
0 always panic on uncorrected errors, log corrected errors
|
||||
1 panic or SIGBUS on uncorrected errors, log corrected errors
|
||||
2 SIGBUS or log uncorrected errors, log corrected errors
|
||||
3 never panic or SIGBUS, log all errors (for testing only)
|
||||
== ===========================================================
|
||||
|
||||
Default: 1
|
||||
|
||||
Note this only makes a difference if the CPU allows recovery
|
||||
from a machine check exception. Current x86 CPUs generally
|
||||
do not.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
What: /sys/fs/selinux/checkreqprot
|
||||
Date: April 2005 (predates git)
|
||||
KernelVersion: 2.6.12-rc2 (predates git)
|
||||
Contact: selinux@vger.kernel.org
|
||||
Description:
|
||||
|
||||
REMOVAL UPDATE: The SELinux checkreqprot functionality was removed in
|
||||
March 2023, the original deprecation notice is shown below.
|
||||
|
||||
The selinuxfs "checkreqprot" node allows SELinux to be configured
|
||||
to check the protection requested by userspace for mmap/mprotect
|
||||
calls instead of the actual protection applied by the kernel.
|
||||
This was a compatibility mechanism for legacy userspace and
|
||||
for the READ_IMPLIES_EXEC personality flag. However, if set to
|
||||
1, it weakens security by allowing mappings to be made executable
|
||||
without authorization by policy. The default value of checkreqprot
|
||||
at boot was changed starting in Linux v4.4 to 0 (i.e. check the
|
||||
actual protection), and Android and Linux distributions have been
|
||||
explicitly writing a "0" to /sys/fs/selinux/checkreqprot during
|
||||
initialization for some time. Support for setting checkreqprot to 1
|
||||
will be removed no sooner than June 2021, at which point the kernel
|
||||
will always cease using checkreqprot internally and will always
|
||||
check the actual protections being applied upon mmap/mprotect calls.
|
||||
The checkreqprot selinuxfs node will remain for backward compatibility
|
||||
but will discard writes of the "0" value and will reject writes of the
|
||||
"1" value when this mechanism is removed.
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
What: /sys/fs/selinux/disable
|
||||
Date: April 2005 (predates git)
|
||||
KernelVersion: 2.6.12-rc2 (predates git)
|
||||
Contact: selinux@vger.kernel.org
|
||||
Description:
|
||||
|
||||
REMOVAL UPDATE: The SELinux runtime disable functionality was removed
|
||||
in March 2023, the original deprecation notice is shown below.
|
||||
|
||||
The selinuxfs "disable" node allows SELinux to be disabled at runtime
|
||||
prior to a policy being loaded into the kernel. If disabled via this
|
||||
mechanism, SELinux will remain disabled until the system is rebooted.
|
||||
|
||||
The preferred method of disabling SELinux is via the "selinux=0" boot
|
||||
parameter, but the selinuxfs "disable" node was created to make it
|
||||
easier for systems with primitive bootloaders that did not allow for
|
||||
easy modification of the kernel command line. Unfortunately, allowing
|
||||
for SELinux to be disabled at runtime makes it difficult to secure the
|
||||
kernel's LSM hooks using the "__ro_after_init" feature.
|
||||
|
||||
Thankfully, the need for the SELinux runtime disable appears to be
|
||||
gone, the default Kconfig configuration disables this selinuxfs node,
|
||||
and only one of the major distributions, Fedora, supports disabling
|
||||
SELinux at runtime. Fedora is in the process of removing the
|
||||
selinuxfs "disable" node and once that is complete we will start the
|
||||
slow process of removing this code from the kernel.
|
||||
|
||||
More information on /sys/fs/selinux/disable can be found under the
|
||||
CONFIG_SECURITY_SELINUX_DISABLE Kconfig option.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
What: video1394 (a.k.a. "OHCI-1394 Video support" for FireWire)
|
||||
Date: May 2010 (scheduled), finally removed in kernel v2.6.37
|
||||
Contact: linux1394-devel@lists.sourceforge.net
|
||||
Description:
|
||||
/dev/video1394/* were character device files, one for each FireWire
|
||||
controller, which were used for isochronous I/O. It was added as an
|
||||
alternative to raw1394's isochronous I/O functionality which had
|
||||
performance issues in its first generation. Any video1394 user had
|
||||
to use raw1394 + libraw1394 too because video1394 did not provide
|
||||
asynchronous I/O for device discovery and configuration.
|
||||
|
||||
Replaced by /dev/fw*, i.e. the <linux/firewire-cdev.h> ABI of
|
||||
firewire-core.
|
||||
|
||||
Users:
|
||||
libdc1394 (works with firewire-cdev too, transparent to library ABI
|
||||
users)
|
||||
|
|
@ -0,0 +1,111 @@
|
|||
What: /dev/fw[0-9]+
|
||||
Date: May 2007
|
||||
KernelVersion: 2.6.22
|
||||
Contact: linux1394-devel@lists.sourceforge.net
|
||||
Description:
|
||||
The character device files /dev/fw* are the interface between
|
||||
firewire-core and IEEE 1394 device drivers implemented in
|
||||
userspace. The ioctl(2)- and read(2)-based ABI is defined and
|
||||
documented in <linux/firewire-cdev.h>.
|
||||
|
||||
This ABI offers most of the features which firewire-core also
|
||||
exposes to kernelspace IEEE 1394 drivers.
|
||||
|
||||
Each /dev/fw* is associated with one IEEE 1394 node, which can
|
||||
be remote or local nodes. Operations on a /dev/fw* file have
|
||||
different scope:
|
||||
|
||||
- The 1394 node which is associated with the file:
|
||||
|
||||
- Asynchronous request transmission
|
||||
- Get the Configuration ROM
|
||||
- Query node ID
|
||||
- Query maximum speed of the path between this node
|
||||
and local node
|
||||
|
||||
- The 1394 bus (i.e. "card") to which the node is attached to:
|
||||
|
||||
- Isochronous stream transmission and reception
|
||||
- Asynchronous stream transmission and reception
|
||||
- Asynchronous broadcast request transmission
|
||||
- PHY packet transmission and reception
|
||||
- Allocate, reallocate, deallocate isochronous
|
||||
resources (channels, bandwidth) at the bus's IRM
|
||||
- Query node IDs of local node, root node, IRM, bus
|
||||
manager
|
||||
- Query cycle time
|
||||
- Bus reset initiation, bus reset event reception
|
||||
|
||||
- All 1394 buses:
|
||||
|
||||
- Allocation of IEEE 1212 address ranges on the local
|
||||
link layers, reception of inbound requests to such
|
||||
an address range, asynchronous response transmission
|
||||
to inbound requests
|
||||
- Addition of descriptors or directories to the local
|
||||
nodes' Configuration ROM
|
||||
|
||||
Due to the different scope of operations and in order to let
|
||||
userland implement different access permission models, some
|
||||
operations are restricted to /dev/fw* files that are associated
|
||||
with a local node:
|
||||
|
||||
- Addition of descriptors or directories to the local
|
||||
nodes' Configuration ROM
|
||||
- PHY packet transmission and reception
|
||||
|
||||
A /dev/fw* file remains associated with one particular node
|
||||
during its entire life time. Bus topology changes, and hence
|
||||
node ID changes, are tracked by firewire-core. ABI users do not
|
||||
need to be aware of topology.
|
||||
|
||||
The following file operations are supported:
|
||||
|
||||
open(2)
|
||||
Currently the only useful flags are O_RDWR.
|
||||
|
||||
ioctl(2)
|
||||
Initiate various actions. Some take immediate effect, others
|
||||
are performed asynchronously while or after the ioctl returns.
|
||||
See the inline documentation in <linux/firewire-cdev.h> for
|
||||
descriptions of all ioctls.
|
||||
|
||||
poll(2), select(2), epoll_wait(2) etc.
|
||||
Watch for events to become available to be read.
|
||||
|
||||
read(2)
|
||||
Receive various events. There are solicited events like
|
||||
outbound asynchronous transaction completion or isochronous
|
||||
buffer completion, and unsolicited events such as bus resets,
|
||||
request reception, or PHY packet reception. Always use a read
|
||||
buffer which is large enough to receive the largest event that
|
||||
could ever arrive. See <linux/firewire-cdev.h> for descriptions
|
||||
of all event types and for which ioctls affect reception of
|
||||
events.
|
||||
|
||||
mmap(2)
|
||||
Allocate a DMA buffer for isochronous reception or transmission
|
||||
and map it into the process address space. The arguments should
|
||||
be used as follows: addr = NULL, length = the desired buffer
|
||||
size, i.e. number of packets times size of largest packet,
|
||||
prot = at least PROT_READ for reception and at least PROT_WRITE
|
||||
for transmission, flags = MAP_SHARED, fd = the handle to the
|
||||
/dev/fw*, offset = 0.
|
||||
|
||||
Isochronous reception works in packet-per-buffer fashion except
|
||||
for multichannel reception which works in buffer-fill mode.
|
||||
|
||||
munmap(2)
|
||||
Unmap the isochronous I/O buffer from the process address space.
|
||||
|
||||
close(2)
|
||||
Besides stopping and freeing I/O contexts that were associated
|
||||
with the file descriptor, back out any changes to the local
|
||||
nodes' Configuration ROM. Deallocate isochronous channels and
|
||||
bandwidth at the IRM that were marked for kernel-assisted
|
||||
re- and deallocation.
|
||||
|
||||
Users: libraw1394;
|
||||
libdc1394;
|
||||
libhinawa;
|
||||
tools like linux-firewire-utils, fwhack, ...
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
What: /sys/fs/o2cb/
|
||||
Date: Dec 2005
|
||||
KernelVersion: 2.6.16
|
||||
Contact: ocfs2-devel@lists.linux.dev
|
||||
Description: Ocfs2-tools looks at 'interface-revision' for versioning
|
||||
information. Each logmask/ file controls a set of debug prints
|
||||
and can be written into with the strings "allow", "deny", or
|
||||
"off". Reading the file returns the current state.
|
||||
Users: ocfs2-tools. It's sufficient to mail proposed changes to
|
||||
ocfs2-devel@lists.linux.dev.
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
What: Audit Login UID
|
||||
Date: 2005-02-01
|
||||
KernelVersion: 2.6.11-rc2 1e2d1492e178 ("[PATCH] audit: handle loginuid through proc")
|
||||
Contact: linux-audit@redhat.com
|
||||
Users: audit and login applications
|
||||
Description:
|
||||
The /proc/$pid/loginuid pseudofile is written to set and
|
||||
read to get the audit login UID of process $pid as a
|
||||
decimal unsigned int (%u, u32). If it is unset,
|
||||
permissions are not needed to set it. The accessor must
|
||||
have CAP_AUDIT_CONTROL in the initial user namespace to
|
||||
write it if it has been set. It cannot be written again
|
||||
if AUDIT_FEATURE_LOGINUID_IMMUTABLE is enabled. It
|
||||
cannot be unset if AUDIT_FEATURE_ONLY_UNSET_LOGINUID is
|
||||
enabled.
|
||||
|
||||
What: Audit Login Session ID
|
||||
Date: 2008-03-13
|
||||
KernelVersion: 2.6.25-rc7 1e0bd7550ea9 ("[PATCH] export sessionid alongside the loginuid in procfs")
|
||||
Contact: linux-audit@redhat.com
|
||||
Users: audit and login applications
|
||||
Description:
|
||||
The /proc/$pid/sessionid pseudofile is read to get the
|
||||
audit login session ID of process $pid as a decimal
|
||||
unsigned int (%u, u32). It is set automatically,
|
||||
serially assigned with each new login.
|
||||
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
What: The kernel syscall interface
|
||||
Description:
|
||||
This interface matches much of the POSIX interface and is based
|
||||
on it and other Unix based interfaces. It will only be added to
|
||||
over time, and not have things removed from it.
|
||||
|
||||
Note that this interface is different for every architecture
|
||||
that Linux supports. Please see the architecture-specific
|
||||
documentation for details on the syscall numbers that are to be
|
||||
mapped to each syscall.
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
What: /sys/firmware/acpi/pm_profile
|
||||
Date: 03-Nov-2011
|
||||
KernelVersion: v3.2
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description: The ACPI pm_profile sysfs interface exposes the preferred
|
||||
power management (and performance) profile of the platform
|
||||
as provided in the ACPI FADT Preferred_PM_Profile field.
|
||||
|
||||
The integer value is directly passed as retrieved from the FADT.
|
||||
|
||||
Values: For the possible values refer to the Preferred_PM_Profile field
|
||||
definition in Table 5.9 "FADT Format", Section 5.2.9 "Fixed ACPI
|
||||
Description Table (FADT)" of the ACPI specification.
|
||||
|
||||
As of ACPI 6.5, the following values are defined:
|
||||
|
||||
== =================
|
||||
0 Unspecified
|
||||
1 Desktop
|
||||
2 Mobile
|
||||
3 Workstation
|
||||
4 Enterprise Server
|
||||
5 SOHO Server
|
||||
6 Appliance PC
|
||||
7 Performance Server
|
||||
8 Tablet
|
||||
>8 Reserved
|
||||
== =================
|
||||
|
|
@ -0,0 +1,737 @@
|
|||
What: /sys/block/<disk>/alignment_offset
|
||||
Date: April 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Storage devices may report a physical block size that is
|
||||
bigger than the logical block size (for instance a drive
|
||||
with 4KB physical sectors exposing 512-byte logical
|
||||
blocks to the operating system). This parameter
|
||||
indicates how many bytes the beginning of the device is
|
||||
offset from the disk's natural alignment.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/discard_alignment
|
||||
Date: May 2011
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Devices that support discard functionality may
|
||||
internally allocate space in units that are bigger than
|
||||
the exported logical block size. The discard_alignment
|
||||
parameter indicates how many bytes the beginning of the
|
||||
device is offset from the internal allocation unit's
|
||||
natural alignment.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/diskseq
|
||||
Date: February 2021
|
||||
Contact: Matteo Croce <mcroce@microsoft.com>
|
||||
Description:
|
||||
The /sys/block/<disk>/diskseq files reports the disk
|
||||
sequence number, which is a monotonically increasing
|
||||
number assigned to every drive.
|
||||
Some devices, like the loop device, refresh such number
|
||||
every time the backing file is changed.
|
||||
The value type is 64 bit unsigned.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/inflight
|
||||
Date: October 2009
|
||||
Contact: Jens Axboe <axboe@kernel.dk>, Nikanth Karthikesan <knikanth@suse.de>
|
||||
Description:
|
||||
Reports the number of I/O requests currently in progress
|
||||
(pending / in flight) in a device driver. This can be less
|
||||
than the number of requests queued in the block device queue.
|
||||
The report contains 2 fields: one for read requests
|
||||
and one for write requests.
|
||||
The value type is unsigned int.
|
||||
Cf. Documentation/block/stat.rst which contains a single value for
|
||||
requests in flight.
|
||||
This is related to /sys/block/<disk>/queue/nr_requests
|
||||
and for SCSI device also its queue_depth.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/integrity/device_is_integrity_capable
|
||||
Date: July 2014
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Indicates whether a storage device is capable of storing
|
||||
integrity metadata. Set if the device is T10 PI-capable.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/integrity/format
|
||||
Date: June 2008
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Metadata format for integrity capable block device.
|
||||
E.g. T10-DIF-TYPE1-CRC.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/integrity/protection_interval_bytes
|
||||
Date: July 2015
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Describes the number of data bytes which are protected
|
||||
by one integrity tuple. Typically the device's logical
|
||||
block size.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/integrity/read_verify
|
||||
Date: June 2008
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Indicates whether the block layer should verify the
|
||||
integrity of read requests serviced by devices that
|
||||
support sending integrity metadata.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/integrity/tag_size
|
||||
Date: June 2008
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Number of bytes of integrity tag space available per
|
||||
512 bytes of data.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/integrity/write_generate
|
||||
Date: June 2008
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Indicates whether the block layer should automatically
|
||||
generate checksums for write requests bound for
|
||||
devices that support receiving integrity metadata.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/<partition>/alignment_offset
|
||||
Date: April 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Storage devices may report a physical block size that is
|
||||
bigger than the logical block size (for instance a drive
|
||||
with 4KB physical sectors exposing 512-byte logical
|
||||
blocks to the operating system). This parameter
|
||||
indicates how many bytes the beginning of the partition
|
||||
is offset from the disk's natural alignment.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/<partition>/discard_alignment
|
||||
Date: May 2011
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Devices that support discard functionality may
|
||||
internally allocate space in units that are bigger than
|
||||
the exported logical block size. The discard_alignment
|
||||
parameter indicates how many bytes the beginning of the
|
||||
partition is offset from the internal allocation unit's
|
||||
natural alignment.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/<partition>/stat
|
||||
Date: February 2008
|
||||
Contact: Jerome Marchand <jmarchan@redhat.com>
|
||||
Description:
|
||||
The /sys/block/<disk>/<partition>/stat files display the
|
||||
I/O statistics of partition <partition>. The format is the
|
||||
same as the format of /sys/block/<disk>/stat.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/add_random
|
||||
Date: June 2010
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] This file allows to turn off the disk entropy contribution.
|
||||
Default value of this file is '1'(on).
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/chunk_sectors
|
||||
Date: September 2016
|
||||
Contact: Hannes Reinecke <hare@suse.com>
|
||||
Description:
|
||||
[RO] chunk_sectors has different meaning depending on the type
|
||||
of the disk. For a RAID device (dm-raid), chunk_sectors
|
||||
indicates the size in 512B sectors of the RAID volume stripe
|
||||
segment. For a zoned block device, either host-aware or
|
||||
host-managed, chunk_sectors indicates the size in 512B sectors
|
||||
of the zones of the device, with the eventual exception of the
|
||||
last zone of the device which may be smaller.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/crypto/
|
||||
Date: February 2022
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
The presence of this subdirectory of /sys/block/<disk>/queue/
|
||||
indicates that the device supports inline encryption. This
|
||||
subdirectory contains files which describe the inline encryption
|
||||
capabilities of the device. For more information about inline
|
||||
encryption, refer to Documentation/block/inline-encryption.rst.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/crypto/max_dun_bits
|
||||
Date: February 2022
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] This file shows the maximum length, in bits, of data unit
|
||||
numbers accepted by the device in inline encryption requests.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/crypto/modes/<mode>
|
||||
Date: February 2022
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] For each crypto mode (i.e., encryption/decryption
|
||||
algorithm) the device supports with inline encryption, a file
|
||||
will exist at this location. It will contain a hexadecimal
|
||||
number that is a bitmask of the supported data unit sizes, in
|
||||
bytes, for that crypto mode.
|
||||
|
||||
Currently, the crypto modes that may be supported are:
|
||||
|
||||
* AES-256-XTS
|
||||
* AES-128-CBC-ESSIV
|
||||
* Adiantum
|
||||
|
||||
For example, if a device supports AES-256-XTS inline encryption
|
||||
with data unit sizes of 512 and 4096 bytes, the file
|
||||
/sys/block/<disk>/queue/crypto/modes/AES-256-XTS will exist and
|
||||
will contain "0x1200".
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/crypto/num_keyslots
|
||||
Date: February 2022
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] This file shows the number of keyslots the device has for
|
||||
use with inline encryption.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/dax
|
||||
Date: June 2016
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] This file indicates whether the device supports Direct
|
||||
Access (DAX), used by CPU-addressable storage to bypass the
|
||||
pagecache. It shows '1' if true, '0' if not.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/discard_granularity
|
||||
Date: May 2011
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
[RO] Devices that support discard functionality may internally
|
||||
allocate space using units that are bigger than the logical
|
||||
block size. The discard_granularity parameter indicates the size
|
||||
of the internal allocation unit in bytes if reported by the
|
||||
device. Otherwise the discard_granularity will be set to match
|
||||
the device's physical block size. A discard_granularity of 0
|
||||
means that the device does not support discard functionality.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/discard_max_bytes
|
||||
Date: May 2011
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
[RW] While discard_max_hw_bytes is the hardware limit for the
|
||||
device, this setting is the software limit. Some devices exhibit
|
||||
large latencies when large discards are issued, setting this
|
||||
value lower will make Linux issue smaller discards and
|
||||
potentially help reduce latencies induced by large discard
|
||||
operations.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/discard_max_hw_bytes
|
||||
Date: July 2015
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] Devices that support discard functionality may have
|
||||
internal limits on the number of bytes that can be trimmed or
|
||||
unmapped in a single operation. The `discard_max_hw_bytes`
|
||||
parameter is set by the device driver to the maximum number of
|
||||
bytes that can be discarded in a single operation. Discard
|
||||
requests issued to the device must not exceed this limit. A
|
||||
`discard_max_hw_bytes` value of 0 means that the device does not
|
||||
support discard functionality.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/discard_zeroes_data
|
||||
Date: May 2011
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
[RO] Will always return 0. Don't rely on any specific behavior
|
||||
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
|
||||
Description:
|
||||
[RO] Whether or not the block driver supports the FUA flag for
|
||||
write requests. FUA stands for Force Unit Access. If the FUA
|
||||
flag is set that means that write requests must bypass the
|
||||
volatile cache of the storage device.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/hw_sector_size
|
||||
Date: January 2008
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] This is the hardware sector size of the device, in bytes.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/independent_access_ranges/
|
||||
Date: October 2021
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] The presence of this sub-directory of the
|
||||
/sys/block/xxx/queue/ directory indicates that the device is
|
||||
capable of executing requests targeting different sector ranges
|
||||
in parallel. For instance, single LUN multi-actuator hard-disks
|
||||
will have an independent_access_ranges directory if the device
|
||||
correctly advertises the sector ranges of its actuators.
|
||||
|
||||
The independent_access_ranges directory contains one directory
|
||||
per access range, with each range described using the sector
|
||||
(RO) attribute file to indicate the first sector of the range
|
||||
and the nr_sectors (RO) attribute file to indicate the total
|
||||
number of sectors in the range starting from the first sector of
|
||||
the range. For example, a dual-actuator hard-disk will have the
|
||||
following independent_access_ranges entries.::
|
||||
|
||||
$ tree /sys/block/<disk>/queue/independent_access_ranges/
|
||||
/sys/block/<disk>/queue/independent_access_ranges/
|
||||
|-- 0
|
||||
| |-- nr_sectors
|
||||
| `-- sector
|
||||
`-- 1
|
||||
|-- nr_sectors
|
||||
`-- sector
|
||||
|
||||
The sector and nr_sectors attributes use 512B sector unit,
|
||||
regardless of the actual block size of the device. Independent
|
||||
access ranges do not overlap and include all sectors within the
|
||||
device capacity. The access ranges are numbered in increasing
|
||||
order of the range start sector, that is, the sector attribute
|
||||
of range 0 always has the value 0.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/io_poll
|
||||
Date: November 2015
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] When read, this file shows whether polling is enabled (1)
|
||||
or disabled (0). Writing '0' to this file will disable polling
|
||||
for this device. Writing any non-zero value will enable this
|
||||
feature.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/io_poll_delay
|
||||
Date: November 2016
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] This was used to control what kind of polling will be
|
||||
performed. It is now fixed to -1, which is classic polling.
|
||||
In this mode, the CPU will repeatedly ask for completions
|
||||
without giving up any time.
|
||||
<deprecated>
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/io_timeout
|
||||
Date: November 2018
|
||||
Contact: Weiping Zhang <zhangweiping@didiglobal.com>
|
||||
Description:
|
||||
[RW] io_timeout is the request timeout in milliseconds. If a
|
||||
request does not complete in this time then the block driver
|
||||
timeout handler is invoked. That timeout handler can decide to
|
||||
retry the request, to fail it or to start a device recovery
|
||||
strategy.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/iostats
|
||||
Date: January 2009
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] This file is used to control (on/off) the iostats
|
||||
accounting of the disk.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/logical_block_size
|
||||
Date: May 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
[RO] This is the smallest unit the storage device can address.
|
||||
It is typically 512 bytes.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/max_active_zones
|
||||
Date: July 2020
|
||||
Contact: Niklas Cassel <niklas.cassel@wdc.com>
|
||||
Description:
|
||||
[RO] For zoned block devices (zoned attribute indicating
|
||||
"host-managed" or "host-aware"), the sum of zones belonging to
|
||||
any of the zone states: EXPLICIT OPEN, IMPLICIT OPEN or CLOSED,
|
||||
is limited by this value. If this value is 0, there is no limit.
|
||||
|
||||
If the host attempts to exceed this limit, the driver should
|
||||
report this error with BLK_STS_ZONE_ACTIVE_RESOURCE, which user
|
||||
space may see as the EOVERFLOW errno.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/max_discard_segments
|
||||
Date: February 2017
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] The maximum number of DMA scatter/gather entries in a
|
||||
discard request.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/max_hw_sectors_kb
|
||||
Date: September 2004
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] This is the maximum number of kilobytes supported in a
|
||||
single data transfer.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/max_integrity_segments
|
||||
Date: September 2010
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] Maximum number of elements in a DMA scatter/gather list
|
||||
with integrity data that will be submitted by the block layer
|
||||
core to the associated block driver.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/max_open_zones
|
||||
Date: July 2020
|
||||
Contact: Niklas Cassel <niklas.cassel@wdc.com>
|
||||
Description:
|
||||
[RO] For zoned block devices (zoned attribute indicating
|
||||
"host-managed" or "host-aware"), the sum of zones belonging to
|
||||
any of the zone states: EXPLICIT OPEN or IMPLICIT OPEN, is
|
||||
limited by this value. If this value is 0, there is no limit.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/max_sectors_kb
|
||||
Date: September 2004
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] This is the maximum number of kilobytes that the block
|
||||
layer will allow for a filesystem request. Must be smaller than
|
||||
or equal to the maximum size allowed by the hardware. Write 0
|
||||
to use default kernel settings.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/max_segment_size
|
||||
Date: March 2010
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] Maximum size in bytes of a single element in a DMA
|
||||
scatter/gather list.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/max_segments
|
||||
Date: March 2010
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] Maximum number of elements in a DMA scatter/gather list
|
||||
that is submitted to the associated block driver.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/minimum_io_size
|
||||
Date: April 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
[RO] Storage devices may report a granularity or preferred
|
||||
minimum I/O size which is the smallest request the device can
|
||||
perform without incurring a performance penalty. For disk
|
||||
drives this is often the physical block size. For RAID arrays
|
||||
it is often the stripe chunk size. A properly aligned multiple
|
||||
of minimum_io_size is the preferred request size for workloads
|
||||
where a high number of I/O operations is desired.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/nomerges
|
||||
Date: January 2010
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] Standard I/O elevator operations include attempts to merge
|
||||
contiguous I/Os. For known random I/O loads these attempts will
|
||||
always fail and result in extra cycles being spent in the
|
||||
kernel. This allows one to turn off this behavior on one of two
|
||||
ways: When set to 1, complex merge checks are disabled, but the
|
||||
simple one-shot merges with the previous I/O request are
|
||||
enabled. When set to 2, all merge tries are disabled. The
|
||||
default value is 0 - which enables all types of merge tries.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/nr_requests
|
||||
Date: July 2003
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] This controls how many requests may be allocated in the
|
||||
block layer for read or write requests. Note that the total
|
||||
allocated number may be twice this amount, since it applies only
|
||||
to reads or writes (not the accumulated sum).
|
||||
|
||||
To avoid priority inversion through request starvation, a
|
||||
request queue maintains a separate request pool per each cgroup
|
||||
when CONFIG_BLK_CGROUP is enabled, and this parameter applies to
|
||||
each such per-block-cgroup request pool. IOW, if there are N
|
||||
block cgroups, each request queue may have up to N request
|
||||
pools, each independently regulated by nr_requests.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/nr_zones
|
||||
Date: November 2018
|
||||
Contact: Damien Le Moal <damien.lemoal@wdc.com>
|
||||
Description:
|
||||
[RO] nr_zones indicates the total number of zones of a zoned
|
||||
block device ("host-aware" or "host-managed" zone model). For
|
||||
regular block devices, the value is always 0.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/optimal_io_size
|
||||
Date: April 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
[RO] Storage devices may report an optimal I/O size, which is
|
||||
the device's preferred unit for sustained I/O. This is rarely
|
||||
reported for disk drives. For RAID arrays it is usually the
|
||||
stripe width or the internal track size. A properly aligned
|
||||
multiple of optimal_io_size is the preferred request size for
|
||||
workloads where sustained throughput is desired. If no optimal
|
||||
I/O size is reported this file contains 0.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/physical_block_size
|
||||
Date: May 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
[RO] This is the smallest unit a physical storage device can
|
||||
write atomically. It is usually the same as the logical block
|
||||
size but may be bigger. One example is SATA drives with 4KB
|
||||
sectors that expose a 512-byte logical block size to the
|
||||
operating system. For stacked block devices the
|
||||
physical_block_size variable contains the maximum
|
||||
physical_block_size of the component devices.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/read_ahead_kb
|
||||
Date: May 2004
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] Maximum number of kilobytes to read-ahead for filesystems
|
||||
on this block device.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/rotational
|
||||
Date: January 2009
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] This file is used to stat if the device is of rotational
|
||||
type or non-rotational type.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/rq_affinity
|
||||
Date: September 2008
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] If this option is '1', the block layer will migrate request
|
||||
completions to the cpu "group" that originally submitted the
|
||||
request. For some workloads this provides a significant
|
||||
reduction in CPU cycles due to caching effects.
|
||||
|
||||
For storage configurations that need to maximize distribution of
|
||||
completion processing setting this option to '2' forces the
|
||||
completion to run on the requesting cpu (bypassing the "group"
|
||||
aggregation logic).
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/scheduler
|
||||
Date: October 2004
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] When read, this file will display the current and available
|
||||
IO schedulers for this block device. The currently active IO
|
||||
scheduler will be enclosed in [] brackets. Writing an IO
|
||||
scheduler name to this file will switch control of this block
|
||||
device to that new IO scheduler. Note that writing an IO
|
||||
scheduler name to this file will attempt to load that IO
|
||||
scheduler module, if it isn't already present in the system.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/stable_writes
|
||||
Date: September 2020
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] This file will contain '1' if memory must not be modified
|
||||
while it is being used in a write request to this device. When
|
||||
this is the case and the kernel is performing writeback of a
|
||||
page, the kernel will wait for writeback to complete before
|
||||
allowing the page to be modified again, rather than allowing
|
||||
immediate modification as is normally the case. This
|
||||
restriction arises when the device accesses the memory multiple
|
||||
times where the same data must be seen every time -- for
|
||||
example, once to calculate a checksum and once to actually write
|
||||
the data. If no such restriction exists, this file will contain
|
||||
'0'. This file is writable for testing purposes.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/throttle_sample_time
|
||||
Date: March 2017
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] This is the time window that blk-throttle samples data, in
|
||||
millisecond. blk-throttle makes decision based on the
|
||||
samplings. Lower time means cgroups have more smooth throughput,
|
||||
but higher CPU overhead. This exists only when
|
||||
CONFIG_BLK_DEV_THROTTLING_LOW is enabled.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/virt_boundary_mask
|
||||
Date: April 2021
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] This file shows the I/O segment memory alignment mask for
|
||||
the block device. I/O requests to this device will be split
|
||||
between segments wherever either the memory address of the end
|
||||
of the previous segment or the memory address of the beginning
|
||||
of the current segment is not aligned to virt_boundary_mask + 1
|
||||
bytes.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/wbt_lat_usec
|
||||
Date: November 2016
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] If the device is registered for writeback throttling, then
|
||||
this file shows the target minimum read latency. If this latency
|
||||
is exceeded in a given window of time (see wb_window_usec), then
|
||||
the writeback throttling will start scaling back writes. Writing
|
||||
a value of '0' to this file disables the feature. Writing a
|
||||
value of '-1' to this file resets the value to the default
|
||||
setting.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/write_cache
|
||||
Date: April 2016
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] When read, this file will display whether the device has
|
||||
write back caching enabled or not. It will return "write back"
|
||||
for the former case, and "write through" for the latter. Writing
|
||||
to this file can change the kernels view of the device, but it
|
||||
doesn't alter the device state. This means that it might not be
|
||||
safe to toggle the setting from "write back" to "write through",
|
||||
since that will also eliminate cache flushes issued by the
|
||||
kernel.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/write_same_max_bytes
|
||||
Date: January 2012
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
[RO] Some devices support a write same operation in which a
|
||||
single data block can be written to a range of several
|
||||
contiguous blocks on storage. This can be used to wipe areas on
|
||||
disk or to initialize drives in a RAID configuration.
|
||||
write_same_max_bytes indicates how many bytes can be written in
|
||||
a single write same command. If write_same_max_bytes is 0, write
|
||||
same is not supported by the device.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/write_zeroes_max_bytes
|
||||
Date: November 2016
|
||||
Contact: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
|
||||
Description:
|
||||
[RO] Devices that support write zeroes operation in which a
|
||||
single request can be issued to zero out the range of contiguous
|
||||
blocks on storage without having any payload in the request.
|
||||
This can be used to optimize writing zeroes to the devices.
|
||||
write_zeroes_max_bytes indicates how many bytes can be written
|
||||
in a single write zeroes command. If write_zeroes_max_bytes is
|
||||
0, write zeroes is not supported by the device.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/zone_append_max_bytes
|
||||
Date: May 2020
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] This is the maximum number of bytes that can be written to
|
||||
a sequential zone of a zoned block device using a zone append
|
||||
write operation (REQ_OP_ZONE_APPEND). This value is always 0 for
|
||||
regular block devices.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/zone_write_granularity
|
||||
Date: January 2021
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] This indicates the alignment constraint, in bytes, for
|
||||
write operations in sequential zones of zoned block devices
|
||||
(devices with a zoned attributed that reports "host-managed" or
|
||||
"host-aware"). This value is always 0 for regular block devices.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/zoned
|
||||
Date: September 2016
|
||||
Contact: Damien Le Moal <damien.lemoal@wdc.com>
|
||||
Description:
|
||||
[RO] zoned indicates if the device is a zoned block device and
|
||||
the zone model of the device if it is indeed zoned. The
|
||||
possible values indicated by zoned are "none" for regular block
|
||||
devices and "host-aware" or "host-managed" for zoned block
|
||||
devices. The characteristics of host-aware and host-managed
|
||||
zoned block devices are described in the ZBC (Zoned Block
|
||||
Commands) and ZAC (Zoned Device ATA Command Set) standards.
|
||||
These standards also define the "drive-managed" zone model.
|
||||
However, since drive-managed zoned block devices do not support
|
||||
zone commands, they will be treated as regular block devices and
|
||||
zoned will report "none".
|
||||
|
||||
|
||||
What: /sys/block/<disk>/hidden
|
||||
Date: March 2023
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RO] the block device is hidden. it doesn’t produce events, and
|
||||
can’t be opened from userspace or using blkdev_get*.
|
||||
Used for the underlying components of multipath devices.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/stat
|
||||
Date: February 2008
|
||||
Contact: Jerome Marchand <jmarchan@redhat.com>
|
||||
Description:
|
||||
The /sys/block/<disk>/stat files displays the I/O
|
||||
statistics of disk <disk>. They contain 11 fields:
|
||||
|
||||
== ==============================================
|
||||
1 reads completed successfully
|
||||
2 reads merged
|
||||
3 sectors read
|
||||
4 time spent reading (ms)
|
||||
5 writes completed
|
||||
6 writes merged
|
||||
7 sectors written
|
||||
8 time spent writing (ms)
|
||||
9 I/Os currently in progress
|
||||
10 time spent doing I/Os (ms)
|
||||
11 weighted time spent doing I/Os (ms)
|
||||
12 discards completed
|
||||
13 discards merged
|
||||
14 sectors discarded
|
||||
15 time spent discarding (ms)
|
||||
16 flush requests completed
|
||||
17 time spent flushing (ms)
|
||||
== ==============================================
|
||||
|
||||
For more details refer Documentation/admin-guide/iostats.rst
|
||||
|
|
@ -0,0 +1,136 @@
|
|||
What: /sys/bus/firewire/devices/fw[0-9]+/
|
||||
Date: May 2007
|
||||
KernelVersion: 2.6.22
|
||||
Contact: linux1394-devel@lists.sourceforge.net
|
||||
Description:
|
||||
IEEE 1394 node device attributes.
|
||||
Read-only. Mutable during the node device's lifetime.
|
||||
See IEEE 1212 for semantic definitions.
|
||||
|
||||
config_rom
|
||||
Contents of the Configuration ROM register.
|
||||
Binary attribute; an array of host-endian u32.
|
||||
|
||||
guid
|
||||
The node's EUI-64 in the bus information block of
|
||||
Configuration ROM.
|
||||
Hexadecimal string representation of an u64.
|
||||
|
||||
|
||||
What: /sys/bus/firewire/devices/fw[0-9]+/units
|
||||
Date: June 2009
|
||||
KernelVersion: 2.6.31
|
||||
Contact: linux1394-devel@lists.sourceforge.net
|
||||
Description:
|
||||
IEEE 1394 node device attribute.
|
||||
Read-only. Mutable during the node device's lifetime.
|
||||
See IEEE 1212 for semantic definitions.
|
||||
|
||||
units
|
||||
Summary of all units present in an IEEE 1394 node.
|
||||
Contains space-separated tuples of specifier_id and
|
||||
version of each unit present in the node. Specifier_id
|
||||
and version are hexadecimal string representations of
|
||||
u24 of the respective unit directory entries.
|
||||
Specifier_id and version within each tuple are separated
|
||||
by a colon.
|
||||
|
||||
Users: udev rules to set ownership and access permissions or ACLs of
|
||||
/dev/fw[0-9]+ character device files
|
||||
|
||||
|
||||
What: /sys/bus/firewire/devices/fw[0-9]+/is_local
|
||||
Date: July 2012
|
||||
KernelVersion: 3.6
|
||||
Contact: linux1394-devel@lists.sourceforge.net
|
||||
Description:
|
||||
IEEE 1394 node device attribute.
|
||||
Read-only and immutable.
|
||||
Values: 1: The sysfs entry represents a local node (a controller card).
|
||||
|
||||
0: The sysfs entry represents a remote node.
|
||||
|
||||
|
||||
What: /sys/bus/firewire/devices/fw[0-9]+[.][0-9]+/
|
||||
Date: May 2007
|
||||
KernelVersion: 2.6.22
|
||||
Contact: linux1394-devel@lists.sourceforge.net
|
||||
Description:
|
||||
IEEE 1394 unit device attributes.
|
||||
Read-only. Immutable during the unit device's lifetime.
|
||||
See IEEE 1212 for semantic definitions.
|
||||
|
||||
modalias
|
||||
Same as MODALIAS in the uevent at device creation.
|
||||
|
||||
rom_index
|
||||
Offset of the unit directory within the parent device's
|
||||
(node device's) Configuration ROM, in quadlets.
|
||||
Decimal string representation.
|
||||
|
||||
|
||||
What: /sys/bus/firewire/devices/*/
|
||||
Date: May 2007
|
||||
KernelVersion: 2.6.22
|
||||
Contact: linux1394-devel@lists.sourceforge.net
|
||||
Description:
|
||||
Attributes common to IEEE 1394 node devices and unit devices.
|
||||
Read-only. Mutable during the node device's lifetime.
|
||||
Immutable during the unit device's lifetime.
|
||||
See IEEE 1212 for semantic definitions.
|
||||
|
||||
These attributes are only created if the root directory of an
|
||||
IEEE 1394 node or the unit directory of an IEEE 1394 unit
|
||||
actually contains according entries.
|
||||
|
||||
hardware_version
|
||||
Hexadecimal string representation of an u24.
|
||||
|
||||
hardware_version_name
|
||||
Contents of a respective textual descriptor leaf.
|
||||
|
||||
model
|
||||
Hexadecimal string representation of an u24.
|
||||
|
||||
model_name
|
||||
Contents of a respective textual descriptor leaf.
|
||||
|
||||
specifier_id
|
||||
Hexadecimal string representation of an u24.
|
||||
Mandatory in unit directories according to IEEE 1212.
|
||||
|
||||
vendor
|
||||
Hexadecimal string representation of an u24.
|
||||
Mandatory in the root directory according to IEEE 1212.
|
||||
|
||||
vendor_name
|
||||
Contents of a respective textual descriptor leaf.
|
||||
|
||||
version
|
||||
Hexadecimal string representation of an u24.
|
||||
Mandatory in unit directories according to IEEE 1212.
|
||||
|
||||
|
||||
What: /sys/bus/firewire/drivers/sbp2/fw*/host*/target*/*:*:*:*/ieee1394_id
|
||||
formerly
|
||||
/sys/bus/ieee1394/drivers/sbp2/fw*/host*/target*/*:*:*:*/ieee1394_id
|
||||
Date: Feb 2004
|
||||
KernelVersion: 2.6.4
|
||||
Contact: linux1394-devel@lists.sourceforge.net
|
||||
Description:
|
||||
SCSI target port identifier and logical unit identifier of a
|
||||
logical unit of an SBP-2 target. The identifiers are specified
|
||||
in SAM-2...SAM-4 annex A. They are persistent and world-wide
|
||||
unique properties the SBP-2 attached target.
|
||||
|
||||
Read-only attribute, immutable during the target's lifetime.
|
||||
Format, as exposed by firewire-sbp2 since 2.6.22, May 2007:
|
||||
Colon-separated hexadecimal string representations of
|
||||
|
||||
u64 EUI-64 : u24 directory_ID : u16 LUN
|
||||
|
||||
without 0x prefixes, without whitespace. The former sbp2 driver
|
||||
(removed in 2.6.37 after being superseded by firewire-sbp2) used
|
||||
a somewhat shorter format which was not as close to SAM.
|
||||
|
||||
Users: udev rules to create /dev/disk/by-id/ symlinks
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
What: /sys/bus/fsl-mc/rescan
|
||||
Date: January 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: Ioana Ciornei <ioana.ciornei@nxp.com>
|
||||
Description: Writing a non-zero value to this attribute will
|
||||
force a rescan of fsl-mc bus in the system and
|
||||
synchronize the objects under fsl-mc bus and the
|
||||
Management Complex firmware.
|
||||
Users: Userspace drivers and management tools
|
||||
|
||||
What: /sys/bus/fsl-mc/autorescan
|
||||
Date: January 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: Ioana Ciornei <ioana.ciornei@nxp.com>
|
||||
Description: Writing a zero value to this attribute will
|
||||
disable the DPRC IRQs on which automatic rescan
|
||||
of the fsl-mc bus is performed. A non-zero value
|
||||
will enable the DPRC IRQs.
|
||||
Users: Userspace drivers and management tools
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
What: /sys/bus/mhi/devices/.../serialnumber
|
||||
Date: Sept 2020
|
||||
KernelVersion: 5.10
|
||||
Contact: mhi@lists.linux.dev
|
||||
Description: The file holds the serial number of the client device obtained
|
||||
using a BHI (Boot Host Interface) register read after at least
|
||||
one attempt to power up the device has been done. If 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/.../oem_pk_hash
|
||||
Date: Sept 2020
|
||||
KernelVersion: 5.10
|
||||
Contact: mhi@lists.linux.dev
|
||||
Description: The file holds the OEM PK Hash value of the endpoint device
|
||||
obtained using a BHI (Boot Host Interface) register read after
|
||||
at least one attempt to power up the device has been done. If
|
||||
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.
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
What: /sys/bus/nvmem/devices/.../nvmem
|
||||
Date: July 2015
|
||||
KernelVersion: 4.2
|
||||
Contact: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
Description:
|
||||
This file allows user to read/write the raw NVMEM contents.
|
||||
Permissions for write to this file depends on the nvmem
|
||||
provider configuration.
|
||||
Note: This file is only present if CONFIG_NVMEM_SYSFS
|
||||
is enabled
|
||||
|
||||
ex::
|
||||
|
||||
hexdump /sys/bus/nvmem/devices/qfprom0/nvmem
|
||||
|
||||
0000000 0000 0000 0000 0000 0000 0000 0000 0000
|
||||
*
|
||||
00000a0 db10 2240 0000 e000 0c00 0c00 0000 0c00
|
||||
0000000 0000 0000 0000 0000 0000 0000 0000 0000
|
||||
...
|
||||
*
|
||||
0001000
|
||||
|
|
@ -0,0 +1,142 @@
|
|||
What: /sys/bus/usb/devices/.../power/persist
|
||||
Date: May 2007
|
||||
KernelVersion: 2.6.23
|
||||
Contact: Alan Stern <stern@rowland.harvard.edu>
|
||||
Description:
|
||||
USB device directories can contain a file named power/persist.
|
||||
The file holds a boolean value (0 or 1) indicating whether or
|
||||
not the "USB-Persist" facility is enabled for the device. For
|
||||
hubs this facility is always enabled and their device
|
||||
directories will not contain this file.
|
||||
|
||||
For more information, see Documentation/driver-api/usb/persist.rst.
|
||||
|
||||
What: /sys/bus/usb/devices/.../power/autosuspend
|
||||
Date: March 2007
|
||||
KernelVersion: 2.6.21
|
||||
Contact: Alan Stern <stern@rowland.harvard.edu>
|
||||
Description:
|
||||
Each USB device directory will contain a file named
|
||||
power/autosuspend. This file holds the time (in seconds)
|
||||
the device must be idle before it will be autosuspended.
|
||||
0 means the device will be autosuspended as soon as
|
||||
possible. Negative values will prevent the device from
|
||||
being autosuspended at all, and writing a negative value
|
||||
will resume the device if it is already suspended.
|
||||
|
||||
The autosuspend delay for newly-created devices is set to
|
||||
the value of the usbcore.autosuspend module parameter.
|
||||
|
||||
What: /sys/bus/usb/device/.../power/connected_duration
|
||||
Date: January 2008
|
||||
KernelVersion: 2.6.25
|
||||
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
|
||||
Description:
|
||||
If CONFIG_PM is enabled, then this file is present. When read,
|
||||
it returns the total time (in msec) that the USB device has been
|
||||
connected to the machine. This file is read-only.
|
||||
Users:
|
||||
PowerTOP <powertop@lists.01.org>
|
||||
https://01.org/powertop/
|
||||
|
||||
What: /sys/bus/usb/device/.../power/active_duration
|
||||
Date: January 2008
|
||||
KernelVersion: 2.6.25
|
||||
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
|
||||
Description:
|
||||
If CONFIG_PM is enabled, then this file is present. When read,
|
||||
it returns the total time (in msec) that the USB device has been
|
||||
active, i.e. not in a suspended state. This file is read-only.
|
||||
|
||||
Tools can use this file and the connected_duration file to
|
||||
compute the percentage of time that a device has been active.
|
||||
For example::
|
||||
|
||||
echo $((100 * `cat active_duration` / `cat connected_duration`))
|
||||
|
||||
will give an integer percentage. Note that this does not
|
||||
account for counter wrap.
|
||||
Users:
|
||||
PowerTOP <powertop@lists.01.org>
|
||||
https://01.org/powertop/
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<port[.port]>...:<config num>-<interface num>/supports_autosuspend
|
||||
Date: January 2008
|
||||
KernelVersion: 2.6.27
|
||||
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
|
||||
Description:
|
||||
When read, this file returns 1 if the interface driver
|
||||
for this interface supports autosuspend. It also
|
||||
returns 1 if no driver has claimed this interface, as an
|
||||
unclaimed interface will not stop the device from being
|
||||
autosuspended if all other interface drivers are idle.
|
||||
The file returns 0 if autosuspend support has not been
|
||||
added to the driver.
|
||||
Users:
|
||||
USB PM tool
|
||||
git://git.moblin.org/users/sarah/usb-pm-tool/
|
||||
|
||||
What: /sys/bus/usb/device/.../avoid_reset_quirk
|
||||
Date: December 2009
|
||||
Contact: Oliver Neukum <oliver@neukum.org>
|
||||
Description:
|
||||
Writing 1 to this file tells the kernel that this
|
||||
device will morph into another mode when it is reset.
|
||||
Drivers will not use reset for error handling for
|
||||
such devices.
|
||||
Users:
|
||||
usb_modeswitch
|
||||
|
||||
What: /sys/bus/usb/devices/.../devnum
|
||||
KernelVersion: since at least 2.6.18
|
||||
Description:
|
||||
Device address on the USB bus.
|
||||
Users:
|
||||
libusb
|
||||
|
||||
What: /sys/bus/usb/devices/.../bConfigurationValue
|
||||
KernelVersion: since at least 2.6.18
|
||||
Description:
|
||||
bConfigurationValue of the *active* configuration for the
|
||||
device. Writing 0 or -1 to bConfigurationValue will reset the
|
||||
active configuration (unconfigure the device). Writing
|
||||
another value will change the active configuration.
|
||||
|
||||
Note that some devices, in violation of the USB spec, have a
|
||||
configuration with a value equal to 0. Writing 0 to
|
||||
bConfigurationValue for these devices will install that
|
||||
configuration, rather then unconfigure the device.
|
||||
|
||||
Writing -1 will always unconfigure the device.
|
||||
Users:
|
||||
libusb
|
||||
|
||||
What: /sys/bus/usb/devices/.../busnum
|
||||
KernelVersion: 2.6.22
|
||||
Description:
|
||||
Bus-number of the USB-bus the device is connected to.
|
||||
Users:
|
||||
libusb
|
||||
|
||||
What: /sys/bus/usb/devices/.../descriptors
|
||||
KernelVersion: 2.6.26
|
||||
Description:
|
||||
Binary file containing cached descriptors of the device. The
|
||||
binary data consists of the device descriptor followed by the
|
||||
descriptors for each configuration of the device.
|
||||
Note that the wTotalLength of the config descriptors can not
|
||||
be trusted, as the device may have a smaller config descriptor
|
||||
than it advertises. The bLength field of each (sub) descriptor
|
||||
can be trusted, and can be used to seek forward one (sub)
|
||||
descriptor at a time until the next config descriptor is found.
|
||||
All descriptors read from this file are in bus-endian format
|
||||
Users:
|
||||
libusb
|
||||
|
||||
What: /sys/bus/usb/devices/.../speed
|
||||
KernelVersion: since at least 2.6.18
|
||||
Description:
|
||||
Speed the device is connected with to the usb-host in
|
||||
Mbit / second. IE one of 1.5 / 12 / 480 / 5000.
|
||||
Users:
|
||||
libusb
|
||||
|
|
@ -0,0 +1,187 @@
|
|||
What: /sys/bus/vmbus/hibernation
|
||||
Date: Jan 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: Dexuan Cui <decui@microsoft.com>
|
||||
Description: Whether the host supports hibernation for the VM.
|
||||
Users: Daemon that sets up swap partition/file for hibernation.
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/id
|
||||
Date: Jul 2009
|
||||
KernelVersion: 2.6.31
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The VMBus child_relid of the device's primary channel
|
||||
Users: tools/hv/lsvmbus
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/class_id
|
||||
Date: Jul 2009
|
||||
KernelVersion: 2.6.31
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The VMBus interface type GUID of the device
|
||||
Users: tools/hv/lsvmbus
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/device_id
|
||||
Date: Jul 2009
|
||||
KernelVersion: 2.6.31
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The VMBus interface instance GUID of the device
|
||||
Users: tools/hv/lsvmbus
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channel_vp_mapping
|
||||
Date: Jul 2015
|
||||
KernelVersion: 4.2.0
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The mapping of which primary/sub channels are bound to which
|
||||
Virtual Processors.
|
||||
Format: <channel's child_relid:the bound cpu's number>
|
||||
Users: tools/hv/lsvmbus
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/device
|
||||
Date: Dec. 2015
|
||||
KernelVersion: 4.5
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The 16 bit device ID of the device
|
||||
Users: tools/hv/lsvmbus and user level RDMA libraries
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/vendor
|
||||
Date: Dec. 2015
|
||||
KernelVersion: 4.5
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The 16 bit vendor ID of the device
|
||||
Users: tools/hv/lsvmbus and user level RDMA libraries
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/numa_node
|
||||
Date: Jul 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: This NUMA node to which the VMBUS device is
|
||||
attached, or -1 if the node is unknown.
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Directory for per-channel information
|
||||
NN is the VMBUS relid associated with the channel.
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/cpu
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: VCPU (sub)channel is affinitized to
|
||||
Users: tools/hv/lsvmbus and other debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/in_mask
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Host to guest channel interrupt mask
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/latency
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Channel signaling latency. This file is available only for
|
||||
performance critical channels (storage, network, etc.) that use
|
||||
the monitor page mechanism.
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/out_mask
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Guest to host channel interrupt mask
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/pending
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Channel interrupt pending state. This file is available only for
|
||||
performance critical channels (storage, network, etc.) that use
|
||||
the monitor page mechanism.
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/read_avail
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Bytes available to read
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/write_avail
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Bytes available to write
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/events
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Number of times we have signaled the host
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/interrupts
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Number of times we have taken an interrupt (incoming)
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/subchannel_id
|
||||
Date: January. 2018
|
||||
KernelVersion: 4.16
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Subchannel ID associated with VMBUS channel
|
||||
Users: Debugging tools and userspace drivers
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/monitor_id
|
||||
Date: January. 2018
|
||||
KernelVersion: 4.16
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Monitor bit associated with channel. This file is available only
|
||||
for performance critical channels (storage, network, etc.) that
|
||||
use the monitor page mechanism.
|
||||
Users: Debugging tools and userspace drivers
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/ring
|
||||
Date: January. 2018
|
||||
KernelVersion: 4.16
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Binary file created by uio_hv_generic for ring buffer
|
||||
Users: Userspace drivers
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/intr_in_full
|
||||
Date: February 2019
|
||||
KernelVersion: 5.0
|
||||
Contact: Michael Kelley <mikelley@microsoft.com>
|
||||
Description: Number of guest to host interrupts caused by the inbound ring
|
||||
buffer transitioning from full to not full while a packet is
|
||||
waiting for buffer space to become available
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/intr_out_empty
|
||||
Date: February 2019
|
||||
KernelVersion: 5.0
|
||||
Contact: Michael Kelley <mikelley@microsoft.com>
|
||||
Description: Number of guest to host interrupts caused by the outbound ring
|
||||
buffer transitioning from empty to not empty
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/out_full_first
|
||||
Date: February 2019
|
||||
KernelVersion: 5.0
|
||||
Contact: Michael Kelley <mikelley@microsoft.com>
|
||||
Description: Number of write operations that were the first to encounter an
|
||||
outbound ring buffer full condition
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/out_full_total
|
||||
Date: February 2019
|
||||
KernelVersion: 5.0
|
||||
Contact: Michael Kelley <mikelley@microsoft.com>
|
||||
Description: Total number of write operations that encountered an outbound
|
||||
ring buffer full condition
|
||||
Users: Debugging tools
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
What: /sys/bus/w1/devices/.../w1_master_timeout_us
|
||||
Date: April 2015
|
||||
Contact: Dmitry Khromov <dk@icelogic.net>
|
||||
Description: Bus scanning interval, microseconds component.
|
||||
Some of 1-Wire devices commonly associated with physical access
|
||||
control systems are attached/generate presence for as short as
|
||||
100 ms - hence the tens-to-hundreds milliseconds scan intervals
|
||||
are required.
|
||||
|
||||
see Documentation/w1/w1-generic.rst for detailed information.
|
||||
Users: any user space application which wants to know bus scanning
|
||||
interval
|
||||
|
|
@ -0,0 +1,84 @@
|
|||
What: /sys/bus/xen-backend/devices/*/devtype
|
||||
Date: Feb 2009
|
||||
KernelVersion: 2.6.38
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The type of the device. e.g., one of: 'vbd' (block),
|
||||
'vif' (network), or 'vfb' (framebuffer).
|
||||
|
||||
What: /sys/bus/xen-backend/devices/*/nodename
|
||||
Date: Feb 2009
|
||||
KernelVersion: 2.6.38
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
XenStore node (under /local/domain/NNN/) for this
|
||||
backend device.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/physical_device
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The major:minor number (in hexadecimal) of the
|
||||
physical device providing the storage for this backend
|
||||
block device.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/mode
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Whether the block device is read-only ('r') or
|
||||
read-write ('w').
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/statistics/f_req
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Number of flush requests from the frontend.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/statistics/oo_req
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Number of requests delayed because the backend was too
|
||||
busy processing previous requests.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/statistics/rd_req
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Number of read requests from the frontend.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/statistics/rd_sect
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Number of sectors read by the frontend.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/statistics/wr_req
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Number of write requests from the frontend.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/vbd-*/statistics/wr_sect
|
||||
Date: April 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Number of sectors written by the frontend.
|
||||
|
||||
What: /sys/bus/xen-backend/devices/*/state
|
||||
Date: August 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Joe Jin <joe.jin@oracle.com>
|
||||
Description:
|
||||
The state of the device. One of: 'Unknown',
|
||||
'Initialising', 'Initialised', 'Connected', 'Closing',
|
||||
'Closed', 'Reconfiguring', 'Reconfigured'.
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
What: /sys/class/backlight/<backlight>/bl_power
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: Richard Purdie <rpurdie@rpsys.net>
|
||||
Description:
|
||||
Control BACKLIGHT power, values are FB_BLANK_* from fb.h
|
||||
|
||||
- FB_BLANK_UNBLANK (0) : power on.
|
||||
- FB_BLANK_POWERDOWN (4) : power off
|
||||
Users: HAL
|
||||
|
||||
What: /sys/class/backlight/<backlight>/brightness
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: Richard Purdie <rpurdie@rpsys.net>
|
||||
Description:
|
||||
Control the brightness for this <backlight>. Values
|
||||
are between 0 and max_brightness. This file will also
|
||||
show the brightness level stored in the driver, which
|
||||
may not be the actual brightness (see actual_brightness).
|
||||
Users: HAL
|
||||
|
||||
What: /sys/class/backlight/<backlight>/actual_brightness
|
||||
Date: March 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: Richard Purdie <rpurdie@rpsys.net>
|
||||
Description:
|
||||
Show the actual brightness by querying the hardware.
|
||||
Users: HAL
|
||||
|
||||
What: /sys/class/backlight/<backlight>/max_brightness
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: Richard Purdie <rpurdie@rpsys.net>
|
||||
Description:
|
||||
Maximum brightness for <backlight>.
|
||||
Users: HAL
|
||||
|
||||
What: /sys/class/backlight/<backlight>/type
|
||||
Date: September 2010
|
||||
KernelVersion: 2.6.37
|
||||
Contact: Matthew Garrett <mjg@redhat.com>
|
||||
Description:
|
||||
The type of interface controlled by <backlight>.
|
||||
"firmware": The driver uses a standard firmware interface
|
||||
"platform": The driver uses a platform-specific interface
|
||||
"raw": The driver controls hardware registers directly
|
||||
|
||||
In the general case, when multiple backlight
|
||||
interfaces are available for a single device, firmware
|
||||
control should be preferred to platform control should
|
||||
be preferred to raw control. Using a firmware
|
||||
interface reduces the probability of confusion with
|
||||
the hardware and the OS independently updating the
|
||||
backlight state. Platform interfaces are mostly a
|
||||
holdover from pre-standardisation of firmware
|
||||
interfaces.
|
||||
|
|
@ -0,0 +1,784 @@
|
|||
sysfs interface common for all infiniband devices
|
||||
-------------------------------------------------
|
||||
|
||||
What: /sys/class/infiniband/<device>/node_type
|
||||
What: /sys/class/infiniband/<device>/node_guid
|
||||
What: /sys/class/infiniband/<device>/sys_image_guid
|
||||
Date: Apr, 2005
|
||||
KernelVersion: v2.6.12
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
=============== ===========================================
|
||||
node_type: (RO) Node type (CA, RNIC, usNIC, usNIC UDP,
|
||||
switch or router)
|
||||
|
||||
node_guid: (RO) Node GUID
|
||||
|
||||
sys_image_guid: (RO) System image GUID
|
||||
=============== ===========================================
|
||||
|
||||
|
||||
What: /sys/class/infiniband/<device>/node_desc
|
||||
Date: Feb, 2006
|
||||
KernelVersion: v2.6.17
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
(RW) Update the node description with information such as the
|
||||
node's hostname, so that IB network management software can tie
|
||||
its view to the real world.
|
||||
|
||||
|
||||
What: /sys/class/infiniband/<device>/fw_ver
|
||||
Date: Jun, 2016
|
||||
KernelVersion: v4.10
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
(RO) Display firmware version
|
||||
|
||||
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/lid
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/rate
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/lid_mask_count
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/sm_sl
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/sm_lid
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/state
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/phys_state
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/cap_mask
|
||||
Date: Apr, 2005
|
||||
KernelVersion: v2.6.12
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
|
||||
=============== ===============================================
|
||||
lid: (RO) Port LID
|
||||
|
||||
rate: (RO) Port data rate (active width * active
|
||||
speed)
|
||||
|
||||
lid_mask_count: (RO) Port LID mask count
|
||||
|
||||
sm_sl: (RO) Subnet manager SL for port's subnet
|
||||
|
||||
sm_lid: (RO) Subnet manager LID for port's subnet
|
||||
|
||||
state: (RO) Port state (DOWN, INIT, ARMED, ACTIVE or
|
||||
ACTIVE_DEFER)
|
||||
|
||||
phys_state: (RO) Port physical state (Sleep, Polling,
|
||||
LinkUp, etc)
|
||||
|
||||
cap_mask: (RO) Port capability mask. 2 bits here are
|
||||
settable- IsCommunicationManagementSupported
|
||||
(set when CM module is loaded) and IsSM (set
|
||||
via open of issmN file).
|
||||
=============== ===============================================
|
||||
|
||||
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/link_layer
|
||||
Date: Oct, 2010
|
||||
KernelVersion: v2.6.37
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
(RO) Link layer type information (Infiniband or Ethernet type)
|
||||
|
||||
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/symbol_error
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_rcv_errors
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_rcv_remote_physical_errors
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_rcv_switch_relay_errors
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/link_error_recovery
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_xmit_constraint_errors
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_rcv_contraint_errors
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/local_link_integrity_errors
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/excessive_buffer_overrun_errors
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_xmit_data
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_rcv_data
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_xmit_packets
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_rcv_packets
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/unicast_rcv_packets
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/unicast_xmit_packets
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/multicast_rcv_packets
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/multicast_xmit_packets
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/link_downed
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_xmit_discards
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/VL15_dropped
|
||||
What: /sys/class/infiniband/<device>/ports/<port-num>/counters/port_xmit_wait
|
||||
Date: Apr, 2005
|
||||
KernelVersion: v2.6.12
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
**Errors info**:
|
||||
|
||||
symbol_error: (RO) Total number of minor link errors detected on
|
||||
one or more physical lanes.
|
||||
|
||||
port_rcv_errors : (RO) Total number of packets containing an
|
||||
error that were received on the port.
|
||||
|
||||
port_rcv_remote_physical_errors : (RO) Total number of packets
|
||||
marked with the EBP delimiter received on the port.
|
||||
|
||||
port_rcv_switch_relay_errors : (RO) Total number of packets
|
||||
received on the port that were discarded because they could not
|
||||
be forwarded by the switch relay.
|
||||
|
||||
link_error_recovery: (RO) Total number of times the Port
|
||||
Training state machine has successfully completed the link error
|
||||
recovery process.
|
||||
|
||||
port_xmit_constraint_errors: (RO) Total number of packets not
|
||||
transmitted from the switch physical port due to outbound raw
|
||||
filtering or failing outbound partition or IP version check.
|
||||
|
||||
port_rcv_constraint_errors: (RO) Total number of packets
|
||||
received on the switch physical port that are discarded due to
|
||||
inbound raw filtering or failing inbound partition or IP version
|
||||
check.
|
||||
|
||||
local_link_integrity_errors: (RO) The number of times that the
|
||||
count of local physical errors exceeded the threshold specified
|
||||
by LocalPhyErrors
|
||||
|
||||
excessive_buffer_overrun_errors: (RO) This counter, indicates an
|
||||
input buffer overrun. It indicates possible misconfiguration of
|
||||
a port, either by the Subnet Manager (SM) or by user
|
||||
intervention. It can also indicate hardware issues or extremely
|
||||
poor link signal integrity
|
||||
|
||||
**Data info**:
|
||||
|
||||
port_xmit_data: (RO) Total number of data octets, divided by 4
|
||||
(lanes), transmitted on all VLs. This is 64 bit counter
|
||||
|
||||
port_rcv_data: (RO) Total number of data octets, divided by 4
|
||||
(lanes), received on all VLs. This is 64 bit counter.
|
||||
|
||||
port_xmit_packets: (RO) Total number of packets transmitted on
|
||||
all VLs from this port. This may include packets with errors.
|
||||
This is 64 bit counter.
|
||||
|
||||
port_rcv_packets: (RO) Total number of packets (this may include
|
||||
packets containing Errors. This is 64 bit counter.
|
||||
|
||||
link_downed: (RO) Total number of times the Port Training state
|
||||
machine has failed the link error recovery process and downed
|
||||
the link.
|
||||
|
||||
unicast_rcv_packets: (RO) Total number of unicast packets,
|
||||
including unicast packets containing errors.
|
||||
|
||||
unicast_xmit_packets: (RO) Total number of unicast packets
|
||||
transmitted on all VLs from the port. This may include unicast
|
||||
packets with errors.
|
||||
|
||||
multicast_rcv_packets: (RO) Total number of multicast packets,
|
||||
including multicast packets containing errors.
|
||||
|
||||
multicast_xmit_packets: (RO) Total number of multicast packets
|
||||
transmitted on all VLs from the port. This may include multicast
|
||||
packets with errors.
|
||||
|
||||
**Misc info**:
|
||||
|
||||
port_xmit_discards: (RO) Total number of outbound packets
|
||||
discarded by the port because the port is down or congested.
|
||||
|
||||
VL15_dropped: (RO) Number of incoming VL15 packets dropped due
|
||||
to resource limitations (e.g., lack of buffers) of the port.
|
||||
|
||||
port_xmit_wait: (RO) The number of ticks during which the port
|
||||
had data to transmit but no data was sent during the entire tick
|
||||
(either because of insufficient credits or because of lack of
|
||||
arbitration).
|
||||
|
||||
Each of these files contains the corresponding value from the
|
||||
port's Performance Management PortCounters attribute, as
|
||||
described in the InfiniBand Architecture Specification.
|
||||
|
||||
|
||||
What: /sys/class/infiniband/<device-name>/hw_counters/lifespan
|
||||
What: /sys/class/infiniband/<device-name>/ports/<port-num>/hw_counters/lifespan
|
||||
Date: May, 2016
|
||||
KernelVersion: 4.6
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
The optional "hw_counters" subdirectory can be under either the
|
||||
parent device or the port subdirectories or both. If present,
|
||||
there are a list of counters provided by the hardware. They may
|
||||
match some of the counters in the counters directory, but they
|
||||
often include many other counters. In addition to the various
|
||||
counters, there will be a file named "lifespan" that configures
|
||||
how frequently the core should update the counters when they are
|
||||
being accessed (counters are not updated if they are not being
|
||||
accessed). The lifespan is in milliseconds and defaults to 10
|
||||
unless set to something else by the driver. Users may echo a
|
||||
value between 0-10000 to the lifespan file to set the length
|
||||
of time between updates in milliseconds.
|
||||
|
||||
|
||||
What: /sys/class/infiniband/<hca>/ports/<port-number>/gid_attrs/ndevs/<gid-index>
|
||||
Date: November 29, 2015
|
||||
KernelVersion: 4.4.0
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: The net-device's name associated with the GID resides
|
||||
at index <gid-index>.
|
||||
|
||||
What: /sys/class/infiniband/<hca>/ports/<port-number>/gid_attrs/types/<gid-index>
|
||||
Date: November 29, 2015
|
||||
KernelVersion: 4.4.0
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: The RoCE type of the associated GID resides at index <gid-index>.
|
||||
This could either be "IB/RoCE v1" for IB and RoCE v1 based GIDs
|
||||
or "RoCE v2" for RoCE v2 based GIDs.
|
||||
|
||||
|
||||
What: /sys/class/infiniband_mad/umad<N>/ibdev
|
||||
What: /sys/class/infiniband_mad/umad<N>/port
|
||||
What: /sys/class/infiniband_mad/issm<N>/ibdev
|
||||
What: /sys/class/infiniband_mad/issm<N>/port
|
||||
Date: Apr, 2005
|
||||
KernelVersion: v2.6.12
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
Each port of each InfiniBand device has a "umad" device and an
|
||||
"issm" device attached. For example, a two-port HCA will have
|
||||
two umad devices and two issm devices, while a switch will have
|
||||
one device of each type (for switch port 0).
|
||||
|
||||
======= =====================================
|
||||
ibdev: (RO) Show Infiniband (IB) device name
|
||||
|
||||
port: (RO) Display port number
|
||||
======= =====================================
|
||||
|
||||
|
||||
What: /sys/class/infiniband_mad/abi_version
|
||||
Date: Apr, 2005
|
||||
KernelVersion: v2.6.12
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
(RO) Value is incremented if any changes are made that break
|
||||
userspace ABI compatibility of umad & issm devices.
|
||||
|
||||
|
||||
What: /sys/class/infiniband_verbs/uverbs<N>/ibdev
|
||||
What: /sys/class/infiniband_verbs/uverbs<N>/abi_version
|
||||
Date: Sept, 2005
|
||||
KernelVersion: v2.6.14
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
=============== ===========================================
|
||||
ibdev: (RO) Display Infiniband (IB) device name
|
||||
|
||||
abi_version: (RO) Show ABI version of IB device specific
|
||||
interfaces.
|
||||
=============== ===========================================
|
||||
|
||||
|
||||
What: /sys/class/infiniband_verbs/abi_version
|
||||
Date: Sep, 2005
|
||||
KernelVersion: v2.6.14
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
(RO) Value is incremented if any changes are made that break
|
||||
userspace ABI compatibility of uverbs devices.
|
||||
|
||||
|
||||
sysfs interface for Mellanox IB HCA low-level driver (mthca)
|
||||
------------------------------------------------------------
|
||||
|
||||
What: /sys/class/infiniband/mthcaX/hw_rev
|
||||
What: /sys/class/infiniband/mthcaX/hca_type
|
||||
What: /sys/class/infiniband/mthcaX/board_id
|
||||
Date: Apr, 2005
|
||||
KernelVersion: v2.6.12
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
=============== ================================================
|
||||
hw_rev: (RO) Hardware revision number
|
||||
|
||||
hca_type: (RO) Host Channel Adapter type: MT23108, MT25208
|
||||
(MT23108 compat mode), MT25208 or MT25204
|
||||
|
||||
board_id: (RO) Manufacturing board ID
|
||||
=============== ================================================
|
||||
|
||||
|
||||
sysfs interface for Mellanox ConnectX HCA IB driver (mlx4)
|
||||
----------------------------------------------------------
|
||||
|
||||
What: /sys/class/infiniband/mlx4_X/hw_rev
|
||||
What: /sys/class/infiniband/mlx4_X/hca_type
|
||||
What: /sys/class/infiniband/mlx4_X/board_id
|
||||
Date: Sep, 2007
|
||||
KernelVersion: v2.6.24
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
=============== ===============================
|
||||
hw_rev: (RO) Hardware revision number
|
||||
|
||||
hca_type: (RO) Host channel adapter type
|
||||
|
||||
board_id: (RO) Manufacturing board ID
|
||||
=============== ===============================
|
||||
|
||||
|
||||
What: /sys/class/infiniband/mlx4_X/iov/ports/<port-num>/gids/<n>
|
||||
What: /sys/class/infiniband/mlx4_X/iov/ports/<port-num>/admin_guids/<n>
|
||||
What: /sys/class/infiniband/mlx4_X/iov/ports/<port-num>/pkeys/<n>
|
||||
What: /sys/class/infiniband/mlx4_X/iov/ports/<port-num>/mcgs/
|
||||
What: /sys/class/infiniband/mlx4_X/iov/ports/<pci-slot-num>/ports/<m>/gid_idx/0
|
||||
What: /sys/class/infiniband/mlx4_X/iov/ports/<pci-slot-num>/ports/<m>/pkey_idx/<n>
|
||||
Date: Aug, 2012
|
||||
KernelVersion: v3.6.15
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
The sysfs iov directory is used to manage and examine the port
|
||||
P_Key and guid paravirtualization. This directory is added only
|
||||
for the master -- slaves do not have it.
|
||||
|
||||
Under iov/ports, the administrator may examine the gid and P_Key
|
||||
tables as they are present in the device (and as are seen in the
|
||||
"network view" presented to the SM).
|
||||
|
||||
The "pkeys" and "gids" subdirectories contain one file for each
|
||||
entry in the port's P_Key or GID table respectively. For
|
||||
example, ports/1/pkeys/10 contains the value at index 10 in port
|
||||
1's P_Key table.
|
||||
|
||||
======================= ==========================================
|
||||
gids/<n>: (RO) The physical port gids n = 0..127
|
||||
|
||||
admin_guids/<n>: (RW) Allows examining or changing the
|
||||
administrative state of a given GUID
|
||||
n = 0..127
|
||||
|
||||
pkeys/<n>: (RO) Displays the contents of the physical
|
||||
key table n = 0..126
|
||||
|
||||
mcgs/: (RO) Multicast group table
|
||||
|
||||
<m>/gid_idx/0: (RO) Display the GID mapping m = 1..2
|
||||
|
||||
<m>/pkey_idx/<n>: (RW) Writable except for RoCE pkeys.
|
||||
m = 1..2, n = 0..126
|
||||
|
||||
Under the iov/<pci slot number>
|
||||
directories, the admin may map the index
|
||||
numbers in the physical tables (as under
|
||||
iov/ports) to the paravirtualized index
|
||||
numbers that guests see.
|
||||
|
||||
For example, if the administrator, for
|
||||
port 1 on guest 2 maps physical pkey
|
||||
index 10 to virtual index 1, then that
|
||||
guest, whenever it uses its pkey index
|
||||
1, will actually be using the real pkey
|
||||
index 10.
|
||||
======================= ==========================================
|
||||
|
||||
|
||||
What: /sys/class/infiniband/mlx4_X/iov/<pci-slot-num>/ports/<m>/smi_enabled
|
||||
What: /sys/class/infiniband/mlx4_X/iov/<pci-slot-num>/ports/<m>/enable_smi_admin
|
||||
Date: May, 2014
|
||||
KernelVersion: v3.15.7
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
Enabling QP0 on VFs for selected VF/port. By default, no VFs are
|
||||
enabled for QP0 operation.
|
||||
|
||||
================= ==== ===========================================
|
||||
smi_enabled: (RO) Indicates whether smi is currently enabled
|
||||
for the indicated VF/port
|
||||
|
||||
enable_smi_admin: (RW) Used by the admin to request that smi
|
||||
capability be enabled or disabled for the
|
||||
indicated VF/port. 0 = disable, 1 = enable.
|
||||
================= ==== ===========================================
|
||||
|
||||
The requested enablement will occur at the next reset of the VF
|
||||
(e.g. driver restart on the VM which owns the VF).
|
||||
|
||||
|
||||
sysfs interface for Chelsio T4/T5 RDMA driver (cxgb4)
|
||||
-----------------------------------------------------
|
||||
|
||||
What: /sys/class/infiniband/cxgb4_X/hw_rev
|
||||
What: /sys/class/infiniband/cxgb4_X/hca_type
|
||||
What: /sys/class/infiniband/cxgb4_X/board_id
|
||||
Date: Apr, 2010
|
||||
KernelVersion: v2.6.35
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
|
||||
=============== =============================================
|
||||
hw_rev: (RO) Hardware revision number
|
||||
|
||||
hca_type: (RO) Driver short name. Should normally match
|
||||
the name in its bus driver structure (e.g.
|
||||
pci_driver::name)
|
||||
|
||||
board_id: (RO) Manufacturing board id. (Vendor + device
|
||||
information)
|
||||
=============== =============================================
|
||||
|
||||
|
||||
sysfs interface for Intel IB driver qib
|
||||
---------------------------------------
|
||||
|
||||
What: /sys/class/infiniband/qibX/version
|
||||
What: /sys/class/infiniband/qibX/hw_rev
|
||||
What: /sys/class/infiniband/qibX/hca_type
|
||||
What: /sys/class/infiniband/qibX/board_id
|
||||
What: /sys/class/infiniband/qibX/boardversion
|
||||
What: /sys/class/infiniband/qibX/nctxts
|
||||
What: /sys/class/infiniband/qibX/localbus_info
|
||||
What: /sys/class/infiniband/qibX/tempsense
|
||||
What: /sys/class/infiniband/qibX/serial
|
||||
What: /sys/class/infiniband/qibX/nfreectxts
|
||||
What: /sys/class/infiniband/qibX/chip_reset
|
||||
Date: May, 2010
|
||||
KernelVersion: v2.6.35
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
=============== ======================================================
|
||||
version: (RO) Display version information of installed software
|
||||
and drivers.
|
||||
|
||||
hw_rev: (RO) Hardware revision number
|
||||
|
||||
hca_type: (RO) Host channel adapter type
|
||||
|
||||
board_id: (RO) Manufacturing board id
|
||||
|
||||
boardversion: (RO) Current version of the chip architecture
|
||||
|
||||
nctxts: (RO) Return the number of user ports (contexts)
|
||||
available
|
||||
|
||||
localbus_info: (RO) Human readable localbus info
|
||||
|
||||
tempsense: (RO) Display temp sense registers in decimal
|
||||
|
||||
serial: (RO) Serial number of the HCA
|
||||
|
||||
nfreectxts: (RO) The number of free user ports (contexts)
|
||||
available.
|
||||
|
||||
chip_reset: (WO) Reset the chip if possible by writing
|
||||
"reset" to this file. Only allowed if no user
|
||||
contexts are open that use chip resources.
|
||||
=============== ======================================================
|
||||
|
||||
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/sl2vl/[0-15]
|
||||
Date: May, 2010
|
||||
KernelVersion: v2.6.35
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
(RO) The directory contains 16 files numbered 0-15 that specify
|
||||
the Service Level (SL). Listing the SL files returns the Virtual
|
||||
Lane (VL) as programmed by the SL.
|
||||
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/CCMgtA/cc_settings_bin
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/CCMgtA/cc_table_bin
|
||||
Date: May, 2010
|
||||
KernelVersion: v2.6.35
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
Per-port congestion control. Both are binary attributes.
|
||||
|
||||
=============== ================================================
|
||||
cc_table_bin (RO) Congestion control table size followed by
|
||||
table entries.
|
||||
|
||||
cc_settings_bin (RO) Congestion settings: port control, control
|
||||
map and an array of 16 entries for the
|
||||
congestion entries - increase, timer, event log
|
||||
trigger threshold and the minimum injection rate
|
||||
delay.
|
||||
=============== ================================================
|
||||
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/linkstate/loopback
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/linkstate/led_override
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/linkstate/hrtbt_enable
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/linkstate/status
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/linkstate/status_str
|
||||
Date: May, 2010
|
||||
KernelVersion: v2.6.35
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
[to be documented]
|
||||
|
||||
=============== ===============================================
|
||||
loopback: (WO)
|
||||
led_override: (WO)
|
||||
hrtbt_enable: (RW)
|
||||
status: (RO)
|
||||
|
||||
status_str: (RO) Displays information about the link state,
|
||||
possible cable/switch problems, and hardware
|
||||
errors. Possible states are- "Initted",
|
||||
"Present", "IB_link_up", "IB_configured" or
|
||||
"Fatal_Hardware_Error".
|
||||
=============== ===============================================
|
||||
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/rc_resends
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/seq_naks
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/rdma_seq
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/rnr_naks
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/other_naks
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/rc_timeouts
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/look_pkts
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/pkt_drops
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/dma_wait
|
||||
What: /sys/class/infiniband/qibX/ports/<N>/diag_counters/unaligned
|
||||
Date: May, 2010
|
||||
KernelVersion: v2.6.35
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
[to be documented]
|
||||
|
||||
|
||||
sysfs interface for Mellanox Connect-IB HCA driver mlx5
|
||||
-------------------------------------------------------
|
||||
|
||||
What: /sys/class/infiniband/mlx5_X/hw_rev
|
||||
What: /sys/class/infiniband/mlx5_X/hca_type
|
||||
What: /sys/class/infiniband/mlx5_X/reg_pages
|
||||
What: /sys/class/infiniband/mlx5_X/fw_pages
|
||||
Date: Jul, 2013
|
||||
KernelVersion: v3.11
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
[to be documented]
|
||||
|
||||
|
||||
sysfs interface for Cisco VIC (usNIC) Verbs Driver
|
||||
--------------------------------------------------
|
||||
|
||||
What: /sys/class/infiniband/usnic_X/board_id
|
||||
What: /sys/class/infiniband/usnic_X/config
|
||||
What: /sys/class/infiniband/usnic_X/qp_per_vf
|
||||
What: /sys/class/infiniband/usnic_X/max_vf
|
||||
What: /sys/class/infiniband/usnic_X/cq_per_vf
|
||||
What: /sys/class/infiniband/usnic_X/iface
|
||||
Date: Sep, 2013
|
||||
KernelVersion: v3.14
|
||||
Contact: Christian Benvenuti <benve@cisco.com>,
|
||||
Dave Goodell <dgoodell@cisco.com>,
|
||||
linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
|
||||
=============== ===============================================
|
||||
board_id: (RO) Manufacturing board id
|
||||
|
||||
config: (RO) Report the configuration for this PF
|
||||
|
||||
qp_per_vf: (RO) Queue pairs per virtual function.
|
||||
|
||||
max_vf: (RO) Max virtual functions
|
||||
|
||||
cq_per_vf: (RO) Completion queue per virtual function
|
||||
|
||||
iface: (RO) Shows which network interface this usNIC
|
||||
entry is associated to (visible with ifconfig).
|
||||
=============== ===============================================
|
||||
|
||||
What: /sys/class/infiniband/usnic_X/qpn/summary
|
||||
What: /sys/class/infiniband/usnic_X/qpn/context
|
||||
Date: Sep, 2013
|
||||
KernelVersion: v3.14
|
||||
Contact: Christian Benvenuti <benve@cisco.com>,
|
||||
Dave Goodell <dgoodell@cisco.com>,
|
||||
linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
[to be documented]
|
||||
|
||||
|
||||
sysfs interface for Emulex RoCE HCA Driver
|
||||
------------------------------------------
|
||||
|
||||
What: /sys/class/infiniband/ocrdmaX/hw_rev
|
||||
Date: Feb, 2014
|
||||
KernelVersion: v3.14
|
||||
Description:
|
||||
hw_rev: (RO) Hardware revision number
|
||||
|
||||
What: /sys/class/infiniband/ocrdmaX/hca_type
|
||||
Date: Jun, 2014
|
||||
KernelVersion: v3.16
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
hca_type: (RO) Display FW version
|
||||
|
||||
|
||||
sysfs interface for Intel Omni-Path driver (HFI1)
|
||||
-------------------------------------------------
|
||||
|
||||
What: /sys/class/infiniband/hfi1_X/hw_rev
|
||||
What: /sys/class/infiniband/hfi1_X/board_id
|
||||
What: /sys/class/infiniband/hfi1_X/nctxts
|
||||
What: /sys/class/infiniband/hfi1_X/serial
|
||||
What: /sys/class/infiniband/hfi1_X/chip_reset
|
||||
What: /sys/class/infiniband/hfi1_X/boardversion
|
||||
What: /sys/class/infiniband/hfi1_X/nfreectxts
|
||||
What: /sys/class/infiniband/hfi1_X/tempsense
|
||||
Date: May, 2016
|
||||
KernelVersion: v4.6
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
=============== =============================================
|
||||
hw_rev: (RO) Hardware revision number
|
||||
|
||||
board_id: (RO) Manufacturing board id
|
||||
|
||||
nctxts: (RO) Total contexts available.
|
||||
|
||||
serial: (RO) Board serial number
|
||||
|
||||
chip_reset: (WO) Write "reset" to this file to reset the
|
||||
chip if possible. Only allowed if no user
|
||||
contexts are open that use chip resources.
|
||||
|
||||
boardversion: (RO) Human readable board info
|
||||
|
||||
nfreectxts: (RO) The number of free user ports (contexts)
|
||||
available.
|
||||
|
||||
tempsense: (RO) Thermal sense information
|
||||
=============== =============================================
|
||||
|
||||
|
||||
What: /sys/class/infiniband/hfi1_X/ports/<N>/CCMgtA/cc_settings_bin
|
||||
What: /sys/class/infiniband/hfi1_X/ports/<N>/CCMgtA/cc_table_bin
|
||||
What: /sys/class/infiniband/hfi1_X/ports/<N>/CCMgtA/cc_prescan
|
||||
Date: May, 2016
|
||||
KernelVersion: v4.6
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
Per-port congestion control.
|
||||
|
||||
=============== ================================================
|
||||
cc_table_bin (RO) CCA tables used by PSM2 Congestion control
|
||||
table size followed by table entries. Binary
|
||||
attribute.
|
||||
|
||||
cc_settings_bin (RO) Congestion settings: port control, control
|
||||
map and an array of 16 entries for the
|
||||
congestion entries - increase, timer, event log
|
||||
trigger threshold and the minimum injection rate
|
||||
delay. Binary attribute.
|
||||
|
||||
cc_prescan (RW) enable prescanning for faster BECN
|
||||
response. Write "on" to enable and "off" to
|
||||
disable.
|
||||
=============== ================================================
|
||||
|
||||
What: /sys/class/infiniband/hfi1_X/ports/<N>/sc2vl/[0-31]
|
||||
What: /sys/class/infiniband/hfi1_X/ports/<N>/sl2sc/[0-31]
|
||||
What: /sys/class/infiniband/hfi1_X/ports/<N>/vl2mtu/[0-15]
|
||||
Date: May, 2016
|
||||
KernelVersion: v4.6
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
=============== ===================================================
|
||||
sc2vl/: (RO) 32 files (0 - 31) used to translate sl->vl
|
||||
|
||||
sl2sc/: (RO) 32 files (0 - 31) used to translate sl->sc
|
||||
|
||||
vl2mtu/: (RO) 16 files (0 - 15) used to determine MTU for vl
|
||||
=============== ===================================================
|
||||
|
||||
|
||||
What: /sys/class/infiniband/hfi1_X/sdma_<N>/cpu_list
|
||||
What: /sys/class/infiniband/hfi1_X/sdma_<N>/vl
|
||||
Date: Sept, 2016
|
||||
KernelVersion: v4.8
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
sdma<N>/ contains one directory per sdma engine (0 - 15)
|
||||
|
||||
=============== ==============================================
|
||||
cpu_list: (RW) List of cpus for user-process to sdma
|
||||
engine assignment.
|
||||
|
||||
vl: (RO) Displays the virtual lane (vl) the sdma
|
||||
engine maps to.
|
||||
=============== ==============================================
|
||||
|
||||
This interface gives the user control on the affinity settings
|
||||
for the device. As an example, to set an sdma engine irq
|
||||
affinity and thread affinity of a user processes to use the
|
||||
sdma engine, which is "near" in terms of NUMA configuration, or
|
||||
physical cpu location, the user will do::
|
||||
|
||||
echo "3" > /proc/irq/<N>/smp_affinity_list
|
||||
echo "4-7" > /sys/devices/.../sdma3/cpu_list
|
||||
cat /sys/devices/.../sdma3/vl
|
||||
0
|
||||
echo "8" > /proc/irq/<M>/smp_affinity_list
|
||||
echo "9-12" > /sys/devices/.../sdma4/cpu_list
|
||||
cat /sys/devices/.../sdma4/vl
|
||||
1
|
||||
|
||||
to make sure that when a process runs on cpus 4,5,6, or 7, and
|
||||
uses vl=0, then sdma engine 3 is selected by the driver, and
|
||||
also the interrupt of the sdma engine 3 is steered to cpu 3.
|
||||
Similarly, when a process runs on cpus 9,10,11, or 12 and sets
|
||||
vl=1, then engine 4 will be selected and the irq of the sdma
|
||||
engine 4 is steered to cpu 8. This assumes that in the above N
|
||||
is the irq number of "sdma3", and M is irq number of "sdma4" in
|
||||
the /proc/interrupts file.
|
||||
|
||||
sysfs interface for QLogic qedr NIC Driver
|
||||
------------------------------------------
|
||||
|
||||
What: /sys/class/infiniband/qedrX/hw_rev
|
||||
What: /sys/class/infiniband/qedrX/hca_type
|
||||
Date: Oct, 2016
|
||||
KernelVersion: v4.10
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
|
||||
=============== ==== ========================
|
||||
hw_rev: (RO) Hardware revision number
|
||||
|
||||
hca_type: (RO) Display HCA type
|
||||
=============== ==== ========================
|
||||
|
||||
|
||||
sysfs interface for VMware Paravirtual RDMA driver
|
||||
--------------------------------------------------
|
||||
|
||||
What: /sys/class/infiniband/vmw_pvrdmaX/hw_rev
|
||||
What: /sys/class/infiniband/vmw_pvrdmaX/hca_type
|
||||
What: /sys/class/infiniband/vmw_pvrdmaX/board_id
|
||||
Date: Oct, 2016
|
||||
KernelVersion: v4.10
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
|
||||
=============== ==== =====================================
|
||||
hw_rev: (RO) Hardware revision number
|
||||
|
||||
hca_type: (RO) Host channel adapter type
|
||||
|
||||
board_id: (RO) Display PVRDMA manufacturing board ID
|
||||
=============== ==== =====================================
|
||||
|
||||
|
||||
sysfs interface for Broadcom NetXtreme-E RoCE driver
|
||||
----------------------------------------------------
|
||||
|
||||
What: /sys/class/infiniband/bnxt_reX/hw_rev
|
||||
What: /sys/class/infiniband/bnxt_reX/hca_type
|
||||
Date: Feb, 2017
|
||||
KernelVersion: v4.11
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description:
|
||||
=============== ==== =========================
|
||||
hw_rev: (RO) Hardware revision number
|
||||
|
||||
hca_type: (RO) Host channel adapter type
|
||||
=============== ==== =========================
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
rfkill - radio frequency (RF) connector kill switch support
|
||||
|
||||
For details to this subsystem look at Documentation/driver-api/rfkill.rst.
|
||||
|
||||
For the deprecated ``/sys/class/rfkill/*/claim`` knobs of this interface look in
|
||||
Documentation/ABI/removed/sysfs-class-rfkill.
|
||||
|
||||
What: /sys/class/rfkill
|
||||
Date: 09-Jul-2007
|
||||
KernelVersion: v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org,
|
||||
Description: The rfkill class subsystem folder.
|
||||
Each registered rfkill driver is represented by an rfkillX
|
||||
subfolder (X being an integer >= 0).
|
||||
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/name
|
||||
Date: 09-Jul-2007
|
||||
KernelVersion v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: Name assigned by driver to this key (interface or driver name).
|
||||
Values: arbitrary string.
|
||||
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/type
|
||||
Date: 09-Jul-2007
|
||||
KernelVersion v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: Driver type string ("wlan", "bluetooth", etc).
|
||||
Values: See include/linux/rfkill.h.
|
||||
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/persistent
|
||||
Date: 09-Jul-2007
|
||||
KernelVersion v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: Whether the soft blocked state is initialised from non-volatile
|
||||
storage at startup.
|
||||
Values: A numeric value:
|
||||
|
||||
- 0: false
|
||||
- 1: true
|
||||
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/state
|
||||
Date: 09-Jul-2007
|
||||
KernelVersion v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: Current state of the transmitter.
|
||||
This file was scheduled to be removed in 2014, but due to its
|
||||
large number of users it will be sticking around for a bit
|
||||
longer. Despite it being marked as stable, the newer "hard" and
|
||||
"soft" interfaces should be preferred, since it is not possible
|
||||
to express the 'soft and hard block' state of the rfkill driver
|
||||
through this interface. There will likely be another attempt to
|
||||
remove it in the future.
|
||||
Values: A numeric value.
|
||||
|
||||
0: RFKILL_STATE_SOFT_BLOCKED
|
||||
transmitter is turned off by software
|
||||
1: RFKILL_STATE_UNBLOCKED
|
||||
transmitter is (potentially) active
|
||||
2: RFKILL_STATE_HARD_BLOCKED
|
||||
transmitter is forced off by something outside of
|
||||
the driver's control.
|
||||
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/hard
|
||||
Date: 12-March-2010
|
||||
KernelVersion v2.6.34
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: Current hardblock state. This file is read only.
|
||||
Values: A numeric value.
|
||||
|
||||
0: inactive
|
||||
The transmitter is (potentially) active.
|
||||
1: active
|
||||
The transmitter is forced off by something outside of
|
||||
the driver's control.
|
||||
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/soft
|
||||
Date: 12-March-2010
|
||||
KernelVersion v2.6.34
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: Current softblock state. This file is read and write.
|
||||
Values: A numeric value.
|
||||
|
||||
0: inactive
|
||||
The transmitter is (potentially) active.
|
||||
|
||||
1: active
|
||||
The transmitter is turned off by software.
|
||||
|
|
@ -0,0 +1,210 @@
|
|||
What: /sys/class/tpm/tpmX/device/
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: The device/ directory under a specific TPM instance exposes
|
||||
the properties of that TPM chip
|
||||
|
||||
|
||||
What: /sys/class/tpm/tpmX/device/active
|
||||
Date: April 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: The "active" property prints a '1' if the TPM chip is accepting
|
||||
commands. An inactive TPM chip still contains all the state of
|
||||
an active chip (Storage Root Key, NVRAM, etc), and can be
|
||||
visible to the OS, but will only accept a restricted set of
|
||||
commands. See the TPM Main Specification part 2, Structures,
|
||||
section 17 for more information on which commands are
|
||||
available.
|
||||
|
||||
What: /sys/class/tpm/tpmX/device/cancel
|
||||
Date: June 2005
|
||||
KernelVersion: 2.6.13
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: The "cancel" property allows you to cancel the currently
|
||||
pending TPM command. Writing any value to cancel will call the
|
||||
TPM vendor specific cancel operation.
|
||||
|
||||
What: /sys/class/tpm/tpmX/device/caps
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: The "caps" property contains TPM manufacturer and version info.
|
||||
|
||||
Example output::
|
||||
|
||||
Manufacturer: 0x53544d20
|
||||
TCG version: 1.2
|
||||
Firmware version: 8.16
|
||||
|
||||
Manufacturer is a hex dump of the 4 byte manufacturer info
|
||||
space in a TPM. TCG version shows the TCG TPM spec level that
|
||||
the chip supports. Firmware version is that of the chip and
|
||||
is manufacturer specific.
|
||||
|
||||
What: /sys/class/tpm/tpmX/device/durations
|
||||
Date: March 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: The "durations" property shows the 3 vendor-specific values
|
||||
used to wait for a short, medium and long TPM command. All
|
||||
TPM commands are categorized as short, medium or long in
|
||||
execution time, so that the driver doesn't have to wait
|
||||
any longer than necessary before starting to poll for a
|
||||
result.
|
||||
|
||||
Example output::
|
||||
|
||||
3015000 4508000 180995000 [original]
|
||||
|
||||
Here the short, medium and long durations are displayed in
|
||||
usecs. "[original]" indicates that the values are displayed
|
||||
unmodified from when they were queried from the chip.
|
||||
Durations can be modified in the case where a buggy chip
|
||||
reports them in msec instead of usec and they need to be
|
||||
scaled to be displayed in usecs. In this case "[adjusted]"
|
||||
will be displayed in place of "[original]".
|
||||
|
||||
What: /sys/class/tpm/tpmX/device/enabled
|
||||
Date: April 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: The "enabled" property prints a '1' if the TPM chip is enabled,
|
||||
meaning that it should be visible to the OS. This property
|
||||
may be visible but produce a '0' after some operation that
|
||||
disables the TPM.
|
||||
|
||||
What: /sys/class/tpm/tpmX/device/owned
|
||||
Date: April 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: The "owned" property produces a '1' if the TPM_TakeOwnership
|
||||
ordinal has been executed successfully in the chip. A '0'
|
||||
indicates that ownership hasn't been taken.
|
||||
|
||||
What: /sys/class/tpm/tpmX/device/pcrs
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: The "pcrs" property will dump the current value of all Platform
|
||||
Configuration Registers in the TPM. Note that since these
|
||||
values may be constantly changing, the output is only valid
|
||||
for a snapshot in time.
|
||||
|
||||
Example output::
|
||||
|
||||
PCR-00: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
|
||||
PCR-01: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
|
||||
PCR-02: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
|
||||
PCR-03: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
|
||||
PCR-04: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
|
||||
...
|
||||
|
||||
The number of PCRs and hex bytes needed to represent a PCR
|
||||
value will vary depending on TPM chip version. For TPM 1.1 and
|
||||
1.2 chips, PCRs represent SHA-1 hashes, which are 20 bytes
|
||||
long. Use the "caps" property to determine TPM version.
|
||||
|
||||
What: /sys/class/tpm/tpmX/device/pubek
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: The "pubek" property will return the TPM's public endorsement
|
||||
key if possible. If the TPM has had ownership established and
|
||||
is version 1.2, the pubek will not be available without the
|
||||
owner's authorization. Since the TPM driver doesn't store any
|
||||
secrets, it can't authorize its own request for the pubek,
|
||||
making it unaccessible. The public endorsement key is gener-
|
||||
ated at TPM manufacture time and exists for the life of the
|
||||
chip.
|
||||
|
||||
Example output::
|
||||
|
||||
Algorithm: 00 00 00 01
|
||||
Encscheme: 00 03
|
||||
Sigscheme: 00 01
|
||||
Parameters: 00 00 08 00 00 00 00 02 00 00 00 00
|
||||
Modulus length: 256
|
||||
Modulus:
|
||||
B4 76 41 82 C9 20 2C 10 18 40 BC 8B E5 44 4C 6C
|
||||
3A B2 92 0C A4 9B 2A 83 EB 5C 12 85 04 48 A0 B6
|
||||
1E E4 81 84 CE B2 F2 45 1C F0 85 99 61 02 4D EB
|
||||
86 C4 F7 F3 29 60 52 93 6B B2 E5 AB 8B A9 09 E3
|
||||
D7 0E 7D CA 41 BF 43 07 65 86 3C 8C 13 7A D0 8B
|
||||
82 5E 96 0B F8 1F 5F 34 06 DA A2 52 C1 A9 D5 26
|
||||
0F F4 04 4B D9 3F 2D F2 AC 2F 74 64 1F 8B CD 3E
|
||||
1E 30 38 6C 70 63 69 AB E2 50 DF 49 05 2E E1 8D
|
||||
6F 78 44 DA 57 43 69 EE 76 6C 38 8A E9 8E A3 F0
|
||||
A7 1F 3C A8 D0 12 15 3E CA 0E BD FA 24 CD 33 C6
|
||||
47 AE A4 18 83 8E 22 39 75 93 86 E6 FD 66 48 B6
|
||||
10 AD 94 14 65 F9 6A 17 78 BD 16 53 84 30 BF 70
|
||||
E0 DC 65 FD 3C C6 B0 1E BF B9 C1 B5 6C EF B1 3A
|
||||
F8 28 05 83 62 26 11 DC B4 6B 5A 97 FF 32 26 B6
|
||||
F7 02 71 CF 15 AE 16 DD D1 C1 8E A8 CF 9B 50 7B
|
||||
C3 91 FF 44 1E CF 7C 39 FE 17 77 21 20 BD CE 9B
|
||||
|
||||
Possible values::
|
||||
|
||||
Algorithm: TPM_ALG_RSA (1)
|
||||
Encscheme: TPM_ES_RSAESPKCSv15 (2)
|
||||
TPM_ES_RSAESOAEP_SHA1_MGF1 (3)
|
||||
Sigscheme: TPM_SS_NONE (1)
|
||||
Parameters, a byte string of 3 u32 values:
|
||||
Key Length (bits): 00 00 08 00 (2048)
|
||||
Num primes: 00 00 00 02 (2)
|
||||
Exponent Size: 00 00 00 00 (0 means the
|
||||
default exp)
|
||||
Modulus Length: 256 (bytes)
|
||||
Modulus: The 256 byte Endorsement Key modulus
|
||||
|
||||
What: /sys/class/tpm/tpmX/device/temp_deactivated
|
||||
Date: April 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: The "temp_deactivated" property returns a '1' if the chip has
|
||||
been temporarily deactivated, usually until the next power
|
||||
cycle. Whether a warm boot (reboot) will clear a TPM chip
|
||||
from a temp_deactivated state is platform specific.
|
||||
|
||||
What: /sys/class/tpm/tpmX/device/timeouts
|
||||
Date: March 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: The "timeouts" property shows the 4 vendor-specific values
|
||||
for the TPM's interface spec timeouts. The use of these
|
||||
timeouts is defined by the TPM interface spec that the chip
|
||||
conforms to.
|
||||
|
||||
Example output::
|
||||
|
||||
750000 750000 750000 750000 [original]
|
||||
|
||||
The four timeout values are shown in usecs, with a trailing
|
||||
"[original]" or "[adjusted]" depending on whether the values
|
||||
were scaled by the driver to be reported in usec from msecs.
|
||||
|
||||
What: /sys/class/tpm/tpmX/tpm_version_major
|
||||
Date: October 2019
|
||||
KernelVersion: 5.5
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: The "tpm_version_major" property shows the TCG spec major version
|
||||
implemented by the TPM device.
|
||||
|
||||
Example output::
|
||||
|
||||
2
|
||||
|
||||
What: /sys/class/tpm/tpmX/pcr-<H>/<N>
|
||||
Date: March 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: linux-integrity@vger.kernel.org
|
||||
Description: produces output in compact hex representation for PCR
|
||||
number N from hash bank H. N is the numeric value of
|
||||
the PCR number and H is the crypto string
|
||||
representation of the hash
|
||||
|
||||
Example output::
|
||||
|
||||
cat /sys/class/tpm/tpm0/pcr-sha256/7
|
||||
2ED93F199692DC6788EFA6A1FE74514AB9760B2A6CEEAEF6C808C13E4ABB0D42
|
||||
|
|
@ -0,0 +1,221 @@
|
|||
What: /sys/class/ubi/
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
The ubi/ class sub-directory belongs to the UBI subsystem and
|
||||
provides general UBI information, per-UBI device information
|
||||
and per-UBI volume information.
|
||||
|
||||
What: /sys/class/ubi/version
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
This file contains version of the latest supported UBI on-media
|
||||
format. Currently it is 1, and there is no plan to change this.
|
||||
However, if in the future UBI needs on-flash format changes
|
||||
which cannot be done in a compatible manner, a new format
|
||||
version will be added. So this is a mechanism for possible
|
||||
future backward-compatible (but forward-incompatible)
|
||||
improvements.
|
||||
|
||||
What: /sys/class/ubiX/
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
The /sys/class/ubi0, /sys/class/ubi1, etc directories describe
|
||||
UBI devices (UBI device 0, 1, etc). They contain general UBI
|
||||
device information and per UBI volume information (each UBI
|
||||
device may have many UBI volumes)
|
||||
|
||||
What: /sys/class/ubi/ubiX/avail_eraseblocks
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Amount of available logical eraseblock. For example, one may
|
||||
create a new UBI volume which has this amount of logical
|
||||
eraseblocks.
|
||||
|
||||
What: /sys/class/ubi/ubiX/bad_peb_count
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Count of bad physical eraseblocks on the underlying MTD device.
|
||||
|
||||
What: /sys/class/ubi/ubiX/bgt_enabled
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Contains ASCII "0\n" if the UBI background thread is disabled,
|
||||
and ASCII "1\n" if it is enabled.
|
||||
|
||||
What: /sys/class/ubi/ubiX/dev
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Major and minor numbers of the character device corresponding
|
||||
to this UBI device (in <major>:<minor> format).
|
||||
|
||||
What: /sys/class/ubi/ubiX/eraseblock_size
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Maximum logical eraseblock size this UBI device may provide. UBI
|
||||
volumes may have smaller logical eraseblock size because of their
|
||||
alignment.
|
||||
|
||||
What: /sys/class/ubi/ubiX/max_ec
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Maximum physical eraseblock erase counter value.
|
||||
|
||||
What: /sys/class/ubi/ubiX/max_vol_count
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Maximum number of volumes which this UBI device may have.
|
||||
|
||||
What: /sys/class/ubi/ubiX/min_io_size
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Minimum input/output unit size. All the I/O may only be done
|
||||
in fractions of the contained number.
|
||||
|
||||
What: /sys/class/ubi/ubiX/mtd_num
|
||||
Date: January 2008
|
||||
KernelVersion: 2.6.25
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Number of the underlying MTD device.
|
||||
|
||||
What: /sys/class/ubi/ubiX/reserved_for_bad
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Number of physical eraseblocks reserved for bad block handling.
|
||||
|
||||
What: /sys/class/ubi/ubiX/ro_mode
|
||||
Date: April 2016
|
||||
KernelVersion: 4.7
|
||||
Contact: linux-mtd@lists.infradead.org
|
||||
Description:
|
||||
Contains ASCII "1\n" if the read-only flag is set on this
|
||||
device, and "0\n" if it is cleared. UBI devices mark themselves
|
||||
as read-only when they detect an unrecoverable error.
|
||||
|
||||
What: /sys/class/ubi/ubiX/total_eraseblocks
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Total number of good (not marked as bad) physical eraseblocks on
|
||||
the underlying MTD device.
|
||||
|
||||
What: /sys/class/ubi/ubiX/volumes_count
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Count of volumes on this UBI device.
|
||||
|
||||
What: /sys/class/ubi/ubiX/ubiX_Y/
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
The /sys/class/ubi/ubiX/ubiX_0/, /sys/class/ubi/ubiX/ubiX_1/,
|
||||
etc directories describe UBI volumes on UBI device X (volumes
|
||||
0, 1, etc).
|
||||
|
||||
What: /sys/class/ubi/ubiX/ubiX_Y/alignment
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Volume alignment - the value the logical eraseblock size of
|
||||
this volume has to be aligned on. For example, 2048 means that
|
||||
logical eraseblock size is multiple of 2048. In other words,
|
||||
volume logical eraseblock size is UBI device logical eraseblock
|
||||
size aligned to the alignment value.
|
||||
|
||||
What: /sys/class/ubi/ubiX/ubiX_Y/corrupted
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Contains ASCII "0\n" if the UBI volume is OK, and ASCII "1\n"
|
||||
if it is corrupted (e.g., due to an interrupted volume update).
|
||||
|
||||
What: /sys/class/ubi/ubiX/ubiX_Y/data_bytes
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
The amount of data this volume contains. This value makes sense
|
||||
only for static volumes, and for dynamic volume it equivalent
|
||||
to the total volume size in bytes.
|
||||
|
||||
What: /sys/class/ubi/ubiX/ubiX_Y/dev
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Major and minor numbers of the character device corresponding
|
||||
to this UBI volume (in <major>:<minor> format).
|
||||
|
||||
What: /sys/class/ubi/ubiX/ubiX_Y/name
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Volume name.
|
||||
|
||||
What: /sys/class/ubi/ubiX/ubiX_Y/reserved_ebs
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Count of physical eraseblock reserved for this volume.
|
||||
Equivalent to the volume size in logical eraseblocks.
|
||||
|
||||
What: /sys/class/ubi/ubiX/ubiX_Y/type
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Volume type. Contains ASCII "dynamic\n" for dynamic volumes and
|
||||
"static\n" for static volumes.
|
||||
|
||||
What: /sys/class/ubi/ubiX/ubiX_Y/upd_marker
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Contains ASCII "0\n" if the update marker is not set for this
|
||||
volume, and "1\n" if it is set. The update marker is set when
|
||||
volume update starts, and cleaned when it ends. So the presence
|
||||
of the update marker indicates that the volume is being updated
|
||||
at the moment of the update was interrupted. The later may be
|
||||
checked using the "corrupted" sysfs file.
|
||||
|
||||
What: /sys/class/ubi/ubiX/ubiX_Y/usable_eb_size
|
||||
Date: July 2006
|
||||
KernelVersion: 2.6.22
|
||||
Contact: Artem Bityutskiy <dedekind@infradead.org>
|
||||
Description:
|
||||
Logical eraseblock size of this volume. Equivalent to logical
|
||||
eraseblock size of the device aligned on the volume alignment
|
||||
value.
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
What: /sys/class/udc/<udc>/a_alt_hnp_support
|
||||
Date: June 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: Felipe Balbi <balbi@kernel.org>
|
||||
Description:
|
||||
Indicates if an OTG A-Host supports HNP at an alternate port.
|
||||
Users:
|
||||
|
||||
What: /sys/class/udc/<udc>/a_hnp_support
|
||||
Date: June 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: Felipe Balbi <balbi@kernel.org>
|
||||
Description:
|
||||
Indicates if an OTG A-Host supports HNP at this port.
|
||||
Users:
|
||||
|
||||
What: /sys/class/udc/<udc>/b_hnp_enable
|
||||
Date: June 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: Felipe Balbi <balbi@kernel.org>
|
||||
Description:
|
||||
Indicates if an OTG A-Host enabled HNP support.
|
||||
Users:
|
||||
|
||||
What: /sys/class/udc/<udc>/current_speed
|
||||
Date: June 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: Felipe Balbi <balbi@kernel.org>
|
||||
Description:
|
||||
Indicates the current negotiated speed at this port.
|
||||
Users:
|
||||
|
||||
What: /sys/class/udc/<udc>/is_a_peripheral
|
||||
Date: June 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: Felipe Balbi <balbi@kernel.org>
|
||||
Description:
|
||||
Indicates that this port is the default Host on an OTG session
|
||||
but HNP was used to switch roles.
|
||||
Users:
|
||||
|
||||
What: /sys/class/udc/<udc>/is_otg
|
||||
Date: June 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: Felipe Balbi <balbi@kernel.org>
|
||||
Description:
|
||||
Indicates that this port support OTG.
|
||||
Users:
|
||||
|
||||
What: /sys/class/udc/<udc>/maximum_speed
|
||||
Date: June 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: Felipe Balbi <balbi@kernel.org>
|
||||
Description:
|
||||
Indicates the maximum USB speed supported by this port.
|
||||
Users:
|
||||
|
||||
What: /sys/class/udc/<udc>/soft_connect
|
||||
Date: June 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: Felipe Balbi <balbi@kernel.org>
|
||||
Description:
|
||||
Allows users to disconnect data pullup resistors thus causing a
|
||||
logical disconnection from the USB Host.
|
||||
Users:
|
||||
|
||||
What: /sys/class/udc/<udc>/srp
|
||||
Date: June 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: Felipe Balbi <balbi@kernel.org>
|
||||
Description:
|
||||
Allows users to manually start Session Request Protocol.
|
||||
Users:
|
||||
|
||||
What: /sys/class/udc/<udc>/state
|
||||
Date: June 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: Felipe Balbi <balbi@kernel.org>
|
||||
Description:
|
||||
Indicates current state of the USB Device Controller. Valid
|
||||
states are: 'not-attached', 'attached', 'powered',
|
||||
'reconnecting', 'unauthenticated', 'default', 'addressed',
|
||||
'configured', and 'suspended'; however not all USB Device
|
||||
Controllers support reporting all states.
|
||||
Users:
|
||||
|
||||
What: /sys/class/udc/<udc>/function
|
||||
Date: June 2017
|
||||
KernelVersion: 4.13
|
||||
Contact: Felipe Balbi <balbi@kernel.org>
|
||||
Description:
|
||||
Prints out name of currently running USB Gadget Driver.
|
||||
Users:
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
Note:
|
||||
This documents additional properties of any device beyond what
|
||||
is documented in Documentation/admin-guide/sysfs-rules.rst
|
||||
|
||||
What: /sys/devices/*/of_node
|
||||
Date: February 2015
|
||||
Contact: Device Tree mailing list <devicetree@vger.kernel.org>
|
||||
Description:
|
||||
Any device associated with a device-tree node will have
|
||||
an of_path symlink pointing to the corresponding device
|
||||
node in /sys/firmware/devicetree/
|
||||
|
||||
What: /sys/devices/*/devspec
|
||||
Date: October 2016
|
||||
Contact: Device Tree mailing list <devicetree@vger.kernel.org>
|
||||
Description:
|
||||
If CONFIG_OF is enabled, then this file is present. When
|
||||
read, it returns full name of the device node.
|
||||
|
||||
What: /sys/devices/*/obppath
|
||||
Date: October 2016
|
||||
Contact: Device Tree mailing list <devicetree@vger.kernel.org>
|
||||
Description:
|
||||
If CONFIG_OF is enabled, then this file is present. When
|
||||
read, it returns full name of the device node.
|
||||
|
||||
What: /sys/devices/*/dev
|
||||
Date: Jun 2006
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
Major and minor numbers of the character device corresponding
|
||||
to the device (in <major>:<minor> format).
|
||||
|
|
@ -0,0 +1,223 @@
|
|||
What: /sys/devices/system/node/possible
|
||||
Date: October 2002
|
||||
Contact: Linux Memory Management list <linux-mm@kvack.org>
|
||||
Description:
|
||||
Nodes that could be possibly become online at some point.
|
||||
|
||||
What: /sys/devices/system/node/online
|
||||
Date: October 2002
|
||||
Contact: Linux Memory Management list <linux-mm@kvack.org>
|
||||
Description:
|
||||
Nodes that are online.
|
||||
|
||||
What: /sys/devices/system/node/has_normal_memory
|
||||
Date: October 2002
|
||||
Contact: Linux Memory Management list <linux-mm@kvack.org>
|
||||
Description:
|
||||
Nodes that have regular memory.
|
||||
|
||||
What: /sys/devices/system/node/has_cpu
|
||||
Date: October 2002
|
||||
Contact: Linux Memory Management list <linux-mm@kvack.org>
|
||||
Description:
|
||||
Nodes that have one or more CPUs.
|
||||
|
||||
What: /sys/devices/system/node/has_high_memory
|
||||
Date: October 2002
|
||||
Contact: Linux Memory Management list <linux-mm@kvack.org>
|
||||
Description:
|
||||
Nodes that have regular or high memory.
|
||||
Depends on CONFIG_HIGHMEM.
|
||||
|
||||
What: /sys/devices/system/node/nodeX
|
||||
Date: October 2002
|
||||
Contact: Linux Memory Management list <linux-mm@kvack.org>
|
||||
Description:
|
||||
When CONFIG_NUMA is enabled, this is a directory containing
|
||||
information on node X such as what CPUs are local to the
|
||||
node. Each file is detailed next.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/cpumap
|
||||
Date: October 2002
|
||||
Contact: Linux Memory Management list <linux-mm@kvack.org>
|
||||
Description:
|
||||
The node's cpumap.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/cpulist
|
||||
Date: October 2002
|
||||
Contact: Linux Memory Management list <linux-mm@kvack.org>
|
||||
Description:
|
||||
The CPUs associated to the node.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/meminfo
|
||||
Date: October 2002
|
||||
Contact: Linux Memory Management list <linux-mm@kvack.org>
|
||||
Description:
|
||||
Provides information about the node's distribution and memory
|
||||
utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.rst
|
||||
|
||||
What: /sys/devices/system/node/nodeX/numastat
|
||||
Date: October 2002
|
||||
Contact: Linux Memory Management list <linux-mm@kvack.org>
|
||||
Description:
|
||||
The node's hit/miss statistics, in units of pages.
|
||||
See Documentation/admin-guide/numastat.rst
|
||||
|
||||
What: /sys/devices/system/node/nodeX/distance
|
||||
Date: October 2002
|
||||
Contact: Linux Memory Management list <linux-mm@kvack.org>
|
||||
Description:
|
||||
Distance between the node and all the other nodes
|
||||
in the system.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/vmstat
|
||||
Date: October 2002
|
||||
Contact: Linux Memory Management list <linux-mm@kvack.org>
|
||||
Description:
|
||||
The node's zoned virtual memory statistics.
|
||||
This is a superset of numastat.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/compact
|
||||
Date: February 2010
|
||||
Contact: Mel Gorman <mel@csn.ul.ie>
|
||||
Description:
|
||||
When this file is written to, all memory within that node
|
||||
will be compacted. When it completes, memory will be freed
|
||||
into blocks which have as many contiguous pages as possible
|
||||
|
||||
What: /sys/devices/system/node/nodeX/hugepages/hugepages-<size>/
|
||||
Date: December 2009
|
||||
Contact: Lee Schermerhorn <lee.schermerhorn@hp.com>
|
||||
Description:
|
||||
The node's huge page size control/query attributes.
|
||||
See Documentation/admin-guide/mm/hugetlbpage.rst
|
||||
|
||||
What: /sys/devices/system/node/nodeX/accessY/
|
||||
Date: December 2018
|
||||
Contact: Keith Busch <keith.busch@intel.com>
|
||||
Description:
|
||||
The node's relationship to other nodes for access class "Y".
|
||||
|
||||
What: /sys/devices/system/node/nodeX/accessY/initiators/
|
||||
Date: December 2018
|
||||
Contact: Keith Busch <keith.busch@intel.com>
|
||||
Description:
|
||||
The directory containing symlinks to memory initiator
|
||||
nodes that have class "Y" access to this target node's
|
||||
memory. CPUs and other memory initiators in nodes not in
|
||||
the list accessing this node's memory may have different
|
||||
performance.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/accessY/targets/
|
||||
Date: December 2018
|
||||
Contact: Keith Busch <keith.busch@intel.com>
|
||||
Description:
|
||||
The directory containing symlinks to memory targets that
|
||||
this initiator node has class "Y" access.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/accessY/initiators/read_bandwidth
|
||||
Date: December 2018
|
||||
Contact: Keith Busch <keith.busch@intel.com>
|
||||
Description:
|
||||
This node's read bandwidth in MB/s when accessed from
|
||||
nodes found in this access class's linked initiators.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/accessY/initiators/read_latency
|
||||
Date: December 2018
|
||||
Contact: Keith Busch <keith.busch@intel.com>
|
||||
Description:
|
||||
This node's read latency in nanoseconds when accessed
|
||||
from nodes found in this access class's linked initiators.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/accessY/initiators/write_bandwidth
|
||||
Date: December 2018
|
||||
Contact: Keith Busch <keith.busch@intel.com>
|
||||
Description:
|
||||
This node's write bandwidth in MB/s when accessed from
|
||||
found in this access class's linked initiators.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/accessY/initiators/write_latency
|
||||
Date: December 2018
|
||||
Contact: Keith Busch <keith.busch@intel.com>
|
||||
Description:
|
||||
This node's write latency in nanoseconds when access
|
||||
from nodes found in this class's linked initiators.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/memory_side_cache/indexY/
|
||||
Date: December 2018
|
||||
Contact: Keith Busch <keith.busch@intel.com>
|
||||
Description:
|
||||
The directory containing attributes for the memory-side cache
|
||||
level 'Y'.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/memory_side_cache/indexY/indexing
|
||||
Date: December 2018
|
||||
Contact: Keith Busch <keith.busch@intel.com>
|
||||
Description:
|
||||
The caches associativity indexing: 0 for direct mapped,
|
||||
non-zero if indexed.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/memory_side_cache/indexY/line_size
|
||||
Date: December 2018
|
||||
Contact: Keith Busch <keith.busch@intel.com>
|
||||
Description:
|
||||
The number of bytes accessed from the next cache level on a
|
||||
cache miss.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/memory_side_cache/indexY/size
|
||||
Date: December 2018
|
||||
Contact: Keith Busch <keith.busch@intel.com>
|
||||
Description:
|
||||
The size of this memory side cache in bytes.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/memory_side_cache/indexY/write_policy
|
||||
Date: December 2018
|
||||
Contact: Keith Busch <keith.busch@intel.com>
|
||||
Description:
|
||||
The cache write policy: 0 for write-back, 1 for write-through,
|
||||
other or unknown.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/x86/sgx_total_bytes
|
||||
Date: November 2021
|
||||
Contact: Jarkko Sakkinen <jarkko@kernel.org>
|
||||
Description:
|
||||
The total amount of SGX physical memory in bytes.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/memory_failure/total
|
||||
Date: January 2023
|
||||
Contact: Jiaqi Yan <jiaqiyan@google.com>
|
||||
Description:
|
||||
The total number of raw poisoned pages (pages containing
|
||||
corrupted data due to memory errors) on a NUMA node.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/memory_failure/ignored
|
||||
Date: January 2023
|
||||
Contact: Jiaqi Yan <jiaqiyan@google.com>
|
||||
Description:
|
||||
Of the raw poisoned pages on a NUMA node, how many pages are
|
||||
ignored by memory error recovery attempt, usually because
|
||||
support for this type of pages is unavailable, and kernel
|
||||
gives up the recovery.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/memory_failure/failed
|
||||
Date: January 2023
|
||||
Contact: Jiaqi Yan <jiaqiyan@google.com>
|
||||
Description:
|
||||
Of the raw poisoned pages on a NUMA node, how many pages are
|
||||
failed by memory error recovery attempt. This usually means
|
||||
a key recovery operation failed.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/memory_failure/delayed
|
||||
Date: January 2023
|
||||
Contact: Jiaqi Yan <jiaqiyan@google.com>
|
||||
Description:
|
||||
Of the raw poisoned pages on a NUMA node, how many pages are
|
||||
delayed by memory error recovery attempt. Delayed poisoned
|
||||
pages usually will be retried by kernel.
|
||||
|
||||
What: /sys/devices/system/node/nodeX/memory_failure/recovered
|
||||
Date: January 2023
|
||||
Contact: Jiaqi Yan <jiaqiyan@google.com>
|
||||
Description:
|
||||
Of the raw poisoned pages on a NUMA node, how many pages are
|
||||
recovered by memory error recovery attempt.
|
||||
|
|
@ -0,0 +1,127 @@
|
|||
What: /sys/devices/system/cpu/dscr_default
|
||||
Date: 13-May-2014
|
||||
KernelVersion: v3.15.0
|
||||
Contact:
|
||||
Description: Writes are equivalent to writing to
|
||||
/sys/devices/system/cpu/cpuN/dscr on all CPUs.
|
||||
Reads return the last written value or 0.
|
||||
This value is not a global default: it is a way to set
|
||||
all per-CPU defaults at the same time.
|
||||
Values: 64 bit unsigned integer (bit field)
|
||||
|
||||
What: /sys/devices/system/cpu/cpu[0-9]+/dscr
|
||||
Date: 13-May-2014
|
||||
KernelVersion: v3.15.0
|
||||
Contact:
|
||||
Description: Default value for the Data Stream Control Register (DSCR) on
|
||||
a CPU.
|
||||
This default value is used when the kernel is executing and
|
||||
for any process that has not set the DSCR itself.
|
||||
If a process ever sets the DSCR (via direct access to the
|
||||
SPR) that value will be persisted for that process and used
|
||||
on any CPU where it executes (overriding the value described
|
||||
here).
|
||||
If set by a process it will be inherited by child processes.
|
||||
Values: 64 bit unsigned integer (bit field)
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/physical_package_id
|
||||
Description: physical package id of cpuX. Typically corresponds to a physical
|
||||
socket number, but the actual value is architecture and platform
|
||||
dependent.
|
||||
Values: integer
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/die_id
|
||||
Description: the CPU die ID of cpuX. Typically it is the hardware platform's
|
||||
identifier (rather than the kernel's). The actual value is
|
||||
architecture and platform dependent.
|
||||
Values: integer
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/core_id
|
||||
Description: 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.
|
||||
Values: integer
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/cluster_id
|
||||
Description: the cluster ID of cpuX. Typically it is the hardware platform's
|
||||
identifier (rather than the kernel's). The actual value is
|
||||
architecture and platform dependent.
|
||||
Values: integer
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/book_id
|
||||
Description: the book ID of cpuX. Typically it is the hardware platform's
|
||||
identifier (rather than the kernel's). The actual value is
|
||||
architecture and platform dependent. it's only used on s390.
|
||||
Values: integer
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/drawer_id
|
||||
Description: the drawer ID of cpuX. Typically it is the hardware platform's
|
||||
identifier (rather than the kernel's). The actual value is
|
||||
architecture and platform dependent. it's only used on s390.
|
||||
Values: integer
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/core_cpus
|
||||
Description: internal kernel map of CPUs within the same core.
|
||||
(deprecated name: "thread_siblings")
|
||||
Values: hexadecimal bitmask.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/core_cpus_list
|
||||
Description: human-readable list of CPUs within the same core.
|
||||
The format is like 0-3, 8-11, 14,17.
|
||||
(deprecated name: "thread_siblings_list").
|
||||
Values: decimal list.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/package_cpus
|
||||
Description: internal kernel map of the CPUs sharing the same physical_package_id.
|
||||
(deprecated name: "core_siblings").
|
||||
Values: hexadecimal bitmask.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/package_cpus_list
|
||||
Description: human-readable list of CPUs sharing the same physical_package_id.
|
||||
The format is like 0-3, 8-11, 14,17.
|
||||
(deprecated name: "core_siblings_list")
|
||||
Values: decimal list.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/die_cpus
|
||||
Description: internal kernel map of CPUs within the same die.
|
||||
Values: hexadecimal bitmask.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/ppin
|
||||
Description: per-socket protected processor inventory number
|
||||
Values: hexadecimal.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/die_cpus_list
|
||||
Description: human-readable list of CPUs within the same die.
|
||||
The format is like 0-3, 8-11, 14,17.
|
||||
Values: decimal list.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/cluster_cpus
|
||||
Description: internal kernel map of CPUs within the same cluster.
|
||||
Values: hexadecimal bitmask.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/cluster_cpus_list
|
||||
Description: human-readable list of CPUs within the same cluster.
|
||||
The format is like 0-3, 8-11, 14,17.
|
||||
Values: decimal list.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/book_siblings
|
||||
Description: internal kernel map of cpuX's hardware threads within the same
|
||||
book_id. it's only used on s390.
|
||||
Values: hexadecimal bitmask.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/book_siblings_list
|
||||
Description: human-readable list of cpuX's hardware threads within the same
|
||||
book_id.
|
||||
The format is like 0-3, 8-11, 14,17. it's only used on s390.
|
||||
Values: decimal list.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/drawer_siblings
|
||||
Description: internal kernel map of cpuX's hardware threads within the same
|
||||
drawer_id. it's only used on s390.
|
||||
Values: hexadecimal bitmask.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/topology/drawer_siblings_list
|
||||
Description: human-readable list of cpuX's hardware threads within the same
|
||||
drawer_id.
|
||||
The format is like 0-3, 8-11, 14,17. it's only used on s390.
|
||||
Values: decimal list.
|
||||
|
|
@ -0,0 +1,86 @@
|
|||
What: /sys/devices/system/xen_memory/xen_memory0/max_retry_count
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.39
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The maximum number of times the balloon driver will
|
||||
attempt to increase the balloon before giving up. See
|
||||
also 'retry_count' below.
|
||||
A value of zero means retry forever and is the default one.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/max_schedule_delay
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.39
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The limit that 'schedule_delay' (see below) will be
|
||||
increased to. The default value is 32 seconds.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/retry_count
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.39
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The current number of times that the balloon driver
|
||||
has attempted to increase the size of the balloon.
|
||||
The default value is one. With max_retry_count being
|
||||
zero (unlimited), this means that the driver will attempt
|
||||
to retry with a 'schedule_delay' delay.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/schedule_delay
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.39
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The time (in seconds) to wait between attempts to
|
||||
increase the balloon. Each time the balloon cannot be
|
||||
increased, 'schedule_delay' is increased (until
|
||||
'max_schedule_delay' is reached at which point it
|
||||
will use the max value).
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/target
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
The target number of pages to adjust this domain's
|
||||
memory reservation to.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/target_kb
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
As target above, except the value is in KiB.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/info/current_kb
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Current size (in KiB) of this domain's memory
|
||||
reservation.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/info/high_kb
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Amount (in KiB) of high memory in the balloon.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/info/low_kb
|
||||
Date: April 2008
|
||||
KernelVersion: 2.6.26
|
||||
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Description:
|
||||
Amount (in KiB) of low (or normal) memory in the
|
||||
balloon.
|
||||
|
||||
What: /sys/devices/system/xen_memory/xen_memory0/scrub_pages
|
||||
Date: September 2018
|
||||
KernelVersion: 4.20
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description:
|
||||
Control scrubbing pages before returning them to Xen for others domains
|
||||
use. Can be set with xen_scrub_pages cmdline
|
||||
parameter. Default value controlled with CONFIG_XEN_SCRUB_PAGES_DEFAULT.
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
What: /sys/bus/platform/drivers/aspeed-vuart/*/lpc_address
|
||||
Date: April 2017
|
||||
Contact: Jeremy Kerr <jk@ozlabs.org>
|
||||
Description: Configures which IO port the host side of the UART
|
||||
will appear on the host <-> BMC LPC bus.
|
||||
Users: OpenBMC. Proposed changes should be mailed to
|
||||
openbmc@lists.ozlabs.org
|
||||
|
||||
What: /sys/bus/platform/drivers/aspeed-vuart/*/sirq
|
||||
Date: April 2017
|
||||
Contact: Jeremy Kerr <jk@ozlabs.org>
|
||||
Description: Configures which interrupt number the host side of
|
||||
the UART will appear on the host <-> BMC LPC bus.
|
||||
Users: OpenBMC. Proposed changes should be mailed to
|
||||
openbmc@lists.ozlabs.org
|
||||
|
||||
What: /sys/bus/platform/drivers/aspeed-vuart/*/sirq_polarity
|
||||
Date: July 2019
|
||||
Contact: Oskar Senft <osk@google.com>
|
||||
Description: Configures the polarity of the serial interrupt to the
|
||||
host via the BMC LPC bus.
|
||||
Set to 0 for active-low or 1 for active-high.
|
||||
Users: OpenBMC. Proposed changes should be mailed to
|
||||
openbmc@lists.ozlabs.org
|
||||
|
|
@ -0,0 +1,361 @@
|
|||
What: /sys/bus/dsa/devices/dsa<m>/version
|
||||
Date: Apr 15, 2020
|
||||
KernelVersion: 5.8.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The hardware version number.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/cdev_major
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The major number that the character device driver assigned to
|
||||
this device.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/errors
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The error information for this device.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_batch_size
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The largest number of work descriptors in a batch.
|
||||
It's not visible when the device does not support batch.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_work_queues_size
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The maximum work queue size supported by this device.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_engines
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The maximum number of engines supported by this device.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_groups
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The maximum number of groups can be created under this device.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_read_buffers
|
||||
Date: Dec 10, 2021
|
||||
KernelVersion: 5.17.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The total number of read buffers supported by this device.
|
||||
The read buffers represent resources within the DSA
|
||||
implementation, and these resources are allocated by engines to
|
||||
support operations. See DSA spec v1.2 9.2.4 Total Read Buffers.
|
||||
It's not visible when the device does not support Read Buffer
|
||||
allocation control.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_transfer_size
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The number of bytes to be read from the source address to
|
||||
perform the operation. The maximum transfer size is dependent on
|
||||
the workqueue the descriptor was submitted to.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/max_work_queues
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The maximum work queue number that this device supports.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/numa_node
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The numa node number for this device.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/op_cap
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The operation capability bit mask specify the operation types
|
||||
supported by the this device.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/pasid_enabled
|
||||
Date: Oct 27, 2020
|
||||
KernelVersion: 5.11.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: To indicate if user PASID (process address space identifier) is
|
||||
enabled or not for this device.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/state
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The state information of this device. It can be either enabled
|
||||
or disabled.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/group<m>.<n>
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The assigned group under this device.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/engine<m>.<n>
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The assigned engine under this device.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/wq<m>.<n>
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The assigned work queue under this device.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/configurable
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: To indicate if this device is configurable or not.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/read_buffer_limit
|
||||
Date: Dec 10, 2021
|
||||
KernelVersion: 5.17.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The maximum number of read buffers that may be in use at
|
||||
one time by operations that access low bandwidth memory in the
|
||||
device. See DSA spec v1.2 9.2.8 GENCFG on Global Read Buffer Limit.
|
||||
It's not visible when the device does not support Read Buffer
|
||||
allocation control.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/cmd_status
|
||||
Date: Aug 28, 2020
|
||||
KernelVersion: 5.10.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The last executed device administrative command's status/error.
|
||||
Also last configuration error overloaded.
|
||||
Writing to it will clear the status.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/iaa_cap
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.0.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: IAA (IAX) capability mask. Exported to user space for application
|
||||
consumption. This attribute should only be visible on IAA devices
|
||||
that are version 2 or later.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/event_log_size
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The event log size to be configured. Default is 64 entries and
|
||||
occupies 4k size if the evl entry is 64 bytes. It's visible
|
||||
only on platforms that support the capability.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/block_on_fault
|
||||
Date: Oct 27, 2020
|
||||
KernelVersion: 5.11.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: To indicate block on fault is allowed or not for the work queue
|
||||
to support on demand paging.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/group_id
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The group id that this work queue belongs to.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/size
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The work queue size for this work queue.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/type
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The type of this work queue, it can be "kernel" type for work
|
||||
queue usages in the kernel space or "user" type for work queue
|
||||
usages by applications in user space.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/cdev_minor
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The minor number assigned to this work queue by the character
|
||||
device driver.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/mode
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The work queue mode type for this work queue.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/priority
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The priority value of this work queue, it is a value relative to
|
||||
other work queue in the same group to control quality of service
|
||||
for dispatching work from multiple workqueues in the same group.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/state
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The current state of the work queue.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/threshold
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The number of entries in this work queue that may be filled
|
||||
via a limited portal.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/max_transfer_size
|
||||
Date: Aug 28, 2020
|
||||
KernelVersion: 5.10.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The max transfer sized for this workqueue. Cannot exceed device
|
||||
max transfer size. Configurable parameter.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/max_batch_size
|
||||
Date: Aug 28, 2020
|
||||
KernelVersion: 5.10.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The max batch size for this workqueue. Cannot exceed device
|
||||
max batch size. Configurable parameter.
|
||||
It's not visible when the device does not support batch.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/ats_disable
|
||||
Date: Nov 13, 2020
|
||||
KernelVersion: 5.11.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Indicate whether ATS disable is turned on for the workqueue.
|
||||
0 indicates ATS is on, and 1 indicates ATS is off for the workqueue.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/prs_disable
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Controls whether PRS disable is turned on for the workqueue.
|
||||
0 indicates PRS is on, and 1 indicates PRS is off for the
|
||||
workqueue. This option overrides block_on_fault attribute
|
||||
if set. It's visible only on platforms that support the
|
||||
capability.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/occupancy
|
||||
Date May 25, 2021
|
||||
KernelVersion: 5.14.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Show the current number of entries in this WQ if WQ Occupancy
|
||||
Support bit WQ capabilities is 1.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/enqcmds_retries
|
||||
Date Oct 29, 2021
|
||||
KernelVersion: 5.17.0
|
||||
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/wq<m>.<n>/driver_name
|
||||
Date: Sept 8, 2023
|
||||
KernelVersion: 6.7.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Name of driver to be bounded to the wq.
|
||||
|
||||
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The group that this engine belongs to.
|
||||
|
||||
What: /sys/bus/dsa/devices/group<m>.<n>/use_read_buffer_limit
|
||||
Date: Dec 10, 2021
|
||||
KernelVersion: 5.17.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Enable the use of global read buffer limit for the group. See DSA
|
||||
spec v1.2 9.2.18 GRPCFG Use Global Read Buffer Limit.
|
||||
It's not visible when the device does not support Read Buffer
|
||||
allocation control.
|
||||
|
||||
What: /sys/bus/dsa/devices/group<m>.<n>/read_buffers_allowed
|
||||
Date: Dec 10, 2021
|
||||
KernelVersion: 5.17.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Indicates max number of read buffers that may be in use at one time
|
||||
by all engines in the group. See DSA spec v1.2 9.2.18 GRPCFG Read
|
||||
Buffers Allowed.
|
||||
It's not visible when the device does not support Read Buffer
|
||||
allocation control.
|
||||
|
||||
What: /sys/bus/dsa/devices/group<m>.<n>/read_buffers_reserved
|
||||
Date: Dec 10, 2021
|
||||
KernelVersion: 5.17.0
|
||||
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.
|
||||
It's not visible when the device does not support Read Buffer
|
||||
allocation control.
|
||||
|
||||
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.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/cr_faults
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Show the number of Completion Record (CR) faults this application
|
||||
has caused.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/cr_fault_failures
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Show the number of Completion Record (CR) faults failures that this
|
||||
application has caused. The failure counter is incremented when the
|
||||
driver cannot fault in the address for the CR. Typically this is caused
|
||||
by a bad address programmed in the submitted descriptor or a malicious
|
||||
submitter is using bad CR address on purpose.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/pid
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Show the process id of the application that opened the file. This is
|
||||
helpful information for a monitor daemon that wants to kill the
|
||||
application that opened the file.
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/cap
|
||||
Date: December 3, 2009
|
||||
KernelVersion: 2.6.32
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Capabilities the DMA supports.Currently there are DMA_PQ, DMA_PQ_VAL,
|
||||
DMA_XOR,DMA_XOR_VAL,DMA_INTERRUPT.
|
||||
|
||||
What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/ring_active
|
||||
Date: December 3, 2009
|
||||
KernelVersion: 2.6.32
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The number of descriptors active in the ring.
|
||||
|
||||
What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/ring_size
|
||||
Date: December 3, 2009
|
||||
KernelVersion: 2.6.32
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Descriptor ring size, total number of descriptors available.
|
||||
|
||||
What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/version
|
||||
Date: December 3, 2009
|
||||
KernelVersion: 2.6.32
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Version of ioatdma device.
|
||||
|
||||
What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dma<n>chan<n>/quickdata/intr_coalesce
|
||||
Date: August 8, 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Tune-able interrupt delay value per channel basis.
|
||||
|
|
@ -0,0 +1,256 @@
|
|||
What: /sys/devices/platform/firmware\:zynqmp-firmware/ggs*
|
||||
Date: March 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: "Jolly Shah" <jollys@xilinx.com>
|
||||
Description:
|
||||
Read/Write PMU global general storage register value,
|
||||
GLOBAL_GEN_STORAGE{0:3}.
|
||||
Global general storage register that can be used
|
||||
by system to pass information between masters.
|
||||
|
||||
The register is reset during system or power-on
|
||||
resets. Three registers are used by the FSBL and
|
||||
other Xilinx software products: GLOBAL_GEN_STORAGE{4:6}.
|
||||
|
||||
Usage::
|
||||
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
|
||||
# echo <value> > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
|
||||
|
||||
Example::
|
||||
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
|
||||
# echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
|
||||
|
||||
Users: Xilinx
|
||||
|
||||
What: /sys/devices/platform/firmware\:zynqmp-firmware/pggs*
|
||||
Date: March 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: "Jolly Shah" <jollys@xilinx.com>
|
||||
Description:
|
||||
Read/Write PMU persistent global general storage register
|
||||
value, PERS_GLOB_GEN_STORAGE{0:3}.
|
||||
Persistent global general storage register that
|
||||
can be used by system to pass information between
|
||||
masters.
|
||||
|
||||
This register is only reset by the power-on reset
|
||||
and maintains its value through a system reset.
|
||||
Four registers are used by the FSBL and other Xilinx
|
||||
software products: PERS_GLOB_GEN_STORAGE{4:7}.
|
||||
Register is reset only by a POR reset.
|
||||
|
||||
Usage::
|
||||
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
|
||||
# echo <value> > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
|
||||
|
||||
Example::
|
||||
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
|
||||
# echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0
|
||||
|
||||
Users: Xilinx
|
||||
|
||||
What: /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
|
||||
Date: March 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: "Jolly Shah" <jollys@xilinx.com>
|
||||
Description:
|
||||
This sysfs interface allows to set the shutdown scope for the
|
||||
next shutdown request. When the next shutdown is performed, the
|
||||
platform specific portion of PSCI-system_off can use the chosen
|
||||
shutdown scope.
|
||||
|
||||
Following are available shutdown scopes(subtypes):
|
||||
|
||||
subsystem:
|
||||
Only the APU along with all of its peripherals
|
||||
not used by other processing units will be
|
||||
shut down. This may result in the FPD power
|
||||
domain being shut down provided that no other
|
||||
processing unit uses FPD peripherals or DRAM.
|
||||
ps_only:
|
||||
The complete PS will be shut down, including the
|
||||
RPU, PMU, etc. Only the PL domain (FPGA)
|
||||
remains untouched.
|
||||
system:
|
||||
The complete system/device is shut down.
|
||||
|
||||
Usage::
|
||||
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
|
||||
# echo <scope> > /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
|
||||
|
||||
Example::
|
||||
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
|
||||
# echo "subsystem" > /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope
|
||||
|
||||
Users: Xilinx
|
||||
|
||||
What: /sys/devices/platform/firmware\:zynqmp-firmware/health_status
|
||||
Date: March 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: "Jolly Shah" <jollys@xilinx.com>
|
||||
Description:
|
||||
This sysfs interface allows to set the health status. If PMUFW
|
||||
is compiled with CHECK_HEALTHY_BOOT, it will check the healthy
|
||||
bit on FPD WDT expiration. If healthy bit is set by a user
|
||||
application running in Linux, PMUFW will do APU only restart. If
|
||||
healthy bit is not set during FPD WDT expiration, PMUFW will do
|
||||
system restart.
|
||||
|
||||
Usage:
|
||||
|
||||
Set healthy bit::
|
||||
|
||||
# echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status
|
||||
|
||||
Unset healthy bit::
|
||||
|
||||
# echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status
|
||||
|
||||
Users: Xilinx
|
||||
|
||||
What: /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
Date: Feb 2022
|
||||
KernelVersion: 5.18
|
||||
Contact: "Ronak Jain" <ronak.jain@xilinx.com>
|
||||
Description:
|
||||
This sysfs interface allows user to configure features at
|
||||
runtime. The user can enable or disable features running at
|
||||
firmware as well as the user can configure the parameters of
|
||||
the features at runtime. The supported features are over
|
||||
temperature and external watchdog. Here, the external watchdog
|
||||
is completely different than the /dev/watchdog as the external
|
||||
watchdog is running on the firmware and it is used to monitor
|
||||
the health of firmware not APU(Linux). Also, the external
|
||||
watchdog is interfaced outside of the zynqmp soc.
|
||||
|
||||
The supported config ids are for the feature configuration is,
|
||||
1. PM_FEATURE_OVERTEMP_STATUS = 1, the user can enable or
|
||||
disable the over temperature feature.
|
||||
2. PM_FEATURE_OVERTEMP_VALUE = 2, the user can configure the
|
||||
over temperature limit in Degree Celsius.
|
||||
3. PM_FEATURE_EXTWDT_STATUS = 3, the user can enable or disable
|
||||
the external watchdog feature.
|
||||
4. PM_FEATURE_EXTWDT_VALUE = 4, the user can configure the
|
||||
external watchdog feature.
|
||||
|
||||
Usage:
|
||||
|
||||
Select over temperature config ID to enable/disable feature
|
||||
# echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
|
||||
Check over temperature config ID is selected or not
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
The expected result is 1.
|
||||
|
||||
Select over temperature config ID to configure OT limit
|
||||
# echo 2 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
|
||||
Check over temperature config ID is selected or not
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
The expected result is 2.
|
||||
|
||||
Select external watchdog config ID to enable/disable feature
|
||||
# echo 3 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
|
||||
Check external watchdog config ID is selected or not
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
The expected result is 3.
|
||||
|
||||
Select external watchdog config ID to configure time interval
|
||||
# echo 4 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
|
||||
Check external watchdog config ID is selected or not
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
The expected result is 4.
|
||||
|
||||
Users: Xilinx
|
||||
|
||||
What: /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
|
||||
Date: Feb 2022
|
||||
KernelVersion: 5.18
|
||||
Contact: "Ronak Jain" <ronak.jain@xilinx.com>
|
||||
Description:
|
||||
This sysfs interface allows to configure features at runtime.
|
||||
The user can enable or disable features running at firmware.
|
||||
Also, the user can configure the parameters of the features
|
||||
at runtime. The supported features are over temperature and
|
||||
external watchdog. Here, the external watchdog is completely
|
||||
different than the /dev/watchdog as the external watchdog is
|
||||
running on the firmware and it is used to monitor the health
|
||||
of firmware not APU(Linux). Also, the external watchdog is
|
||||
interfaced outside of the zynqmp soc.
|
||||
|
||||
By default the features are disabled in the firmware. The user
|
||||
can enable features by querying appropriate config id of the
|
||||
features.
|
||||
|
||||
The default limit for the over temperature is 90 Degree Celsius.
|
||||
The default timer interval for the external watchdog is 570ms.
|
||||
|
||||
The supported config ids are for the feature configuration is,
|
||||
1. PM_FEATURE_OVERTEMP_STATUS = 1, the user can enable or
|
||||
disable the over temperature feature.
|
||||
2. PM_FEATURE_OVERTEMP_VALUE = 2, the user can configure the
|
||||
over temperature limit in Degree Celsius.
|
||||
3. PM_FEATURE_EXTWDT_STATUS = 3, the user can enable or disable
|
||||
the external watchdog feature.
|
||||
4. PM_FEATURE_EXTWDT_VALUE = 4, the user can configure the
|
||||
external watchdog feature.
|
||||
|
||||
Usage:
|
||||
|
||||
Enable over temperature feature
|
||||
# echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
# echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
|
||||
|
||||
Check whether the over temperature feature is enabled or not
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
|
||||
The expected result is 1.
|
||||
|
||||
Disable over temperature feature
|
||||
# echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
# echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
|
||||
|
||||
Check whether the over temperature feature is disabled or not
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
|
||||
The expected result is 0.
|
||||
|
||||
Configure over temperature limit to 50 Degree Celsius
|
||||
# echo 2 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
# echo 50 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
|
||||
|
||||
Check whether the over temperature limit is configured or not
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
|
||||
The expected result is 50.
|
||||
|
||||
Enable external watchdog feature
|
||||
# echo 3 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
# echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
|
||||
|
||||
Check whether the external watchdog feature is enabled or not
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
|
||||
The expected result is 1.
|
||||
|
||||
Disable external watchdog feature
|
||||
# echo 3 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
# echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
|
||||
|
||||
Check whether the external watchdog feature is disabled or not
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
|
||||
The expected result is 0.
|
||||
|
||||
Configure external watchdog timer interval to 500ms
|
||||
# echo 4 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id
|
||||
# echo 500 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
|
||||
|
||||
Check whether the external watchdog timer interval is configured or not
|
||||
# cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value
|
||||
The expected result is 500.
|
||||
|
||||
Users: Xilinx
|
||||
|
|
@ -0,0 +1,192 @@
|
|||
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/add_target
|
||||
Date: January 2, 2006
|
||||
KernelVersion: 2.6.15
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: Interface for making ib_srp connect to a new target.
|
||||
One can request ib_srp to connect to a new target by writing
|
||||
a comma-separated list of login parameters to this sysfs
|
||||
attribute. The supported parameters are:
|
||||
|
||||
* id_ext, a 16-digit hexadecimal number specifying the eight
|
||||
byte identifier extension in the 16-byte SRP target port
|
||||
identifier. The target port identifier is sent by ib_srp
|
||||
to the target in the SRP_LOGIN_REQ request.
|
||||
* ioc_guid, a 16-digit hexadecimal number specifying the eight
|
||||
byte I/O controller GUID portion of the 16-byte target port
|
||||
identifier.
|
||||
* dgid, a 32-digit hexadecimal number specifying the
|
||||
destination GID.
|
||||
* pkey, a four-digit hexadecimal number specifying the
|
||||
InfiniBand partition key.
|
||||
* service_id, a 16-digit hexadecimal number specifying the
|
||||
InfiniBand service ID used to establish communication with
|
||||
the SRP target. How to find out the value of the service ID
|
||||
is specified in the documentation of the SRP target.
|
||||
* max_sect, a decimal number specifying the maximum number of
|
||||
512-byte sectors to be transferred via a single SCSI command.
|
||||
* max_cmd_per_lun, a decimal number specifying the maximum
|
||||
number of outstanding commands for a single LUN.
|
||||
* io_class, a hexadecimal number specifying the SRP I/O class.
|
||||
Must be either 0xff00 (rev 10) or 0x0100 (rev 16a). The I/O
|
||||
class defines the format of the SRP initiator and target
|
||||
port identifiers.
|
||||
* initiator_ext, a 16-digit hexadecimal number specifying the
|
||||
identifier extension portion of the SRP initiator port
|
||||
identifier. This data is sent by the initiator to the target
|
||||
in the SRP_LOGIN_REQ request.
|
||||
* cmd_sg_entries, a number in the range 1..255 that specifies
|
||||
the maximum number of data buffer descriptors stored in the
|
||||
SRP_CMD information unit itself. With allow_ext_sg=0 the
|
||||
parameter cmd_sg_entries defines the maximum S/G list length
|
||||
for a single SRP_CMD, and commands whose S/G list length
|
||||
exceeds this limit after S/G list collapsing will fail.
|
||||
* allow_ext_sg, whether ib_srp is allowed to include a partial
|
||||
memory descriptor list in an SRP_CMD instead of the entire
|
||||
list. If a partial memory descriptor list has been included
|
||||
in an SRP_CMD the remaining memory descriptors are
|
||||
communicated from initiator to target via an additional RDMA
|
||||
transfer. Setting allow_ext_sg to 1 increases the maximum
|
||||
amount of data that can be transferred between initiator and
|
||||
target via a single SCSI command. Since not all SRP target
|
||||
implementations support partial memory descriptor lists the
|
||||
default value for this option is 0.
|
||||
* sg_tablesize, a number in the range 1..2048 specifying the
|
||||
maximum S/G list length the SCSI layer is allowed to pass to
|
||||
ib_srp. Specifying a value that exceeds cmd_sg_entries is
|
||||
only safe with partial memory descriptor list support enabled
|
||||
(allow_ext_sg=1).
|
||||
* comp_vector, a number in the range 0..n-1 specifying the
|
||||
MSI-X completion vector of the first RDMA channel. Some
|
||||
HCA's allocate multiple (n) MSI-X vectors per HCA port. If
|
||||
the IRQ affinity masks of these interrupts have been
|
||||
configured such that each MSI-X interrupt is handled by a
|
||||
different CPU then the comp_vector parameter can be used to
|
||||
spread the SRP completion workload over multiple CPU's.
|
||||
* tl_retry_count, a number in the range 2..7 specifying the
|
||||
IB RC retry count.
|
||||
* queue_size, the maximum number of commands that the
|
||||
initiator is allowed to queue per SCSI host. The default
|
||||
value for this parameter is 62. The lowest supported value
|
||||
is 2.
|
||||
* max_it_iu_size, a decimal number specifying the maximum
|
||||
initiator to target information unit length.
|
||||
|
||||
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev
|
||||
Date: January 2, 2006
|
||||
KernelVersion: 2.6.15
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: HCA name (<hca>).
|
||||
|
||||
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/port
|
||||
Date: January 2, 2006
|
||||
KernelVersion: 2.6.15
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: HCA port number (<port_number>).
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/allow_ext_sg
|
||||
Date: May 19, 2011
|
||||
KernelVersion: 2.6.39
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: Whether ib_srp is allowed to include a partial memory
|
||||
descriptor list in an SRP_CMD when communicating with an SRP
|
||||
target.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/ch_count
|
||||
Date: April 1, 2015
|
||||
KernelVersion: 3.19
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: Number of RDMA channels used for communication with the SRP
|
||||
target.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/cmd_sg_entries
|
||||
Date: May 19, 2011
|
||||
KernelVersion: 2.6.39
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: Maximum number of data buffer descriptors that may be sent to
|
||||
the target in a single SRP_CMD request.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/comp_vector
|
||||
Date: September 2, 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: Completion vector used for the first RDMA channel.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/dgid
|
||||
Date: June 17, 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: InfiniBand destination GID used for communication with the SRP
|
||||
target. Differs from orig_dgid if port redirection has happened.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/id_ext
|
||||
Date: June 17, 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: Eight-byte identifier extension portion of the 16-byte target
|
||||
port identifier.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/ioc_guid
|
||||
Date: June 17, 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: Eight-byte I/O controller GUID portion of the 16-byte target
|
||||
port identifier.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/local_ib_device
|
||||
Date: November 29, 2006
|
||||
KernelVersion: 2.6.19
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: Name of the InfiniBand HCA used for communicating with the
|
||||
SRP target.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/local_ib_port
|
||||
Date: November 29, 2006
|
||||
KernelVersion: 2.6.19
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: Number of the HCA port used for communicating with the
|
||||
SRP target.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/orig_dgid
|
||||
Date: June 17, 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: InfiniBand destination GID specified in the parameters
|
||||
written to the add_target sysfs attribute.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/pkey
|
||||
Date: June 17, 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: A 16-bit number representing the InfiniBand partition key used
|
||||
for communication with the SRP target.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/req_lim
|
||||
Date: October 20, 2010
|
||||
KernelVersion: 2.6.36
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: Number of requests ib_srp can send to the target before it has
|
||||
to wait for more credits. For more information see also the
|
||||
SRP credit algorithm in the SRP specification.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/service_id
|
||||
Date: June 17, 2006
|
||||
KernelVersion: 2.6.17
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: InfiniBand service ID used for establishing communication with
|
||||
the SRP target.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/sgid
|
||||
Date: February 1, 2014
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: InfiniBand GID of the source port used for communication with
|
||||
the SRP target.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/zero_req_lim
|
||||
Date: September 20, 2006
|
||||
KernelVersion: 2.6.18
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: Number of times the initiator had to wait before sending a
|
||||
request to the target because it ran out of credits. For more
|
||||
information see also the SRP credit algorithm in the SRP
|
||||
specification.
|
||||
|
|
@ -0,0 +1,717 @@
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic_health
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file shows ASIC health status. The possible values are:
|
||||
0 - health failed, 2 - health OK, 3 - ASIC in booting state.
|
||||
|
||||
The files are read only.
|
||||
|
||||
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>
|
||||
Description: These files show with which CPLD versions have been burned
|
||||
on carrier and switch boards.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/fan_dir
|
||||
Date: December 2018
|
||||
KernelVersion: 5.0
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file shows the system fans direction:
|
||||
forward direction - relevant bit is set 0;
|
||||
reversed direction - relevant bit is set 1.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_version
|
||||
Date: November 2018
|
||||
KernelVersion: 5.0
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files show with which CPLD versions have been burned
|
||||
on LED or Gearbox board.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/jtag_enable
|
||||
Date: November 2018
|
||||
KernelVersion: 5.0
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files enable and disable the access to the JTAG domain.
|
||||
By default access to the JTAG domain is disabled.
|
||||
|
||||
The file is read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/select_iio
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file allows iio devices selection.
|
||||
|
||||
Attribute select_iio can be written with 0 or with 1. It
|
||||
selects which one of iio devices can be accessed.
|
||||
|
||||
The file is read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu1_on
|
||||
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu2_on
|
||||
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_cycle
|
||||
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_down
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files allow asserting system power cycling, switching
|
||||
power supply units on and off and system's main power domain
|
||||
shutdown.
|
||||
Expected behavior:
|
||||
When pwr_cycle is written 1: auxiliary power domain will go
|
||||
down and after short period (about 1 second) up.
|
||||
When psu1_on or psu2_on is written 1, related unit will be
|
||||
disconnected from the power source, when written 0 - connected.
|
||||
If both are written 1 - power supplies main power domain will
|
||||
go down.
|
||||
When pwr_down is written 1, system's main power domain will go
|
||||
down.
|
||||
|
||||
The files are write only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_aux_pwr_or_ref
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_asic_thermal
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_hotswap_or_halt
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_hotswap_or_wd
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_fw_reset
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_long_pb
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_main_pwr_fail
|
||||
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>
|
||||
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,
|
||||
short press power button, software reset. Value 1 in file means
|
||||
this is reset cause, 0 - otherwise. Only one of the above
|
||||
causes could be 1 at the same time, representing only last
|
||||
reset cause.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_comex_pwr_fail
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_from_comex
|
||||
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>
|
||||
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,
|
||||
Value 1 in file means this is reset cause, 0 - otherwise.
|
||||
Only one bit could be 1 at the same time, representing only
|
||||
the last reset cause.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_version
|
||||
Date: November 2018
|
||||
KernelVersion: 5.0
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files show with which CPLD versions have been burned
|
||||
on LED board.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_comex_thermal
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_comex_wd
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_from_asic
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_reload_bios
|
||||
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>
|
||||
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
|
||||
Factor mezzanine, reset requested from ASIC, reset caused by BIOS
|
||||
reload. Value 1 in file means this is reset cause, 0 - otherwise.
|
||||
Only one of the above causes could be 1 at the same time, representing
|
||||
only last reset cause.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/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>
|
||||
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.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_ac_pwr_fail
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_platform
|
||||
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>
|
||||
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
|
||||
asserted by SOC through ACPI register, reset invoked from
|
||||
software by assertion power off signal through CPLD.
|
||||
|
||||
The files are read only.
|
||||
|
||||
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>
|
||||
Description: This file allows to retain ASIC up during PCIe root complex
|
||||
reset, when attribute is set 1.
|
||||
|
||||
The file is read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/vpd_wp
|
||||
Date: January 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file allows to overwrite system VPD hardware write
|
||||
protection when attribute is set 1.
|
||||
|
||||
The file is read/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>
|
||||
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.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ufm_version
|
||||
Date: January 2020
|
||||
KernelVersion: 5.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file exposes the firmware version of burnable voltage
|
||||
regulator devices.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld1_pn
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld2_pn
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_pn
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_pn
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld1_version_min
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld2_version_min
|
||||
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>
|
||||
Description: These files show with which CPLD part numbers and minor
|
||||
versions have been burned CPLD devices equipped on a
|
||||
system.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/bios_active_image
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/bios_auth_fail
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/bios_upgrade_fail
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: The files represent BIOS statuses:
|
||||
|
||||
bios_active_image: location of current active BIOS image:
|
||||
0: Top, 1: Bottom.
|
||||
The reported value should correspond to value expected by OS
|
||||
in case of BIOS safe mode is 0. This bit is related to Intel
|
||||
top-swap feature of DualBios on the same flash.
|
||||
|
||||
bios_auth_fail: BIOS upgrade is failed because provided BIOS
|
||||
image is not signed correctly.
|
||||
|
||||
bios_upgrade_fail: BIOS upgrade is failed by some other
|
||||
reason not because authentication. For example due to
|
||||
physical SPI flash problem.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc1_enable
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc2_enable
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc3_enable
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc4_enable
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc5_enable
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc6_enable
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc7_enable
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc8_enable
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files allow line cards enable state control.
|
||||
Expected behavior:
|
||||
When lc{n}_enable is written 1, related line card is released
|
||||
from the reset state, when 0 - is hold in reset state.
|
||||
|
||||
The files are read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc1_pwr
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc2_pwr
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc3_pwr
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc4_pwr
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc5_pwr
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc6_pwr
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc7_pwr
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc8_pwr
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files switching line cards power on and off.
|
||||
Expected behavior:
|
||||
When lc{n}_pwr is written 1, related line card is powered
|
||||
on, when written 0 - powered off.
|
||||
|
||||
The files are read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc1_rst_mask
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc2_rst_mask
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc3_rst_mask
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc4_rst_mask
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc5_rst_mask
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc6_rst_mask
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc7_rst_mask
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lc8_rst_mask
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files clear line card reset bit enforced by ASIC, when it
|
||||
sets it due to some abnormal ASIC behavior.
|
||||
Expected behavior:
|
||||
When lc{n}_rst_mask is written 1, related line card reset bit
|
||||
is cleared, when written 0 - no effect.
|
||||
|
||||
The files are write only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/os_started
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file, when written 1, indicates to programmable devices
|
||||
that OS is taking control over it.
|
||||
|
||||
The file is read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pm_mgmt_en
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file assigns power management control ownership.
|
||||
When power management control is provided by hardware, hardware
|
||||
will automatically power off one or more line previously
|
||||
powered line cards in case system power budget is getting
|
||||
insufficient. It could be in case when some of power units lost
|
||||
power good state.
|
||||
When pm_mgmt_en is written 1, power management control by
|
||||
software is enabled, 0 - power management control by hardware.
|
||||
Note that for any setting of pm_mgmt_en attribute hardware will
|
||||
not allow to power on any new line card in case system power
|
||||
budget is insufficient.
|
||||
Same in case software will try to power on several line cards
|
||||
at once - hardware will power line cards while system has
|
||||
enough power budget.
|
||||
Default is 0.
|
||||
|
||||
The file is read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu3_on
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu4_on
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files switching power supply units on and off.
|
||||
Expected behavior:
|
||||
When psu3_on or psu4_on is written 1, related unit will be
|
||||
disconnected from the power source, when written 0 - connected.
|
||||
|
||||
The files are write only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/shutdown_unlock
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file allows to unlock ASIC after thermal shutdown event.
|
||||
When system thermal shutdown is enforced by ASIC, ASIC is
|
||||
getting locked and after system boot it will not be available.
|
||||
Software can decide to unlock it by setting this attribute to
|
||||
1 and then perform system power cycle by setting pwr_cycle
|
||||
attribute to 1 (power cycle of main power domain).
|
||||
Before setting shutdown_unlock to 1 it is recommended to
|
||||
validate that system reboot cause is reset_asic_thermal or
|
||||
reset_thermal_spc_or_pciesw.
|
||||
In case shutdown_unlock is not set 1, the only way to release
|
||||
ASIC from locking - is full system power cycle through the
|
||||
external power distribution unit.
|
||||
Default is 1.
|
||||
|
||||
The file is read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/cpld1_pn
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/cpld1_version
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/cpld1_version_min
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files show with which CPLD major and minor versions
|
||||
and part number has been burned CPLD device on line card.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga1_pn
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga1_version
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga1_version_min
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files show with which FPGA major and minor versions
|
||||
and part number has been burned FPGA device on line card.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/vpd_wp
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file allow to overwrite line card VPD hardware write
|
||||
protection mode. When attribute is set 1 - write protection is
|
||||
disabled, when 0 - enabled.
|
||||
Default is 0.
|
||||
If the system is in locked-down mode writing this file will not
|
||||
be allowed.
|
||||
The purpose if this file is to allow line card VPD burning
|
||||
during production flow.
|
||||
|
||||
The file is read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_aux_pwr_or_ref
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_dc_dc_pwr_fail
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_fpga_not_done
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_from_chassis
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_line_card
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/reset_pwr_off_from_chassis
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files show the line reset cause, as following: power
|
||||
auxiliary outage or power refresh, DC-to-DC power failure, FPGA reset
|
||||
failed, line card reset failed, power off from chassis.
|
||||
Value 1 in file means this is reset cause, 0 - otherwise. Only one of
|
||||
the above causes could be 1 at the same time, representing only last
|
||||
reset cause.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/cpld_upgrade_en
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga_upgrade_en
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files allow CPLD and FPGA burning. Value 1 in file means burning
|
||||
is enabled, 0 - otherwise.
|
||||
If the system is in locked-down mode writing these files will
|
||||
not be allowed.
|
||||
The purpose of these files to allow line card CPLD and FPGA
|
||||
upgrade through the JTAG daisy-chain.
|
||||
|
||||
The files are read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/qsfp_pwr_en
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/pwr_en
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files allow to power on/off all QSFP ports and whole line card.
|
||||
The attributes are set 1 for power on, 0 - for power off.
|
||||
|
||||
The files are read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/agb_spi_burn_en
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/fpga_spi_burn_en
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files allow gearboxes and FPGA SPI flash burning.
|
||||
The attributes are set 1 to enable burning, 0 - to disable.
|
||||
If the system is in locked-down mode writing these files will
|
||||
not be allowed.
|
||||
The purpose of these files to allow line card Gearboxes and FPGA
|
||||
burning during production flow.
|
||||
|
||||
The file is read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/max_power
|
||||
What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/i2c-*/*-0032/mlxreg-io.*/hwmon/hwmon*/config
|
||||
Date: October 2021
|
||||
KernelVersion: 5.16
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files provide the maximum powered required for line card
|
||||
feeding and line card configuration Id.
|
||||
|
||||
The files are read only.
|
||||
|
||||
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.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_pwr_converter_fail
|
||||
Date: February 2023
|
||||
KernelVersion: 6.3
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file shows the system reset cause due to power converter
|
||||
devices failure.
|
||||
Value 1 in file means this is reset cause, 0 - otherwise.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_ap_reset
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_ap_reset
|
||||
Date: February 2023
|
||||
KernelVersion: 6.3
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files aim to monitor the status of the External Root of Trust (EROT)
|
||||
processor's RESET output to the Application Processor (AP).
|
||||
By reading this file, could be determined if the EROT has invalidated or
|
||||
revoked AP Firmware, at which point it will hold the AP in RESET until a
|
||||
valid firmware is loaded. This protects the AP from running an
|
||||
unauthorized firmware. In the normal flow, the AP reset should be released
|
||||
after the EROT validates the integrity of the FW, and it should be done so
|
||||
as quickly as possible so that the AP boots before the CPU starts to
|
||||
communicate to each ASIC.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_recovery
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_recovery
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_reset
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_reset
|
||||
Date: February 2023
|
||||
KernelVersion: 6.3
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files aim to perform External Root of Trust (EROT) recovery
|
||||
sequence after EROT device failure.
|
||||
These EROT devices protect ASICs from unauthorized access and in normal
|
||||
flow their reset should be released with system power – earliest power
|
||||
up stage, so that EROTs can begin boot and authentication process before
|
||||
CPU starts to communicate to ASICs.
|
||||
Issuing a reset to the EROT while asserting the recovery signal will cause
|
||||
the EROT Application Processor to enter recovery mode so that the EROT FW
|
||||
can be updated/recovered.
|
||||
For reset/recovery the related file should be toggled by 1/0.
|
||||
|
||||
The files are read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_wp
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_wp
|
||||
Date: February 2023
|
||||
KernelVersion: 6.3
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files allow access to External Root of Trust (EROT) for reset
|
||||
and recovery sequence after EROT device failure.
|
||||
Default is 0 (programming disabled).
|
||||
If the system is in locked-down mode writing this file will not be allowed.
|
||||
|
||||
The files are read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/spi_chnl_select
|
||||
Date: February 2023
|
||||
KernelVersion: 6.3
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file allows SPI chip selection for External Root of Trust (EROT)
|
||||
device Out-of-Band recovery.
|
||||
File can be written with 0 or with 1. It selects which EROT can be accessed
|
||||
through SPI device.
|
||||
|
||||
The file is read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic_pg_fail
|
||||
Date: February 2023
|
||||
KernelVersion: 6.3
|
||||
Contact: Vadim Pasternak vadimp@nvidia.com
|
||||
Description: This file shows ASIC Power Good status.
|
||||
Value 1 in file means ASIC Power Good failed, 0 - otherwise.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd1_boot_fail
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd2_boot_fail
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd_fail
|
||||
Date: February 2023
|
||||
KernelVersion: 6.3
|
||||
Contact: Vadim Pasternak vadimp@nvidia.com
|
||||
Description: These files are related to clock boards status in system.
|
||||
- clk_brd1_boot_fail: warning about 1-st clock board failed to boot from CI.
|
||||
- clk_brd2_boot_fail: warning about 2-nd clock board failed to boot from CI.
|
||||
- clk_brd_fail: error about common clock board boot failure.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd_prog_en
|
||||
Date: February 2023
|
||||
KernelVersion: 6.3
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file enables programming of clock boards.
|
||||
Default is 0 (programming disabled).
|
||||
If the system is in locked-down mode writing this file will not be allowed.
|
||||
|
||||
The file is read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_converter_prog_en
|
||||
Date: February 2023
|
||||
KernelVersion: 6.3
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file enables programming of power converters.
|
||||
Default is 0 (programming disabled).
|
||||
If the system is in locked-down mode writing this file will not be allowed.
|
||||
|
||||
The file is read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_ac_ok_fail
|
||||
Date: February 2023
|
||||
KernelVersion: 6.3
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file shows the system reset cause due to AC power failure.
|
||||
Value 1 in file means this is reset cause, 0 - otherwise.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld5_pn
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld5_version
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld5_version_min
|
||||
Date: August 2023
|
||||
KernelVersion: 6.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: These files show with which CPLD part numbers, version and minor
|
||||
versions have been burned the 5-th CPLD device equipped on a
|
||||
system.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/jtag_cap
|
||||
Date: August 2023
|
||||
KernelVersion: 6.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file indicates the available method of CPLD/FPGA devices
|
||||
field update through the JTAG chain:
|
||||
|
||||
b00 - field update through LPC bus register memory space.
|
||||
b01 - Reserved.
|
||||
b10 - Reserved.
|
||||
b11 - field update through CPU GPIOs bit-banging.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lid_open
|
||||
Date: August 2023
|
||||
KernelVersion: 6.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: 1 - indicates that system lid is opened, otherwise 0.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_long_pwr_pb
|
||||
Date: August 2023
|
||||
KernelVersion: 6.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file if set 1 indicates that system has been reset by
|
||||
long press of power button.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_swb_dc_dc_pwr_fail
|
||||
Date: August 2023
|
||||
KernelVersion: 6.6
|
||||
Contact: Vadim Pasternak <vadimp@nvidia.com>
|
||||
Description: This file shows 1 in case the system reset happened due to the
|
||||
failure of any DC-DC power converter devices equipped on the
|
||||
switch board.
|
||||
|
||||
The file is read only.
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
What: /sys/bus/pci/drivers/qla2xxx/.../devices/*
|
||||
Date: September 2009
|
||||
Contact: QLogic Linux Driver <linux-driver@qlogic.com>
|
||||
Description: qla2xxx-udev.sh currently looks for uevent CHANGE events to
|
||||
signal a firmware-dump has been generated by the driver and is
|
||||
ready for retrieval.
|
||||
Users: qla2xxx-udev.sh. Proposed changes should be mailed to
|
||||
linux-driver@qlogic.com
|
||||
|
|
@ -0,0 +1,395 @@
|
|||
What: /sys/accessibility/speakup/attrib_bleep
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Beeps the PC speaker when there is an attribute change such as
|
||||
foreground or background color when using speakup review
|
||||
commands. One = on, zero = off.
|
||||
|
||||
What: /sys/accessibility/speakup/bell_pos
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This works much like a typewriter bell. If for example 72 is
|
||||
echoed to bell_pos, it will beep the PC speaker when typing on
|
||||
a line past character 72.
|
||||
|
||||
What: /sys/accessibility/speakup/bleeps
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This controls whether one hears beeps through the PC speaker
|
||||
when using speakup's review commands.
|
||||
TODO: what values does it accept?
|
||||
|
||||
What: /sys/accessibility/speakup/bleep_time
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This controls the duration of the PC speaker beeps speakup
|
||||
produces.
|
||||
TODO: What are the units? Jiffies?
|
||||
|
||||
What: /sys/accessibility/speakup/cursor_time
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This controls cursor delay when using arrow keys. When a
|
||||
connection is very slow, with the default setting, when moving
|
||||
with the arrows, or backspacing etc. speakup says the incorrect
|
||||
characters. Set this to a higher value to adjust for the delay
|
||||
and better synchronisation between cursor position and speech.
|
||||
|
||||
What: /sys/accessibility/speakup/cur_phonetic
|
||||
KernelVersion: 6.2
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This allows speakup to speak letters phoneticaly when arrowing through
|
||||
a word letter by letter. This doesn't affect the spelling when typing
|
||||
the characters. When cur_phonetic=1, speakup will speak characters
|
||||
phoneticaly when arrowing over a letter. When cur_phonetic=0, speakup
|
||||
will speak letters as normally.
|
||||
|
||||
What: /sys/accessibility/speakup/delimiters
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Delimit a word from speakup.
|
||||
TODO: add more info
|
||||
|
||||
What: /sys/accessibility/speakup/ex_num
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: TODO:
|
||||
|
||||
What: /sys/accessibility/speakup/key_echo
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Controls if speakup speaks keys when they are typed. One = on,
|
||||
zero = off or don't echo keys.
|
||||
|
||||
What: /sys/accessibility/speakup/keymap
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Speakup keymap remaps keys to Speakup functions.
|
||||
It uses a binary
|
||||
format. A special program called genmap is needed to compile a
|
||||
textual keymap into the binary format which is then loaded into
|
||||
/sys/accessibility/speakup/keymap.
|
||||
|
||||
What: /sys/accessibility/speakup/no_interrupt
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Controls if typing interrupts output from speakup. With
|
||||
no_interrupt set to zero, typing on the keyboard will interrupt
|
||||
speakup if for example
|
||||
the say screen command is used before the
|
||||
entire screen is read.
|
||||
|
||||
With no_interrupt set to one, if the say
|
||||
screen command is used, and one then types on the keyboard,
|
||||
speakup will continue to say the whole screen regardless until
|
||||
it finishes.
|
||||
|
||||
What: /sys/accessibility/speakup/punc_all
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This is a list of all the punctuation speakup should speak when
|
||||
punc_level is set to four.
|
||||
|
||||
What: /sys/accessibility/speakup/punc_level
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Controls the level of punctuation spoken as the screen is
|
||||
displayed, not reviewed. Levels range from zero no punctuation,
|
||||
to four, all punctuation. One corresponds to punc_some, two
|
||||
corresponds to punc_most, and three as well as four both
|
||||
correspond to punc_all. Some hardware synthesizers may have
|
||||
different levels each corresponding to three and four for
|
||||
punc_level. Also note that if punc_level is set to zero, and
|
||||
key_echo is set to one, typed punctuation is still spoken as it
|
||||
is typed.
|
||||
|
||||
What: /sys/accessibility/speakup/punc_most
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This is a list of all the punctuation speakup should speak when
|
||||
punc_level is set to two.
|
||||
|
||||
What: /sys/accessibility/speakup/punc_some
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This is a list of all the punctuation speakup should speak when
|
||||
punc_level is set to one.
|
||||
|
||||
What: /sys/accessibility/speakup/reading_punc
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Almost the same as punc_level, the differences being that
|
||||
reading_punc controls the level of punctuation when reviewing
|
||||
the screen with speakup's screen review commands. The other
|
||||
difference is that reading_punc set to three speaks punc_all,
|
||||
and reading_punc set to four speaks all punctuation, including
|
||||
spaces.
|
||||
|
||||
What: /sys/accessibility/speakup/repeats
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: A list of characters speakup repeats. Normally, when there are
|
||||
more than three characters in a row, speakup
|
||||
just reads three of
|
||||
those characters. For example, "......" would be read as dot,
|
||||
dot, dot. If a . is added to the list of characters in repeats,
|
||||
"......" would be read as dot, dot, dot, times six.
|
||||
|
||||
What: /sys/accessibility/speakup/say_control
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: If set to one, speakup speaks shift, alt and control when those
|
||||
keys are pressed. If say_control is set to zero, shift, ctrl,
|
||||
and alt are not spoken when they are pressed.
|
||||
|
||||
What: /sys/accessibility/speakup/say_word_ctl
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: TODO:
|
||||
|
||||
What: /sys/accessibility/speakup/silent
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: TODO:
|
||||
|
||||
What: /sys/accessibility/speakup/spell_delay
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This controls how fast a word is spelled
|
||||
when speakup's say word
|
||||
review command is pressed twice quickly to speak the current
|
||||
word being reviewed. Zero just speaks the letters one after
|
||||
another, while values one through four
|
||||
seem to introduce more of
|
||||
a pause between the spelling of each letter by speakup.
|
||||
|
||||
What: /sys/accessibility/speakup/synth
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the synthesizer driver currently in use. Reading
|
||||
synth returns the synthesizer driver currently in use. Writing
|
||||
synth switches to the given synthesizer driver, provided it is
|
||||
either built into the kernel, or already loaded as a module.
|
||||
|
||||
What: /sys/accessibility/speakup/synth_direct
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Sends whatever is written to synth_direct
|
||||
directly to the speech synthesizer in use, bypassing speakup.
|
||||
This could be used to make the synthesizer speak
|
||||
a string, or to
|
||||
send control sequences to the synthesizer to change how the
|
||||
synthesizer behaves.
|
||||
|
||||
What: /sys/accessibility/speakup/version
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Reading version returns the version of speakup, and the version
|
||||
of the synthesizer driver currently in use.
|
||||
|
||||
What: /sys/accessibility/speakup/i18n/announcements
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This file contains various general announcements, most of which
|
||||
cannot be categorized. You will find messages such as "You
|
||||
killed Speakup", "I'm alive", "leaving help", "parked",
|
||||
"unparked", and others. You will also find the names of the
|
||||
screen edges and cursor tracking modes here.
|
||||
|
||||
What: /sys/accessibility/speakup/i18n/chartab
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: TODO
|
||||
|
||||
What: /sys/accessibility/speakup/i18n/ctl_keys
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Here, you will find names of control keys. These are used with
|
||||
Speakup's say_control feature.
|
||||
|
||||
What: /sys/accessibility/speakup/i18n/function_names
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Here, you will find a list of names for Speakup functions.
|
||||
These are used by the help system. For example, suppose that
|
||||
you have activated help mode, and you pressed
|
||||
keypad 3. Speakup
|
||||
says: "keypad 3 is character, say next."
|
||||
The message "character, say next" names a Speakup function, and
|
||||
it comes from this function_names file.
|
||||
|
||||
What: /sys/accessibility/speakup/i18n/states
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This file contains names for key states.
|
||||
Again, these are part of the help system. For instance, if you
|
||||
had pressed speakup + keypad 3, you would hear:
|
||||
"speakup keypad 3 is go to bottom edge."
|
||||
|
||||
The speakup key is depressed, so the name of the key state is
|
||||
speakup.
|
||||
|
||||
This part of the message comes from the states collection.
|
||||
|
||||
What: /sys/accessibility/speakup/i18n/characters
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Through this sys entry, Speakup gives you the ability to change
|
||||
how Speakup pronounces a given character. You could, for
|
||||
example, change how some punctuation characters are spoken. You
|
||||
can even change how Speakup will pronounce certain letters. For
|
||||
further details see '12. Changing the Pronunciation of
|
||||
Characters' in Speakup User's Guide (file spkguide.txt in
|
||||
source).
|
||||
|
||||
What: /sys/accessibility/speakup/i18n/colors
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: When you use the "say attributes" function, Speakup says the
|
||||
name of the foreground and background colors. These names come
|
||||
from the i18n/colors file.
|
||||
|
||||
What: /sys/accessibility/speakup/i18n/formatted
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This group of messages contains embedded formatting codes, to
|
||||
specify the type and width of displayed data. If you change
|
||||
these, you must preserve all of the formatting codes, and they
|
||||
must appear in the order used by the default messages.
|
||||
|
||||
What: /sys/accessibility/speakup/i18n/key_names
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Again, key_names is used by Speakup's help system. In the
|
||||
previous example, Speakup said that you pressed "keypad 3."
|
||||
This name came from the key_names file.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: In `/sys/accessibility/speakup` is a directory corresponding to
|
||||
the synthesizer driver currently in use (E.G) `soft` for the
|
||||
soft driver. This directory contains files which control the
|
||||
speech synthesizer itself,
|
||||
as opposed to controlling the speakup
|
||||
screen reader. The parameters in this directory have the same
|
||||
names and functions across all
|
||||
supported synthesizers. The range
|
||||
of values for freq, pitch, rate, and vol is the same for all
|
||||
supported synthesizers, with the given range being internally
|
||||
mapped by the driver to more or less fit the range of values
|
||||
supported for a given parameter by the individual synthesizer.
|
||||
Below is a description of values and parameters for soft
|
||||
synthesizer, which is currently the most commonly used.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/caps_start
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This is the string that is sent to the synthesizer to cause it
|
||||
to start speaking uppercase letters. For the soft synthesizer
|
||||
and most others, this causes the pitch of the voice to rise
|
||||
above the currently set pitch.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/caps_stop
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This is the string sent to the synthesizer to cause it to stop
|
||||
speaking uppercase letters. In the case of the soft synthesizer
|
||||
and most others, this returns the pitch of the voice
|
||||
down to the
|
||||
currently set pitch.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/delay_time
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: TODO:
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/direct
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Controls if punctuation is spoken by speakup, or by the
|
||||
synthesizer.
|
||||
|
||||
For example, speakup speaks ">" as "greater", while
|
||||
the espeak synthesizer used by the soft driver speaks "greater
|
||||
than". Zero lets speakup speak the punctuation. One lets the
|
||||
synthesizer itself speak punctuation.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/freq
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the frequency of the speech synthesizer. Range is
|
||||
0-9.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/flush_time
|
||||
KernelVersion: 5.12
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the timeout to wait for the synthesizer flush to
|
||||
complete. This can be used when the cable gets faulty and flush
|
||||
notifications are getting lost.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/full_time
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: TODO:
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/jiffy_delta
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: This controls how many jiffys the kernel gives to the
|
||||
synthesizer. Setting this too high can make a system unstable,
|
||||
or even crash it.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/pitch
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the pitch of the synthesizer. The range is 0-9.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/inflection
|
||||
KernelVersion: 5.8
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the inflection of the synthesizer, i.e. the pitch
|
||||
range. The range is 0-9.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/punct
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the amount of punctuation spoken by the
|
||||
synthesizer. The range for the soft driver seems to be 0-2.
|
||||
TODO: How is this related to speakup's punc_level, or
|
||||
reading_punc.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/rate
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the rate of the synthesizer. Range is from zero
|
||||
slowest, to nine fastest.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/tone
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the tone of the speech synthesizer. The range for
|
||||
the soft driver seems to be 0-2. This seems to make no
|
||||
difference if using espeak and the espeakup connector.
|
||||
TODO: does espeakup support different tonalities?
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/trigger_time
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: TODO:
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/voice
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the voice used by the synthesizer if the
|
||||
synthesizer can speak in more than one voice. The range for the
|
||||
soft driver is 0-7. Note that while espeak supports multiple
|
||||
voices, this parameter will not set the voice when the espeakup
|
||||
connector is used between speakup and espeak.
|
||||
|
||||
What: /sys/accessibility/speakup/<synth-name>/vol
|
||||
KernelVersion: 2.6
|
||||
Contact: speakup@linux-speakup.org
|
||||
Description: Gets or sets the volume of the speech synthesizer. Range is 0-9,
|
||||
with zero being the softest, and nine being the loudest.
|
||||
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
What: /sys/bus/usb/drivers/usbtmc/*/interface_capabilities
|
||||
What: /sys/bus/usb/drivers/usbtmc/*/device_capabilities
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
These files show the various USB TMC capabilities as described
|
||||
by the device itself. The full description of the bitfields
|
||||
can be found in the USB TMC documents from the USB-IF entitled
|
||||
"Universal Serial Bus Test and Measurement Class Specification
|
||||
(USBTMC) Revision 1.0" section 4.2.1.8.
|
||||
|
||||
The files are read only.
|
||||
|
||||
|
||||
What: /sys/bus/usb/drivers/usbtmc/*/usb488_interface_capabilities
|
||||
What: /sys/bus/usb/drivers/usbtmc/*/usb488_device_capabilities
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
These files show the various USB TMC capabilities as described
|
||||
by the device itself. The full description of the bitfields
|
||||
can be found in the USB TMC documents from the USB-IF entitled
|
||||
"Universal Serial Bus Test and Measurement Class, Subclass
|
||||
USB488 Specification (USBTMC-USB488) Revision 1.0" section
|
||||
4.2.2.
|
||||
|
||||
The files are read only.
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
What: /sys/bus/w1/devices/.../page1
|
||||
Date: April 2021
|
||||
Contact: Luiz Sampaio <sampaio.ime@gmail.com>
|
||||
Description: read the contents of the page1 of the DS2438
|
||||
see Documentation/w1/slaves/w1_ds2438.rst for detailed information
|
||||
Users: any user space application which wants to communicate with DS2438
|
||||
|
||||
What: /sys/bus/w1/devices/.../offset
|
||||
Date: April 2021
|
||||
Contact: Luiz Sampaio <sampaio.ime@gmail.com>
|
||||
Description: write the contents to the offset register of the DS2438
|
||||
see Documentation/w1/slaves/w1_ds2438.rst for detailed information
|
||||
Users: any user space application which wants to communicate with DS2438
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
What: /sys/bus/w1/devices/.../pio
|
||||
Date: May 2012
|
||||
Contact: Markus Franke <franm@hrz.tu-chemnitz.de>
|
||||
Description: read/write the contents of the two PIO's of the DS28E04-100
|
||||
see Documentation/w1/slaves/w1_ds28e04.rst for detailed information
|
||||
Users: any user space application which wants to communicate with DS28E04-100
|
||||
|
||||
|
||||
|
||||
What: /sys/bus/w1/devices/.../eeprom
|
||||
Date: May 2012
|
||||
Contact: Markus Franke <franm@hrz.tu-chemnitz.de>
|
||||
Description: read/write the contents of the EEPROM memory of the DS28E04-100
|
||||
see Documentation/w1/slaves/w1_ds28e04.rst for detailed information
|
||||
Users: any user space application which wants to communicate with DS28E04-100
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
What: /sys/bus/w1/devices/.../w1_seq
|
||||
Date: Apr 2015
|
||||
Contact: Matt Campbell <mattrcampbell@gmail.com>
|
||||
Description: Support for the DS28EA00 chain sequence function
|
||||
see Documentation/w1/slaves/w1_therm.rst for detailed information
|
||||
Users: any user space application which wants to communicate with DS28EA00
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
What: /sys/firmware/efi/vars
|
||||
Date: April 2004
|
||||
Contact: Matt Domsch <Matt_Domsch@dell.com>
|
||||
Description:
|
||||
This directory exposes interfaces for interactive with
|
||||
EFI variables. For more information on EFI variables,
|
||||
see 'Variable Services' in the UEFI specification
|
||||
(section 7.2 in specification version 2.3 Errata D).
|
||||
|
||||
In summary, EFI variables are named, and are classified
|
||||
into separate namespaces through the use of a vendor
|
||||
GUID. They also have an arbitrary binary value
|
||||
associated with them.
|
||||
|
||||
The efivars module enumerates these variables and
|
||||
creates a separate directory for each one found. Each
|
||||
directory has a name of the form "<key>-<vendor guid>"
|
||||
and contains the following files:
|
||||
|
||||
=============== ========================================
|
||||
attributes: A read-only text file enumerating the
|
||||
EFI variable flags. Potential values
|
||||
include:
|
||||
|
||||
EFI_VARIABLE_NON_VOLATILE
|
||||
EFI_VARIABLE_BOOTSERVICE_ACCESS
|
||||
EFI_VARIABLE_RUNTIME_ACCESS
|
||||
EFI_VARIABLE_HARDWARE_ERROR_RECORD
|
||||
EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
|
||||
|
||||
See the EFI documentation for an
|
||||
explanation of each of these variables.
|
||||
|
||||
data: A read-only binary file that can be read
|
||||
to attain the value of the EFI variable
|
||||
|
||||
guid: The vendor GUID of the variable. This
|
||||
should always match the GUID in the
|
||||
variable's name.
|
||||
|
||||
raw_var: A binary file that can be read to obtain
|
||||
a structure that contains everything
|
||||
there is to know about the variable.
|
||||
For structure definition see "struct
|
||||
efi_variable" in the kernel sources.
|
||||
|
||||
This file can also be written to in
|
||||
order to update the value of a variable.
|
||||
For this to work however, all fields of
|
||||
the "struct efi_variable" passed must
|
||||
match byte for byte with the structure
|
||||
read out of the file, save for the value
|
||||
portion.
|
||||
|
||||
**Note** the efi_variable structure
|
||||
read/written with this file contains a
|
||||
'long' type that may change widths
|
||||
depending on your underlying
|
||||
architecture.
|
||||
|
||||
size: As ASCII representation of the size of
|
||||
the variable's value.
|
||||
=============== ========================================
|
||||
|
||||
|
||||
In addition, two other magic binary files are provided
|
||||
in the top-level directory and are used for adding and
|
||||
removing variables:
|
||||
|
||||
=============== ========================================
|
||||
new_var: Takes a "struct efi_variable" and
|
||||
instructs the EFI firmware to create a
|
||||
new variable.
|
||||
|
||||
del_var: Takes a "struct efi_variable" and
|
||||
instructs the EFI firmware to remove any
|
||||
variable that has a matching vendor GUID
|
||||
and variable key name.
|
||||
=============== ========================================
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
What: /sys/firmware/opal/dump
|
||||
Date: Feb 2014
|
||||
Contact: Stewart Smith <stewart@linux.vnet.ibm.com>
|
||||
Description:
|
||||
This directory exposes interfaces for interacting with
|
||||
the FSP and platform dumps through OPAL firmware interface.
|
||||
|
||||
This is only for the powerpc/powernv platform.
|
||||
|
||||
=============== ===============================================
|
||||
initiate_dump: When '1' is written to it,
|
||||
we will initiate a dump.
|
||||
Read this file for supported commands.
|
||||
|
||||
0xXX-0xYYYY: A directory for dump of type 0xXX and
|
||||
id 0xYYYY (in hex). The name of this
|
||||
directory should not be relied upon to
|
||||
be in this format, only that it's unique
|
||||
among all dumps. For determining the type
|
||||
and ID of the dump, use the id and type files.
|
||||
Do not rely on any particular size of dump
|
||||
type or dump id.
|
||||
=============== ===============================================
|
||||
|
||||
Each dump has the following files:
|
||||
|
||||
=============== ===============================================
|
||||
id: An ASCII representation of the dump ID
|
||||
in hex (e.g. '0x01')
|
||||
type: An ASCII representation of the type of
|
||||
dump in the format "0x%x %s" with the ID
|
||||
in hex and a description of the dump type
|
||||
(or 'unknown').
|
||||
Type '0xffffffff unknown' is used when
|
||||
we could not get the type from firmware.
|
||||
e.g. '0x02 System/Platform Dump'
|
||||
dump: A binary file containing the dump.
|
||||
The size of the dump is the size of this file.
|
||||
acknowledge: When 'ack' is written to this, we will
|
||||
acknowledge that we've retrieved the
|
||||
dump to the service processor. It will
|
||||
then remove it, making the dump
|
||||
inaccessible.
|
||||
Reading this file will get a list of
|
||||
supported actions.
|
||||
=============== ===============================================
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
What: /sys/firmware/opal/elog
|
||||
Date: Feb 2014
|
||||
Contact: Stewart Smith <stewart@linux.vnet.ibm.com>
|
||||
Description:
|
||||
This directory exposes error log entries retrieved
|
||||
through the OPAL firmware interface.
|
||||
|
||||
Each error log is identified by a unique ID and will
|
||||
exist until explicitly acknowledged to firmware.
|
||||
|
||||
Each log entry has a directory in /sys/firmware/opal/elog.
|
||||
|
||||
Log entries may be purged by the service processor
|
||||
before retrieved by firmware or retrieved/acknowledged by
|
||||
Linux if there is no room for more log entries.
|
||||
|
||||
In the event that Linux has retrieved the log entries
|
||||
but not explicitly acknowledged them to firmware and
|
||||
the service processor needs more room for log entries,
|
||||
the only remaining copy of a log message may be in
|
||||
Linux.
|
||||
|
||||
Typically, a user space daemon will monitor for new
|
||||
entries, read them out and acknowledge them.
|
||||
|
||||
The service processor may be able to store more log
|
||||
entries than firmware can, so after you acknowledge
|
||||
an event from Linux you may instantly get another one
|
||||
from the queue that was generated some time in the past.
|
||||
|
||||
The raw log format is a binary format. We currently
|
||||
do not parse this at all in kernel, leaving it up to
|
||||
user space to solve the problem. In future, we may
|
||||
do more parsing in kernel and add more files to make
|
||||
it easier for simple user space processes to extract
|
||||
more information.
|
||||
|
||||
For each log entry (directory), there are the following
|
||||
files:
|
||||
|
||||
============== ================================================
|
||||
id: An ASCII representation of the ID of the
|
||||
error log, in hex - e.g. "0x01".
|
||||
|
||||
type: An ASCII representation of the type id and
|
||||
description of the type of error log.
|
||||
Currently just "0x00 PEL" - platform error log.
|
||||
In the future there may be additional types.
|
||||
|
||||
raw: A read-only binary file that can be read
|
||||
to get the raw log entry. These are
|
||||
<16kb, often just hundreds of bytes and
|
||||
"average" 2kb.
|
||||
|
||||
acknowledge: Writing 'ack' to this file will acknowledge
|
||||
the error log to firmware (and in turn
|
||||
the service processor, if applicable).
|
||||
Shortly after acknowledging it, the log
|
||||
entry will be removed from sysfs.
|
||||
Reading this file will list the supported
|
||||
operations (currently just acknowledge).
|
||||
============== ================================================
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
What: /sys/fs/orangefs/perf_counters/*
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Counters and settings for various caches.
|
||||
Read only.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/perf_counter_reset
|
||||
Date: June 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
echo a 0 or a 1 into perf_counter_reset to
|
||||
reset all the counters in
|
||||
/sys/fs/orangefs/perf_counters
|
||||
except ones with PINT_PERF_PRESERVE set.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/perf_time_interval_secs
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Length of perf counter intervals in
|
||||
seconds.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/perf_history_size
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
The perf_counters cache statistics have N, or
|
||||
perf_history_size, samples. The default is
|
||||
one.
|
||||
|
||||
Every perf_time_interval_secs the (first)
|
||||
samples are reset.
|
||||
|
||||
If N is greater than one, the "current" set
|
||||
of samples is reset, and the samples from the
|
||||
other N-1 intervals remain available.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/op_timeout_secs
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Service operation timeout in seconds.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/slot_timeout_secs
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
"Slot" timeout in seconds. A "slot"
|
||||
is an indexed buffer in the shared
|
||||
memory segment used for communication
|
||||
between the kernel module and userspace.
|
||||
Slots are requested and waited for,
|
||||
the wait times out after slot_timeout_secs.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/acache/*
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Attribute cache configurable settings.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/ncache/*
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Name cache configurable settings.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/capcache/*
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Capability cache configurable settings.
|
||||
|
||||
|
||||
What: /sys/fs/orangefs/ccache/*
|
||||
Date: Jun 2015
|
||||
Contact: Mike Marshall <hubcap@omnibond.com>
|
||||
Description:
|
||||
Credential cache configurable settings.
|
||||
|
|
@ -0,0 +1,135 @@
|
|||
What: /sys/hypervisor/compilation/compile_date
|
||||
Date: March 2009
|
||||
KernelVersion: 2.6.30
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
Contains the build time stamp of the Xen hypervisor
|
||||
Might return "<denied>" in case of special security settings
|
||||
in the hypervisor.
|
||||
|
||||
What: /sys/hypervisor/compilation/compiled_by
|
||||
Date: March 2009
|
||||
KernelVersion: 2.6.30
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
Contains information who built the Xen hypervisor
|
||||
Might return "<denied>" in case of special security settings
|
||||
in the hypervisor.
|
||||
|
||||
What: /sys/hypervisor/compilation/compiler
|
||||
Date: March 2009
|
||||
KernelVersion: 2.6.30
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
Compiler which was used to build the Xen hypervisor
|
||||
Might return "<denied>" in case of special security settings
|
||||
in the hypervisor.
|
||||
|
||||
What: /sys/hypervisor/properties/capabilities
|
||||
Date: March 2009
|
||||
KernelVersion: 2.6.30
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
Space separated list of supported guest system types. Each type
|
||||
is in the format: <class>-<major>.<minor>-<arch>
|
||||
With:
|
||||
|
||||
======== ============================================
|
||||
<class>: "xen" -- x86: paravirtualized, arm: standard
|
||||
"hvm" -- x86 only: fully virtualized
|
||||
<major>: major guest interface version
|
||||
<minor>: minor guest interface version
|
||||
<arch>: architecture, e.g.:
|
||||
"x86_32": 32 bit x86 guest without PAE
|
||||
"x86_32p": 32 bit x86 guest with PAE
|
||||
"x86_64": 64 bit x86 guest
|
||||
"armv7l": 32 bit arm guest
|
||||
"aarch64": 64 bit arm guest
|
||||
======== ============================================
|
||||
|
||||
What: /sys/hypervisor/properties/changeset
|
||||
Date: March 2009
|
||||
KernelVersion: 2.6.30
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
Changeset of the hypervisor (git commit)
|
||||
Might return "<denied>" in case of special security settings
|
||||
in the hypervisor.
|
||||
|
||||
What: /sys/hypervisor/properties/features
|
||||
Date: March 2009
|
||||
KernelVersion: 2.6.30
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
Features the Xen hypervisor supports for the guest as defined
|
||||
in include/xen/interface/features.h printed as a hex value.
|
||||
|
||||
What: /sys/hypervisor/properties/pagesize
|
||||
Date: March 2009
|
||||
KernelVersion: 2.6.30
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
Default page size of the hypervisor printed as a hex value.
|
||||
Might return "0" in case of special security settings
|
||||
in the hypervisor.
|
||||
|
||||
What: /sys/hypervisor/properties/virtual_start
|
||||
Date: March 2009
|
||||
KernelVersion: 2.6.30
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
Virtual address of the hypervisor as a hex value.
|
||||
|
||||
What: /sys/hypervisor/type
|
||||
Date: March 2009
|
||||
KernelVersion: 2.6.30
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
Type of hypervisor:
|
||||
"xen": Xen hypervisor
|
||||
|
||||
What: /sys/hypervisor/uuid
|
||||
Date: March 2009
|
||||
KernelVersion: 2.6.30
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
UUID of the guest as known to the Xen hypervisor.
|
||||
|
||||
What: /sys/hypervisor/version/extra
|
||||
Date: March 2009
|
||||
KernelVersion: 2.6.30
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
The Xen version is in the format <major>.<minor><extra>
|
||||
This is the <extra> part of it.
|
||||
Might return "<denied>" in case of special security settings
|
||||
in the hypervisor.
|
||||
|
||||
What: /sys/hypervisor/version/major
|
||||
Date: March 2009
|
||||
KernelVersion: 2.6.30
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
The Xen version is in the format <major>.<minor><extra>
|
||||
This is the <major> part of it.
|
||||
|
||||
What: /sys/hypervisor/version/minor
|
||||
Date: March 2009
|
||||
KernelVersion: 2.6.30
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
The Xen version is in the format <major>.<minor><extra>
|
||||
This is the <minor> part of it.
|
||||
|
||||
What: /sys/hypervisor/start_flags/*
|
||||
Date: March 2023
|
||||
KernelVersion: 6.3.0
|
||||
Contact: xen-devel@lists.xenproject.org
|
||||
Description: If running under Xen:
|
||||
All bits in Xen's start-flags are represented as
|
||||
boolean files, returning '1' if set, '0' otherwise.
|
||||
This takes the place of the defunct /proc/xen/capabilities,
|
||||
which would contain "control_d" on dom0, and be empty
|
||||
otherwise. This flag is now exposed as "initdomain" in
|
||||
addition to the "privileged" flag; all other possible flags
|
||||
are accessible as "unknownXX".
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
What: /sys/kernel/notes
|
||||
Date: July 2009
|
||||
Contact: <linux-kernel@vger.kernel.org>
|
||||
Description: The /sys/kernel/notes file contains the binary representation
|
||||
of the running vmlinux's .notes section.
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
The /sys/module tree consists of the following structure:
|
||||
|
||||
What: /sys/module/<MODULENAME>
|
||||
Description:
|
||||
The name of the module that is in the kernel. This
|
||||
module name will always show up if the module is loaded as a
|
||||
dynamic module. If it is built directly into the kernel, it
|
||||
will only show up if it has a version or at least one
|
||||
parameter.
|
||||
|
||||
Note: The conditions of creation in the built-in case are not
|
||||
by design and may be removed in the future.
|
||||
|
||||
What: /sys/module/<MODULENAME>/parameters
|
||||
Description:
|
||||
This directory contains individual files that are each
|
||||
individual parameters of the module that are able to be
|
||||
changed at runtime. See the individual module
|
||||
documentation as to the contents of these parameters and
|
||||
what they accomplish.
|
||||
|
||||
Note: The individual parameter names and values are not
|
||||
considered stable, only the fact that they will be
|
||||
placed in this location within sysfs. See the
|
||||
individual driver documentation for details as to the
|
||||
stability of the different parameters.
|
||||
|
||||
What: /sys/module/<MODULENAME>/refcnt
|
||||
Description:
|
||||
If the module is able to be unloaded from the kernel, this file
|
||||
will contain the current reference count of the module.
|
||||
|
||||
Note: If the module is built into the kernel, or if the
|
||||
CONFIG_MODULE_UNLOAD kernel configuration value is not enabled,
|
||||
this file will not be present.
|
||||
|
||||
What: /sys/module/<MODULENAME>/srcversion
|
||||
Date: Jun 2005
|
||||
Description:
|
||||
If the module source has MODULE_VERSION, this file will contain
|
||||
the checksum of the source code.
|
||||
|
||||
What: /sys/module/<MODULENAME>/version
|
||||
Date: Jun 2005
|
||||
Description:
|
||||
If the module source has MODULE_VERSION, this file will contain
|
||||
the version of the source code.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
What: /sys/bus/wmi/devices/05901221-D566-11D1-B2F0-00A0C9062910[-X]/bmof
|
||||
Date: Jun 2017
|
||||
KernelVersion: 4.13
|
||||
Description:
|
||||
Binary MOF metadata used to describe the details of available ACPI WMI interfaces.
|
||||
|
||||
See Documentation/wmi/devices/wmi-bmof.rst for details.
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
What: /sys/class/srp_remote_ports/port-<h>:<n>/delete
|
||||
Date: June 1, 2012
|
||||
KernelVersion: 3.7
|
||||
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
|
||||
Description: Instructs an SRP initiator to disconnect from a target and to
|
||||
remove all LUNs imported from that target.
|
||||
|
||||
What: /sys/class/srp_remote_ports/port-<h>:<n>/dev_loss_tmo
|
||||
Date: February 1, 2014
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
|
||||
Description: Number of seconds the SCSI layer will wait after a transport
|
||||
layer error has been observed before removing a target port.
|
||||
Zero means immediate removal. Setting this attribute to "off"
|
||||
will disable the dev_loss timer.
|
||||
|
||||
What: /sys/class/srp_remote_ports/port-<h>:<n>/fast_io_fail_tmo
|
||||
Date: February 1, 2014
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
|
||||
Description: Number of seconds the SCSI layer will wait after a transport
|
||||
layer error has been observed before failing I/O. Zero means
|
||||
failing I/O immediately. Setting this attribute to "off" will
|
||||
disable the fast_io_fail timer.
|
||||
|
||||
What: /sys/class/srp_remote_ports/port-<h>:<n>/port_id
|
||||
Date: June 27, 2007
|
||||
KernelVersion: 2.6.24
|
||||
Contact: linux-scsi@vger.kernel.org
|
||||
Description: 16-byte local SRP port identifier in hexadecimal format. An
|
||||
example: 4c:49:4e:55:58:20:56:49:4f:00:00:00:00:00:00:00.
|
||||
|
||||
What: /sys/class/srp_remote_ports/port-<h>:<n>/reconnect_delay
|
||||
Date: February 1, 2014
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
|
||||
Description: Number of seconds the SCSI layer will wait after a reconnect
|
||||
attempt failed before retrying. Setting this attribute to
|
||||
"off" will disable time-based reconnecting.
|
||||
|
||||
What: /sys/class/srp_remote_ports/port-<h>:<n>/roles
|
||||
Date: June 27, 2007
|
||||
KernelVersion: 2.6.24
|
||||
Contact: linux-scsi@vger.kernel.org
|
||||
Description: Role of the remote port. Either "SRP Initiator" or "SRP Target".
|
||||
|
||||
What: /sys/class/srp_remote_ports/port-<h>:<n>/state
|
||||
Date: February 1, 2014
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
|
||||
Description: State of the transport layer used for communication with the
|
||||
remote port. "running" if the transport layer is operational;
|
||||
"blocked" if a transport layer error has been encountered but
|
||||
the fast_io_fail_tmo timer has not yet fired; "fail-fast"
|
||||
after the fast_io_fail_tmo timer has fired and before the
|
||||
"dev_loss_tmo" timer has fired; "lost" after the
|
||||
"dev_loss_tmo" timer has fired and before the port is finally
|
||||
removed.
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
What: A notification mechanism for thermal related events
|
||||
Description:
|
||||
This interface enables notification for thermal related events.
|
||||
The notification is in the form of a netlink event.
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
What: vDSO
|
||||
Date: July 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: Andy Lutomirski <luto@kernel.org>
|
||||
Description:
|
||||
|
||||
On some architectures, when the kernel loads any userspace program it
|
||||
maps an ELF DSO into that program's address space. This DSO is called
|
||||
the vDSO and it often contains useful and highly-optimized alternatives
|
||||
to real syscalls.
|
||||
|
||||
These functions are called just like ordinary C function according to
|
||||
your platform's ABI. Call them from a sensible context. (For example,
|
||||
if you set CS on x86 to something strange, the vDSO functions are
|
||||
within their rights to crash.) In addition, if you pass a bad
|
||||
pointer to a vDSO function, you might get SIGSEGV instead of -EFAULT.
|
||||
|
||||
To find the DSO, parse the auxiliary vector passed to the program's
|
||||
entry point. The AT_SYSINFO_EHDR entry will point to the vDSO.
|
||||
|
||||
The vDSO uses symbol versioning; whenever you request a symbol from the
|
||||
vDSO, specify the version you are expecting.
|
||||
|
||||
Programs that dynamically link to glibc will use the vDSO automatically.
|
||||
Otherwise, you can use the reference parser in
|
||||
tools/testing/selftests/vDSO/parse_vdso.c.
|
||||
|
||||
Unless otherwise noted, the set of symbols with any given version and the
|
||||
ABI of those symbols is considered stable. It may vary across architectures,
|
||||
though.
|
||||
|
||||
Note:
|
||||
As of this writing, this ABI documentation as been confirmed for x86_64.
|
||||
The maintainers of the other vDSO-using architectures should confirm
|
||||
that it is correct for their architecture.
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
What: /config/acpi
|
||||
Date: July 2016
|
||||
KernelVersion: 4.8
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description:
|
||||
This represents the ACPI subsystem entry point directory. It
|
||||
contains sub-groups corresponding to ACPI configurable options.
|
||||
|
||||
What: /config/acpi/table
|
||||
Date: July 2016
|
||||
KernelVersion: 4.8
|
||||
Description:
|
||||
|
||||
This group contains the configuration for user defined ACPI
|
||||
tables. The attributes of a user define table are:
|
||||
|
||||
aml
|
||||
- a binary attribute that the user can use to
|
||||
fill in the ACPI aml definitions. Once the aml
|
||||
data is written to this file and the file is
|
||||
closed the table will be loaded and ACPI devices
|
||||
will be enumerated. To check if the operation is
|
||||
successful the user must check the error code
|
||||
for close(). If the operation is successful,
|
||||
subsequent writes to this attribute will fail.
|
||||
|
||||
The rest of the attributes are read-only and are valid only
|
||||
after the table has been loaded by filling the aml entry:
|
||||
|
||||
signature
|
||||
- ASCII table signature
|
||||
|
||||
length
|
||||
- length of table in bytes, including the header
|
||||
|
||||
revision
|
||||
- ACPI Specification minor version number
|
||||
|
||||
oem_id
|
||||
- ASCII OEM identification
|
||||
|
||||
oem_table_id
|
||||
- ASCII OEM table identification
|
||||
|
||||
oem_revision
|
||||
- OEM revision number
|
||||
|
||||
asl_compiler_id
|
||||
- ASCII ASL compiler vendor ID
|
||||
|
||||
asl_compiler_revision
|
||||
- ASL compiler version
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
What: /config/iio
|
||||
Date: October 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
This represents Industrial IO configuration entry point
|
||||
directory. It contains sub-groups corresponding to IIO
|
||||
objects.
|
||||
|
||||
What: /config/iio/triggers
|
||||
Date: October 2015
|
||||
KernelVersion: 4.4
|
||||
Description:
|
||||
Industrial IO software triggers directory.
|
||||
|
||||
What: /config/iio/triggers/hrtimers
|
||||
Date: October 2015
|
||||
KernelVersion: 4.4
|
||||
Description:
|
||||
High resolution timers directory. Creating a directory here
|
||||
will result in creating a hrtimer trigger in the IIO subsystem.
|
||||
|
||||
What: /config/iio/devices
|
||||
Date: April 2016
|
||||
KernelVersion: 4.7
|
||||
Description:
|
||||
Industrial IO software devices directory.
|
||||
|
||||
What: /config/iio/devices/dummy
|
||||
Date: April 2016
|
||||
KernelVersion: 4.7
|
||||
Description:
|
||||
Dummy IIO devices directory. Creating a directory here will result
|
||||
in creating a dummy IIO device in the IIO subsystem.
|
||||
|
|
@ -0,0 +1,241 @@
|
|||
What: /sys/kernel/config/most_<component>
|
||||
Date: March 8, 2019
|
||||
KernelVersion: 5.2
|
||||
Description: Interface is used to configure and connect device channels
|
||||
to component drivers.
|
||||
|
||||
Attributes are visible only when configfs is mounted. To mount
|
||||
configfs in /sys/kernel/config directory use:
|
||||
# mount -t configfs none /sys/kernel/config/
|
||||
|
||||
|
||||
What: /sys/kernel/config/most_cdev/<link>
|
||||
Date: March 8, 2019
|
||||
KernelVersion: 5.2
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
buffer_size
|
||||
configure the buffer size for this channel
|
||||
|
||||
subbuffer_size
|
||||
configure the sub-buffer size for this channel
|
||||
(needed for synchronous and isochronous data)
|
||||
|
||||
|
||||
num_buffers
|
||||
configure number of buffers used for this
|
||||
channel
|
||||
|
||||
datatype
|
||||
configure type of data that will travel over
|
||||
this channel
|
||||
|
||||
direction
|
||||
configure whether this link will be an input
|
||||
or output
|
||||
|
||||
dbr_size
|
||||
configure DBR data buffer size (this is used
|
||||
for MediaLB communication only)
|
||||
|
||||
packets_per_xact
|
||||
configure the number of packets that will be
|
||||
collected from the network before being
|
||||
transmitted via USB (this is used for USB
|
||||
communication only)
|
||||
|
||||
device
|
||||
name of the device the link is to be attached to
|
||||
|
||||
channel
|
||||
name of the channel the link is to be attached to
|
||||
|
||||
comp_params
|
||||
pass parameters needed by some components
|
||||
|
||||
create_link
|
||||
write '1' to this attribute to trigger the
|
||||
creation of the link. In case of speculative
|
||||
configuration, the creation is post-poned until
|
||||
a physical device is being attached to the bus.
|
||||
|
||||
destroy_link
|
||||
write '1' to this attribute to destroy an
|
||||
active link
|
||||
|
||||
What: /sys/kernel/config/most_video/<link>
|
||||
Date: March 8, 2019
|
||||
KernelVersion: 5.2
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
buffer_size
|
||||
configure the buffer size for this channel
|
||||
|
||||
subbuffer_size
|
||||
configure the sub-buffer size for this channel
|
||||
(needed for synchronous and isochronous data)
|
||||
|
||||
|
||||
num_buffers
|
||||
configure number of buffers used for this
|
||||
channel
|
||||
|
||||
datatype
|
||||
configure type of data that will travel over
|
||||
this channel
|
||||
|
||||
direction
|
||||
configure whether this link will be an input
|
||||
or output
|
||||
|
||||
dbr_size
|
||||
configure DBR data buffer size (this is used
|
||||
for MediaLB communication only)
|
||||
|
||||
packets_per_xact
|
||||
configure the number of packets that will be
|
||||
collected from the network before being
|
||||
transmitted via USB (this is used for USB
|
||||
communication only)
|
||||
|
||||
device
|
||||
name of the device the link is to be attached to
|
||||
|
||||
channel
|
||||
name of the channel the link is to be attached to
|
||||
|
||||
comp_params
|
||||
pass parameters needed by some components
|
||||
|
||||
create_link
|
||||
write '1' to this attribute to trigger the
|
||||
creation of the link. In case of speculative
|
||||
configuration, the creation is post-poned until
|
||||
a physical device is being attached to the bus.
|
||||
|
||||
destroy_link
|
||||
write '1' to this attribute to destroy an
|
||||
active link
|
||||
|
||||
What: /sys/kernel/config/most_net/<link>
|
||||
Date: March 8, 2019
|
||||
KernelVersion: 5.2
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
buffer_size
|
||||
configure the buffer size for this channel
|
||||
|
||||
subbuffer_size
|
||||
configure the sub-buffer size for this channel
|
||||
(needed for synchronous and isochronous data)
|
||||
|
||||
|
||||
num_buffers
|
||||
configure number of buffers used for this
|
||||
channel
|
||||
|
||||
datatype
|
||||
configure type of data that will travel over
|
||||
this channel
|
||||
|
||||
direction
|
||||
configure whether this link will be an input
|
||||
or output
|
||||
|
||||
dbr_size
|
||||
configure DBR data buffer size (this is used
|
||||
for MediaLB communication only)
|
||||
|
||||
packets_per_xact
|
||||
configure the number of packets that will be
|
||||
collected from the network before being
|
||||
transmitted via USB (this is used for USB
|
||||
communication only)
|
||||
|
||||
device
|
||||
name of the device the link is to be attached to
|
||||
|
||||
channel
|
||||
name of the channel the link is to be attached to
|
||||
|
||||
comp_params
|
||||
pass parameters needed by some components
|
||||
|
||||
create_link
|
||||
write '1' to this attribute to trigger the
|
||||
creation of the link. In case of speculative
|
||||
configuration, the creation is post-poned until
|
||||
a physical device is being attached to the bus.
|
||||
|
||||
destroy_link
|
||||
write '1' to this attribute to destroy an
|
||||
active link
|
||||
|
||||
What: /sys/kernel/config/most_sound/<card>
|
||||
Date: March 8, 2019
|
||||
KernelVersion: 5.2
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
create_card
|
||||
write '1' to this attribute to trigger the
|
||||
registration of the sound card with the ALSA
|
||||
subsystem.
|
||||
|
||||
What: /sys/kernel/config/most_sound/<card>/<link>
|
||||
Date: March 8, 2019
|
||||
KernelVersion: 5.2
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
buffer_size
|
||||
configure the buffer size for this channel
|
||||
|
||||
subbuffer_size
|
||||
configure the sub-buffer size for this channel
|
||||
(needed for synchronous and isochronous data)
|
||||
|
||||
|
||||
num_buffers
|
||||
configure number of buffers used for this
|
||||
channel
|
||||
|
||||
datatype
|
||||
configure type of data that will travel over
|
||||
this channel
|
||||
|
||||
direction
|
||||
configure whether this link will be an input
|
||||
or output
|
||||
|
||||
dbr_size
|
||||
configure DBR data buffer size (this is used
|
||||
for MediaLB communication only)
|
||||
|
||||
packets_per_xact
|
||||
configure the number of packets that will be
|
||||
collected from the network before being
|
||||
transmitted via USB (this is used for USB
|
||||
communication only)
|
||||
|
||||
device
|
||||
name of the device the link is to be attached to
|
||||
|
||||
channel
|
||||
name of the channel the link is to be attached to
|
||||
|
||||
comp_params
|
||||
pass parameters needed by some components
|
||||
|
||||
create_link
|
||||
write '1' to this attribute to trigger the
|
||||
creation of the link. In case of speculative
|
||||
configuration, the creation is post-poned until
|
||||
a physical device is being attached to the bus.
|
||||
|
||||
destroy_link
|
||||
write '1' to this attribute to destroy an
|
||||
active link
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
What: /config/rdma_cm
|
||||
Date: November 29, 2015
|
||||
KernelVersion: 4.4.0
|
||||
Description: Interface is used to configure RDMA-cable HCAs in respect to
|
||||
RDMA-CM attributes.
|
||||
|
||||
Attributes are visible only when configfs is mounted. To mount
|
||||
configfs in /config directory use:
|
||||
# mount -t configfs none /config/
|
||||
|
||||
In order to set parameters related to a specific HCA, a directory
|
||||
for this HCA has to be created:
|
||||
mkdir -p /config/rdma_cm/<hca>
|
||||
|
||||
|
||||
What: /config/rdma_cm/<hca>/ports/<port-num>/default_roce_mode
|
||||
Date: November 29, 2015
|
||||
KernelVersion: 4.4.0
|
||||
Description: RDMA-CM based connections from HCA <hca> at port <port-num>
|
||||
will be initiated with this RoCE type as default.
|
||||
The possible RoCE types are either "IB/RoCE v1" or "RoCE v2".
|
||||
This parameter has RW access.
|
||||
|
||||
What: /config/rdma_cm/<hca>/ports/<port-num>/default_roce_tos
|
||||
Date: February 7, 2017
|
||||
KernelVersion: 4.11.0
|
||||
Description: RDMA-CM QPs from HCA <hca> at port <port-num>
|
||||
will be created with this TOS as default.
|
||||
This can be overridden by using the rdma_set_option API.
|
||||
The possible RoCE TOS values are 0-255.
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
What: /config/pcie-gadget
|
||||
Date: Feb 2011
|
||||
KernelVersion: 2.6.37
|
||||
Contact: Pratyush Anand <pratyush.anand@gmail.com>
|
||||
Description:
|
||||
|
||||
Interface is used to configure selected dual mode PCIe controller
|
||||
as device and then program its various registers to configure it
|
||||
as a particular device type.
|
||||
This interfaces can be used to show spear's PCIe device capability.
|
||||
|
||||
Nodes are only visible when configfs is mounted. To mount configfs
|
||||
in /config directory use::
|
||||
|
||||
# mount -t configfs none /config/
|
||||
|
||||
For nth PCIe Device Controller /config/pcie-gadget.n/:
|
||||
|
||||
=============== ======================================================
|
||||
link used to enable ltssm and read its status.
|
||||
int_type used to configure and read type of supported interrupt
|
||||
no_of_msi used to configure number of MSI vector needed and
|
||||
to read no of MSI granted.
|
||||
inta write 1 to assert INTA and 0 to de-assert.
|
||||
send_msi write MSI vector to be sent.
|
||||
vendor_id used to write and read vendor id (hex)
|
||||
device_id used to write and read device id (hex)
|
||||
bar0_size used to write and read bar0_size
|
||||
bar0_address used to write and read bar0 mapped area in hex.
|
||||
bar0_rw_offset used to write and read offset of bar0 where bar0_data
|
||||
will be written or read.
|
||||
bar0_data used to write and read data at bar0_rw_offset.
|
||||
=============== ======================================================
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue