Merge remote-tracking branch 'drm/drm-next' into drm-misc-next

drm-misc-next is still based on v4.16-rc7, and was getting a bit stale.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

.clang-format

@@ -0,0 +1,428 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# clang-format configuration file. Intended for clang-format >= 4.
+#
+# 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 # Unknown to clang-format-4.0
+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 # Unknown to clang-format-5.0
+  BeforeCatch: false
+  BeforeElse: false
+  IndentBraces: false
+  #SplitEmptyFunction: true # Unknown to clang-format-4.0
+  #SplitEmptyRecord: true # Unknown to clang-format-4.0
+  #SplitEmptyNamespace: true # Unknown to clang-format-4.0
+BreakBeforeBinaryOperators: None
+BreakBeforeBraces: Custom
+#BreakBeforeInheritanceComma: false # Unknown to clang-format-4.0
+BreakBeforeTernaryOperators: false
+BreakConstructorInitializersBeforeComma: false
+#BreakConstructorInitializers: BeforeComma # Unknown to clang-format-4.0
+BreakAfterJavaFieldAnnotations: false
+BreakStringLiterals: false
+ColumnLimit: 80
+CommentPragmas: '^ IWYU pragma:'
+#CompactNamespaces: false # Unknown to clang-format-4.0
+ConstructorInitializerAllOnOneLineOrOnePerLine: false
+ConstructorInitializerIndentWidth: 8
+ContinuationIndentWidth: 8
+Cpp11BracedListStyle: false
+DerivePointerAlignment: false
+DisableFormat: false
+ExperimentalAutoDetectBinPacking: false
+#FixNamespaceComments: false # Unknown to clang-format-4.0
+
+# Taken from:
+#   git grep -h '^#define [^[:space:]]*for_each[^[:space:]]*(' include/ \
+#   | sed "s,^#define \([^[:space:]]*for_each[^[:space:]]*\)(.*$,  - '\1'," \
+#   | sort | uniq
+ForEachMacros:
+  - 'apei_estatus_for_each_section'
+  - 'ata_for_each_dev'
+  - 'ata_for_each_link'
+  - 'ax25_for_each'
+  - 'ax25_uid_for_each'
+  - 'bio_for_each_integrity_vec'
+  - '__bio_for_each_segment'
+  - 'bio_for_each_segment'
+  - 'bio_for_each_segment_all'
+  - 'bio_list_for_each'
+  - 'bip_for_each_vec'
+  - 'blkg_for_each_descendant_post'
+  - 'blkg_for_each_descendant_pre'
+  - 'blk_queue_for_each_rl'
+  - 'bond_for_each_slave'
+  - 'bond_for_each_slave_rcu'
+  - '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'
+  - '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'
+  - 'device_for_each_child_node'
+  - 'drm_atomic_crtc_for_each_plane'
+  - 'drm_atomic_crtc_state_for_each_plane'
+  - 'drm_atomic_crtc_state_for_each_plane_state'
+  - 'drm_for_each_connector_iter'
+  - 'drm_for_each_crtc'
+  - '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_mm_for_each_hole'
+  - 'drm_mm_for_each_node'
+  - 'drm_mm_for_each_node_in_range'
+  - 'drm_mm_for_each_node_safe'
+  - 'for_each_active_drhd_unit'
+  - 'for_each_active_iommu'
+  - 'for_each_available_child_of_node'
+  - 'for_each_bio'
+  - 'for_each_board_func_rsrc'
+  - 'for_each_bvec'
+  - 'for_each_child_of_node'
+  - 'for_each_clear_bit'
+  - 'for_each_clear_bit_from'
+  - 'for_each_cmsghdr'
+  - 'for_each_compatible_node'
+  - 'for_each_console'
+  - 'for_each_cpu'
+  - 'for_each_cpu_and'
+  - 'for_each_cpu_not'
+  - 'for_each_cpu_wrap'
+  - 'for_each_dev_addr'
+  - 'for_each_dma_cap_mask'
+  - 'for_each_drhd_unit'
+  - 'for_each_dss_dev'
+  - 'for_each_efi_memory_desc'
+  - 'for_each_efi_memory_desc_in_map'
+  - 'for_each_endpoint_of_node'
+  - 'for_each_evictable_lru'
+  - 'for_each_fib6_node_rt_rcu'
+  - 'for_each_fib6_walker_rt'
+  - 'for_each_free_mem_range'
+  - 'for_each_free_mem_range_reverse'
+  - 'for_each_func_rsrc'
+  - 'for_each_hstate'
+  - 'for_each_if'
+  - 'for_each_iommu'
+  - 'for_each_ip_tunnel_rcu'
+  - 'for_each_irq_nr'
+  - 'for_each_lru'
+  - 'for_each_matching_node'
+  - 'for_each_matching_node_and_match'
+  - 'for_each_memblock'
+  - 'for_each_memblock_type'
+  - 'for_each_memcg_cache_index'
+  - 'for_each_mem_pfn_range'
+  - 'for_each_mem_range'
+  - 'for_each_mem_range_rev'
+  - 'for_each_migratetype_order'
+  - 'for_each_msi_entry'
+  - 'for_each_net'
+  - 'for_each_netdev'
+  - 'for_each_netdev_continue'
+  - 'for_each_netdev_continue_rcu'
+  - 'for_each_netdev_feature'
+  - 'for_each_netdev_in_bond_rcu'
+  - 'for_each_netdev_rcu'
+  - 'for_each_netdev_reverse'
+  - 'for_each_netdev_safe'
+  - 'for_each_net_rcu'
+  - 'for_each_new_connector_in_state'
+  - 'for_each_new_crtc_in_state'
+  - 'for_each_new_plane_in_state'
+  - 'for_each_new_private_obj_in_state'
+  - '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_of_allnodes'
+  - 'for_each_of_allnodes_from'
+  - 'for_each_of_pci_range'
+  - 'for_each_old_connector_in_state'
+  - 'for_each_old_crtc_in_state'
+  - 'for_each_oldnew_connector_in_state'
+  - 'for_each_oldnew_crtc_in_state'
+  - 'for_each_oldnew_plane_in_state'
+  - 'for_each_oldnew_private_obj_in_state'
+  - 'for_each_old_plane_in_state'
+  - 'for_each_old_private_obj_in_state'
+  - 'for_each_online_cpu'
+  - 'for_each_online_node'
+  - 'for_each_online_pgdat'
+  - 'for_each_pci_bridge'
+  - 'for_each_pci_dev'
+  - 'for_each_pci_msi_entry'
+  - 'for_each_populated_zone'
+  - 'for_each_possible_cpu'
+  - 'for_each_present_cpu'
+  - 'for_each_prime_number'
+  - 'for_each_prime_number_from'
+  - 'for_each_process'
+  - 'for_each_process_thread'
+  - 'for_each_property_of_node'
+  - 'for_each_reserved_mem_region'
+  - 'for_each_resv_unavail_range'
+  - 'for_each_rtdcom'
+  - 'for_each_rtdcom_safe'
+  - 'for_each_set_bit'
+  - 'for_each_set_bit_from'
+  - 'for_each_sg'
+  - 'for_each_sg_page'
+  - '__for_each_thread'
+  - 'for_each_thread'
+  - 'for_each_zone'
+  - 'for_each_zone_zonelist'
+  - 'for_each_zone_zonelist_nodemask'
+  - 'fwnode_for_each_available_child_node'
+  - 'fwnode_for_each_child_node'
+  - 'fwnode_graph_for_each_endpoint'
+  - 'gadget_for_each_ep'
+  - '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'
+  - 'hctx_for_each_ctx'
+  - '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_rcu'
+  - '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'
+  - 'ide_host_for_each_port'
+  - 'ide_port_for_each_dev'
+  - 'ide_port_for_each_present_dev'
+  - 'idr_for_each_entry'
+  - 'idr_for_each_entry_continue'
+  - 'idr_for_each_entry_ul'
+  - 'inet_bind_bucket_for_each'
+  - 'inet_lhash2_for_each_icsk_rcu'
+  - 'iov_for_each'
+  - 'key_for_each'
+  - 'key_for_each_safe'
+  - 'klp_for_each_func'
+  - 'klp_for_each_object'
+  - 'kvm_for_each_memslot'
+  - 'kvm_for_each_vcpu'
+  - 'list_for_each'
+  - '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_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_prev'
+  - 'list_for_each_prev_safe'
+  - 'list_for_each_safe'
+  - 'llist_for_each'
+  - 'llist_for_each_entry'
+  - 'llist_for_each_entry_safe'
+  - 'llist_for_each_safe'
+  - 'media_device_for_each_entity'
+  - 'media_device_for_each_intf'
+  - 'media_device_for_each_link'
+  - 'media_device_for_each_pad'
+  - 'netdev_for_each_lower_dev'
+  - 'netdev_for_each_lower_private'
+  - 'netdev_for_each_lower_private_rcu'
+  - 'netdev_for_each_mc_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'
+  - 'ping_portaddr_for_each_entry'
+  - '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_contig'
+  - 'radix_tree_for_each_slot'
+  - 'radix_tree_for_each_tagged'
+  - 'rbtree_postorder_for_each_entry_safe'
+  - '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_continue'
+  - 'rht_for_each_entry'
+  - 'rht_for_each_entry_continue'
+  - 'rht_for_each_entry_rcu'
+  - 'rht_for_each_entry_rcu_continue'
+  - 'rht_for_each_entry_safe'
+  - 'rht_for_each_rcu'
+  - 'rht_for_each_rcu_continue'
+  - '__rq_for_each_bio'
+  - 'rq_for_each_segment'
+  - 'scsi_for_each_prot_sg'
+  - 'scsi_for_each_sg'
+  - 'sctp_for_each_hentry'
+  - 'sctp_skb_for_each'
+  - 'shdma_for_each_chan'
+  - '__shost_for_each_device'
+  - 'shost_for_each_device'
+  - 'sk_for_each'
+  - 'sk_for_each_bound'
+  - '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_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'
+  - 'tb_property_for_each'
+  - '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'
+  - 'zorro_for_each_dev'
+
+#IncludeBlocks: Preserve # Unknown to clang-format-5.0
+IncludeCategories:
+  - Regex: '.*'
+    Priority: 1
+IncludeIsMainRegex: '(Test)?$'
+IndentCaseLabels: false
+#IndentPPDirectives: None # Unknown to clang-format-5.0
+IndentWidth: 8
+IndentWrappedFunctionNames: true
+JavaScriptQuotes: Leave
+JavaScriptWrapImports: true
+KeepEmptyLinesAtTheStartOfBlocks: false
+MacroBlockBegin: ''
+MacroBlockEnd: ''
+MaxEmptyLinesToKeep: 1
+NamespaceIndentation: Inner
+#ObjCBinPackProtocolList: Auto # Unknown to clang-format-5.0
+ObjCBlockIndentWidth: 8
+ObjCSpaceAfterProperty: true
+ObjCSpaceBeforeProtocolList: true
+
+# Taken from git's rules
+#PenaltyBreakAssignment: 10 # Unknown to clang-format-4.0
+PenaltyBreakBeforeFirstCallParameter: 30
+PenaltyBreakComment: 10
+PenaltyBreakFirstLessLess: 0
+PenaltyBreakString: 10
+PenaltyExcessCharacter: 100
+PenaltyReturnTypeOnItsOwnLine: 60
+
+PointerAlignment: Right
+ReflowComments: false
+SortIncludes: false
+#SortUsingDeclarations: false # Unknown to clang-format-4.0
+SpaceAfterCStyleCast: false
+SpaceAfterTemplateKeyword: true
+SpaceBeforeAssignmentOperators: true
+#SpaceBeforeCtorInitializerColon: true # Unknown to clang-format-5.0
+#SpaceBeforeInheritanceColon: true # Unknown to clang-format-5.0
+SpaceBeforeParens: ControlStatements
+#SpaceBeforeRangeBasedForLoopColon: true # Unknown to clang-format-5.0
+SpaceInEmptyParentheses: false
+SpacesBeforeTrailingComments: 1
+SpacesInAngles: false
+SpacesInContainerLiterals: false
+SpacesInCStyleCastParentheses: false
+SpacesInParentheses: false
+SpacesInSquareBrackets: false
+Standard: Cpp03
+TabWidth: 8
+UseTab: Always
+...

.gitignore

@@ -11,6 +11,7 @@
 #
 .*
 *.a
+*.asn1.[ch]
 *.bin
 *.bz2
 *.c.[012]*.*
@@ -22,6 +23,7 @@
 *.gz
 *.i
 *.ko
+*.lex.c
 *.ll
 *.lst
 *.lz4
@@ -37,6 +39,7 @@
 *.so.dbg
 *.su
 *.symtypes
+*.tab.[ch]
 *.tar
 *.xz
 Module.symvers
@@ -81,12 +84,14 @@ modules.builtin
 !.gitignore
 !.mailmap
 !.cocciconfig
+!.clang-format
 
 #
 # Generated include files
 #
 include/config
 include/generated
+include/ksym
 arch/*/include/generated
 
 # stgit generated dirs
@@ -127,7 +132,3 @@ all.config
 
 # Kdevelop4
 *.kdev4
-
-#Automatically generated by ASN.1 compiler
-net/ipv4/netfilter/nf_nat_snmp_basic-asn1.c
-net/ipv4/netfilter/nf_nat_snmp_basic-asn1.h

.mailmap

@@ -18,6 +18,7 @@ Aleksey Gorelov <aleksey_gorelov@phoenix.com>
 Aleksandar Markovic <aleksandar.markovic@mips.com> <aleksandar.markovic@imgtec.com>
 Al Viro <viro@ftp.linux.org.uk>
 Al Viro <viro@zenIV.linux.org.uk>
+Andi Shyti <andi@etezian.org> <andi.shyti@samsung.com>
 Andreas Herrmann <aherrman@de.ibm.com>
 Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
 Andrew Morton <akpm@linux-foundation.org>
@@ -33,9 +34,9 @@ Axel Lin <axel.lin@gmail.com>
 Ben Gardner <bgardner@wabtec.com>
 Ben M Cahill <ben.m.cahill@intel.com>
 Björn Steinbrink <B.Steinbrink@gmx.de>
-Boris Brezillon <boris.brezillon@free-electrons.com>
-Boris Brezillon <boris.brezillon@free-electrons.com> <b.brezillon.dev@gmail.com>
-Boris Brezillon <boris.brezillon@free-electrons.com> <b.brezillon@overkiz.com>
+Boris Brezillon <boris.brezillon@bootlin.com> <boris.brezillon@free-electrons.com>
+Boris Brezillon <boris.brezillon@bootlin.com> <b.brezillon.dev@gmail.com>
+Boris Brezillon <boris.brezillon@bootlin.com> <b.brezillon@overkiz.com>
 Brian Avery <b.avery@hp.com>
 Brian King <brking@us.ibm.com>
 Christoph Hellwig <hch@lst.de>
@@ -62,6 +63,7 @@ Frank Zago <fzago@systemfabricworks.com>
 Greg Kroah-Hartman <greg@echidna.(none)>
 Greg Kroah-Hartman <gregkh@suse.de>
 Greg Kroah-Hartman <greg@kroah.com>
+Gregory CLEMENT <gregory.clement@bootlin.com> <gregory.clement@free-electrons.com>
 Henk Vergonet <Henk.Vergonet@gmail.com>
 Henrik Kretzschmar <henne@nachtwindheim.de>
 Henrik Rydberg <rydberg@bitmath.org>
@@ -100,6 +102,8 @@ Koushik <raghavendra.koushik@neterion.com>
 Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski@samsung.com>
 Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski.k@gmail.com>
 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+Leon Romanovsky <leon@kernel.org> <leon@leon.nu>
+Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com>
 Leonid I Ananiev <leonid.i.ananiev@intel.com>
 Linas Vepstas <linas@austin.ibm.com>
 Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
@@ -126,6 +130,7 @@ Mayuresh Janorkar <mayur@ti.com>
 Michael Buesch <m@bues.ch>
 Michel Dänzer <michel@tungstengraphics.com>
 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>

COPYING

@@ -1,356 +1,18 @@
+The Linux Kernel is provided under:
 
-   NOTE! This copyright does *not* cover user programs that use kernel
- services by normal system calls - this is merely considered normal use
- of the kernel, and does *not* fall under the heading of "derived work".
- Also note that the GPL below is copyrighted by the Free Software
- Foundation, but the instance of code that it refers to (the Linux
- kernel) is copyrighted by me and others who actually wrote it.
+	SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
 
- Also note that the only valid version of the GPL as far as the kernel
- is concerned is _this_ particular version of the license (ie v2, not
- v2.2 or v3.x or whatever), unless explicitly otherwise stated.
+Being under the terms of the GNU General Public License version 2 only,
+according with:
 
-			Linus Torvalds
+	LICENSES/preferred/GPL-2.0
 
-----------------------------------------
+With an explicit syscall exception, as stated at:
 
-		    GNU GENERAL PUBLIC LICENSE
-		       Version 2, June 1991
+	LICENSES/exceptions/Linux-syscall-note
 
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
-                       51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
+In addition, other licenses may also apply. Please see:
 
-			    Preamble
+	Documentation/process/license-rules.rst
 
-  The licenses for most software are designed to take away your
-freedom to share and change it.  By contrast, the GNU General Public
-License is intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users.  This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it.  (Some other Free Software Foundation software is covered by
-the GNU Library General Public License instead.)  You can apply it to
-your programs, too.
-
-  When we speak of free software, we are referring to freedom, not
-price.  Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it
-in new free programs; and that you know you can do these things.
-
-  To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-
-  For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have.  You must make sure that they, too, receive or can get the
-source code.  And you must show them these terms so they know their
-rights.
-
-  We protect your rights with two steps: (1) copyright the software, and
-(2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-
-  Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software.  If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-
-  Finally, any free program is threatened constantly by software
-patents.  We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary.  To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-
-  The precise terms and conditions for copying, distribution and
-modification follow.
-
-		    GNU GENERAL PUBLIC LICENSE
-   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-
-  0. This License applies to any program or other work which contains
-a notice placed by the copyright holder saying it may be distributed
-under the terms of this General Public License.  The "Program", below,
-refers to any such program or work, and a "work based on the Program"
-means either the Program or any derivative work under copyright law:
-that is to say, a work containing the Program or a portion of it,
-either verbatim or with modifications and/or translated into another
-language.  (Hereinafter, translation is included without limitation in
-the term "modification".)  Each licensee is addressed as "you".
-
-Activities other than copying, distribution and modification are not
-covered by this License; they are outside its scope.  The act of
-running the Program is not restricted, and the output from the Program
-is covered only if its contents constitute a work based on the
-Program (independent of having been made by running the Program).
-Whether that is true depends on what the Program does.
-
-  1. You may copy and distribute verbatim copies of the Program's
-source code as you receive it, in any medium, provided that you
-conspicuously and appropriately publish on each copy an appropriate
-copyright notice and disclaimer of warranty; keep intact all the
-notices that refer to this License and to the absence of any warranty;
-and give any other recipients of the Program a copy of this License
-along with the Program.
-
-You may charge a fee for the physical act of transferring a copy, and
-you may at your option offer warranty protection in exchange for a fee.
-
-  2. You may modify your copy or copies of the Program or any portion
-of it, thus forming a work based on the Program, and copy and
-distribute such modifications or work under the terms of Section 1
-above, provided that you also meet all of these conditions:
-
-    a) You must cause the modified files to carry prominent notices
-    stating that you changed the files and the date of any change.
-
-    b) You must cause any work that you distribute or publish, that in
-    whole or in part contains or is derived from the Program or any
-    part thereof, to be licensed as a whole at no charge to all third
-    parties under the terms of this License.
-
-    c) If the modified program normally reads commands interactively
-    when run, you must cause it, when started running for such
-    interactive use in the most ordinary way, to print or display an
-    announcement including an appropriate copyright notice and a
-    notice that there is no warranty (or else, saying that you provide
-    a warranty) and that users may redistribute the program under
-    these conditions, and telling the user how to view a copy of this
-    License.  (Exception: if the Program itself is interactive but
-    does not normally print such an announcement, your work based on
-    the Program is not required to print an announcement.)
-
-These requirements apply to the modified work as a whole.  If
-identifiable sections of that work are not derived from the Program,
-and can be reasonably considered independent and separate works in
-themselves, then this License, and its terms, do not apply to those
-sections when you distribute them as separate works.  But when you
-distribute the same sections as part of a whole which is a work based
-on the Program, the distribution of the whole must be on the terms of
-this License, whose permissions for other licensees extend to the
-entire whole, and thus to each and every part regardless of who wrote it.
-
-Thus, it is not the intent of this section to claim rights or contest
-your rights to work written entirely by you; rather, the intent is to
-exercise the right to control the distribution of derivative or
-collective works based on the Program.
-
-In addition, mere aggregation of another work not based on the Program
-with the Program (or with a work based on the Program) on a volume of
-a storage or distribution medium does not bring the other work under
-the scope of this License.
-
-  3. You may copy and distribute the Program (or a work based on it,
-under Section 2) in object code or executable form under the terms of
-Sections 1 and 2 above provided that you also do one of the following:
-
-    a) Accompany it with the complete corresponding machine-readable
-    source code, which must be distributed under the terms of Sections
-    1 and 2 above on a medium customarily used for software interchange; or,
-
-    b) Accompany it with a written offer, valid for at least three
-    years, to give any third party, for a charge no more than your
-    cost of physically performing source distribution, a complete
-    machine-readable copy of the corresponding source code, to be
-    distributed under the terms of Sections 1 and 2 above on a medium
-    customarily used for software interchange; or,
-
-    c) Accompany it with the information you received as to the offer
-    to distribute corresponding source code.  (This alternative is
-    allowed only for noncommercial distribution and only if you
-    received the program in object code or executable form with such
-    an offer, in accord with Subsection b above.)
-
-The source code for a work means the preferred form of the work for
-making modifications to it.  For an executable work, complete source
-code means all the source code for all modules it contains, plus any
-associated interface definition files, plus the scripts used to
-control compilation and installation of the executable.  However, as a
-special exception, the source code distributed need not include
-anything that is normally distributed (in either source or binary
-form) with the major components (compiler, kernel, and so on) of the
-operating system on which the executable runs, unless that component
-itself accompanies the executable.
-
-If distribution of executable or object code is made by offering
-access to copy from a designated place, then offering equivalent
-access to copy the source code from the same place counts as
-distribution of the source code, even though third parties are not
-compelled to copy the source along with the object code.
-
-  4. You may not copy, modify, sublicense, or distribute the Program
-except as expressly provided under this License.  Any attempt
-otherwise to copy, modify, sublicense or distribute the Program is
-void, and will automatically terminate your rights under this License.
-However, parties who have received copies, or rights, from you under
-this License will not have their licenses terminated so long as such
-parties remain in full compliance.
-
-  5. You are not required to accept this License, since you have not
-signed it.  However, nothing else grants you permission to modify or
-distribute the Program or its derivative works.  These actions are
-prohibited by law if you do not accept this License.  Therefore, by
-modifying or distributing the Program (or any work based on the
-Program), you indicate your acceptance of this License to do so, and
-all its terms and conditions for copying, distributing or modifying
-the Program or works based on it.
-
-  6. Each time you redistribute the Program (or any work based on the
-Program), the recipient automatically receives a license from the
-original licensor to copy, distribute or modify the Program subject to
-these terms and conditions.  You may not impose any further
-restrictions on the recipients' exercise of the rights granted herein.
-You are not responsible for enforcing compliance by third parties to
-this License.
-
-  7. If, as a consequence of a court judgment or allegation of patent
-infringement or for any other reason (not limited to patent issues),
-conditions are imposed on you (whether by court order, agreement or
-otherwise) that contradict the conditions of this License, they do not
-excuse you from the conditions of this License.  If you cannot
-distribute so as to satisfy simultaneously your obligations under this
-License and any other pertinent obligations, then as a consequence you
-may not distribute the Program at all.  For example, if a patent
-license would not permit royalty-free redistribution of the Program by
-all those who receive copies directly or indirectly through you, then
-the only way you could satisfy both it and this License would be to
-refrain entirely from distribution of the Program.
-
-If any portion of this section is held invalid or unenforceable under
-any particular circumstance, the balance of the section is intended to
-apply and the section as a whole is intended to apply in other
-circumstances.
-
-It is not the purpose of this section to induce you to infringe any
-patents or other property right claims or to contest validity of any
-such claims; this section has the sole purpose of protecting the
-integrity of the free software distribution system, which is
-implemented by public license practices.  Many people have made
-generous contributions to the wide range of software distributed
-through that system in reliance on consistent application of that
-system; it is up to the author/donor to decide if he or she is willing
-to distribute software through any other system and a licensee cannot
-impose that choice.
-
-This section is intended to make thoroughly clear what is believed to
-be a consequence of the rest of this License.
-
-  8. If the distribution and/or use of the Program is restricted in
-certain countries either by patents or by copyrighted interfaces, the
-original copyright holder who places the Program under this License
-may add an explicit geographical distribution limitation excluding
-those countries, so that distribution is permitted only in or among
-countries not thus excluded.  In such case, this License incorporates
-the limitation as if written in the body of this License.
-
-  9. The Free Software Foundation may publish revised and/or new versions
-of the General Public License from time to time.  Such new versions will
-be similar in spirit to the present version, but may differ in detail to
-address new problems or concerns.
-
-Each version is given a distinguishing version number.  If the Program
-specifies a version number of this License which applies to it and "any
-later version", you have the option of following the terms and conditions
-either of that version or of any later version published by the Free
-Software Foundation.  If the Program does not specify a version number of
-this License, you may choose any version ever published by the Free Software
-Foundation.
-
-  10. If you wish to incorporate parts of the Program into other free
-programs whose distribution conditions are different, write to the author
-to ask for permission.  For software which is copyrighted by the Free
-Software Foundation, write to the Free Software Foundation; we sometimes
-make exceptions for this.  Our decision will be guided by the two goals
-of preserving the free status of all derivatives of our free software and
-of promoting the sharing and reuse of software generally.
-
-			    NO WARRANTY
-
-  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
-FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
-OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
-PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
-OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
-TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
-PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
-REPAIR OR CORRECTION.
-
-  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
-WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
-REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
-INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
-OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
-TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
-YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
-PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES.
-
-		     END OF TERMS AND CONDITIONS
-
-	    How to Apply These Terms to Your New Programs
-
-  If you develop a new program, and you want it to be of the greatest
-possible use to the public, the best way to achieve this is to make it
-free software which everyone can redistribute and change under these terms.
-
-  To do so, attach the following notices to the program.  It is safest
-to attach them to the start of each source file to most effectively
-convey the exclusion of warranty; and each file should have at least
-the "copyright" line and a pointer to where the full notice is found.
-
-    <one line to give the program's name and a brief idea of what it does.>
-    Copyright (C) <year>  <name of author>
-
-    This program is free software; you can redistribute it and/or modify
-    it under the terms of the GNU General Public License as published by
-    the Free Software Foundation; either version 2 of the License, or
-    (at your option) any later version.
-
-    This program is distributed in the hope that it will be useful,
-    but WITHOUT ANY WARRANTY; without even the implied warranty of
-    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-    GNU General Public License for more details.
-
-    You should have received a copy of the GNU General Public License
-    along with this program; if not, write to the Free Software
-    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
-
-
-Also add information on how to contact you by electronic and paper mail.
-
-If the program is interactive, make it output a short notice like this
-when it starts in an interactive mode:
-
-    Gnomovision version 69, Copyright (C) year name of author
-    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
-    This is free software, and you are welcome to redistribute it
-    under certain conditions; type `show c' for details.
-
-The hypothetical commands `show w' and `show c' should show the appropriate
-parts of the General Public License.  Of course, the commands you use may
-be called something other than `show w' and `show c'; they could even be
-mouse-clicks or menu items--whatever suits your program.
-
-You should also get your employer (if you work as a programmer) or your
-school, if any, to sign a "copyright disclaimer" for the program, if
-necessary.  Here is a sample; alter the names:
-
-  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
-  `Gnomovision' (which makes passes at compilers) written by James Hacker.
-
-  <signature of Ty Coon>, 1 April 1989
-  Ty Coon, President of Vice
-
-This General Public License does not permit incorporating your program into
-proprietary programs.  If your program is a subroutine library, you may
-consider it more useful to permit linking proprietary applications with the
-library.  If this is what you want to do, use the GNU Library General
-Public License instead of this License.
+for more details.

CREDITS

@@ -1564,6 +1564,11 @@ W: http://www.carumba.com/
 D: bug toaster (A1 sauce makes all the difference)
 D: Random linux hacker
 
+N: James Hogan
+E: jhogan@kernel.org
+D: Metag architecture maintainer
+D: TZ1090 SoC maintainer
+
 N: Tim Hockin
 E: thockin@hockin.org
 W: http://www.hockin.org/~thockin

Documentation/00-INDEX

@@ -66,8 +66,6 @@ backlight/
 	- directory with info on controlling backlights in flat panel displays
 bcache.txt
 	- Block-layer cache on fast SSDs to improve slow (raid) I/O performance.
-blackfin/
-	- directory with documentation for the Blackfin arch.
 block/
 	- info on the Block I/O (BIO) layer.
 blockdev/
@@ -114,8 +112,6 @@ cputopology.txt
 	- documentation on how CPU topology info is exported via sysfs.
 crc32.txt
 	- brief tutorial on CRC computation
-cris/
-	- directory with info about Linux on CRIS architecture.
 crypto/
 	- directory with info on the Crypto API.
 dcdbas.txt
@@ -172,8 +168,6 @@ fmc/
 	- information about the FMC bus abstraction
 fpga/
 	- FPGA Manager Core.
-frv/
-	- Fujitsu FR-V Linux documentation.
 futex-requeue-pi.txt
 	- info on requeueing of tasks from a non-PI futex to a PI futex
 gcc-plugins.txt
@@ -276,8 +270,6 @@ memory-hotplug.txt
 	- Hotpluggable memory support, how to use and current status.
 men-chameleon-bus.txt
 	- info on MEN chameleon bus.
-metag/
-	- directory with info about Linux on Meta architecture.
 mic/
 	- Intel Many Integrated Core (MIC) architecture device driver.
 mips/
@@ -286,8 +278,6 @@ misc-devices/
 	- directory with info about devices using the misc dev subsystem
 mmc/
 	- directory with info about the MMC subsystem
-mn10300/
-	- directory with info about the mn10300 architecture port
 mtd/
 	- directory with info about memory technology devices (flash)
 namespaces/

Documentation/ABI/stable/sysfs-bus-vmbus

@@ -132,3 +132,10 @@ KernelVersion:	4.16
 Contact:	Stephen Hemminger <sthemmin@microsoft.com>
 Description:	Monitor bit associated with channel
 Users:		Debugging tools and userspace drivers
+
+What:		/sys/bus/vmbus/devices/vmbus_*/channels/NN/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

Documentation/ABI/stable/sysfs-class-infiniband

@@ -0,0 +1,818 @@
+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/umadN/ibdev
+What:		/sys/class/infiniband_mad/umadN/port
+What:		/sys/class/infiniband_mad/issmN/ibdev
+What:		/sys/class/infiniband_mad/issmN/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_cm/ucmN/ibdev
+Date:		Oct, 2005
+KernelVersion:	v2.6.14
+Contact:	linux-rdma@vger.kernel.org
+Description:
+		(RO) Display Infiniband (IB) device name
+
+
+What:		/sys/class/infiniband_cm/abi_version
+Date:		Oct, 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 ucm devices.
+
+
+What:		/sys/class/infiniband_verbs/uverbsN/ibdev
+What:		/sys/class/infiniband_verbs/uverbsN/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 Chelsio T3 RDMA Driver (cxgb3)
+--------------------------------------------------
+
+What:		/sys/class/infiniband/cxgb3_X/hw_rev
+What:		/sys/class/infiniband/cxgb3_X/hca_type
+What:		/sys/class/infiniband/cxgb3_X/board_id
+Date:		Feb, 2007
+KernelVersion:	v2.6.21
+Contact:	linux-rdma@vger.kernel.org
+Description:
+		hw_rev:		(RO) Hardware revision number
+
+		hca_type:	(RO) HCA type. Here it is a driver short name.
+				It should normally match the name in its bus
+				driver structure (e.g.  pci_driver::name).
+
+		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) Muticast 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 NetEffect RNIC Low-Level iWARP driver (nes)
+---------------------------------------------------------------
+
+What:		/sys/class/infiniband/nesX/hw_rev
+What:		/sys/class/infiniband/nesX/hca_type
+What:		/sys/class/infiniband/nesX/board_id
+Date:		Feb, 2008
+KernelVersion:	v2.6.25
+Contact:	linux-rdma@vger.kernel.org
+Description:
+		hw_rev:		(RO) Hardware revision number
+
+		hca_type:	(RO) Host Channel Adapter type (NEX020)
+
+		board_id:	(RO) Manufacturing board id
+
+
+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 Intel(R) X722 iWARP i40iw driver
+----------------------------------------------------
+
+What:		/sys/class/infiniband/i40iwX/hw_rev
+What:		/sys/class/infiniband/i40iwX/hca_type
+What:		/sys/class/infiniband/i40iwX/board_id
+Date:		Jan, 2016
+KernelVersion:	v4.10
+Contact:	linux-rdma@vger.kernel.org
+Description:
+		hw_rev:		(RO) Hardware revision number
+
+		hca_type:	(RO) Show HCA type (I40IW)
+
+		board_id:	(RO) I40IW board ID
+
+
+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

Documentation/ABI/testing/debugfs-cec-error-inj

@@ -0,0 +1,40 @@
+What:		/sys/kernel/debug/cec/*/error-inj
+Date:		March 2018
+Contact:	Hans Verkuil <hans.verkuil@cisco.com>
+Description:
+
+The CEC Framework allows for CEC error injection commands through
+debugfs. Drivers that support this will create an error-inj file
+through which the error injection commands can be given.
+
+The basic syntax is as follows:
+
+Leading spaces/tabs are ignored. If the next character is a '#' or the
+end of the line was reached, then the whole line is ignored. Otherwise
+a command is expected.
+
+It is up to the driver to decide what commands to implement. The only
+exception is that the command 'clear' without any arguments must be
+implemented and that it will remove all current error injection
+commands.
+
+This ensures that you can always do 'echo clear >error-inj' to clear any
+error injections without having to know the details of the driver-specific
+commands.
+
+Note that the output of 'error-inj' shall be valid as input to 'error-inj'.
+So this must work:
+
+	$ cat error-inj >einj.txt
+	$ cat einj.txt >error-inj
+
+Other than these basic rules described above this ABI is not considered
+stable and may change in the future.
+
+Drivers that implement this functionality must document the commands as
+part of the CEC documentation and must keep that documentation up to date
+when changes are made.
+
+The following CEC error injection implementations exist:
+
+- Documentation/media/uapi/cec/cec-pin-error-inj.rst

Documentation/ABI/testing/ima_policy

@@ -26,7 +26,7 @@ Description:
 				 [obj_user=] [obj_role=] [obj_type=]]
 			option:	[[appraise_type=]] [permit_directio]
 
-		base: 	func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
+		base: 	func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK]
 				[FIRMWARE_CHECK]
 				[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
 			mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]

Documentation/ABI/testing/sysfs-block-aoe

@@ -0,0 +1,45 @@
+What:		/sys/block/etherd*/mac
+Date:		Apr, 2005
+KernelVersion:	v2.6.12
+Contact:	Ed L. Cashin <ed.cashin@acm.org>
+Description:
+		(RO) The ethernet address of the remote Ata over Ethernet (AoE)
+		device.
+
+What:		/sys/block/etherd*/netif
+Date:		Apr, 2005
+KernelVersion:	v2.6.12
+Contact:	Ed L. Cashin <ed.cashin@acm.org>
+Description:
+		(RO) The names of the network interfaces on the localhost (comma
+		separated) through which we are communicating with the remote
+		AoE device.
+
+What:		/sys/block/etherd*/state
+Date:		Apr, 2005
+KernelVersion:	v2.6.12
+Contact:	Ed L. Cashin <ed.cashin@acm.org>
+Description:
+		(RO) Device status. The state attribute is "up" when the device
+		is ready for I/O and "down" if detected but unusable. The
+		"down,closewait" state shows that the device is still open and
+		cannot come up again until it has been closed.  The "up,kickme"
+		state means that the driver wants to send more commands to the
+		target but found out there were already the max number of
+		commands waiting for a response. It will retry again after being
+		kicked by the periodic timer handler routine.
+
+What:		/sys/block/etherd*/firmware-version
+Date:		Apr, 2005
+KernelVersion:	v2.6.12
+Contact:	Ed L. Cashin <ed.cashin@acm.org>
+Description:
+		(RO) Version of the firmware in the target.
+
+What:		/sys/block/etherd*/payload
+Date:		Dec, 2012
+KernelVersion:	v3.10
+Contact:	Ed L. Cashin <ed.cashin@acm.org>
+Description:
+		(RO) The amount of user data transferred (in bytes) inside each AoE
+		command on the network, network headers excluded.

Documentation/ABI/testing/sysfs-block-loop

@@ -0,0 +1,50 @@
+What:		/sys/block/loopX/loop/autoclear
+Date:		Aug, 2010
+KernelVersion:	v2.6.37
+Contact:	linux-block@vger.kernel.org
+Description:
+		(RO) Shows if the device is in autoclear mode or not ( "1" or
+		"0"). Autoclear (if set) indicates that the loopback device will
+		self-distruct after last close.
+
+What:		/sys/block/loopX/loop/backing_file
+Date:		Aug, 2010
+KernelVersion:	v2.6.37
+Contact:	linux-block@vger.kernel.org
+Description:
+		(RO) The path of the backing file that the loop device maps its
+		data blocks to.
+
+What:		/sys/block/loopX/loop/offset
+Date:		Aug, 2010
+KernelVersion:	v2.6.37
+Contact:	linux-block@vger.kernel.org
+Description:
+		(RO) Start offset (in bytes).
+
+What:		/sys/block/loopX/loop/sizelimit
+Date:		Aug, 2010
+KernelVersion:	v2.6.37
+Contact:	linux-block@vger.kernel.org
+Description:
+		(RO) The size (in bytes) that the block device maps, starting
+		from the offset.
+
+What:		/sys/block/loopX/loop/partscan
+Date:		Aug, 2011
+KernelVersion:	v3.10
+Contact:	linux-block@vger.kernel.org
+Description:
+		(RO) Shows if automatic partition scanning is enabled for the
+		device or not ("1" or "0"). This can be requested individually
+		per loop device during its setup by setting LO_FLAGS_PARTSCAN in
+		in the ioctl request. By default, no partition tables are
+		scanned.
+
+What:		/sys/block/loopX/loop/dio
+Date:		Aug, 2015
+KernelVersion:	v4.10
+Contact:	linux-block@vger.kernel.org
+Description:
+		(RO) Shows if direct IO is being used to access backing file or
+		not ("1 or "0").

Documentation/ABI/testing/sysfs-bus-acpi

@@ -56,3 +56,40 @@ Description:
 		Writing 1 to this attribute will trigger hot removal of
 		this device object.  This file exists for every device
 		object that has _EJ0 method.
+
+What:		/sys/bus/acpi/devices/.../status
+Date:		Jan, 2014
+Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+		(RO) Returns the ACPI device status: enabled, disabled or
+		functioning or present, if the method _STA is present.
+
+		The return value is a decimal integer representing the device's
+		status bitmap:
+
+		Bit [0] –  Set if the device is present.
+		Bit [1] –  Set if the device is enabled and decoding its
+		           resources.
+		Bit [2] –  Set if the device should be shown in the UI.
+		Bit [3] –  Set if the device is functioning properly (cleared if
+		           device failed its diagnostics).
+		Bit [4] –  Set if the battery is present.
+		Bits [31:5] –  Reserved (must be cleared)
+
+		If bit [0] is clear, then bit 1 must also be clear (a device
+		that is not present cannot be enabled).
+
+		Bit 0 can be clear (not present) with bit [3] set (device is
+		functional).  This case is used to indicate a valid device for
+		which no device driver should be loaded.
+
+		More special cases are covered in the ACPI specification.
+
+What:		/sys/bus/acpi/devices/.../hrv
+Date:		Apr, 2016
+Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+		(RO) Allows users to read the hardware version of non-PCI
+		hardware, if the _HRV control method is present.  It is mostly
+		useful for non-PCI devices because lspci can list the hardware
+		version for PCI devices.

Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x

@@ -1,7 +1,7 @@
 What:		/sys/bus/iio/devices/iio:deviceX/in_concentration_VOC_short_raw
 Date:		September 2015
 KernelVersion:	4.3
-Contact:	Matt Ranostay <mranostay@gmail.com>
+Contact:	Matt Ranostay <matt.ranostay@konsulko.com>
 Description:
 		Get the raw calibration VOC value from the sensor.
 		This value has little application outside of calibration.

Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935

@@ -1,7 +1,7 @@
 What		/sys/bus/iio/devices/iio:deviceX/in_proximity_input
 Date:		March 2014
 KernelVersion:	3.15
-Contact:	Matt Ranostay <mranostay@gmail.com>
+Contact:	Matt Ranostay <matt.ranostay@konsulko.com>
 Description:
 		Get the current distance in meters of storm (1km steps)
 		1000-40000 = distance in meters
@@ -9,7 +9,7 @@ Description:
 What		/sys/bus/iio/devices/iio:deviceX/sensor_sensitivity
 Date:		March 2014
 KernelVersion:	3.15
-Contact:	Matt Ranostay <mranostay@gmail.com>
+Contact:	Matt Ranostay <matt.ranostay@konsulko.com>
 Description:
 		Show or set the gain boost of the amp, from 0-31 range.
 		18 = indoors (default)

Documentation/ABI/testing/sysfs-bus-nfit

@@ -0,0 +1,233 @@
+For all of the nmem device attributes under nfit/*, see the 'NVDIMM Firmware
+Interface Table (NFIT)' section in the ACPI specification
+(http://www.uefi.org/specifications) for more details.
+
+What:		/sys/bus/nd/devices/nmemX/nfit/serial
+Date:		Jun, 2015
+KernelVersion:	v4.2
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) Serial number of the NVDIMM (non-volatile dual in-line
+		memory module), assigned by the module vendor.
+
+
+What:		/sys/bus/nd/devices/nmemX/nfit/handle
+Date:		Apr, 2015
+KernelVersion:	v4.2
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) The address (given by the _ADR object) of the device on its
+		parent bus of the NVDIMM device containing the NVDIMM region.
+
+
+What:		/sys/bus/nd/devices/nmemX/nfit/device
+Date:		Apr, 2015
+KernelVersion:	v4.1
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) Device id for the NVDIMM, assigned by the module vendor.
+
+
+What:		/sys/bus/nd/devices/nmemX/nfit/rev_id
+Date:		Jun, 2015
+KernelVersion:	v4.2
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) Revision of the NVDIMM, assigned by the module vendor.
+
+
+What:		/sys/bus/nd/devices/nmemX/nfit/phys_id
+Date:		Apr, 2015
+KernelVersion:	v4.2
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) Handle (i.e., instance number) for the SMBIOS (system
+		management BIOS) Memory Device structure describing the NVDIMM
+		containing the NVDIMM region.
+
+
+What:		/sys/bus/nd/devices/nmemX/nfit/flags
+Date:		Jun, 2015
+KernelVersion:	v4.2
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) The flags in the NFIT memory device sub-structure indicate
+		the state of the data on the nvdimm relative to its energy
+		source or last "flush to persistence".
+
+		The attribute is a translation of the 'NVDIMM State Flags' field
+		in section 5.2.25.3 'NVDIMM Region Mapping' Structure of the
+		ACPI specification 6.2.
+
+		The health states are "save_fail", "restore_fail", "flush_fail",
+		"not_armed", "smart_event", "map_fail" and "smart_notify".
+
+
+What:		/sys/bus/nd/devices/nmemX/nfit/format
+What:		/sys/bus/nd/devices/nmemX/nfit/format1
+What:		/sys/bus/nd/devices/nmemX/nfit/formats
+Date:		Apr, 2016
+KernelVersion:	v4.7
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) The interface codes indicate support for persistent memory
+		mapped directly into system physical address space and / or a
+		block aperture access mechanism to the NVDIMM media.
+		The 'formats' attribute displays the number of supported
+		interfaces.
+
+		This layout is compatible with existing libndctl binaries that
+		only expect one code per-dimm as they will ignore
+		nmemX/nfit/formats and nmemX/nfit/formatN.
+
+
+What:		/sys/bus/nd/devices/nmemX/nfit/vendor
+Date:		Apr, 2016
+KernelVersion:	v4.7
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) Vendor id of the NVDIMM.
+
+
+What:		/sys/bus/nd/devices/nmemX/nfit/dsm_mask
+Date:		May, 2016
+KernelVersion:	v4.7
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) The bitmask indicates the supported device specific control
+		functions relative to the NVDIMM command family supported by the
+		device
+
+
+What:		/sys/bus/nd/devices/nmemX/nfit/family
+Date:		Apr, 2016
+KernelVersion:	v4.7
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) Displays the NVDIMM family command sets. Values
+		0, 1, 2 and 3 correspond to NVDIMM_FAMILY_INTEL,
+		NVDIMM_FAMILY_HPE1, NVDIMM_FAMILY_HPE2 and NVDIMM_FAMILY_MSFT
+		respectively.
+
+		See the specifications for these command families here:
+		http://pmem.io/documents/NVDIMM_DSM_Interface-V1.6.pdf
+		https://github.com/HewlettPackard/hpe-nvm/blob/master/Documentation/
+		https://msdn.microsoft.com/library/windows/hardware/mt604741"
+
+
+What:		/sys/bus/nd/devices/nmemX/nfit/id
+Date:		Apr, 2016
+KernelVersion:	v4.7
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) ACPI specification 6.2 section 5.2.25.9, defines an
+		identifier for an NVDIMM, which refelects the id attribute.
+
+
+What:		/sys/bus/nd/devices/nmemX/nfit/subsystem_vendor
+Date:		Apr, 2016
+KernelVersion:	v4.7
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) Sub-system vendor id of the NVDIMM non-volatile memory
+		subsystem controller.
+
+
+What:		/sys/bus/nd/devices/nmemX/nfit/subsystem_rev_id
+Date:		Apr, 2016
+KernelVersion:	v4.7
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) Sub-system revision id of the NVDIMM non-volatile memory subsystem
+		controller, assigned by the non-volatile memory subsystem
+		controller vendor.
+
+
+What:		/sys/bus/nd/devices/nmemX/nfit/subsystem_device
+Date:		Apr, 2016
+KernelVersion:	v4.7
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) Sub-system device id for the NVDIMM non-volatile memory
+		subsystem controller, assigned by the non-volatile memory
+		subsystem controller vendor.
+
+
+What:		/sys/bus/nd/devices/ndbusX/nfit/revision
+Date:		Jun, 2015
+KernelVersion:	v4.2
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) ACPI NFIT table revision number.
+
+
+What:		/sys/bus/nd/devices/ndbusX/nfit/scrub
+Date:		Sep, 2016
+KernelVersion:	v4.9
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RW) This shows the number of full Address Range Scrubs (ARS)
+		that have been completed since driver load time. Userspace can
+		wait on this using select/poll etc. A '+' at the end indicates
+		an ARS is in progress
+
+		Writing a value of 1 triggers an ARS scan.
+
+
+What:		/sys/bus/nd/devices/ndbusX/nfit/hw_error_scrub
+Date:		Sep, 2016
+KernelVersion:	v4.9
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RW) Provides a way to toggle the behavior between just adding
+		the address (cache line) where the MCE happened to the poison
+		list and doing a full scrub. The former (selective insertion of
+		the address) is done unconditionally.
+
+		This attribute can have the following values written to it:
+
+		'0': Switch to the default mode where an exception will only
+		insert the address of the memory error into the poison and
+		badblocks lists.
+		'1': Enable a full scrub to happen if an exception for a memory
+		error is received.
+
+
+What:		/sys/bus/nd/devices/ndbusX/nfit/dsm_mask
+Date:		Jun, 2017
+KernelVersion:	v4.13
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) The bitmask indicates the supported bus specific control
+		functions. See the section named 'NVDIMM Root Device _DSMs' in
+		the ACPI specification.
+
+
+What:		/sys/bus/nd/devices/regionX/nfit/range_index
+Date:		Jun, 2015
+KernelVersion:	v4.2
+Contact:	linux-nvdimm@lists.01.org
+Description:
+		(RO) A unique number provided by the BIOS to identify an address
+		range. Used by NVDIMM Region Mapping Structure to uniquely refer
+		to this structure. Value of 0 is reserved and not used as an
+		index.
+
+
+What:		/sys/bus/nd/devices/regionX/nfit/ecc_unit_size
+Date:		Aug, 2017
+KernelVersion:	v4.14
+Contact:	linux-nvdimm@lists.01.org
+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.

Documentation/ABI/testing/sysfs-bus-rapidio

@@ -0,0 +1,198 @@
+What:		/sys/bus/rapidio/devices/nn:d:iiii
+Description:
+		For each RapidIO device, the RapidIO subsystem creates files in
+		an individual subdirectory with the following name format of
+		device_name "nn:d:iiii", where:
+
+		nn   - two-digit hexadecimal ID of RapidIO network where the
+		       device resides
+		d    - device type: 'e' - for endpoint or 's' - for switch
+		iiii - four-digit device destID for endpoints, or switchID for
+		       switches
+
+		For example, below is a list of device directories that
+		represents a typical RapidIO network with one switch, one host,
+		and two agent endpoints, as it is seen by the enumerating host
+		(with destID = 1):
+
+		/sys/bus/rapidio/devices/00:e:0000
+		/sys/bus/rapidio/devices/00:e:0002
+		/sys/bus/rapidio/devices/00:s:0001
+
+		NOTE: An enumerating or discovering endpoint does not create a
+		sysfs entry for itself, this is why an endpoint with destID=1 is
+		not shown in the list.
+
+Attributes Common for All RapidIO Devices
+-----------------------------------------
+
+What:		/sys/bus/rapidio/devices/nn:d:iiii/did
+Date:		Nov, 2005
+KernelVersion:	v2.6.15
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) returns the device identifier
+
+What:		/sys/bus/rapidio/devices/nn:d:iiii/vid
+Date:		Nov, 2005
+KernelVersion:	v2.6.15
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) returns the device vendor identifier
+
+What:		/sys/bus/rapidio/devices/nn:d:iiii/device_rev
+Date:		Nov, 2005
+KernelVersion:	v2.6.15
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) returns the device revision level
+
+What:		/sys/bus/rapidio/devices/nn:d:iiii/asm_did
+Date:		Nov, 2005
+KernelVersion:	v2.6.15
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) returns identifier for the assembly containing the device
+
+What:		/sys/bus/rapidio/devices/nn:d:iiii/asm_rev
+Date:		Nov, 2005
+KernelVersion:	v2.6.15
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) returns revision level of the assembly containing the
+		device
+
+What:		/sys/bus/rapidio/devices/nn:d:iiii/asm_vid
+Date:		Nov, 2005
+KernelVersion:	v2.6.15
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) returns vendor identifier of the assembly containing the
+		device
+
+What:		/sys/bus/rapidio/devices/nn:d:iiii/destid
+Date:		Mar, 2011
+KernelVersion:	v2.6.3
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) returns device destination ID assigned by the enumeration
+		routine
+
+What:		/sys/bus/rapidio/devices/nn:d:iiii/lprev
+Date:		Mar, 2011
+KernelVersion:	v2.6.39
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) returns name of previous device (switch) on the path to the
+		device that that owns this attribute
+
+What:		/sys/bus/rapidio/devices/nn:d:iiii/modalias
+Date:		Jul, 2013
+KernelVersion:	v3.11
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) returns the device modalias
+
+What:		/sys/bus/rapidio/devices/nn:d:iiii/config
+Date:		Nov, 2005
+KernelVersion:	v2.6.15
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RW) Binary attribute to read from and write to the device
+		configuration registers using the RapidIO maintenance
+		transactions. This attribute is similar in behaviour to the
+		"config" attribute of PCI devices and provides an access to the
+		RapidIO device registers using standard file read and write
+		operations.
+
+RapidIO Switch Device Attributes
+--------------------------------
+
+RapidIO switches have additional attributes in sysfs. RapidIO subsystem supports
+common and device-specific sysfs attributes for switches. Because switches are
+integrated into the RapidIO subsystem, it offers a method to create
+device-specific sysfs attributes by specifying a callback function that may be
+set by the switch initialization routine during enumeration or discovery
+process.
+
+What:		/sys/bus/rapidio/devices/nn:s:iiii/routes
+Date:		Nov, 2005
+KernelVersion:	v2.6.15
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) reports switch routing information in "destID port" format.
+		This attribute reports only valid routing table entries, one
+		line for each entry.
+
+What:		/sys/bus/rapidio/devices/nn:s:iiii/destid
+Date:		Mar, 2011
+KernelVersion:	v2.6.3
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) device destination ID of the associated device that defines
+		a route to the switch
+
+What:		/sys/bus/rapidio/devices/nn:s:iiii/hopcount
+Date:		Mar, 2011
+KernelVersion:	v2.6.39
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) number of hops on the path to the switch
+
+What:		/sys/bus/rapidio/devices/nn:s:iiii/lnext
+Date:		Mar, 2011
+KernelVersion:	v2.6.39
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) returns names of devices linked to the switch except one of
+		a device linked to the ingress port (reported as "lprev"). This
+		is an array names with number of lines equal to number of ports
+		in switch. If a switch port has no attached device, returns
+		"null" instead of a device name.
+
+Device-specific Switch Attributes
+---------------------------------
+
+IDT_GEN2-
+
+What:		/sys/bus/rapidio/devices/nn:s:iiii/errlog
+Date:		Oct, 2010
+KernelVersion:	v2.6.37
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) reads contents of device error log until it is empty.
+
+RapidIO Bus Attributes
+----------------------
+
+What:		/sys/bus/rapidio/scan
+Date:		May, 2013
+KernelVersion:	v3.11
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(WO) Allows to trigger enumeration discovery process from user
+		space. To initiate an enumeration or discovery process on
+		specific mport device, a user needs to write mport_ID (not
+		RapidIO destination ID) into this file. The mport_ID is a
+		sequential number (0 ...  RIO_MAX_MPORTS) assigned to the mport
+		device. For example, for a machine with a single RapidIO
+		controller, mport_ID for that controller always will be 0. To
+		initiate RapidIO enumeration/discovery on all available mports a
+		user must write '-1' (or RIO_MPORT_ANY) into this attribute
+		file.

Documentation/ABI/testing/sysfs-bus-rbd

@@ -1,121 +1,162 @@
-What:		/sys/bus/rbd/
-Date:		November 2010
-Contact:	Yehuda Sadeh <yehuda@newdream.net>,
-		Sage Weil <sage@newdream.net>
+What:		/sys/bus/rbd/add
+Date:		Oct, 2010
+KernelVersion:	v2.6.37
+Contact:	Sage Weil <sage@newdream.net>
 Description:
+		(WO) Add rbd block device.
 
-Being used for adding and removing rbd block devices.
+		Usage: <mon ip addr> <options> <pool name> <rbd image name> [<snap name>]
 
-Usage: <mon ip addr> <options> <pool name> <rbd image name> [<snap name>]
+		 $ echo "192.168.0.1 name=admin rbd foo" > /sys/bus/rbd/add
 
- $ echo "192.168.0.1 name=admin rbd foo" > /sys/bus/rbd/add
+		The snapshot name can be "-" or omitted to map the image
+		read/write. A <dev-id> will be assigned for any registered block
+		device. If snapshot is used, it will be mapped read-only.
 
-The snapshot name can be "-" or omitted to map the image read/write. A <dev-id>
-will be assigned for any registered block device. If snapshot is used, it will
-be mapped read-only.
 
-Usage: <dev-id> [force]
+What:		/sys/bus/rbd/remove
+Date:		Oct, 2010
+KernelVersion:	v2.6.37
+Contact:	Sage Weil <sage@newdream.net>
+Description:
+		(WO) Remove rbd block device.
+
+		Usage: <dev-id> [force]
 
- $ echo 2 > /sys/bus/rbd/remove
+		 $ echo 2 > /sys/bus/rbd/remove
+
+		Optional "force" argument which when passed will wait for
+		running requests and then unmap the image. Requests sent to the
+		driver after initiating the removal will be failed. (August
+		2016, since 4.9.)
 
-Optional "force" argument which when passed will wait for running requests and
-then unmap the image. Requests sent to the driver after initiating the removal
-will be failed.  (August 2016, since 4.9.)
 
 What:		/sys/bus/rbd/add_single_major
-Date:		December 2013
-KernelVersion:	3.14
-Contact:	Sage Weil <sage@inktank.com>
-Description:	Available only if rbd module is inserted with single_major
+Date:		Dec, 2013
+KernelVersion:	v3.14
+Contact:	Sage Weil <sage@newdream.net>
+Description:
+		(WO) Available only if rbd module is inserted with single_major
 		parameter set to true.
-		Usage is the same as for /sys/bus/rbd/add.  If present,
+
+		Usage is the same as for /sys/bus/rbd/add. If present, this
 		should be used instead of the latter: any attempts to use
-		/sys/bus/rbd/add if /sys/bus/rbd/add_single_major is
-		available will fail for backwards compatibility reasons.
+		/sys/bus/rbd/add if /sys/bus/rbd/add_single_major is available
+		will fail for backwards compatibility reasons.
+
 
 What:		/sys/bus/rbd/remove_single_major
-Date:		December 2013
-KernelVersion:	3.14
-Contact:	Sage Weil <sage@inktank.com>
-Description:	Available only if rbd module is inserted with single_major
+Date:		Dec, 2013
+KernelVersion:	v3.14
+Contact:	Sage Weil <sage@newdream.net>
+Description:
+		(WO) Available only if rbd module is inserted with single_major
 		parameter set to true.
-		Usage is the same as for /sys/bus/rbd/remove.  If present,
+
+		Usage is the same as for /sys/bus/rbd/remove. If present, this
 		should be used instead of the latter: any attempts to use
 		/sys/bus/rbd/remove if /sys/bus/rbd/remove_single_major is
 		available will fail for backwards compatibility reasons.
 
-Entries under /sys/bus/rbd/devices/<dev-id>/
---------------------------------------------
-
-client_addr
-
-	The ceph unique client entity_addr_t (address + nonce).
-	The format is <address>:<port>/<nonce>: '1.2.3.4:1234/5678' or
-	'[1:2:3:4:5:6:7:8]:1234/5678'.  (August 2016, since 4.9.)
-
-client_id
-
-	The ceph unique client id that was assigned for this specific session.
-
-cluster_fsid
 
-	The ceph cluster UUID.  (August 2016, since 4.9.)
-
-config_info
-
-	The string written into /sys/bus/rbd/add{,_single_major}.  (August
-	2016, since 4.9.)
-
-features
-
-	A hexadecimal encoding of the feature bits for this image.
-
-major
-
-	The block device major number.
+What:		/sys/bus/rbd/supported_features
+Date:		Mar, 2017
+KernelVersion:	v4.11
+Contact:	Sage Weil <sage@newdream.net>
+Description:
+		(RO) Displays the features supported by the rbd module so that
+		userspace can generate meaningful error messages and spell out
+		unsupported features that need to be disabled.
+
+
+What:		/sys/bus/rbd/devices/<dev-id>/size
+What:		/sys/bus/rbd/devices/<dev-id>/major
+What:		/sys/bus/rbd/devices/<dev-id>/client_id
+What:		/sys/bus/rbd/devices/<dev-id>/pool
+What:		/sys/bus/rbd/devices/<dev-id>/name
+What:		/sys/bus/rbd/devices/<dev-id>/refresh
+What:		/sys/bus/rbd/devices/<dev-id>/current_snap
+Date:		Oct, 2010
+KernelVersion:	v2.6.37
+Contact:	Sage Weil <sage@newdream.net>
+Description:
+		size:		(RO) The size (in bytes) of the mapped block
+				device.
 
-minor
+		major:		(RO) The block device major number.
 
-	The block device minor number.  (December 2013, since 3.14.)
+		client_id:	(RO) The ceph unique client id that was assigned
+				for this specific session.
 
-name
+		pool:		(RO) The name of the storage pool where this rbd
+				image resides. An rbd image name is unique
+				within its pool.
 
-	The name of the rbd image.
+		name:		(RO) The name of the rbd image.
 
-image_id
+		refresh:	(WO) Writing to this file will reread the image
+				header data and set all relevant data structures
+				accordingly.
 
-	The unique id for the rbd image.  (For rbd image format 1
-	this is empty.)
+		current_snap:	(RO) The current snapshot for which the device
+				is mapped.
 
-pool
 
-	The name of the storage pool where this rbd image resides.
-	An rbd image name is unique within its pool.
+What:		/sys/bus/rbd/devices/<dev-id>/pool_id
+Date:		Jul, 2012
+KernelVersion:	v3.6
+Contact:	Sage Weil <sage@newdream.net>
+Description:
+		(RO) The unique identifier for the rbd image's pool. This is a
+		permanent attribute of the pool. A pool's id will never change.
 
-pool_id
 
-	The unique identifier for the rbd image's pool.  This is
-	a permanent attribute of the pool.  A pool's id will never
-	change.
+What:		/sys/bus/rbd/devices/<dev-id>/image_id
+What:		/sys/bus/rbd/devices/<dev-id>/features
+Date:		Oct, 2012
+KernelVersion:	v3.7
+Contact:	Sage Weil <sage@newdream.net>
+Description:
+		image_id:	(RO) The unique id for the rbd image. (For rbd
+				image format 1 this is empty.)
 
-size
+		features:	(RO) A hexadecimal encoding of the feature bits
+				for this image.
 
-	The size (in bytes) of the mapped block device.
 
-refresh
+What:		/sys/bus/rbd/devices/<dev-id>/parent
+Date:		Nov, 2012
+KernelVersion:	v3.8
+Contact:	Sage Weil <sage@newdream.net>
+Description:
+		(RO) Information identifying the chain of parent images in a
+		layered rbd image. Entries are separated by empty lines.
 
-	Writing to this file will reread the image header data and set
-	all relevant datastructures accordingly.
 
-current_snap
+What:		/sys/bus/rbd/devices/<dev-id>/minor
+Date:		Dec, 2013
+KernelVersion:	v3.14
+Contact:	Sage Weil <sage@newdream.net>
+Description:
+		(RO) The block device minor number.
 
-	The current snapshot for which the device is mapped.
 
-snap_id
+What:		/sys/bus/rbd/devices/<dev-id>/snap_id
+What:		/sys/bus/rbd/devices/<dev-id>/config_info
+What:		/sys/bus/rbd/devices/<dev-id>/cluster_fsid
+What:		/sys/bus/rbd/devices/<dev-id>/client_addr
+Date:		Aug, 2016
+KernelVersion:	v4.9
+Contact:	Sage Weil <sage@newdream.net>
+Description:
+		snap_id:	(RO) The current snapshot's id.
 
-	The current snapshot's id.  (August 2016, since 4.9.)
+		config_info:	(RO) The string written into
+				/sys/bus/rbd/add{,_single_major}.
 
-parent
+		cluster_fsid:	(RO) The ceph cluster UUID.
 
-	Information identifying the chain of parent images in a layered rbd
-	image.  Entries are separated by empty lines.
+		client_addr:	(RO) The ceph unique client
+				entity_addr_t (address + nonce). The format is
+				<address>:<port>/<nonce>: '1.2.3.4:1234/5678' or
+				'[1:2:3:4:5:6:7:8]:1234/5678'.

Documentation/ABI/testing/sysfs-bus-thunderbolt

@@ -1,3 +1,26 @@
+What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl
+Date:		Jun 2018
+KernelVersion:	4.17
+Contact:	thunderbolt-software@lists.01.org
+Description:	Holds a comma separated list of device unique_ids that
+		are allowed to be connected automatically during system
+		startup (e.g boot devices). The list always contains
+		maximum supported number of unique_ids where unused
+		entries are empty. This allows the userspace software
+		to determine how many entries the controller supports.
+		If there are multiple controllers, each controller has
+		its own ACL list and size may be different between the
+		controllers.
+
+		System BIOS may have an option "Preboot ACL" or similar
+		that needs to be selected before this list is taken into
+		consideration.
+
+		Software always updates a full list in each write.
+
+		If a device is authorized automatically during boot its
+		boot attribute is set to 1.
+
 What: /sys/bus/thunderbolt/devices/.../domainX/security
 Date:		Sep 2017
 KernelVersion:	4.13
@@ -12,6 +35,9 @@ Description:	This attribute holds current Thunderbolt security level
 			minimum. User needs to authorize each device.
 		dponly: Automatically tunnel Display port (and USB). No
 			PCIe tunnels are created.
+		usbonly: Automatically tunnel USB controller of the
+			 connected Thunderbolt dock (and Display Port). All
+			 PCIe links downstream of the dock are removed.
 
 What: /sys/bus/thunderbolt/devices/.../authorized
 Date:		Sep 2017
@@ -38,6 +64,13 @@ Description:	This attribute is used to authorize Thunderbolt devices
 		   the device did not contain a key at all, and
 		   EKEYREJECTED if the challenge response did not match.
 
+What: /sys/bus/thunderbolt/devices/.../boot
+Date:		Jun 2018
+KernelVersion:	4.17
+Contact:	thunderbolt-software@lists.01.org
+Description:	This attribute contains 1 if Thunderbolt device was already
+		authorized on boot and 0 otherwise.
+
 What: /sys/bus/thunderbolt/devices/.../key
 Date:		Sep 2017
 KernelVersion:	4.13

Documentation/ABI/testing/sysfs-bus-usb

@@ -189,6 +189,16 @@ Description:
 		The file will read "hotplug", "wired" and "not used" if the
 		information is available, and "unknown" otherwise.
 
+What:		/sys/bus/usb/devices/.../(hub interface)/portX/over_current_count
+Date:		February 2018
+Contact:	Richard Leitner <richard.leitner@skidata.com>
+Description:
+		Most hubs are able to detect over-current situations on their
+		ports and report them to the kernel. This attribute is to expose
+		the number of over-current situation occurred on a specific port
+		to user space. This file will contain an unsigned 32 bit value
+		which wraps to 0 after its maximum is reached.
+
 What:		/sys/bus/usb/devices/.../(hub interface)/portX/usb3_lpm_permit
 Date:		November 2015
 Contact:	Lu Baolu <baolu.lu@linux.intel.com>

Documentation/ABI/testing/sysfs-class-backlight-adp5520

@@ -0,0 +1,31 @@
+sysfs interface for analog devices adp5520(01) backlight driver
+---------------------------------------------------------------
+
+The backlight brightness control operates at three different levels for the
+adp5520 and adp5501 devices: daylight (level 1), office (level 2) and dark
+(level 3). By default the brightness operates at the daylight brightness level.
+
+What:		/sys/class/backlight/<backlight>/daylight_max
+What:		/sys/class/backlight/<backlight>/office_max
+What:		/sys/class/backlight/<backlight>/dark_max
+Date:		Sep, 2009
+KernelVersion:	v2.6.32
+Contact:	Michael Hennerich <michael.hennerich@analog.com>
+Description:
+		(RW) Maximum current setting for the backlight when brightness
+		is at one of the three levels (daylight, office or dark). This
+		is an input code between 0 and 127, which is transformed to a
+		value between 0 mA and 30 mA using linear or non-linear
+		algorithms.
+
+What:		/sys/class/backlight/<backlight>/daylight_dim
+What:		/sys/class/backlight/<backlight>/office_dim
+What:		/sys/class/backlight/<backlight>/dark_dim
+Date:		Sep, 2009
+KernelVersion:	v2.6.32
+Contact:	Michael Hennerich <michael.hennerich@analog.com>
+Description:
+		(RW) Dim current setting for the backlight when brightness is at
+		one of the three levels (daylight, office or dark). This is an
+		input code between 0 and 127, which is transformed to a value
+		between 0 mA and 30 mA using linear or non-linear algorithms.

Documentation/ABI/testing/sysfs-class-backlight-adp8860

@@ -0,0 +1,54 @@
+sysfs interface for analog devices adp8860 backlight driver
+-----------------------------------------------------------
+
+The backlight brightness control operates at three different levels for the
+adp8860, adp8861 and adp8863 devices: daylight (level 1), office (level 2) and
+dark (level 3). By default the brightness operates at the daylight brightness
+level.
+
+What:		/sys/class/backlight/<backlight>/ambient_light_level
+Date:		Apr, 2010
+KernelVersion:	v2.6.35
+Contact:	Michael Hennerich <michael.hennerich@analog.com>
+Description:
+		(RO) 13-bit conversion value for the first light sensor—high
+		byte (Bit 12 to Bit 8). The value is updated every 80 ms (when
+		the light sensor is enabled).
+
+
+What:		/sys/class/backlight/<backlight>/ambient_light_zone
+Date:		Apr, 2010
+KernelVersion:	v2.6.35
+Contact:	Michael Hennerich <michael.hennerich@analog.com>
+Description:
+		(RW) Read or write the specific level at which the backlight
+		operates. Value "0" enables automatic ambient light sensing, and
+		values "1", "2" or "3" set the control to daylight, office or
+		dark respectively.
+
+
+What:		/sys/class/backlight/<backlight>/l1_daylight_max
+What:		/sys/class/backlight/<backlight>/l2_office_max
+What:		/sys/class/backlight/<backlight>/l3_dark_max
+Date:		Apr, 2010
+KernelVersion:	v2.6.35
+Contact:	Michael Hennerich <michael.hennerich@analog.com>
+Description:
+		(RW) Maximum current setting for the backlight when brightness
+		is at one of the three levels (daylight, office or dark). This
+		is an input code between 0 and 127, which is transformed to a
+		value between 0 mA and 30 mA using linear or non-linear
+		algorithms.
+
+
+What:		/sys/class/backlight/<backlight>/l1_daylight_dim
+What:		/sys/class/backlight/<backlight>/l2_office_dim
+What:		/sys/class/backlight/<backlight>/l3_dark_dim
+Date:		Apr, 2010
+KernelVersion:	v2.6.35
+Contact:	Michael Hennerich <michael.hennerich@analog.com>
+Description:
+		(RW) Dim current setting for the backlight when brightness is at
+		one of the three levels (daylight, office or dark). This is an
+		input code between 0 and 127, which is transformed to a value
+		between 0 mA and 30 mA using linear or non-linear algorithms.

Documentation/ABI/testing/sysfs-class-backlight-lm3639

@@ -0,0 +1,11 @@
+sysfs interface for Texas Instruments lm3639 backlight + flash led driver chip
+------------------------------------------------------------------------------
+
+What:		/sys/class/backlight/<backlight>/bled_mode
+Date:		Oct, 2012
+KernelVersion:	v3.10
+Contact:	dri-devel@lists.freedesktop.org
+Description:
+		(WO) Write to the backlight mapping mode. The backlight current
+		can be mapped for either exponential (value "0") or linear
+		mapping modes (default).

Documentation/ABI/testing/sysfs-class-bsr

@@ -0,0 +1,25 @@
+What:		/sys/class/bsr/bsr*/bsr_size
+Date:		Jul, 2008
+KernelVersion:	2.6.27
+Contact:	Arnd Bergmann <arnd@arndb.de>,
+		Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Description:
+		(RO) Size of the barrier-synchronization register (BSR)
+		register in bytes.
+
+What:		/sys/class/bsr/bsr*/bsr_length
+Date:		Jul, 2008
+KernelVersion:	2.6.27
+Contact:	Arnd Bergmann <arnd@arndb.de>,
+		Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Description:
+		(RO) The length of memory region that can be mapped in bytes.
+
+What:		/sys/class/bsr/bsr*/bsr_stride
+Date:		Jul, 2008
+KernelVersion:	2.6.27
+Contact:	Arnd Bergmann <arnd@arndb.de>,
+		Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Description:
+		(RO) The stride or the interval at which the allocated BSR bytes
+		repeat within the mapping.

Documentation/ABI/testing/sysfs-class-infiniband

@@ -1,16 +0,0 @@
-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 GODs
-		or "RoCE v2" for RoCE v2 based GIDs.
-
-

Documentation/ABI/testing/sysfs-class-lcd-s6e63m0

@@ -0,0 +1,27 @@
+sysfs interface for the S6E63M0 AMOLED LCD panel driver
+-------------------------------------------------------
+
+What:		/sys/class/lcd/<lcd>/gamma_mode
+Date:		May, 2010
+KernelVersion:	v2.6.35
+Contact:	dri-devel@lists.freedesktop.org
+Description:
+		(RW) Read or write the gamma mode. Following three modes are
+		supported:
+		0 - gamma value 2.2,
+		1 - gamma value 1.9 and
+		2 - gamma value 1.7.
+
+
+What:		/sys/class/lcd/<lcd>/gamma_table
+Date:		May, 2010
+KernelVersion:	v2.6.35
+Contact:	dri-devel@lists.freedesktop.org
+Description:
+		(RO) Displays the size of the gamma table i.e. the number of
+		gamma modes available.
+
+This is a backlight lcd driver. These interfaces are an extension to the API
+documented in Documentation/ABI/testing/sysfs-class-lcd and in
+Documentation/ABI/stable/sysfs-class-backlight (under
+/sys/class/backlight/<backlight>/).

Documentation/ABI/testing/sysfs-class-mei

@@ -45,3 +45,12 @@ Contact:	Tomas Winkler <tomas.winkler@intel.com>
 Description:	Display the driver HBM protocol version.
 
 		The HBM protocol version supported by the driver.
+
+What:		/sys/class/mei/meiN/tx_queue_limit
+Date:		Jan 2018
+KernelVersion:	4.16
+Contact:	Tomas Winkler <tomas.winkler@intel.com>
+Description:	Configure tx queue limit
+
+		Set maximal number of pending writes
+		per opened session.

Documentation/ABI/testing/sysfs-class-pktcdvd

@@ -1,60 +1,81 @@
-What:           /sys/class/pktcdvd/
-Date:           Oct. 2006
-KernelVersion:  2.6.20
-Contact:        Thomas Maier <balagi@justmail.de>
-Description:
-
 sysfs interface
 ---------------
+The pktcdvd module (packet writing driver) creates the following files in the
+sysfs: (<devid> is in the format major:minor)
+
+What:		/sys/class/pktcdvd/add
+What:		/sys/class/pktcdvd/remove
+What:		/sys/class/pktcdvd/device_map
+Date:		Oct. 2006
+KernelVersion:	2.6.20
+Contact:	Thomas Maier <balagi@justmail.de>
+Description:
+
+		add:		(WO) Write a block device id (major:minor) to
+				create a new pktcdvd device and map it to the
+				block device.
+
+		remove:		(WO) Write the pktcdvd device id (major:minor)
+				to remove the pktcdvd device.
+
+		device_map:	(RO) Shows the device mapping in format:
+				pktcdvd[0-7] <pktdevid> <blkdevid>
+
+
+What:		/sys/class/pktcdvd/pktcdvd[0-7]/dev
+What:		/sys/class/pktcdvd/pktcdvd[0-7]/uevent
+Date:		Oct. 2006
+KernelVersion:	2.6.20
+Contact:	Thomas Maier <balagi@justmail.de>
+Description:
+		dev:	(RO) Device id
+
+		uevent:	(WO) To send a uevent
+
+
+What:		/sys/class/pktcdvd/pktcdvd[0-7]/stat/packets_started
+What:		/sys/class/pktcdvd/pktcdvd[0-7]/stat/packets_finished
+What:		/sys/class/pktcdvd/pktcdvd[0-7]/stat/kb_written
+What:		/sys/class/pktcdvd/pktcdvd[0-7]/stat/kb_read
+What:		/sys/class/pktcdvd/pktcdvd[0-7]/stat/kb_read_gather
+What:		/sys/class/pktcdvd/pktcdvd[0-7]/stat/reset
+Date:		Oct. 2006
+KernelVersion:	2.6.20
+Contact:	Thomas Maier <balagi@justmail.de>
+Description:
+		packets_started:	(RO) Number of started packets.
+
+		packets_finished:	(RO) Number of finished packets.
+
+		kb_written:		(RO) kBytes written.
+
+		kb_read:		(RO) kBytes read.
+
+		kb_read_gather:		(RO) kBytes read to fill write packets.
+
+		reset:			(WO) Write any value to it to reset
+					pktcdvd device statistic values, like
+					bytes read/written.
+
+
+What:		/sys/class/pktcdvd/pktcdvd[0-7]/write_queue/size
+What:		/sys/class/pktcdvd/pktcdvd[0-7]/write_queue/congestion_off
+What:		/sys/class/pktcdvd/pktcdvd[0-7]/write_queue/congestion_on
+Date:		Oct. 2006
+KernelVersion:	2.6.20
+Contact:	Thomas Maier <balagi@justmail.de>
+Description:
+		size:		(RO) Contains the size of the bio write queue.
+
+		congestion_off:	(RW) If bio write queue size is below this mark,
+				accept new bio requests from the block layer.
 
-The pktcdvd module (packet writing driver) creates
-these files in the sysfs:
-(<devid> is in format  major:minor )
-
-/sys/class/pktcdvd/
-    add            (0200)  Write a block device id (major:minor)
-                           to create a new pktcdvd device and map
-                           it to the block device.
-
-    remove         (0200)  Write the pktcdvd device id (major:minor)
-                           to it to remove the pktcdvd device.
-
-    device_map     (0444)  Shows the device mapping in format:
-                             pktcdvd[0-7] <pktdevid> <blkdevid>
-
-/sys/class/pktcdvd/pktcdvd[0-7]/
-    dev                   (0444) Device id
-    uevent                (0200) To send an uevent.
-
-/sys/class/pktcdvd/pktcdvd[0-7]/stat/
-    packets_started       (0444) Number of started packets.
-    packets_finished      (0444) Number of finished packets.
-
-    kb_written            (0444) kBytes written.
-    kb_read               (0444) kBytes read.
-    kb_read_gather        (0444) kBytes read to fill write packets.
-
-    reset                 (0200) Write any value to it to reset
-                                 pktcdvd device statistic values, like
-                                 bytes read/written.
-
-/sys/class/pktcdvd/pktcdvd[0-7]/write_queue/
-    size                  (0444) Contains the size of the bio write
-                                 queue.
-
-    congestion_off        (0644) If bio write queue size is below
-                                 this mark, accept new bio requests
-                                 from the block layer.
-
-    congestion_on         (0644) If bio write queue size is higher
-                                 as this mark, do no longer accept
-                                 bio write requests from the block
-                                 layer and wait till the pktcdvd
-                                 device has processed enough bio's
-                                 so that bio write queue size is
-                                 below congestion off mark.
-                                 A value of <= 0 disables congestion
-                                 control.
+		congestion_on:	(RW) If bio write queue size is higher as this
+				mark, do no longer accept bio write requests
+				from the block layer and wait till the pktcdvd
+				device has processed enough bio's so that bio
+				write queue size is below congestion off mark.
+				A value of <= 0 disables congestion control.
 
 
 Example:

Documentation/ABI/testing/sysfs-class-rapidio

@@ -0,0 +1,55 @@
+What:		/sys/class/rapidio_port
+Description:
+		On-chip RapidIO controllers and PCIe-to-RapidIO bridges
+		(referenced as "Master Port" or "mport") are presented in sysfs
+		as the special class of devices: "rapidio_port".
+		The /sys/class/rapidio_port subdirectory contains individual
+		subdirectories named as "rapidioN" where N = mport ID registered
+		with RapidIO subsystem.
+		NOTE: An mport ID is not a RapidIO destination ID assigned to a
+		given local mport device.
+
+What:		/sys/class/rapidio_port/rapidioN/sys_size
+Date:		Apr, 2014
+KernelVersion:	v3.15
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) reports RapidIO common transport system size:
+		0 = small (8-bit destination ID, max. 256 devices),
+		1 = large (16-bit destination ID, max. 65536 devices).
+
+What:		/sys/class/rapidio_port/rapidioN/port_destid
+Date:		Apr, 2014
+KernelVersion:	v3.15
+Contact:	Matt Porter <mporter@kernel.crashing.org>,
+		Alexandre Bounine <alexandre.bounine@idt.com>
+Description:
+		(RO) reports RapidIO destination ID assigned to the given
+		RapidIO mport device. If value 0xFFFFFFFF is returned this means
+		that no valid destination ID have been assigned to the mport
+		(yet). Normally, before enumeration/discovery have been executed
+		only fabric enumerating mports have a valid destination ID
+		assigned to them using "hdid=..." rapidio module parameter.
+
+After enumeration or discovery was performed for a given mport device,
+the corresponding subdirectory will also contain subdirectories for each
+child RapidIO device connected to the mport.
+
+The example below shows mport device subdirectory with several child RapidIO
+devices attached to it.
+
+[rio@rapidio ~]$ ls /sys/class/rapidio_port/rapidio0/ -l
+total 0
+drwxr-xr-x 3 root root    0 Feb 11 15:10 00:e:0001
+drwxr-xr-x 3 root root    0 Feb 11 15:10 00:e:0004
+drwxr-xr-x 3 root root    0 Feb 11 15:10 00:e:0007
+drwxr-xr-x 3 root root    0 Feb 11 15:10 00:s:0002
+drwxr-xr-x 3 root root    0 Feb 11 15:10 00:s:0003
+drwxr-xr-x 3 root root    0 Feb 11 15:10 00:s:0005
+lrwxrwxrwx 1 root root    0 Feb 11 15:11 device -> ../../../0000:01:00.0
+-r--r--r-- 1 root root 4096 Feb 11 15:11 port_destid
+drwxr-xr-x 2 root root    0 Feb 11 15:11 power
+lrwxrwxrwx 1 root root    0 Feb 11 15:04 subsystem -> ../../../../../../class/rapidio_port
+-r--r--r-- 1 root root 4096 Feb 11 15:11 sys_size
+-rw-r--r-- 1 root root 4096 Feb 11 15:04 uevent

Documentation/ABI/testing/sysfs-class-rtc

@@ -43,6 +43,14 @@ Contact:	linux-rtc@vger.kernel.org
 Description:
 		(RO) The name of the RTC corresponding to this sysfs directory
 
+What:		/sys/class/rtc/rtcX/range
+Date:		January 2018
+KernelVersion:	4.16
+Contact:	linux-rtc@vger.kernel.org
+Description:
+		Valid time range for the RTC, as seconds from epoch, formatted
+		as [min, max]
+
 What:		/sys/class/rtc/rtcX/since_epoch
 Date:		March 2006
 KernelVersion:	2.6.17
@@ -57,14 +65,6 @@ Contact:	linux-rtc@vger.kernel.org
 Description:
 		(RO) RTC-provided time in 24-hour notation (hh:mm:ss)
 
-What:		/sys/class/rtc/rtcX/*/nvmem
-Date:		February 2016
-KernelVersion:	4.6
-Contact:	linux-rtc@vger.kernel.org
-Description:
-		(RW) The non volatile storage exported as a raw file, as
-		described in Documentation/nvmem/nvmem.txt
-
 What:		/sys/class/rtc/rtcX/offset
 Date:		February 2016
 KernelVersion:	4.6

Documentation/ABI/testing/sysfs-class-usb_role

@@ -0,0 +1,21 @@
+What:		/sys/class/usb_role/
+Date:		Jan 2018
+Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Description:
+		Place in sysfs for USB Role Switches. USB Role Switch is a
+		device that can select the data role (host or device) for USB
+		port.
+
+What:		/sys/class/usb_role/<switch>/role
+Date:		Jan 2018
+Contact:	Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Description:
+		The current role of the switch. This attribute can be used for
+		requesting role swapping with non-USB Type-C ports. With USB
+		Type-C ports, the ABI defined for USB Type-C connector class
+		must be used.
+
+		Valid values:
+		- none
+		- host
+		- device

Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD

@@ -0,0 +1,113 @@
+		ACPI Time and Alarm (TAD) device attributes.
+
+What:		/sys/bus/platform/devices/ACPI000E:00/caps
+Date:		March 2018
+Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+		(RO) Hexadecimal bitmask of the TAD attributes are reported by
+		the platform firmware (see ACPI 6.2, section 9.18.2):
+
+		BIT(0): AC wakeup implemented if set
+		BIT(1): DC wakeup implemented if set
+		BIT(2): Get/set real time features implemented if set
+		BIT(3): Real time accuracy in milliseconds if set
+		BIT(4): Correct status reported for wakeups from S4/S5 if set
+		BIT(5): The AC timer wakes up from S4 if set
+		BIT(6): The AC timer wakes up from S5 if set
+		BIT(7): The DC timer wakes up from S4 if set
+		BIT(8): The DC timer wakes up from S5 if set
+
+		The other bits are reserved.
+
+What:		/sys/bus/platform/devices/ACPI000E:00/ac_alarm
+Date:		March 2018
+Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+		(RW) The AC alarm timer value.
+
+		Reads return the current AC alarm timer value in seconds or
+		"disabled", if the AC alarm is not set to wake up the system.
+
+		Write a new AC alarm timer value in seconds or "disabled" to it
+		to set the AC alarm timer or to disable it, respectively.
+
+		If the AC alarm timer is set through this attribute and it
+		expires, it will immediately wake up the system from the S3
+		sleep state (and from S4/S5 too if supported) until its status
+		is explicitly cleared via the ac_status attribute.
+
+What:		/sys/bus/platform/devices/ACPI000E:00/ac_policy
+Date:		March 2018
+Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+		(RW) The AC alarm expired timer wake policy (see ACPI 6.2,
+		Section 9.18 for details).
+
+		Reads return the current expired timer wake delay for the AC
+		alarm timer or "never", if the policy is to discard AC timer
+		wakeups if the system is on DC power.
+
+		Write a new expired timer wake delay for the AC alarm timer in
+		seconds or "never" to it to set the expired timer wake delay for
+		the AC alarm timer or to set its expired wake policy to discard
+		wakeups if the system is on DC power, respectively.
+
+What:		/sys/bus/platform/devices/ACPI000E:00/ac_status
+Date:		March 2018
+Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+		(RW) The AC alarm status.
+
+		Reads return a hexadecimal bitmask representing the AC alarm
+		timer status with the following meaning of bits (see ACPI 6.2,
+		Section 9.18.5):
+
+		Bit(0): The timer has expired if set.
+		Bit(1): The timer has woken up the system from a sleep state
+		        (S3 or S4/S5 if supported) if set.
+
+		The other bits are reserved.
+
+		Reads also cause the AC alarm timer status to be reset.
+
+		Another way to reset the the status of the AC alarm timer is to
+		write (the number) 0 to this file.
+
+		If the status return value indicates that the timer has expired,
+		it will immediately wake up the system from the S3 sleep state
+		(and from S4/S5 too if supported) until its status is explicitly
+		cleared through this attribute.
+
+What:		/sys/bus/platform/devices/ACPI000E:00/dc_alarm
+Date:		March 2018
+Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+		(RW,optional) The DC alarm timer value.
+
+		This attribute is only present if the TAD supports a separate
+		DC timer.
+
+		It is analogous to the ac_alarm attribute.
+
+What:		/sys/bus/platform/devices/ACPI000E:00/dc_policy
+Date:		March 2018
+Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+		(RW,optional) The DC alarm expired timer wake policy.
+
+		This attribute is only present if the TAD supports a separate
+		DC timer.
+
+		It is analogous to the ac_policy attribute.
+
+What:		/sys/bus/platform/devices/ACPI000E:00/dc_status
+Date:		March 2018
+Contact:	Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+Description:
+		(RW,optional) The DC alarm status.
+
+		This attribute is only present if the TAD supports a separate
+		DC timer.
+
+		It is analogous to the ac_status attribute.

Documentation/ABI/testing/sysfs-devices-platform-ipmi

@@ -0,0 +1,238 @@
+What:		/sys/devices/platform/ipmi_bmc.*/firmware_revision
+Date:		Mar, 2006
+KernelVersion:	v2.6.17
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		(RO) The major and minor revision of the firmware.
+
+
+What:		/sys/devices/platform/ipmi_bmc.*/aux_firmware_revision
+Date:		Mar, 2006
+KernelVersion:	v2.6.17
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		(RO) Holds additional information about the firmware revision,
+		such as boot block or internal data structure version numbers.
+		The meanings of the numbers are specific to the vendor
+		identified by Manufacturer ID.
+
+
+What:		/sys/devices/platform/ipmi_bmc.*/revision
+Date:		Mar, 2006
+KernelVersion:	v2.6.17
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		(RO) Device revision. Useful for identifying if significant
+		hardware changes have been made to the implementation of the
+		management controller.
+
+
+What:		/sys/devices/platform/ipmi_bmc.*/provides_device_sdrs
+Date:		Mar, 2006
+KernelVersion:	v2.6.17
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		(RO) Indicates whether device provides device sensor data
+		records (1) or not (0).
+
+
+What:		/sys/devices/platform/ipmi_bmc.*/device_id
+Date:		Mar, 2006
+KernelVersion:	v2.6.17
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		(RO) Device id is specified by the manufacturer identified by
+		the Manufacturer ID field. This field allows controller specific
+		software to identify the unique application command, OEM
+		fields, and functionality that are provided by the controller
+
+
+What:		/sys/devices/platform/ipmi_bmc.*/additional_device_support
+Date:		Mar, 2006
+KernelVersion:	v2.6.17
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		(RO) Lists the IPMI ‘logical device’ commands and functions
+		that the controller supports that are in addition to the
+		mandatory IPM and Application commands.
+
+
+What:		/sys/devices/platform/ipmi_bmc.*/ipmi_version
+Date:		Mar, 2006
+KernelVersion:	v2.6.17
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		(RO) Displays the IPMI Command Specification Version.
+
+
+What:		/sys/devices/platform/ipmi_bmc.*/manufacturer_id
+Date:		Mar, 2006
+KernelVersion:	v2.6.17
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		(RO) Identifies the manufacturer responsible for the
+		specification of functionality of the vendor (OEM)-specific
+		commands, codes, and interfaces used in the controller.
+
+
+What:		/sys/devices/platform/ipmi_bmc.*/product_id
+Date:		Mar, 2006
+KernelVersion:	v2.6.17
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		(RO) Displays a number that identifies a particular system,
+		module, add-in card, or board set. The number is specified
+		according to the manufacturer given by Manufacturer ID.
+
+For detailed definitions of the above attributes, refer to section 20.1 'Get
+Device ID Command' of the IPMI specification v2.0.
+
+
+What:		/sys/devices/platform/ipmi_bmc.*/guid
+Date:		Mar, 2006
+KernelVersion:	v2.6.17
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		(RO) A GUID (Globally Unique ID), also referred to as a UUID
+		(Universally Unique Identifier), for the management controller,
+		as described in section 20.8 'Get Device GUID Command' of the
+		IPMI specification v2.0.
+
+
+What:		/sys/devices/platform/ipmi_si.*/type
+Date:		Sep, 2017
+KernelVersion:	v4.15
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		(RO) The device interface for IPMI "kcs", "smic", "bt" or
+		"invalid"
+
+What:		/sys/devices/platform/ipmi_si.*/idles
+What:		/sys/devices/platform/ipmi_si.*/watchdog_pretimeouts
+What:		/sys/devices/platform/ipmi_si.*/complete_transactions
+What:		/sys/devices/platform/ipmi_si.*/events
+What:		/sys/devices/platform/ipmi_si.*/interrupts
+What:		/sys/devices/platform/ipmi_si.*/hosed_count
+What:		/sys/devices/platform/ipmi_si.*/long_timeouts
+What:		/sys/devices/platform/ipmi_si.*/flag_fetches
+What:		/sys/devices/platform/ipmi_si.*/attentions
+What:		/sys/devices/platform/ipmi_si.*/incoming_messages
+What:		/sys/devices/platform/ipmi_si.*/short_timeouts
+Date:		Sep, 2017
+KernelVersion:	v4.15
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+
+		idles:			(RO) Number of times the interface was
+					idle while being polled.
+
+		watchdog_pretimeouts:	(RO) Number of watchdog pretimeouts.
+
+		complete_transactions:	(RO) Number of completed messages.
+
+		events:			(RO) Number of IPMI events received from
+					the hardware.
+
+		interrupts:		(RO) Number of interrupts the driver
+					handled.
+
+		hosed_count:		(RO) Number of times the hardware didn't
+					follow the state machine.
+
+		long_timeouts:		(RO) Number of times the driver
+					requested a timer while nothing was in
+					progress.
+
+		flag_fetches:		(RO) Number of times the driver
+					requested flags from the hardware.
+
+		attentions:		(RO) Number of time the driver got an
+					ATTN from the hardware.
+
+		incoming_messages:	(RO) Number of asynchronous messages
+					received.
+
+		short_timeouts:		(RO) Number of times the driver
+					requested a timer while an operation was
+					in progress.
+
+
+What:		/sys/devices/platform/ipmi_si.*/interrupts_enabled
+Date:		Sep, 2017
+KernelVersion:	v4.15
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		(RO) Indicates whether interrupts are enabled or not. The driver
+		disables interrupts when it gets into a situation where it
+		cannot handle messages due to lack of memory. Once that
+		situation clears up, it will re-enable interrupts.
+
+
+What:		/sys/devices/platform/ipmi_si.*/params
+Date:		Sep, 2017
+KernelVersion:	v4.15
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		[to be documented]
+
+
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/type
+Date:		Sep, 2017
+KernelVersion:	v4.15
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		(RO) Shows the IMPI device interface type - "ssif" here.
+
+
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/hosed
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/alerts
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/sent_messages
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/sent_messages_parts
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/received_messages
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/received_message_parts
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/events
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/watchdog_pretimeouts
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/flag_fetches
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/send_retries
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/receive_retries
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/send_errors
+What:		/sys/devices/platform/dmi-ipmi-ssif.*/receive_errors
+Date:		Sep, 2017
+KernelVersion:	v4.15
+Contact:	openipmi-developer@lists.sourceforge.net
+Description:
+		hosed:			(RO) Number of times the hardware didn't
+					follow the state machine.
+
+		alerts:			(RO) Number of alerts received.
+
+		sent_messages:		(RO) Number of total messages sent.
+
+		sent_message_parts:	(RO) Number of message parts sent.
+					Messages may be broken into parts if
+					they are long.
+
+		receieved_messages:	(RO) Number of message responses
+					received.
+
+		received_message_parts: (RO) Number of message fragments
+					received.
+
+		events:			(RO) Number of received events.
+
+		watchdog_pretimeouts:	(RO) Number of watchdog pretimeouts.
+
+		flag_fetches:		(RO) Number of times a flag fetch was
+					requested.
+
+		send_retries:		(RO) Number of time a message was
+					retried.
+
+		receive_retries:	(RO) Number of times the receive of a
+					message was retried.
+
+		send_errors:		(RO) Number of times the send of a
+					message failed.
+
+		receive_errors:		(RO) Number of errors in receiving
+					messages.

Documentation/ABI/testing/sysfs-devices-platform-trackpoint

@@ -0,0 +1,115 @@
+What:		/sys/devices/platform/i8042/.../sensitivity
+Date:		Aug, 2005
+KernelVersion:	2.6.14
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) Trackpoint sensitivity.
+
+What:		/sys/devices/platform/i8042/.../intertia
+Date:		Aug, 2005
+KernelVersion:	2.6.14
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) Negative inertia factor. High values cause the cursor to
+		snap backward when the trackpoint is released.
+
+What:		/sys/devices/platform/i8042/.../reach
+Date:		Aug, 2005
+KernelVersion:	2.6.14
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) Backup range for z-axis press.
+
+What:		/sys/devices/platform/i8042/.../draghys
+Date:		Aug, 2005
+KernelVersion:	2.6.14
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) The drag hysteresis controls how hard it is to drag with
+		z-axis pressed.
+
+What:		/sys/devices/platform/i8042/.../mindrag
+Date:		Aug, 2005
+KernelVersion:	2.6.14
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) Minimum amount of force needed to trigger dragging.
+
+What:		/sys/devices/platform/i8042/.../speed
+Date:		Aug, 2005
+KernelVersion:	2.6.14
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) Speed of the trackpoint cursor.
+
+What:		/sys/devices/platform/i8042/.../thresh
+Date:		Aug, 2005
+KernelVersion:	2.6.14
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) Minimum value for z-axis force required to trigger a press
+		or release, relative to the running average.
+
+What:		/sys/devices/platform/i8042/.../upthresh
+Date:		Aug, 2005
+KernelVersion:	2.6.14
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) The offset from the running average required to generate a
+		select (click) on z-axis on release.
+
+What:		/sys/devices/platform/i8042/.../ztime
+Date:		Aug, 2005
+KernelVersion:	2.6.14
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) This attribute determines how sharp a press has to be in
+		order to be recognized.
+
+What:		/sys/devices/platform/i8042/.../jenks
+Date:		Aug, 2005
+KernelVersion:	2.6.14
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) Minimum curvature in degrees required to generate a double
+		click without a release.
+
+What:		/sys/devices/platform/i8042/.../skipback
+Date:		Aug, 2005
+KernelVersion:	2.6.14
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) When the skipback bit is set, backup cursor movement during
+		releases from drags will be suppressed. The default value for
+		this bit is 0.
+
+What:		/sys/devices/platform/i8042/.../ext_dev
+Date:		Aug, 2005
+KernelVersion:	2.6.14
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) Disable (0) or enable (1) external pointing device.
+
+What:		/sys/devices/platform/i8042/.../press_to_select
+Date:		Aug, 2005
+KernelVersion:	2.6.14
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) Writing a value of 1 to this file will enable the Press to
+		Select functions like tapping the control stick to simulate a
+		left click, and writing 0 will disable it.
+
+What:		/sys/devices/platform/i8042/.../drift_time
+Date:		Dec, 2014
+KernelVersion:	3.19
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) This parameter controls the period of time to test for a
+		‘hands off’ condition (i.e. when no force is applied) before a
+		drift (noise) calibration occurs.
+
+		IBM Trackpoints have a feature to compensate for drift by
+		recalibrating themselves periodically. By default, if for 0.5
+		seconds there is no change in position, it's used as the new
+		zero. This duration is too low. Often, the calibration happens
+		when the trackpoint is in fact being used.

Documentation/ABI/testing/sysfs-devices-system-cpu

@@ -198,6 +198,31 @@ Description:
 		time (in microseconds) this cpu should spend in this idle state
 		to make the transition worth the effort.
 
+What:		/sys/devices/system/cpu/cpuX/cpuidle/stateN/s2idle/
+Date:		March 2018
+KernelVersion:	v4.17
+Contact:	Linux power management list <linux-pm@vger.kernel.org>
+Description:
+		Idle state usage statistics related to suspend-to-idle.
+
+		This attribute group is only present for states that can be
+		used in suspend-to-idle with suspended timekeeping.
+
+What:		/sys/devices/system/cpu/cpuX/cpuidle/stateN/s2idle/time
+Date:		March 2018
+KernelVersion:	v4.17
+Contact:	Linux power management list <linux-pm@vger.kernel.org>
+Description:
+		Total time spent by the CPU in suspend-to-idle (with scheduler
+		tick suspended) after requesting this state.
+
+What:		/sys/devices/system/cpu/cpuX/cpuidle/stateN/s2idle/usage
+Date:		March 2018
+KernelVersion:	v4.17
+Contact:	Linux power management list <linux-pm@vger.kernel.org>
+Description:
+		Total number of times this state has been requested by the CPU
+		while entering suspend-to-idle.
 
 What:		/sys/devices/system/cpu/cpu#/cpufreq/*
 Date:		pre-git history

Documentation/ABI/testing/sysfs-driver-fsi-master-gpio

@@ -0,0 +1,10 @@
+What:           /sys/bus/platform/devices/[..]/fsi-master-gpio/external_mode
+Date:           Feb 2018
+KernelVersion:  4.17
+Contact:        jk@ozlabs.org
+Description:
+                Controls access arbitration for GPIO-based FSI master. A
+		value of 0 (the default) sets normal mode, where the
+		driver performs FSI bus transactions, 1 sets external mode,
+		where the FSI bus is driven externally (for example, by
+		a debug device).

Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp

@@ -0,0 +1,19 @@
+What:		/sys/bus/hid/drivers/logitech-hidpp-device/<dev>/range
+Date:		Jan, 2016
+KernelVersion:	4.6
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) This attribute controls the amount of 'turn' permitted in
+		Logitech G920 wheel. Reading from the file shows the current
+		range of the steering wheel. Writing a value within the min and
+		max boundary sets the range of the wheel.
+
+What:		/sys/bus/hid/drivers/logitech-hidpp-device/<dev>/builtin_power_supply
+Date:		Apr, 2017
+KernelVersion:	4.12
+Contact:	linux-input@vger.kernel.org
+Description:
+		Presence of this file indicates that HID++ driver is capable of
+		handling battery properties in the kernel. This way, upower can
+		add a udev rule to decide whether or not it should use the
+		internal unifying support or the generic kernel one.

Documentation/ABI/testing/sysfs-driver-hid-ntrig

@@ -0,0 +1,70 @@
+What:		/sys/bus/hid/drivers/ntrig/<dev>/activate_slack
+Date:		May, 2010
+KernelVersion:	2.6.35
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) Number of contact frames ignored before acknowledging the
+		start of activity (activating touch).
+
+
+What:		/sys/bus/hid/drivers/ntrig/<dev>/decativate_slack
+Date:		May, 2010
+KernelVersion:	2.6.35
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RW) Number of empty (no contact) frames ignored before
+		acknowledging the end of activity (deactivating touch).
+
+		When the last finger is removed from the device, it sends a
+		number of empty frames. By holding off on deactivation for a few
+		frames false erroneous disconnects can be tolerated, where the
+		sensor may mistakenly not detect a finger that is still present.
+
+
+What:		/sys/bus/hid/drivers/ntrig/<dev>/activation_width
+What:		/sys/bus/hid/drivers/ntrig/<dev>/activation_height
+Date:		May, 2010
+KernelVersion:	2.6.35
+Contact:	linux-input@vger.kernel.org
+Description:
+		Threholds to override activation slack.
+
+		activation_width:	(RW) Width threshold to immediately
+					start processing touch events.
+
+		activation_height:	(RW) Height threshold to immediately
+					start processing touch events.
+
+
+What:		/sys/bus/hid/drivers/ntrig/<dev>/min_width
+What:		/sys/bus/hid/drivers/ntrig/<dev>/min_height
+Date:		May, 2010
+KernelVersion:	2.6.35
+Contact:	linux-input@vger.kernel.org
+Description:
+		Minimum size contact accepted.
+
+		min_width:	(RW) Minimum touch contact width to decide
+				activation and activity.
+
+		min_height:	(RW) Minimum touch contact height to decide
+				activation and activity.
+
+
+What:		/sys/bus/hid/drivers/ntrig/<dev>/sensor_physical_width
+What:		/sys/bus/hid/drivers/ntrig/<dev>/sensor_physical_height
+Date:		May, 2010
+KernelVersion:	2.6.35
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RO) These are internal ranges not used for normal events but
+		useful for tuning.
+
+
+What:		/sys/bus/hid/drivers/ntrig/<dev>/sensor_logical_width
+What:		/sys/bus/hid/drivers/ntrig/<dev>/sensor_logical_height
+Date:		May, 2010
+KernelVersion:	2.6.35
+Contact:	linux-input@vger.kernel.org
+Description:
+		(RO) The range for positions reported during activity.

Documentation/ABI/testing/sysfs-driver-ufs

@@ -0,0 +1,885 @@
+What:		/sys/bus/*/drivers/ufshcd/*/auto_hibern8
+Date:		March 2018
+Contact:	linux-scsi@vger.kernel.org
+Description:
+		This file contains the auto-hibernate idle timer setting of a
+		UFS host controller. A value of '0' means auto-hibernate is not
+		enabled. Otherwise the value is the number of microseconds of
+		idle time before the UFS host controller will autonomously put
+		the link into hibernate state. That will save power at the
+		expense of increased latency. Note that the hardware supports
+		10-bit values with a power-of-ten multiplier which allows a
+		maximum value of 102300000. Refer to the UFS Host Controller
+		Interface specification for more details.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/device_type
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the device type. This is one of the UFS
+		device descriptor parameters. The full information about
+		the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/device_class
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the device class. This is one of the UFS
+		device descriptor parameters. The full information about
+		the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/device_sub_class
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the UFS storage subclass. This is one of
+		the UFS device descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/protocol
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the protocol supported by an UFS device.
+		This is one of the UFS device descriptor parameters.
+		The full information about the descriptor could be found
+		at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/number_of_luns
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows number of logical units. This is one of
+		the UFS device descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/number_of_wluns
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows number of well known logical units.
+		This is one of the UFS device descriptor parameters.
+		The full information about the descriptor could be found
+		at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/boot_enable
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows value that indicates whether the device is
+		enabled for boot. This is one of the UFS device descriptor
+		parameters. The full information about the descriptor could
+		be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/descriptor_access_enable
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows value that indicates whether the device
+		descriptor could be read after partial initialization phase
+		of the boot sequence. This is one of the UFS device descriptor
+		parameters. The full information about the descriptor could
+		be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/initial_power_mode
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows value that defines the power mode after
+		device initialization or hardware reset. This is one of
+		the UFS device descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/high_priority_lun
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the high priority lun. This is one of
+		the UFS device descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/secure_removal_type
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the secure removal type. This is one of
+		the UFS device descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/support_security_lun
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows whether the security lun is supported.
+		This is one of the UFS device descriptor parameters.
+		The full information about the descriptor could be found
+		at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/bkops_termination_latency
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the background operations termination
+		latency. This is one of the UFS device descriptor parameters.
+		The full information about the descriptor could be found
+		at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/initial_active_icc_level
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the initial active ICC level. This is one
+		of the UFS device descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/specification_version
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the specification version. This is one
+		of the UFS device descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/manufacturing_date
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the manufacturing date in BCD format.
+		This is one of the UFS device descriptor parameters.
+		The full information about the descriptor could be found
+		at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/manufacturer_id
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the manufacturee ID. This is one of the
+		UFS device descriptor parameters. The full information about
+		the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/rtt_capability
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the maximum number of outstanding RTTs
+		supported by the device. This is one of the UFS device
+		descriptor parameters. The full information about
+		the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/rtc_update
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the frequency and method of the realtime
+		clock update. This is one of the UFS device descriptor
+		parameters. The full information about the descriptor
+		could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/ufs_features
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows which features are supported by the device.
+		This is one of the UFS device descriptor parameters.
+		The full information about the descriptor could be
+		found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/ffu_timeout
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the FFU timeout. This is one of the
+		UFS device descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/queue_depth
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the device queue depth. This is one of the
+		UFS device descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/device_version
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the device version. This is one of the
+		UFS device descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/number_of_secure_wpa
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows number of secure write protect areas
+		supported by the device. This is one of the UFS device
+		descriptor parameters. The full information about
+		the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/psa_max_data_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the maximum amount of data that may be
+		written during the pre-soldering phase of the PSA flow.
+		This is one of the UFS device descriptor parameters.
+		The full information about the descriptor could be found
+		at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/device_descriptor/psa_state_timeout
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the command maximum timeout for a change
+		in PSA state. This is one of the UFS device descriptor
+		parameters. The full information about the descriptor could
+		be found at UFS specifications 2.1.
+		The file is read only.
+
+
+What:		/sys/bus/platform/drivers/ufshcd/*/interconnect_descriptor/unipro_version
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the MIPI UniPro version number in BCD format.
+		This is one of the UFS interconnect descriptor parameters.
+		The full information about the descriptor could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/interconnect_descriptor/mphy_version
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the MIPI M-PHY version number in BCD format.
+		This is one of the UFS interconnect descriptor parameters.
+		The full information about the descriptor could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/raw_device_capacity
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the total memory quantity available to
+		the user to configure the device logical units. This is one
+		of the UFS geometry descriptor parameters. The full
+		information about the descriptor could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/max_number_of_luns
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the maximum number of logical units
+		supported by the UFS device. This is one of the UFS
+		geometry descriptor parameters. The full information about
+		the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/segment_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the segment size. This is one of the UFS
+		geometry descriptor parameters. The full information about
+		the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/allocation_unit_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the allocation unit size. This is one of
+		the UFS geometry descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/min_addressable_block_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the minimum addressable block size. This
+		is one of the UFS geometry descriptor parameters. The full
+		information about the descriptor could be found at UFS
+		specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/optimal_read_block_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the optimal read block size. This is one
+		of the UFS geometry descriptor parameters. The full
+		information about the descriptor could be found at UFS
+		specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/optimal_write_block_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the optimal write block size. This is one
+		of the UFS geometry descriptor parameters. The full
+		information about the descriptor could be found at UFS
+		specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/max_in_buffer_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the maximum data-in buffer size. This
+		is one of the UFS geometry descriptor parameters. The full
+		information about the descriptor could be found at UFS
+		specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/max_out_buffer_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the maximum data-out buffer size. This
+		is one of the UFS geometry descriptor parameters. The full
+		information about the descriptor could be found at UFS
+		specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/rpmb_rw_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the maximum number of RPMB frames allowed
+		in Security Protocol In/Out. This is one of the UFS geometry
+		descriptor parameters. The full information about the
+		descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/dyn_capacity_resource_policy
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the dynamic capacity resource policy. This
+		is one of the UFS geometry descriptor parameters. The full
+		information about the descriptor could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/data_ordering
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows support for out-of-order data transfer.
+		This is one of the UFS geometry descriptor parameters.
+		The full information about the descriptor could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/max_number_of_contexts
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows maximum available number of contexts which
+		are supported by the device. This is one of the UFS geometry
+		descriptor parameters. The full information about the
+		descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/sys_data_tag_unit_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows system data tag unit size. This is one of
+		the UFS geometry descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/sys_data_tag_resource_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows maximum storage area size allocated by
+		the device to handle system data by the tagging mechanism.
+		This is one of the UFS geometry descriptor parameters.
+		The full information about the descriptor could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/secure_removal_types
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows supported secure removal types. This is
+		one of the UFS geometry descriptor parameters. The full
+		information about the descriptor could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/memory_types
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows supported memory types. This is one of
+		the UFS geometry descriptor parameters. The full
+		information about the descriptor could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/*_memory_max_alloc_units
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the maximum number of allocation units for
+		different memory types (system code, non persistent,
+		enhanced type 1-4). This is one of the UFS geometry
+		descriptor parameters. The full information about the
+		descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/*_memory_capacity_adjustment_factor
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the memory capacity adjustment factor for
+		different memory types (system code, non persistent,
+		enhanced type 1-4). This is one of the UFS geometry
+		descriptor parameters. The full information about the
+		descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+
+What:		/sys/bus/platform/drivers/ufshcd/*/health_descriptor/eol_info
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows preend of life information. This is one
+		of the UFS health descriptor parameters. The full
+		information about the descriptor could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/health_descriptor/life_time_estimation_a
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows indication of the device life time
+		(method a). This is one of the UFS health descriptor
+		parameters. The full information about the descriptor
+		could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/health_descriptor/life_time_estimation_b
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows indication of the device life time
+		(method b). This is one of the UFS health descriptor
+		parameters. The full information about the descriptor
+		could be found at UFS specifications 2.1.
+		The file is read only.
+
+
+What:		/sys/bus/platform/drivers/ufshcd/*/power_descriptor/active_icc_levels_vcc*
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows maximum VCC, VCCQ and VCCQ2 value for
+		active ICC levels from 0 to 15. This is one of the UFS
+		power descriptor parameters. The full information about
+		the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+
+What:		/sys/bus/platform/drivers/ufshcd/*/string_descriptors/manufacturer_name
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file contains a device manufactureer name string.
+		The full information about the descriptor could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/string_descriptors/product_name
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file contains a product name string. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/string_descriptors/oem_id
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file contains a OEM ID string. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/string_descriptors/serial_number
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file contains a device serial number string. The full
+		information about the descriptor could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/string_descriptors/product_revision
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file contains a product revision string. The full
+		information about the descriptor could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+
+What:		/sys/class/scsi_device/*/device/unit_descriptor/boot_lun_id
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows boot LUN information. This is one of
+		the UFS unit descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/class/scsi_device/*/device/unit_descriptor/lun_write_protect
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows LUN write protection status. This is one of
+		the UFS unit descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/class/scsi_device/*/device/unit_descriptor/lun_queue_depth
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows LUN queue depth. This is one of the UFS
+		unit descriptor parameters. The full information about
+		the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/class/scsi_device/*/device/unit_descriptor/psa_sensitive
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows PSA sensitivity. This is one of the UFS
+		unit descriptor parameters. The full information about
+		the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/class/scsi_device/*/device/unit_descriptor/lun_memory_type
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows LUN memory type. This is one of the UFS
+		unit descriptor parameters. The full information about
+		the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/class/scsi_device/*/device/unit_descriptor/data_reliability
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file defines the device behavior when a power failure
+		occurs during a write operation. This is one of the UFS
+		unit descriptor parameters. The full information about
+		the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/class/scsi_device/*/device/unit_descriptor/logical_block_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the size of addressable logical blocks
+		(calculated as an exponent with base 2). This is one of
+		the UFS unit descriptor parameters. The full information about
+		the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/class/scsi_device/*/device/unit_descriptor/logical_block_count
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows total number of addressable logical blocks.
+		This is one of the UFS unit descriptor parameters. The full
+		information about the descriptor could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/class/scsi_device/*/device/unit_descriptor/erase_block_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the erase block size. This is one of
+		the UFS unit descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/class/scsi_device/*/device/unit_descriptor/provisioning_type
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the thin provisioning type. This is one of
+		the UFS unit descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/class/scsi_device/*/device/unit_descriptor/physical_memory_resourse_count
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the total physical memory resources. This is
+		one of the UFS unit descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/class/scsi_device/*/device/unit_descriptor/context_capabilities
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the context capabilities. This is one of
+		the UFS unit descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/class/scsi_device/*/device/unit_descriptor/large_unit_granularity
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the granularity of the LUN. This is one of
+		the UFS unit descriptor parameters. The full information
+		about the descriptor could be found at UFS specifications 2.1.
+		The file is read only.
+
+
+What:		/sys/bus/platform/drivers/ufshcd/*/flags/device_init
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the device init status. The full information
+		about the flag could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/flags/permanent_wpe
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows whether permanent write protection is enabled.
+		The full information about the flag could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/flags/power_on_wpe
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows whether write protection is enabled on all
+		logical units configured as power on write protected. The
+		full information about the flag could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/flags/bkops_enable
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows whether the device background operations are
+		enabled. The full information about the flag could be
+		found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/flags/life_span_mode_enable
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows whether the device life span mode is enabled.
+		The full information about the flag could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/flags/phy_resource_removal
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows whether physical resource removal is enable.
+		The full information about the flag could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/flags/busy_rtc
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows whether the device is executing internal
+		operation related to real time clock. The full information
+		about the flag could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/flags/disable_fw_update
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows whether the device FW update is permanently
+		disabled. The full information about the flag could be found
+		at UFS specifications 2.1.
+		The file is read only.
+
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/boot_lun_enabled
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file provides the boot lun enabled UFS device attribute.
+		The full information about the attribute could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/current_power_mode
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file provides the current power mode UFS device attribute.
+		The full information about the attribute could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/active_icc_level
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file provides the active icc level UFS device attribute.
+		The full information about the attribute could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/ooo_data_enabled
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file provides the out of order data transfer enabled UFS
+		device attribute. The full information about the attribute
+		could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/bkops_status
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file provides the background operations status UFS device
+		attribute. The full information about the attribute could
+		be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/purge_status
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file provides the purge operation status UFS device
+		attribute. The full information about the attribute could
+		be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/max_data_in_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the maximum data size in a DATA IN
+		UPIU. The full information about the attribute could
+		be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/max_data_out_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the maximum number of bytes that can be
+		requested with a READY TO TRANSFER UPIU. The full information
+		about the attribute could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/reference_clock_frequency
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file provides the reference clock frequency UFS device
+		attribute. The full information about the attribute could
+		be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/configuration_descriptor_lock
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows whether the configuration descriptor is locked.
+		The full information about the attribute could be found at
+		UFS specifications 2.1. The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/max_number_of_rtt
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file provides the maximum current number of
+		outstanding RTTs in device that is allowed. The full
+		information about the attribute could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/exception_event_control
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file provides the exception event control UFS device
+		attribute. The full information about the attribute could
+		be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/exception_event_status
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file provides the exception event status UFS device
+		attribute. The full information about the attribute could
+		be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/ffu_status
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file provides the ffu status UFS device attribute.
+		The full information about the attribute could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/psa_state
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file show the PSA feature status. The full information
+		about the attribute could be found at UFS specifications 2.1.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/attributes/psa_data_size
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the amount of data that the host plans to
+		load to all logical units in pre-soldering state.
+		The full information about the attribute could be found at
+		UFS specifications 2.1.
+		The file is read only.
+
+
+What:		/sys/class/scsi_device/*/device/dyn_cap_needed
+Date:		February 2018
+Contact:	Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Description:	This file shows the The amount of physical memory needed
+		to be removed from the physical memory resources pool of
+		the particular logical unit. The full information about
+		the attribute could be found at UFS specifications 2.1.
+		The file is read only.
+
+
+What:		/sys/bus/platform/drivers/ufshcd/*/rpm_lvl
+Date:		September 2014
+Contact:	Subhash Jadavani <subhashj@codeaurora.org>
+Description:	This entry could be used to set or show the UFS device
+		runtime power management level. The current driver
+		implementation supports 6 levels with next target states:
+		0 - an UFS device will stay active, an UIC link will
+		stay active
+		1 - an UFS device will stay active, an UIC link will
+		hibernate
+		2 - an UFS device will moved to sleep, an UIC link will
+		stay active
+		3 - an UFS device will moved to sleep, an UIC link will
+		hibernate
+		4 - an UFS device will be powered off, an UIC link will
+		hibernate
+		5 - an UFS device will be powered off, an UIC link will
+		be powered off
+
+What:		/sys/bus/platform/drivers/ufshcd/*/rpm_target_dev_state
+Date:		February 2018
+Contact:	Subhash Jadavani <subhashj@codeaurora.org>
+Description:	This entry shows the target power mode of an UFS device
+		for the chosen runtime power management level.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/rpm_target_link_state
+Date:		February 2018
+Contact:	Subhash Jadavani <subhashj@codeaurora.org>
+Description:	This entry shows the target state of an UFS UIC link
+		for the chosen runtime power management level.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/spm_lvl
+Date:		September 2014
+Contact:	Subhash Jadavani <subhashj@codeaurora.org>
+Description:	This entry could be used to set or show the UFS device
+		system power management level. The current driver
+		implementation supports 6 levels with next target states:
+		0 - an UFS device will stay active, an UIC link will
+		stay active
+		1 - an UFS device will stay active, an UIC link will
+		hibernate
+		2 - an UFS device will moved to sleep, an UIC link will
+		stay active
+		3 - an UFS device will moved to sleep, an UIC link will
+		hibernate
+		4 - an UFS device will be powered off, an UIC link will
+		hibernate
+		5 - an UFS device will be powered off, an UIC link will
+		be powered off
+
+What:		/sys/bus/platform/drivers/ufshcd/*/spm_target_dev_state
+Date:		February 2018
+Contact:	Subhash Jadavani <subhashj@codeaurora.org>
+Description:	This entry shows the target power mode of an UFS device
+		for the chosen system power management level.
+		The file is read only.
+
+What:		/sys/bus/platform/drivers/ufshcd/*/spm_target_link_state
+Date:		February 2018
+Contact:	Subhash Jadavani <subhashj@codeaurora.org>
+Description:	This entry shows the target state of an UFS UIC link
+		for the chosen system power management level.
+		The file is read only.

Documentation/ABI/testing/sysfs-fs-f2fs

@@ -192,3 +192,14 @@ Date:		November 2017
 Contact:	"Sheng Yong" <shengyong1@huawei.com>
 Description:
 		 Controls readahead inode block in readdir.
+
+What:		/sys/fs/f2fs/<disk>/extension_list
+Date:		Feburary 2018
+Contact:	"Chao Yu" <yuchao0@huawei.com>
+Description:
+		 Used to control configure extension list:
+		 - Query: cat /sys/fs/f2fs/<disk>/extension_list
+		 - Add: echo '[h/c]extension' > /sys/fs/f2fs/<disk>/extension_list
+		 - Del: echo '[h/c]!extension' > /sys/fs/f2fs/<disk>/extension_list
+		 - [h] means add/del hot file extension
+		 - [c] means add/del cold file extension

Documentation/ABI/testing/sysfs-kernel-irq

@@ -51,3 +51,10 @@ Date:		September 2016
 KernelVersion:	4.9
 Contact:	Craig Gallek <kraig@google.com>
 Description:	The type of the interrupt.  Either the string 'level' or 'edge'.
+
+What:		/sys/kernel/irq/<irq>/wakeup
+Date:		March 2018
+KernelVersion:	4.17
+Contact:	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Description:	The wakeup state of the interrupt. Either the string
+		'enabled' or 'disabled'.

Documentation/ABI/testing/sysfs-power

@@ -287,3 +287,17 @@ Description:
 		Writing a "1" to this file enables the debug messages and
 		writing a "0" (default) to it disables them.  Reads from
 		this file return the current value.
+
+What:		/sys/power/resume_offset
+Date:		April 2018
+Contact:	Mario Limonciello <mario.limonciello@dell.com>
+Description:
+		This file is used for telling the kernel an offset into a disk
+		to use when hibernating the system such as with a swap file.
+
+		Reads from this file will display the current offset
+		the kernel will be using on the next hibernation
+		attempt.
+
+		Using this sysfs file will override any values that were
+		set using the kernel command line for disk offset.

Documentation/admin-guide/README.rst

@@ -26,8 +26,8 @@ On what hardware does it run?
   Although originally developed first for 32-bit x86-based PCs (386 or higher),
   today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
   UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
-  IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
-  Xtensa, Tilera TILE, ARC and Renesas M32R architectures.
+  IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64 Xtensa, and
+  ARC architectures.
 
   Linux is easily portable to most general-purpose 32- or 64-bit architectures
   as long as they have a paged memory management unit (PMMU) and a port of the
@@ -218,6 +218,13 @@ Configuring the kernel
      "make localyesconfig" Similar to localmodconfig, except it will convert
                            all module options to built in (=y) options.
 
+     "make kvmconfig"   Enable additional options for kvm guest kernel support.
+
+     "make xenconfig"   Enable additional options for xen dom0 guest kernel
+                        support.
+
+     "make tinyconfig"  Configure the tiniest possible kernel.
+
    You can find more information on using the Linux kernel config tools
    in Documentation/kbuild/kconfig.txt.
 

Documentation/admin-guide/kernel-parameters.rst

@@ -89,7 +89,6 @@ parameter is applicable::
 	APM	Advanced Power Management support is enabled.
 	ARM	ARM architecture is enabled.
 	AX25	Appropriate AX.25 support is enabled.
-	BLACKFIN Blackfin architecture is enabled.
 	CLK	Common clock infrastructure is enabled.
 	CMA	Contiguous Memory Area support is enabled.
 	DRM	Direct Rendering Management support is enabled.

Documentation/admin-guide/kernel-parameters.txt

@@ -389,15 +389,15 @@
 			Use software keyboard repeat
 
 	audit=		[KNL] Enable the audit sub-system
-			Format: { "0" | "1" } (0 = disabled, 1 = enabled)
-			0 - kernel audit is disabled and can not be enabled
-			    until the next reboot
+			Format: { "0" | "1" | "off" | "on" }
+			0 | off - kernel audit is disabled and can not be
+			    enabled until the next reboot
 			unset - kernel audit is initialized but disabled and
 			    will be fully enabled by the userspace auditd.
-			1 - kernel audit is initialized and partially enabled,
-			    storing at most audit_backlog_limit messages in
-			    RAM until it is fully enabled by the userspace
-			    auditd.
+			1 | on - kernel audit is initialized and partially
+			    enabled, storing at most audit_backlog_limit
+			    messages in RAM until it is fully enabled by the
+			    userspace auditd.
 			Default: unset
 
 	audit_backlog_limit= [KNL] Set the audit queue size limit.
@@ -1025,7 +1025,7 @@
 			address. The serial port must already be setup
 			and configured. Options are not yet supported.
 
-	earlyprintk=	[X86,SH,BLACKFIN,ARM,M68k,S390]
+	earlyprintk=	[X86,SH,ARM,M68k,S390]
 			earlyprintk=vga
 			earlyprintk=efi
 			earlyprintk=sclp
@@ -1347,10 +1347,6 @@
 			       If specified, z/VM IUCV HVC accepts connections
 			       from listed z/VM user IDs only.
 
-	hwthread_map=	[METAG] Comma-separated list of Linux cpu id to
-			        hardware thread id mappings.
-				Format: <cpu>:<hwthread>
-
 	keep_bootcon	[KNL]
 			Do not unregister boot console at start. This is only
 			useful for debugging when something happens in the window
@@ -1525,7 +1521,8 @@
 
 	ima_policy=	[IMA]
 			The builtin policies to load during IMA setup.
-			Format: "tcb | appraise_tcb | secure_boot"
+			Format: "tcb | appraise_tcb | secure_boot |
+				 fail_securely"
 
 			The "tcb" policy measures all programs exec'd, files
 			mmap'd for exec, and all files opened with the read
@@ -1540,6 +1537,11 @@
 			of files (eg. kexec kernel image, kernel modules,
 			firmware, policy, etc) based on file signatures.
 
+			The "fail_securely" policy forces file signature
+			verification failure also on privileged mounted
+			filesystems with the SB_I_UNVERIFIABLE_SIGNATURE
+			flag.
+
 	ima_tcb		[IMA] Deprecated.  Use ima_policy= instead.
 			Load a policy which meets the needs of the Trusted
 			Computing Base.  This means IMA will measure all
@@ -1743,6 +1745,14 @@
 			of a GICv2 controller even if the memory range
 			exposed by the device tree is too small.
 
+	irqchip.gicv3_nolpi=
+			[ARM, ARM64]
+			Force the kernel to ignore the availability of
+			LPIs (and by consequence ITSs). Intended for system
+			that use the kernel as a bootloader, and thus want
+			to let secondary kernels in charge of setting up
+			LPIs.
+
 	irqfixup	[HW]
 			When an interrupt is not handled search all handlers
 			for it. Intended to get systems with badly broken
@@ -1766,6 +1776,17 @@
 
 			nohz
 			  Disable the tick when a single task runs.
+
+			  A residual 1Hz tick is offloaded to workqueues, which you
+			  need to affine to housekeeping through the global
+			  workqueue's affinity configured via the
+			  /sys/devices/virtual/workqueue/cpumask sysfs file, or
+			  by using the 'domain' flag described below.
+
+			  NOTE: by default the global workqueue runs on all CPUs,
+			  so to protect individual CPUs the 'cpumask' file has to
+			  be configured manually after bootup.
+
 			domain
 			  Isolate from the general SMP balancing and scheduling
 			  algorithms. Note that performing domain isolation this way
@@ -1825,30 +1846,29 @@
 	keepinitrd	[HW,ARM]
 
 	kernelcore=	[KNL,X86,IA-64,PPC]
-			Format: nn[KMGTPE] | "mirror"
-			This parameter
-			specifies the amount of memory usable by the kernel
-			for non-movable allocations.  The requested amount is
-			spread evenly throughout all nodes in the system. The
-			remaining memory in each node is used for Movable
-			pages. In the event, a node is too small to have both
-			kernelcore and Movable pages, kernelcore pages will
-			take priority and other nodes will have a larger number
-			of Movable pages.  The Movable zone is used for the
-			allocation of pages that may be reclaimed or moved
-			by the page migration subsystem.  This means that
-			HugeTLB pages may not be allocated from this zone.
-			Note that allocations like PTEs-from-HighMem still
-			use the HighMem zone if it exists, and the Normal
+			Format: nn[KMGTPE] | nn% | "mirror"
+			This parameter specifies the amount of memory usable by
+			the kernel for non-movable allocations.  The requested
+			amount is spread evenly throughout all nodes in the
+			system as ZONE_NORMAL.  The remaining memory is used for
+			movable memory in its own zone, ZONE_MOVABLE.  In the
+			event, a node is too small to have both ZONE_NORMAL and
+			ZONE_MOVABLE, kernelcore memory will take priority and
+			other nodes will have a larger ZONE_MOVABLE.
+
+			ZONE_MOVABLE is used for the allocation of pages that
+			may be reclaimed or moved by the page migration
+			subsystem.  Note that allocations like PTEs-from-HighMem
+			still use the HighMem zone if it exists, and the Normal
 			zone if it does not.
 
-			Instead of specifying the amount of memory (nn[KMGTPE]),
-			you can specify "mirror" option. In case "mirror"
+			It is possible to specify the exact amount of memory in
+			the form of "nn[KMGTPE]", a percentage of total system
+			memory in the form of "nn%", or "mirror".  If "mirror"
 			option is specified, mirrored (reliable) memory is used
 			for non-movable allocations and remaining memory is used
-			for Movable pages. nn[KMGTPE] and "mirror" are exclusive,
-			so you can NOT specify nn[KMGTPE] and "mirror" at the same
-			time.
+			for Movable pages.  "nn[KMGTPE]", "nn%", and "mirror"
+			are exclusive, so you cannot specify multiple forms.
 
 	kgdbdbgp=	[KGDB,HW] kgdb over EHCI usb debug port.
 			Format: <Controller#>[,poll interval]
@@ -1887,6 +1907,9 @@
 	kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs.
 			Default is 0 (don't ignore, but inject #GP)
 
+	kvm.enable_vmware_backdoor=[KVM] Support VMware backdoor PV interface.
+				   Default is false (don't support).
+
 	kvm.mmu_audit=	[KVM] This is a R/W parameter which allows audit
 			KVM MMU at runtime.
 			Default is 0 (off)
@@ -2237,6 +2260,15 @@
 			The memory region may be marked as e820 type 12 (0xc)
 			and is NVDIMM or ADR memory.
 
+	memmap=<size>%<offset>-<oldtype>+<newtype>
+			[KNL,ACPI] Convert memory within the specified region
+			from <oldtype> to <newtype>. If "-<oldtype>" is left
+			out, the whole region will be marked as <newtype>,
+			even if previously unavailable. If "+<newtype>" is left
+			out, matching memory will be removed. Types are
+			specified as e820 types, e.g., 1 = RAM, 2 = reserved,
+			3 = ACPI, 12 = PRAM.
+
 	memory_corruption_check=0/1 [X86]
 			Some BIOSes seem to corrupt the first 64k of
 			memory when doing things like suspend/resume.
@@ -2353,13 +2385,14 @@
 	mousedev.yres=	[MOUSE] Vertical screen resolution, used for devices
 			reporting absolute coordinates, such as tablets
 
-	movablecore=nn[KMG]	[KNL,X86,IA-64,PPC] This parameter
-			is similar to kernelcore except it specifies the
-			amount of memory used for migratable allocations.
-			If both kernelcore and movablecore is specified,
-			then kernelcore will be at *least* the specified
-			value but may be more. If movablecore on its own
-			is specified, the administrator must be careful
+	movablecore=	[KNL,X86,IA-64,PPC]
+			Format: nn[KMGTPE] | nn%
+			This parameter is the complement to kernelcore=, it
+			specifies the amount of memory used for migratable
+			allocations.  If both kernelcore and movablecore is
+			specified, then kernelcore will be at *least* the
+			specified value but may be more.  If movablecore on its
+			own is specified, the administrator must be careful
 			that the amount of memory usable for all allocations
 			is not too small.
 
@@ -3130,18 +3163,13 @@
 		force	Enable ASPM even on devices that claim not to support it.
 			WARNING: Forcing ASPM on may cause system lockups.
 
-	pcie_hp=	[PCIE] PCI Express Hotplug driver options:
-		nomsi	Do not use MSI for PCI Express Native Hotplug (this
-			makes all PCIe ports use INTx for hotplug services).
-
-	pcie_ports=	[PCIE] PCIe ports handling:
-		auto	Ask the BIOS whether or not to use native PCIe services
-			associated with PCIe ports (PME, hot-plug, AER).  Use
-			them only if that is allowed by the BIOS.
-		native	Use native PCIe services associated with PCIe ports
-			unconditionally.
-		compat	Treat PCIe ports as PCI-to-PCI bridges, disable the PCIe
-			ports driver.
+	pcie_ports=	[PCIE] PCIe port services handling:
+		native	Use native PCIe services (PME, AER, DPC, PCIe hotplug)
+			even if the platform doesn't give the OS permission to
+			use them.  This may cause conflicts if the platform
+			also tries to use these services.
+		compat	Disable native PCIe services (PME, AER, DPC, PCIe
+			hotplug).
 
 	pcie_port_pm=	[PCIE] PCIe port power management handling:
 		off	Disable power management of all PCIe ports
@@ -4368,12 +4396,73 @@
 
 	usbcore.nousb	[USB] Disable the USB subsystem
 
+	usbcore.quirks=
+			[USB] A list of quirk entries to augment the built-in
+			usb core quirk list. List entries are separated by
+			commas. Each entry has the form
+			VendorID:ProductID:Flags. The IDs are 4-digit hex
+			numbers and Flags is a set of letters. Each letter
+			will change the built-in quirk; setting it if it is
+			clear and clearing it if it is set. The letters have
+			the following meanings:
+				a = USB_QUIRK_STRING_FETCH_255 (string
+					descriptors must not be fetched using
+					a 255-byte read);
+				b = USB_QUIRK_RESET_RESUME (device can't resume
+					correctly so reset it instead);
+				c = USB_QUIRK_NO_SET_INTF (device can't handle
+					Set-Interface requests);
+				d = USB_QUIRK_CONFIG_INTF_STRINGS (device can't
+					handle its Configuration or Interface
+					strings);
+				e = USB_QUIRK_RESET (device can't be reset
+					(e.g morph devices), don't use reset);
+				f = USB_QUIRK_HONOR_BNUMINTERFACES (device has
+					more interface descriptions than the
+					bNumInterfaces count, and can't handle
+					talking to these interfaces);
+				g = USB_QUIRK_DELAY_INIT (device needs a pause
+					during initialization, after we read
+					the device descriptor);
+				h = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL (For
+					high speed and super speed interrupt
+					endpoints, the USB 2.0 and USB 3.0 spec
+					require the interval in microframes (1
+					microframe = 125 microseconds) to be
+					calculated as interval = 2 ^
+					(bInterval-1).
+					Devices with this quirk report their
+					bInterval as the result of this
+					calculation instead of the exponent
+					variable used in the calculation);
+				i = USB_QUIRK_DEVICE_QUALIFIER (device can't
+					handle device_qualifier descriptor
+					requests);
+				j = USB_QUIRK_IGNORE_REMOTE_WAKEUP (device
+					generates spurious wakeup, ignore
+					remote wakeup capability);
+				k = USB_QUIRK_NO_LPM (device can't handle Link
+					Power Management);
+				l = USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL
+					(Device reports its bInterval as linear
+					frames instead of the USB 2.0
+					calculation);
+				m = USB_QUIRK_DISCONNECT_SUSPEND (Device needs
+					to be disconnected before suspend to
+					prevent spurious wakeup);
+				n = USB_QUIRK_DELAY_CTRL_MSG (Device needs a
+					pause after every control message);
+			Example: quirks=0781:5580:bk,0a5c:5834:gij
+
 	usbhid.mousepoll=
 			[USBHID] The interval which mice are to be polled at.
 
 	usbhid.jspoll=
 			[USBHID] The interval which joysticks are to be polled at.
 
+	usbhid.kbpoll=
+			[USBHID] The interval which keyboards are to be polled at.
+
 	usb-storage.delay_use=
 			[UMS] The delay in seconds before a new device is
 			scanned for Logical Units (default 1).

Documentation/admin-guide/module-signing.rst

@@ -180,11 +180,11 @@ Public keys in the kernel
 =========================
 
 The kernel contains a ring of public keys that can be viewed by root.  They're
-in a keyring called ".system_keyring" that can be seen by::
+in a keyring called ".builtin_trusted_keys" that can be seen by::
 
 	[root@deneb ~]# cat /proc/keys
 	...
-	223c7853 I------     1 perm 1f030000     0     0 keyring   .system_keyring: 1
+	223c7853 I------     1 perm 1f030000     0     0 keyring   .builtin_trusted_keys: 1
 	302d2d52 I------     1 perm 1f010000     0     0 asymmetri Fedora kernel signing key: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 []
 	...
 
@@ -197,15 +197,15 @@ add those in also (e.g. from the UEFI key database).
 
 Finally, it is possible to add additional public keys by doing::
 
-	keyctl padd asymmetric "" [.system_keyring-ID] <[key-file]
+	keyctl padd asymmetric "" [.builtin_trusted_keys-ID] <[key-file]
 
 e.g.::
 
 	keyctl padd asymmetric "" 0x223c7853 <my_public_key.x509
 
 Note, however, that the kernel will only permit keys to be added to
-``.system_keyring _if_`` the new key's X.509 wrapper is validly signed by a key
-that is already resident in the .system_keyring at the time the key was added.
+``.builtin_trusted_keys`` **if** the new key's X.509 wrapper is validly signed by a key
+that is already resident in the ``.builtin_trusted_keys`` at the time the key was added.
 
 
 ========================

Documentation/admin-guide/security-bugs.rst

@@ -29,18 +29,20 @@ made public.
 Disclosure
 ----------
 
-The goal of the Linux kernel security team is to work with the
-bug submitter to bug resolution as well as disclosure.  We prefer
-to fully disclose the bug as soon as possible.  It is reasonable to
-delay disclosure when the bug or the fix is not yet fully understood,
-the solution is not well-tested or for vendor coordination.  However, we
-expect these delays to be short, measurable in days, not weeks or months.
-A disclosure date is negotiated by the security team working with the
-bug submitter as well as vendors.  However, the kernel security team
-holds the final say when setting a disclosure date.  The timeframe for
-disclosure is from immediate (esp. if it's already publicly known)
+The goal of the Linux kernel security team is to work with the bug
+submitter to understand and fix the bug.  We prefer to publish the fix as
+soon as possible, but try to avoid public discussion of the bug itself
+and leave that to others.
+
+Publishing the fix may be delayed when the bug or the fix is not yet
+fully understood, the solution is not well-tested or for vendor
+coordination.  However, we expect these delays to be short, measurable in
+days, not weeks or months.  A release date is negotiated by the security
+team working with the bug submitter as well as vendors.  However, the
+kernel security team holds the final say when setting a timeframe.  The
+timeframe varies from immediate (esp. if it's already publicly known bug)
 to a few weeks.  As a basic default policy, we expect report date to
-disclosure date to be on the order of 7 days.
+release date to be on the order of 7 days.
 
 Coordination
 ------------

Documentation/admin-guide/tainted-kernels.rst

@@ -6,34 +6,34 @@ counter. This indicates that the kernel has been tainted by some
 mechanism.  The string is followed by a series of position-sensitive
 characters, each representing a particular tainted value.
 
-  1) 'G' if all modules loaded have a GPL or compatible license, 'P' if
+ 1)  ``G`` if all modules loaded have a GPL or compatible license, ``P`` if
      any proprietary module has been loaded.  Modules without a
      MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by
      insmod as GPL compatible are assumed to be proprietary.
 
-  2) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all
+ 2)  ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all
      modules were loaded normally.
 
-  3) ``S`` if the oops occurred on an SMP kernel running on hardware that
+ 3)  ``S`` if the oops occurred on an SMP kernel running on hardware that
      hasn't been certified as safe to run multiprocessor.
      Currently this occurs only on various Athlons that are not
      SMP capable.
 
-  4) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all
+ 4)  ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all
      modules were unloaded normally.
 
-  5) ``M`` if any processor has reported a Machine Check Exception,
+ 5)  ``M`` if any processor has reported a Machine Check Exception,
      ``' '`` if no Machine Check Exceptions have occurred.
 
-  6) ``B`` if a page-release function has found a bad page reference or
+ 6)  ``B`` if a page-release function has found a bad page reference or
      some unexpected page flags.
 
-  7) ``U`` if a user or user application specifically requested that the
+ 7)  ``U`` if a user or user application specifically requested that the
      Tainted flag be set, ``' '`` otherwise.
 
-  8) ``D`` if the kernel has died recently, i.e. there was an OOPS or BUG.
+ 8)  ``D`` if the kernel has died recently, i.e. there was an OOPS or BUG.
 
-  9) ``A`` if the ACPI table has been overridden.
+ 9)  ``A`` if the ACPI table has been overridden.
 
  10) ``W`` if a warning has previously been issued by the kernel.
      (Though some warnings may set more specific taint flags.)

Documentation/admin-guide/thunderbolt.rst

@@ -21,11 +21,11 @@ vulnerable to DMA attacks.
 Security levels and how to use them
 -----------------------------------
 Starting with Intel Falcon Ridge Thunderbolt controller there are 4
-security levels available. The reason for these is the fact that the
-connected devices can be DMA masters and thus read contents of the host
-memory without CPU and OS knowing about it. There are ways to prevent
-this by setting up an IOMMU but it is not always available for various
-reasons.
+security levels available. Intel Titan Ridge added one more security level
+(usbonly). The reason for these is the fact that the connected devices can
+be DMA masters and thus read contents of the host memory without CPU and OS
+knowing about it. There are ways to prevent this by setting up an IOMMU but
+it is not always available for various reasons.
 
 The security levels are as follows:
 
@@ -52,6 +52,11 @@ The security levels are as follows:
     USB. No PCIe tunneling is done. In BIOS settings this is
     typically called *Display Port Only*.
 
+  usbonly
+    The firmware automatically creates tunnels for the USB controller and
+    Display Port in a dock. All PCIe links downstream of the dock are
+    removed.
+
 The current security level can be read from
 ``/sys/bus/thunderbolt/devices/domainX/security`` where ``domainX`` is
 the Thunderbolt domain the host controller manages. There is typically

Documentation/arm/Atmel/README

@@ -1,171 +0,0 @@
-ARM Atmel SoCs (aka AT91)
-=========================
-
-
-Introduction
-------------
-This document gives useful information about the ARM Atmel SoCs that are
-currently supported in Linux Mainline (you know, the one on kernel.org).
-
-It is important to note that the Atmel | SMART ARM-based MPU product line is
-historically named "AT91" or "at91" throughout the Linux kernel development
-process even if this product prefix has completely disappeared from the
-official Atmel product name. Anyway, files, directories, git trees,
-git branches/tags and email subject always contain this "at91" sub-string.
-
-
-AT91 SoCs
----------
-Documentation and detailed datasheet for each product are available on
-the Atmel website: http://www.atmel.com.
-
-  Flavors:
-    * ARM 920 based SoC
-      - at91rm9200
-        + Datasheet
-          http://www.atmel.com/Images/doc1768.pdf
-
-    * ARM 926 based SoCs
-      - at91sam9260
-        + Datasheet
-          http://www.atmel.com/Images/doc6221.pdf
-
-      - at91sam9xe
-        + Datasheet
-          http://www.atmel.com/Images/Atmel-6254-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9XE_Datasheet.pdf
-
-      - at91sam9261
-        + Datasheet
-          http://www.atmel.com/Images/doc6062.pdf
-
-      - at91sam9263
-        + Datasheet
-          http://www.atmel.com/Images/Atmel_6249_32-bit-ARM926EJ-S-Microcontroller_SAM9263_Datasheet.pdf
-
-      - at91sam9rl
-        + Datasheet
-          http://www.atmel.com/Images/doc6289.pdf
-
-      - at91sam9g20
-        + Datasheet
-          http://www.atmel.com/Images/doc6384.pdf
-
-      - at91sam9g45 family
-        - at91sam9g45
-        - at91sam9g46
-        - at91sam9m10
-        - at91sam9m11 (device superset)
-        + Datasheet
-          http://www.atmel.com/Images/Atmel-6437-32-bit-ARM926-Embedded-Microprocessor-SAM9M11_Datasheet.pdf
-
-      - at91sam9x5 family (aka "The 5 series")
-        - at91sam9g15
-        - at91sam9g25
-        - at91sam9g35
-        - at91sam9x25
-        - at91sam9x35
-        + Datasheet (can be considered as covering the whole family)
-          http://www.atmel.com/Images/Atmel_11055_32-bit-ARM926EJ-S-Microcontroller_SAM9X35_Datasheet.pdf
-
-      - at91sam9n12
-        + Datasheet
-          http://www.atmel.com/Images/Atmel_11063_32-bit-ARM926EJ-S-Microcontroller_SAM9N12CN11CN12_Datasheet.pdf
-
-    * ARM Cortex-A5 based SoCs
-      - sama5d3 family
-        - sama5d31
-        - sama5d33
-        - sama5d34
-        - sama5d35
-        - sama5d36 (device superset)
-        + Datasheet
-          http://www.atmel.com/Images/Atmel-11121-32-bit-Cortex-A5-Microcontroller-SAMA5D3_Datasheet.pdf
-
-    * ARM Cortex-A5 + NEON based SoCs
-      - sama5d4 family
-        - sama5d41
-        - sama5d42
-        - sama5d43
-        - sama5d44 (device superset)
-        + Datasheet
-          http://www.atmel.com/Images/Atmel-11238-32-bit-Cortex-A5-Microcontroller-SAMA5D4_Datasheet.pdf
-
-      - sama5d2 family
-        - sama5d21
-        - sama5d22
-        - sama5d23
-        - sama5d24
-        - sama5d26
-        - sama5d27 (device superset)
-        - sama5d28 (device superset + environmental monitors)
-        + Datasheet
-          http://www.atmel.com/Images/Atmel-11267-32-bit-Cortex-A5-Microcontroller-SAMA5D2_Datasheet.pdf
-
-    * ARM Cortex-M7 MCUs
-      - sams70 family
-        - sams70j19
-        - sams70j20
-        - sams70j21
-        - sams70n19
-        - sams70n20
-        - sams70n21
-        - sams70q19
-        - sams70q20
-        - sams70q21
-        + Datasheet
-          http://www.atmel.com/Images/Atmel-11242-32-bit-Cortex-M7-Microcontroller-SAM-S70Q-SAM-S70N-SAM-S70J_Datasheet.pdf
-
-      - samv70 family
-        - samv70j19
-        - samv70j20
-        - samv70n19
-        - samv70n20
-        - samv70q19
-        - samv70q20
-        + Datasheet
-          http://www.atmel.com/Images/Atmel-11297-32-bit-Cortex-M7-Microcontroller-SAM-V70Q-SAM-V70N-SAM-V70J_Datasheet.pdf
-
-      - samv71 family
-        - samv71j19
-        - samv71j20
-        - samv71j21
-        - samv71n19
-        - samv71n20
-        - samv71n21
-        - samv71q19
-        - samv71q20
-        - samv71q21
-        + Datasheet
-          http://www.atmel.com/Images/Atmel-44003-32-bit-Cortex-M7-Microcontroller-SAM-V71Q-SAM-V71N-SAM-V71J_Datasheet.pdf
-
-Linux kernel information
-------------------------
-Linux kernel mach directory: arch/arm/mach-at91
-MAINTAINERS entry is: "ARM/ATMEL AT91RM9200 AND AT91SAM ARM ARCHITECTURES"
-
-
-Device Tree for AT91 SoCs and boards
-------------------------------------
-All AT91 SoCs are converted to Device Tree. Since Linux 3.19, these products
-must use this method to boot the Linux kernel.
-
-Work In Progress statement:
-Device Tree files and Device Tree bindings that apply to AT91 SoCs and boards are
-considered as "Unstable". To be completely clear, any at91 binding can change at
-any time. So, be sure to use a Device Tree Binary and a Kernel Image generated from
-the same source tree.
-Please refer to the Documentation/devicetree/bindings/ABI.txt file for a
-definition of a "Stable" binding/ABI.
-This statement will be removed by AT91 MAINTAINERS when appropriate.
-
-Naming conventions and best practice:
-- SoCs Device Tree Source Include files are named after the official name of
-  the product (at91sam9g20.dtsi or sama5d33.dtsi for instance).
-- Device Tree Source Include files (.dtsi) are used to collect common nodes that can be
-  shared across SoCs or boards (sama5d3.dtsi or at91sam9x5cm.dtsi for instance).
-  When collecting nodes for a particular peripheral or topic, the identifier have to
-  be placed at the end of the file name, separated with a "_" (at91sam9x5_can.dtsi
-  or sama5d3_gmac.dtsi for example).
-- board Device Tree Source files (.dts) are prefixed by the string "at91-" so
-  that they can be identified easily. Note that some files are historical exceptions
-  to this rule (sama5d3[13456]ek.dts, usb_a9g20.dts or animeo_ip.dts for example).

Documentation/arm/Microchip/README

@@ -0,0 +1,169 @@
+ARM Microchip SoCs (aka AT91)
+=============================
+
+
+Introduction
+------------
+This document gives useful information about the ARM Microchip SoCs that are
+currently supported in Linux Mainline (you know, the one on kernel.org).
+
+It is important to note that the Microchip (previously Atmel) ARM-based MPU
+product line is historically named "AT91" or "at91" throughout the Linux kernel
+development process even if this product prefix has completely disappeared from
+the official Microchip product name. Anyway, files, directories, git trees,
+git branches/tags and email subject always contain this "at91" sub-string.
+
+
+AT91 SoCs
+---------
+Documentation and detailed datasheet for each product are available on
+the Microchip website: http://www.microchip.com.
+
+  Flavors:
+    * ARM 920 based SoC
+      - at91rm9200
+        + Datasheet
+          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-1768-32-bit-ARM920T-Embedded-Microprocessor-AT91RM9200_Datasheet.pdf
+
+    * ARM 926 based SoCs
+      - at91sam9260
+        + Datasheet
+          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6221-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9260_Datasheet.pdf
+
+      - at91sam9xe
+        + Datasheet
+          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6254-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9XE_Datasheet.pdf
+
+      - at91sam9261
+        + Datasheet
+          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6062-ARM926EJ-S-Microprocessor-SAM9261_Datasheet.pdf
+
+      - at91sam9263
+        + Datasheet
+          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6249-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9263_Datasheet.pdf
+
+      - at91sam9rl
+        + Datasheet
+          http://ww1.microchip.com/downloads/en/DeviceDoc/doc6289.pdf
+
+      - at91sam9g20
+        + Datasheet
+          http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001516A.pdf
+
+      - at91sam9g45 family
+        - at91sam9g45
+        - at91sam9g46
+        - at91sam9m10
+        - at91sam9m11 (device superset)
+        + Datasheet
+          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6437-32-bit-ARM926-Embedded-Microprocessor-SAM9M11_Datasheet.pdf
+
+      - at91sam9x5 family (aka "The 5 series")
+        - at91sam9g15
+        - at91sam9g25
+        - at91sam9g35
+        - at91sam9x25
+        - at91sam9x35
+        + Datasheet (can be considered as covering the whole family)
+          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11055-32-bit-ARM926EJ-S-Microcontroller-SAM9X35_Datasheet.pdf
+
+      - at91sam9n12
+        + Datasheet
+          http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001517A.pdf
+
+    * ARM Cortex-A5 based SoCs
+      - sama5d3 family
+        - sama5d31
+        - sama5d33
+        - sama5d34
+        - sama5d35
+        - sama5d36 (device superset)
+        + Datasheet
+          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11121-32-bit-Cortex-A5-Microcontroller-SAMA5D3_Datasheet.pdf
+
+    * ARM Cortex-A5 + NEON based SoCs
+      - sama5d4 family
+        - sama5d41
+        - sama5d42
+        - sama5d43
+        - sama5d44 (device superset)
+        + Datasheet
+          http://ww1.microchip.com/downloads/en/DeviceDoc/60001525A.pdf
+
+      - sama5d2 family
+        - sama5d21
+        - sama5d22
+        - sama5d23
+        - sama5d24
+        - sama5d26
+        - sama5d27 (device superset)
+        - sama5d28 (device superset + environmental monitors)
+        + Datasheet
+          http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001476B.pdf
+
+    * ARM Cortex-M7 MCUs
+      - sams70 family
+        - sams70j19
+        - sams70j20
+        - sams70j21
+        - sams70n19
+        - sams70n20
+        - sams70n21
+        - sams70q19
+        - sams70q20
+        - sams70q21
+
+      - samv70 family
+        - samv70j19
+        - samv70j20
+        - samv70n19
+        - samv70n20
+        - samv70q19
+        - samv70q20
+
+      - samv71 family
+        - samv71j19
+        - samv71j20
+        - samv71j21
+        - samv71n19
+        - samv71n20
+        - samv71n21
+        - samv71q19
+        - samv71q20
+        - samv71q21
+
+        + Datasheet
+          http://ww1.microchip.com/downloads/en/DeviceDoc/60001527A.pdf
+
+
+Linux kernel information
+------------------------
+Linux kernel mach directory: arch/arm/mach-at91
+MAINTAINERS entry is: "ARM/Microchip (AT91) SoC support"
+
+
+Device Tree for AT91 SoCs and boards
+------------------------------------
+All AT91 SoCs are converted to Device Tree. Since Linux 3.19, these products
+must use this method to boot the Linux kernel.
+
+Work In Progress statement:
+Device Tree files and Device Tree bindings that apply to AT91 SoCs and boards are
+considered as "Unstable". To be completely clear, any at91 binding can change at
+any time. So, be sure to use a Device Tree Binary and a Kernel Image generated from
+the same source tree.
+Please refer to the Documentation/devicetree/bindings/ABI.txt file for a
+definition of a "Stable" binding/ABI.
+This statement will be removed by AT91 MAINTAINERS when appropriate.
+
+Naming conventions and best practice:
+- SoCs Device Tree Source Include files are named after the official name of
+  the product (at91sam9g20.dtsi or sama5d33.dtsi for instance).
+- Device Tree Source Include files (.dtsi) are used to collect common nodes that can be
+  shared across SoCs or boards (sama5d3.dtsi or at91sam9x5cm.dtsi for instance).
+  When collecting nodes for a particular peripheral or topic, the identifier have to
+  be placed at the end of the file name, separated with a "_" (at91sam9x5_can.dtsi
+  or sama5d3_gmac.dtsi for example).
+- board Device Tree Source files (.dts) are prefixed by the string "at91-" so
+  that they can be identified easily. Note that some files are historical exceptions
+  to this rule (sama5d3[13456]ek.dts, usb_a9g20.dts or animeo_ip.dts for example).

Documentation/arm/Samsung-S3C24XX/S3C2412.txt

@@ -46,7 +46,7 @@ NAND
 ----
 
   The NAND hardware is similar to the S3C2440, and is supported by the
-  s3c2410 driver in the drivers/mtd/nand directory.
+  s3c2410 driver in the drivers/mtd/nand/raw directory.
 
 
 USB Host

Documentation/arm/stm32/overview.rst

@@ -0,0 +1,34 @@
+========================
+STM32 ARM Linux Overview
+========================
+
+Introduction
+------------
+
+The STMicroelectronics STM32 family of Cortex-A microprocessors (MPUs) and
+Cortex-M microcontrollers (MCUs) are supported by the 'STM32' platform of
+ARM Linux.
+
+Configuration
+-------------
+
+For MCUs, use the provided default configuration:
+        make stm32_defconfig
+For MPUs, use multi_v7 configuration:
+        make multi_v7_defconfig
+
+Layout
+------
+
+All the files for multiple machine families are located in the platform code
+contained in arch/arm/mach-stm32
+
+There is a generic board board-dt.c in the mach folder which support
+Flattened Device Tree, which means, it works with any compatible board with
+Device Trees.
+
+:Authors:
+
+- Maxime Coquelin <mcoquelin.stm32@gmail.com>
+- Ludovic Barre <ludovic.barre@st.com>
+- Gerald Baeza <gerald.baeza@st.com>

Documentation/arm/stm32/overview.txt

@@ -1,33 +0,0 @@
-			STM32 ARM Linux Overview
-			========================
-
-Introduction
-------------
-
-  The STMicroelectronics family of Cortex-M based MCUs are supported by the
-  'STM32' platform of ARM Linux. Currently only the STM32F429 (Cortex-M4)
-  and STM32F746 (Cortex-M7) are supported.
-
-
-Configuration
--------------
-
-  A generic configuration is provided for STM32 family, and can be used as the
-  default by
-	make stm32_defconfig
-
-Layout
-------
-
-  All the files for multiple machine families are located in the platform code
-  contained in arch/arm/mach-stm32
-
-  There is a generic board board-dt.c in the mach folder which support
-  Flattened Device Tree, which means, it works with any compatible board with
-  Device Trees.
-
-
-Document Author
----------------
-
-  Maxime Coquelin <mcoquelin.stm32@gmail.com>

Documentation/arm/stm32/stm32f429-overview.rst

@@ -0,0 +1,26 @@
+STM32F429 Overview
+==================
+
+Introduction
+------------
+
+The STM32F429 is a Cortex-M4 MCU aimed at various applications.
+It features:
+
+- ARM Cortex-M4 up to 180MHz with FPU
+- 2MB internal Flash Memory
+- External memory support through FMC controller (PSRAM, SDRAM, NOR, NAND)
+- I2C, SPI, SAI, CAN, USB OTG, Ethernet controllers
+- LCD controller & Camera interface
+- Cryptographic processor
+
+Resources
+---------
+
+Datasheet and reference manual are publicly available on ST website (STM32F429_).
+
+.. _STM32F429: http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1577/LN1806?ecmp=stm32f429-439_pron_pr-ces2014_nov2013
+
+:Authors:
+
+Maxime Coquelin <mcoquelin.stm32@gmail.com>

Documentation/arm/stm32/stm32f429-overview.txt

@@ -1,22 +0,0 @@
-			STM32F429 Overview
-			==================
-
-  Introduction
-  ------------
-	The STM32F429 is a Cortex-M4 MCU aimed at various applications.
-	It features:
-	- ARM Cortex-M4 up to 180MHz with FPU
-	- 2MB internal Flash Memory
-	- External memory support through FMC controller (PSRAM, SDRAM, NOR, NAND)
-	- I2C, SPI, SAI, CAN, USB OTG, Ethernet controllers
-	- LCD controller & Camera interface
-	- Cryptographic processor
-
-  Resources
-  ---------
-	Datasheet and reference manual are publicly available on ST website:
-	- http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1577/LN1806?ecmp=stm32f429-439_pron_pr-ces2014_nov2013
-
-  Document Author
-  ---------------
-	Maxime Coquelin <mcoquelin.stm32@gmail.com>

Documentation/arm/stm32/stm32f746-overview.rst

@@ -0,0 +1,33 @@
+STM32F746 Overview
+==================
+
+Introduction
+------------
+
+The STM32F746 is a Cortex-M7 MCU aimed at various applications.
+It features:
+
+- Cortex-M7 core running up to @216MHz
+- 1MB internal flash, 320KBytes internal RAM (+4KB of backup SRAM)
+- FMC controller to connect SDRAM, NOR and NAND memories
+- Dual mode QSPI
+- SD/MMC/SDIO support
+- Ethernet controller
+- USB OTFG FS & HS controllers
+- I2C, SPI, CAN busses support
+- Several 16 & 32 bits general purpose timers
+- Serial Audio interface
+- LCD controller
+- HDMI-CEC
+- SPDIFRX
+
+Resources
+---------
+
+Datasheet and reference manual are publicly available on ST website (STM32F746_).
+
+.. _STM32F746: http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f7-series/stm32f7x6/stm32f746ng.html
+
+:Authors:
+
+Alexandre Torgue <alexandre.torgue@st.com>

Documentation/arm/stm32/stm32f746-overview.txt

@@ -1,34 +0,0 @@
-			STM32F746 Overview
-			==================
-
-  Introduction
-  ------------
-	The STM32F746 is a Cortex-M7 MCU aimed at various applications.
-	It features:
-	- Cortex-M7 core running up to @216MHz
-	- 1MB internal flash, 320KBytes internal RAM (+4KB of backup SRAM)
-	- FMC controller to connect SDRAM, NOR and NAND memories
-	- Dual mode QSPI
-	- SD/MMC/SDIO support
-	- Ethernet controller
-	- USB OTFG FS & HS controllers
-	- I2C, SPI, CAN busses support
-	- Several 16 & 32 bits general purpose timers
-	- Serial Audio interface
-	- LCD controller
-	- HDMI-CEC
-	- SPDIFRX
-
-  Resources
-  ---------
-	Datasheet and reference manual are publicly available on ST website:
-	- http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f7-series/stm32f7x6/stm32f746ng.html
-
-  Document Author
-  ---------------
-	Alexandre Torgue <alexandre.torgue@st.com>
-
-
-
-
-

Documentation/arm/stm32/stm32f769-overview.rst

@@ -0,0 +1,35 @@
+STM32F769 Overview
+==================
+
+Introduction
+------------
+
+The STM32F769 is a Cortex-M7 MCU aimed at various applications.
+It features:
+
+- Cortex-M7 core running up to @216MHz
+- 2MB internal flash, 512KBytes internal RAM (+4KB of backup SRAM)
+- FMC controller to connect SDRAM, NOR and NAND memories
+- Dual mode QSPI
+- SD/MMC/SDIO support*2
+- Ethernet controller
+- USB OTFG FS & HS controllers
+- I2C*4, SPI*6, CAN*3 busses support
+- Several 16 & 32 bits general purpose timers
+- Serial Audio interface*2
+- LCD controller
+- HDMI-CEC
+- DSI
+- SPDIFRX
+- MDIO salave interface
+
+Resources
+---------
+
+Datasheet and reference manual are publicly available on ST website (STM32F769_).
+
+.. _STM32F769: http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32-high-performance-mcus/stm32f7-series/stm32f7x9/stm32f769ni.html
+
+:Authors:
+
+Alexandre Torgue <alexandre.torgue@st.com>

Documentation/arm/stm32/stm32h743-overview.rst

@@ -0,0 +1,34 @@
+STM32H743 Overview
+==================
+
+Introduction
+------------
+
+The STM32H743 is a Cortex-M7 MCU aimed at various applications.
+It features:
+
+- Cortex-M7 core running up to @400MHz
+- 2MB internal flash, 1MBytes internal RAM
+- FMC controller to connect SDRAM, NOR and NAND memories
+- Dual mode QSPI
+- SD/MMC/SDIO support
+- Ethernet controller
+- USB OTFG FS & HS controllers
+- I2C, SPI, CAN busses support
+- Several 16 & 32 bits general purpose timers
+- Serial Audio interface
+- LCD controller
+- HDMI-CEC
+- SPDIFRX
+- DFSDM
+
+Resources
+---------
+
+Datasheet and reference manual are publicly available on ST website (STM32H743_).
+
+.. _STM32H743: http://www.st.com/en/microcontrollers/stm32h7x3.html?querycriteria=productId=LN2033
+
+:Authors:
+
+Alexandre Torgue <alexandre.torgue@st.com>

Documentation/arm/stm32/stm32h743-overview.txt

@@ -1,30 +0,0 @@
-			STM32H743 Overview
-			==================
-
-  Introduction
-  ------------
-	The STM32H743 is a Cortex-M7 MCU aimed at various applications.
-	It features:
-	- Cortex-M7 core running up to @400MHz
-	- 2MB internal flash, 1MBytes internal RAM
-	- FMC controller to connect SDRAM, NOR and NAND memories
-	- Dual mode QSPI
-	- SD/MMC/SDIO support
-	- Ethernet controller
-	- USB OTFG FS & HS controllers
-	- I2C, SPI, CAN busses support
-	- Several 16 & 32 bits general purpose timers
-	- Serial Audio interface
-	- LCD controller
-	- HDMI-CEC
-	- SPDIFRX
-	- DFSDM
-
-  Resources
-  ---------
-	Datasheet and reference manual are publicly available on ST website:
-	- http://www.st.com/en/microcontrollers/stm32h7x3.html?querycriteria=productId=LN2033
-
-  Document Author
-  ---------------
-	Alexandre Torgue <alexandre.torgue@st.com>

Documentation/arm/stm32/stm32mp157-overview.rst

@@ -0,0 +1,19 @@
+STM32MP157 Overview
+===================
+
+Introduction
+------------
+
+The STM32MP157 is a Cortex-A MPU aimed at various applications.
+It features:
+
+- Dual core Cortex-A7 application core
+- 2D/3D image composition with GPU
+- Standard memories interface support
+- Standard connectivity, widely inherited from the STM32 MCU family
+- Comprehensive security support
+
+:Authors:
+
+- Ludovic Barre <ludovic.barre@st.com>
+- Gerald Baeza <gerald.baeza@st.com>

Documentation/arm64/cpu-feature-registers.txt

@@ -110,7 +110,7 @@ infrastructure:
      x--------------------------------------------------x
      | Name                         |  bits   | visible |
      |--------------------------------------------------|
-     | RES0                         | [63-52] |    n    |
+     | TS                           | [55-52] |    y    |
      |--------------------------------------------------|
      | FHM                          | [51-48] |    y    |
      |--------------------------------------------------|
@@ -124,8 +124,6 @@ infrastructure:
      |--------------------------------------------------|
      | RDM                          | [31-28] |    y    |
      |--------------------------------------------------|
-     | RES0                         | [27-24] |    n    |
-     |--------------------------------------------------|
      | ATOMICS                      | [23-20] |    y    |
      |--------------------------------------------------|
      | CRC32                        | [19-16] |    y    |
@@ -135,8 +133,6 @@ infrastructure:
      | SHA1                         | [11-8]  |    y    |
      |--------------------------------------------------|
      | AES                          | [7-4]   |    y    |
-     |--------------------------------------------------|
-     | RES0                         | [3-0]   |    n    |
      x--------------------------------------------------x
 
 
@@ -144,12 +140,10 @@ infrastructure:
      x--------------------------------------------------x
      | Name                         |  bits   | visible |
      |--------------------------------------------------|
-     | RES0                         | [63-36] |    n    |
+     | DIT                          | [51-48] |    y    |
      |--------------------------------------------------|
      | SVE                          | [35-32] |    y    |
      |--------------------------------------------------|
-     | RES0                         | [31-28] |    n    |
-     |--------------------------------------------------|
      | GIC                          | [27-24] |    n    |
      |--------------------------------------------------|
      | AdvSIMD                      | [23-20] |    y    |
@@ -199,6 +193,14 @@ infrastructure:
      | DPB                          | [3-0]   |    y    |
      x--------------------------------------------------x
 
+  5) ID_AA64MMFR2_EL1 - Memory model feature register 2
+
+     x--------------------------------------------------x
+     | Name                         |  bits   | visible |
+     |--------------------------------------------------|
+     | AT                           | [35-32] |    y    |
+     x--------------------------------------------------x
+
 Appendix I: Example
 ---------------------------
 

Documentation/arm64/elf_hwcaps.txt

@@ -162,3 +162,19 @@ HWCAP_SVE
 HWCAP_ASIMDFHM
 
    Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
+
+HWCAP_DIT
+
+    Functionality implied by ID_AA64PFR0_EL1.DIT == 0b0001.
+
+HWCAP_USCAT
+
+    Functionality implied by ID_AA64MMFR2_EL1.AT == 0b0001.
+
+HWCAP_ILRCPC
+
+    Functionality implied by ID_AA64ISR1_EL1.LRCPC == 0b0002.
+
+HWCAP_FLAGM
+
+    Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0001.

Documentation/arm64/memory.txt

@@ -86,9 +86,12 @@ Translation table lookup with 64KB pages:
  +-------------------------------------------------> [63] TTBR0/1
 
 
-When using KVM without the Virtualization Host Extensions, the hypervisor
-maps kernel pages in EL2 at a fixed offset from the kernel VA. See the
-kern_hyp_va macro for more details.
+When using KVM without the Virtualization Host Extensions, the
+hypervisor maps kernel pages in EL2 at a fixed (and potentially
+random) offset from the linear mapping. See the kern_hyp_va macro and
+kvm_update_va_mask function for more details. MMIO devices such as
+GICv2 gets mapped next to the HYP idmap page, as do vectors when
+ARM64_HARDEN_EL2_VECTORS is selected for particular CPUs.
 
 When using KVM with the Virtualization Host Extensions, no additional
 mappings are created, since the host kernel runs directly in EL2.

Documentation/arm64/silicon-errata.txt

@@ -55,6 +55,7 @@ stable kernels.
 | ARM            | Cortex-A57      | #834220         | ARM64_ERRATUM_834220        |
 | ARM            | Cortex-A72      | #853709         | N/A                         |
 | ARM            | Cortex-A73      | #858921         | ARM64_ERRATUM_858921        |
+| ARM            | Cortex-A55      | #1024718        | ARM64_ERRATUM_1024718       |
 | ARM            | MMU-500         | #841119,#826419 | N/A                         |
 |                |                 |                 |                             |
 | Cavium         | ThunderX ITS    | #22375, #24313  | CAVIUM_ERRATUM_22375        |

Documentation/blackfin/00-INDEX

@@ -1,6 +0,0 @@
-00-INDEX
-	- This file
-bfin-gpio-notes.txt
-	- Notes in developing/using bfin-gpio driver.
-bfin-spi-notes.txt
-	- Notes for using bfin spi bus driver.

Documentation/blackfin/bfin-gpio-notes.txt

@@ -1,71 +0,0 @@
-/*
- * File:         Documentation/blackfin/bfin-gpio-notes.txt
- * Based on:
- * Author:
- *
- * Created:      $Id: bfin-gpio-note.txt 2008-11-24 16:42 grafyang $
- * Description:  This file contains the notes in developing/using bfin-gpio.
- *
- *
- * Rev:
- *
- * Modified:
- *               Copyright 2004-2008 Analog Devices Inc.
- *
- * Bugs:         Enter bugs at http://blackfin.uclinux.org/
- *
- */
-
-
-1. Blackfin GPIO introduction
-
-    There are many GPIO pins on Blackfin. Most of these pins are muxed to
-    multi-functions. They can be configured as peripheral, or just as GPIO,
-    configured to input with interrupt enabled, or output.
-
-    For detailed information, please see "arch/blackfin/kernel/bfin_gpio.c",
-    or the relevant HRM.
-
-
-2. Avoiding resource conflict
-
-    Followed function groups are used to avoiding resource conflict,
-    - Use the pin as peripheral,
-	int peripheral_request(unsigned short per, const char *label);
-	int peripheral_request_list(const unsigned short per[], const char *label);
-	void peripheral_free(unsigned short per);
-	void peripheral_free_list(const unsigned short per[]);
-    - Use the pin as GPIO,
-	int bfin_gpio_request(unsigned gpio, const char *label);
-	void bfin_gpio_free(unsigned gpio);
-    - Use the pin as GPIO interrupt,
-	int bfin_gpio_irq_request(unsigned gpio, const char *label);
-	void bfin_gpio_irq_free(unsigned gpio);
-
-    The request functions will record the function state for a certain pin,
-    the free functions will clear its function state.
-    Once a pin is requested, it can't be requested again before it is freed by
-    previous caller, otherwise kernel will dump stacks, and the request
-    function fail.
-    These functions are wrapped by other functions, most of the users need not
-    care.
-
-
-3. But there are some exceptions
-    - Kernel permit the identical GPIO be requested both as GPIO and GPIO
-    interrupt.
-    Some drivers, like gpio-keys, need this behavior. Kernel only print out
-    warning messages like,
-	bfin-gpio: GPIO 24 is already reserved by gpio-keys: BTN0, and you are
-configuring it as IRQ!
-
-        Note: Consider the case that, if there are two drivers need the
-	identical GPIO, one of them use it as GPIO, the other use it as
-	GPIO interrupt. This will really cause resource conflict. So if
-	there is any abnormal driver behavior, please check the bfin-gpio
-	warning messages.
-
-    - Kernel permit the identical GPIO be requested from the same driver twice.
-
-
-

Documentation/blackfin/bfin-spi-notes.txt

@@ -1,16 +0,0 @@
-SPI Chip Select behavior:
-
-With the Blackfin on-chip SPI peripheral, there is some logic tied to the CPHA
-bit whether the Slave Select Line is controlled by hardware (CPHA=0) or
-controlled by software (CPHA=1). However, the Linux SPI bus driver assumes that
-the Slave Select is always under software control and being asserted during
-the entire SPI transfer. - And not just bits_per_word duration.
-
-In most cases you can utilize SPI MODE_3 instead of MODE_0 to work-around this
-behavior. If your SPI slave device in question requires SPI MODE_0 or MODE_2
-timing, you can utilize the GPIO controlled SPI Slave Select option instead.
-In this case, you should use GPIO based CS for all of your slaves and not just
-the ones using mode 0 or 2 in order to guarantee correct CS toggling behavior.
-
-You can even use the same pin whose peripheral role is a SSEL,
-but use it as a GPIO instead.

Documentation/bpf/bpf_devel_QA.txt

@@ -539,6 +539,18 @@ A: Although LLVM IR generation and optimization try to stay architecture
        The clang option "-fno-jump-tables" can be used to disable
        switch table generation.
 
+     - For clang -target bpf, it is guaranteed that pointer or long /
+       unsigned long types will always have a width of 64 bit, no matter
+       whether underlying clang binary or default target (or kernel) is
+       32 bit. However, when native clang target is used, then it will
+       compile these types based on the underlying architecture's conventions,
+       meaning in case of 32 bit architecture, pointer or long / unsigned
+       long types e.g. in BPF context structure will have width of 32 bit
+       while the BPF LLVM back end still operates in 64 bit. The native
+       target is mostly needed in tracing for the case of walking pt_regs
+       or other kernel structures where CPU's register width matters.
+       Otherwise, clang -target bpf is generally recommended.
+
    You should use default target when:
 
      - Your program includes a header file, e.g., ptrace.h, which eventually

Documentation/cdrom/cdrom-standard.tex

@@ -234,6 +234,7 @@ struct& cdrom_device_ops\ \{ \hidewidth\cr
   &int& (* open)(struct\ cdrom_device_info *, int)\cr
   &void& (* release)(struct\ cdrom_device_info *);\cr 
   &int& (* drive_status)(struct\ cdrom_device_info *, int);\cr     
+  &unsigned\ int& (* check_events)(struct\ cdrom_device_info *, unsigned\ int, int);\cr
   &int& (* media_changed)(struct\ cdrom_device_info *, int);\cr 
   &int& (* tray_move)(struct\ cdrom_device_info *, int);\cr
   &int& (* lock_door)(struct\ cdrom_device_info *, int);\cr
@@ -245,10 +246,9 @@ struct& cdrom_device_ops\ \{ \hidewidth\cr
   &int& (* reset)(struct\ cdrom_device_info *);\cr
   &int& (* audio_ioctl)(struct\ cdrom_device_info *, unsigned\ int, 
         void *{});\cr 
-  &int& (* dev_ioctl)(struct\ cdrom_device_info *, unsigned\ int, 
-        unsigned\ long);\cr
 \noalign{\medskip}
   &const\ int& capability;& capability flags \cr
+  &int& (* generic_packet)(struct\ cdrom_device_info *, struct\ packet_command *{});\cr
 \};\cr
 }
 $$
@@ -274,19 +274,32 @@ $$
 \halign{$#$\ \hfil&$#$\ \hfil&\hbox to 10em{$#$\hss}&
   $/*$ \rm# $*/$\hfil\cr
 struct& cdrom_device_info\ \{ \hidewidth\cr
-  & struct\ cdrom_device_ops *& ops;& device operations for this major\cr
-  & struct\ cdrom_device_info *& next;& next device_info for this major\cr
+  & const\ struct\ cdrom_device_ops *& ops;& device operations for this major\cr
+  & struct\ list_head& list;& linked list of all device_info\cr
+  & struct\ gendisk *& disk;& matching block layer disk\cr
   & void *&  handle;& driver-dependent data\cr
 \noalign{\medskip}
-  & kdev_t&  dev;& device number (incorporates minor)\cr
   & int& mask;& mask of capability: disables them \cr
   & int& speed;& maximum speed for reading data \cr
   & int& capacity;& number of discs in a jukebox \cr
 \noalign{\medskip}
-  &int& options : 30;& options flags \cr
+  &unsigned\ int& options : 30;& options flags \cr
   &unsigned& mc_flags : 2;& media-change buffer flags \cr
+  &unsigned\ int& vfs_events;& cached events for vfs path\cr
+  &unsigned\ int& ioctl_events;& cached events for ioctl path\cr
   & int& use_count;& number of times device is opened\cr
   & char& name[20];& name of the device type\cr
+\noalign{\medskip}
+  &__u8& sanyo_slot : 2;& Sanyo 3-CD changer support\cr
+  &__u8& keeplocked : 1;& CDROM_LOCKDOOR status\cr
+  &__u8& reserved : 5;& not used yet\cr
+  & int& cdda_method;& see CDDA_* flags\cr
+  &__u8& last_sense;& saves last sense key\cr
+  &__u8& media_written;& dirty flag, DVD+RW bookkeeping\cr
+  &unsigned\ short& mmc3_profile;& current MMC3 profile\cr
+  & int& for_data;& unknown:TBD\cr
+  & int\ (* exit)\ (struct\ cdrom_device_info *);&& unknown:TBD\cr
+  & int& mrw_mode_page;& which MRW mode page is in use\cr
 \}\cr
 }$$
 Using this $struct$, a linked list of the registered minor devices is
@@ -298,9 +311,7 @@ The $mask$ flags can be used to mask out some of the capabilities listed
 in $ops\to capability$, if a specific drive doesn't support a feature
 of the driver. The value $speed$ specifies the maximum head-rate of the
 drive, measured in units of normal audio speed (176\,kB/sec raw data or
-150\,kB/sec file system data). The value $n_discs$ should reflect the
-number of discs the drive can hold simultaneously, if it is designed
-as a juke-box, or otherwise~1. The parameters are declared $const$
+150\,kB/sec file system data).  The parameters are declared $const$
 because they describe properties of the drive, which don't change after
 registration.
 
@@ -1002,7 +1013,7 @@ taken over the torch in maintaining \cdromc\ and integrating much
 \cdrom-related code in the 2.1-kernel.  Thanks to Scott Snyder and
 Gerd Knorr, who were the first to implement this interface for SCSI
 and IDE-CD drivers and added many ideas for extension of the data
-structures relative to kernel~2.0.  Further thanks to Heiko Ei{\sz}feldt,
+structures relative to kernel~2.0.  Further thanks to Heiko Ei{\ss}feldt,
 Thomas Quinot, Jon Tombs, Ken Pizzini, Eberhard M\"onkeberg and Andrew
 Kroll, the \linux\ \cdrom\ device driver developers who were kind
 enough to give suggestions and criticisms during the writing. Finally

Documentation/cgroup-v1/memory.txt

@@ -262,7 +262,7 @@ When oom event notifier is registered, event will be delivered.
 2.6 Locking
 
    lock_page_cgroup()/unlock_page_cgroup() should not be called under
-   mapping->tree_lock.
+   the i_pages lock.
 
    Other lock order is following:
    PG_locked.

Documentation/clk.txt

@@ -268,9 +268,19 @@ The common clock framework uses two global locks, the prepare lock and the
 enable lock.
 
 The enable lock is a spinlock and is held across calls to the .enable,
-.disable and .is_enabled operations. Those operations are thus not allowed to
-sleep, and calls to the clk_enable(), clk_disable() and clk_is_enabled() API
-functions are allowed in atomic context.
+.disable operations. Those operations are thus not allowed to sleep,
+and calls to the clk_enable(), clk_disable() API functions are allowed in
+atomic context.
+
+For clk_is_enabled() API, it is also designed to be allowed to be used in
+atomic context. However, it doesn't really make any sense to hold the enable
+lock in core, unless you want to do something else with the information of
+the enable state with that lock held. Otherwise, seeing if a clk is enabled is
+a one-shot read of the enabled state, which could just as easily change after
+the function returns because the lock is released. Thus the user of this API
+needs to handle synchronizing the read of the state with whatever they're
+using it for to make sure that the enable state doesn't change during that
+time.
 
 The prepare lock is a mutex and is held across calls to all other operations.
 All those operations are allowed to sleep, and calls to the corresponding API

Documentation/core-api/kernel-api.rst

@@ -136,6 +136,19 @@ Sorting
 .. kernel-doc:: lib/list_sort.c
    :export:
 
+Text Searching
+--------------
+
+.. kernel-doc:: lib/textsearch.c
+   :doc: ts_intro
+
+.. kernel-doc:: lib/textsearch.c
+   :export:
+
+.. kernel-doc:: include/linux/textsearch.h
+   :functions: textsearch_find textsearch_next \
+               textsearch_get_pattern textsearch_get_pattern_len
+
 UUID/GUID
 ---------
 

Documentation/core-api/printk-formats.rst

@@ -60,8 +60,8 @@ Plain Pointers
 Pointers printed without a specifier extension (i.e unadorned %p) are
 hashed to prevent leaking information about the kernel memory layout. This
 has the added benefit of providing a unique identifier. On 64-bit machines
-the first 32 bits are zeroed. If you *really* want the address see %px
-below.
+the first 32 bits are zeroed. The kernel will print ``(ptrval)`` until it
+gathers enough entropy. If you *really* want the address see %px below.
 
 Symbols/Function Pointers
 -------------------------

Documentation/cpu-freq/core.txt

@@ -97,12 +97,10 @@ flags	- flags of the cpufreq driver
 ==================================================================
 For details about OPP, see Documentation/power/opp.txt
 
-dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with
-	cpufreq_table_validate_and_show() which is provided with the list of
-	frequencies that are available for operation. This function provides
-	a ready to use conversion routine to translate the OPP layer's internal
-	information about the available frequencies into a format readily
-	providable to cpufreq.
+dev_pm_opp_init_cpufreq_table -
+	This function provides a ready to use conversion routine to translate
+	the OPP layer's internal information about the available frequencies
+	into a format readily providable to cpufreq.
 
 	WARNING: Do not use this function in interrupt context.
 
@@ -112,7 +110,7 @@ dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with
 		/* Do things */
 		r = dev_pm_opp_init_cpufreq_table(dev, &freq_table);
 		if (!r)
-			cpufreq_table_validate_and_show(policy, freq_table);
+			policy->freq_table = freq_table;
 		/* Do other things */
 	 }
 

Documentation/cpu-freq/cpu-drivers.txt

@@ -259,10 +259,8 @@ CPUFREQ_ENTRY_INVALID. The entries don't need to be in sorted in any
 particular order, but if they are cpufreq core will do DVFS a bit
 quickly for them as search for best match is faster.
 
-By calling cpufreq_table_validate_and_show(), the cpuinfo.min_freq and
-cpuinfo.max_freq values are detected, and policy->min and policy->max
-are set to the same values. This is helpful for the per-CPU
-initialization stage.
+The cpufreq table is verified automatically by the core if the policy contains a
+valid pointer in its policy->freq_table field.
 
 cpufreq_frequency_table_verify() assures that at least one valid
 frequency is within policy->min and policy->max, and all other criteria

Documentation/cpuidle/sysfs.txt

@@ -40,6 +40,7 @@ total 0
 -r--r--r-- 1 root root 4096 Feb  8 10:42 latency
 -r--r--r-- 1 root root 4096 Feb  8 10:42 name
 -r--r--r-- 1 root root 4096 Feb  8 10:42 power
+-r--r--r-- 1 root root 4096 Feb  8 10:42 residency
 -r--r--r-- 1 root root 4096 Feb  8 10:42 time
 -r--r--r-- 1 root root 4096 Feb  8 10:42 usage
 
@@ -50,6 +51,7 @@ total 0
 -r--r--r-- 1 root root 4096 Feb  8 10:42 latency
 -r--r--r-- 1 root root 4096 Feb  8 10:42 name
 -r--r--r-- 1 root root 4096 Feb  8 10:42 power
+-r--r--r-- 1 root root 4096 Feb  8 10:42 residency
 -r--r--r-- 1 root root 4096 Feb  8 10:42 time
 -r--r--r-- 1 root root 4096 Feb  8 10:42 usage
 
@@ -60,6 +62,7 @@ total 0
 -r--r--r-- 1 root root 4096 Feb  8 10:42 latency
 -r--r--r-- 1 root root 4096 Feb  8 10:42 name
 -r--r--r-- 1 root root 4096 Feb  8 10:42 power
+-r--r--r-- 1 root root 4096 Feb  8 10:42 residency
 -r--r--r-- 1 root root 4096 Feb  8 10:42 time
 -r--r--r-- 1 root root 4096 Feb  8 10:42 usage
 
@@ -70,6 +73,7 @@ total 0
 -r--r--r-- 1 root root 4096 Feb  8 10:42 latency
 -r--r--r-- 1 root root 4096 Feb  8 10:42 name
 -r--r--r-- 1 root root 4096 Feb  8 10:42 power
+-r--r--r-- 1 root root 4096 Feb  8 10:42 residency
 -r--r--r-- 1 root root 4096 Feb  8 10:42 time
 -r--r--r-- 1 root root 4096 Feb  8 10:42 usage
 --------------------------------------------------------------------------------
@@ -78,6 +82,8 @@ total 0
 * desc : Small description about the idle state (string)
 * disable : Option to disable this idle state (bool) -> see note below
 * latency : Latency to exit out of this idle state (in microseconds)
+* residency : Time after which a state becomes more effecient than any
+  shallower state (in microseconds)
 * name : Name of the idle state (string)
 * power : Power consumed while in this idle state (in milliwatts)
 * time : Total time spent in this idle state (in microseconds)

Documentation/cris/README

@@ -1,195 +0,0 @@
-Linux on the CRIS architecture
-==============================
-
-This is a port of Linux to Axis Communications ETRAX 100LX,
-ETRAX FS and ARTPEC-3 embedded network CPUs.
-
-For more information about CRIS and ETRAX please see further below.
-
-In order to compile this you need a version of gcc with support for the
-ETRAX chip family. Please see this link for more information on how to
-download the compiler and other tools useful when building and booting
-software for the ETRAX platform:
-
-http://developer.axis.com/wiki/doku.php?id=axis:install-howto-2_20
-
-What is CRIS ?
---------------
-
-CRIS is an acronym for 'Code Reduced Instruction Set'. It is the CPU
-architecture in Axis Communication AB's range of embedded network CPU's,
-called ETRAX.
-
-The ETRAX 100LX chip
---------------------
-
-For reference, please see the following link:
-
-http://www.axis.com/products/dev_etrax_100lx/index.htm
-
-The ETRAX 100LX is a 100 MIPS processor with 8kB cache, MMU, and a very broad
-range of built-in interfaces, all with modern scatter/gather DMA.
-
-Memory interfaces:
-
-	* SRAM
-	* NOR-flash/ROM
-	* EDO or page-mode DRAM
-	* SDRAM
-
-I/O interfaces:
-
-	* one 10/100 Mbit/s ethernet controller
-	* four serial-ports (up to 6 Mbit/s)
-	* two synchronous serial-ports for multimedia codec's etc.
-	* USB host controller and USB slave
-	* ATA
-	* SCSI
-	* two parallel-ports
-	* two generic 8-bit ports
-
-	(not all interfaces are available at the same time due to chip pin
-         multiplexing)
-
-ETRAX 100LX is CRISv10 architecture.
-
-
-The ETRAX FS and ARTPEC-3 chips
--------------------------------
-
-The ETRAX FS is a 200MHz 32-bit RISC processor with on-chip 16kB
-I-cache and 16kB D-cache and with a wide range of device interfaces
-including multiple high speed serial ports and an integrated USB 1.1 PHY.
-
-The ARTPEC-3 is a variant of the ETRAX FS with additional IO-units
-used by the Axis Communications network cameras.
-
-See below link for more information:
-
-http://www.axis.com/products/dev_etrax_fs/index.htm
-
-ETRAX FS and ARTPEC-3 are both CRISv32 architectures.
-
-Bootlog
--------
-
-Just as an example, this is the debug-output from a boot of Linux 2.4 on
-a board with ETRAX 100LX. The displayed BogoMIPS value is 5 times too small :)
-At the end you see some user-mode programs booting like telnet and ftp daemons.
-
-Linux version 2.4.1 (bjornw@godzilla.axis.se) (gcc version 2.96 20000427 (experimental)) #207 Wed Feb 21 15:48:15 CET 2001
-ROM fs in RAM, size 1376256 bytes
-Setting up paging and the MMU.
-On node 0 totalpages: 2048
-zone(0): 2048 pages.
-zone(1): 0 pages.
-zone(2): 0 pages.
-Linux/CRIS port on ETRAX 100LX (c) 2001 Axis Communications AB
-Kernel command line: 
-Calibrating delay loop... 19.91 BogoMIPS
-Memory: 13872k/16384k available (587k kernel code, 2512k reserved, 44k data, 24k init)
-kmem_create: Forcing size word alignment - vm_area_struct
-kmem_create: Forcing size word alignment - filp
-Dentry-cache hash table entries: 2048 (order: 1, 16384 bytes)
-Buffer-cache hash table entries: 2048 (order: 0, 8192 bytes)
-Page-cache hash table entries: 2048 (order: 0, 8192 bytes)
-kmem_create: Forcing size word alignment - kiobuf
-kmem_create: Forcing size word alignment - bdev_cache
-Inode-cache hash table entries: 1024 (order: 0, 8192 bytes)
-kmem_create: Forcing size word alignment - inode_cache
-POSIX conformance testing by UNIFIX
-Linux NET4.0 for Linux 2.4
-Based upon Swansea University Computer Society NET3.039
-Starting kswapd v1.8
-kmem_create: Forcing size word alignment - file lock cache
-kmem_create: Forcing size word alignment - blkdev_requests
-block: queued sectors max/low 9109kB/3036kB, 64 slots per queue
-ETRAX 100LX 10/100MBit ethernet v2.0 (c) 2000 Axis Communications AB
-eth0 initialized
-eth0: changed MAC to 00:40:8C:CD:00:00
-ETRAX 100LX serial-driver $Revision: 1.7 $, (c) 2000 Axis Communications AB
-ttyS0 at 0xb0000060 is a builtin UART with DMA
-ttyS1 at 0xb0000068 is a builtin UART with DMA
-ttyS2 at 0xb0000070 is a builtin UART with DMA
-ttyS3 at 0xb0000078 is a builtin UART with DMA
-Axis flash mapping: 200000 at 50000000
-Axis flash: Found 1 x16 CFI device at 0x0 in 16 bit mode
- Amd/Fujitsu Extended Query Table v1.0 at 0x0040
-Axis flash: JEDEC Device ID is 0xC4. Assuming broken CFI table.
-Axis flash: Swapping erase regions for broken CFI table.
-number of CFI chips: 1
- Using default partition table
-I2C driver v2.2, (c) 1999-2001 Axis Communications AB
-ETRAX 100LX GPIO driver v2.1, (c) 2001 Axis Communications AB
-NET4: Linux TCP/IP 1.0 for NET4.0
-IP Protocols: ICMP, UDP, TCP
-kmem_create: Forcing size word alignment - ip_dst_cache
-IP: routing cache hash table of 1024 buckets, 8Kbytes
-TCP: Hash tables configured (established 2048 bind 2048)
-NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
-VFS: Mounted root (cramfs filesystem) readonly.
-Init starts up...
-Mounted none on /proc ok.
-Setting up eth0 with ip 10.13.9.116 and mac 00:40:8c:18:04:60
-eth0: changed MAC to 00:40:8C:18:04:60
-Setting up lo with ip 127.0.0.1
-Default gateway is 10.13.9.1
-Hostname is bbox1
-Telnetd starting, using port 23.
-  using /bin/sash as shell.
-sftpd[15]: sftpd $Revision: 1.7 $ starting up
-
-
-
-And here is how some /proc entries look:
-
-17# cd /proc
-17# cat cpuinfo
-cpu             : CRIS
-cpu revision    : 10
-cpu model       : ETRAX 100LX
-cache size      : 8 kB
-fpu             : no
-mmu             : yes
-ethernet        : 10/100 Mbps
-token ring      : no
-scsi            : yes
-ata             : yes
-usb             : yes
-bogomips        : 99.84
-
-17# cat meminfo
-        total:    used:    free:  shared: buffers:  cached:
-Mem:   7028736   925696  6103040   114688        0   229376
-Swap:        0        0        0
-MemTotal:         6864 kB
-MemFree:          5960 kB
-MemShared:         112 kB
-Buffers:             0 kB
-Cached:            224 kB
-Active:            224 kB
-Inact_dirty:         0 kB
-Inact_clean:         0 kB
-Inact_target:        0 kB
-HighTotal:           0 kB
-HighFree:            0 kB
-LowTotal:         6864 kB
-LowFree:          5960 kB
-SwapTotal:           0 kB
-SwapFree:            0 kB
-17# ls -l /bin
--rwxr-xr-x  1 342      100         10356  Jan 01 00:00 ifconfig
--rwxr-xr-x  1 342      100         17548  Jan 01 00:00 init
--rwxr-xr-x  1 342      100          9488  Jan 01 00:00 route
--rwxr-xr-x  1 342      100         46036  Jan 01 00:00 sftpd
--rwxr-xr-x  1 342      100         48104  Jan 01 00:00 sh
--rwxr-xr-x  1 342      100         16252  Jan 01 00:00 telnetd
-
-
-
-
-
-
-
-
-

Documentation/crypto/crypto_engine.rst

@@ -0,0 +1,48 @@
+=============
+CRYPTO ENGINE
+=============
+
+Overview
+--------
+The crypto engine API (CE), is a crypto queue manager.
+
+Requirement
+-----------
+You have to put at start of your tfm_ctx the struct crypto_engine_ctx
+struct your_tfm_ctx {
+        struct crypto_engine_ctx enginectx;
+        ...
+};
+Why: Since CE manage only crypto_async_request, it cannot know the underlying
+request_type and so have access only on the TFM.
+So using container_of for accessing __ctx is impossible.
+Furthermore, the crypto engine cannot know the "struct your_tfm_ctx",
+so it must assume that crypto_engine_ctx is at start of it.
+
+Order of operations
+-------------------
+You have to obtain a struct crypto_engine via crypto_engine_alloc_init().
+And start it via crypto_engine_start().
+
+Before transferring any request, you have to fill the enginectx.
+- prepare_request: (taking a function pointer) If you need to do some processing before doing the request
+- unprepare_request: (taking a function pointer) Undoing what's done in prepare_request
+- do_one_request: (taking a function pointer) Do encryption for current request
+
+Note: that those three functions get the crypto_async_request associated with the received request.
+So your need to get the original request via container_of(areq, struct yourrequesttype_request, base);
+
+When your driver receive a crypto_request, you have to transfer it to
+the cryptoengine via one of:
+- crypto_transfer_ablkcipher_request_to_engine()
+- crypto_transfer_aead_request_to_engine()
+- crypto_transfer_akcipher_request_to_engine()
+- crypto_transfer_hash_request_to_engine()
+- crypto_transfer_skcipher_request_to_engine()
+
+At the end of the request process, a call to one of the following function is needed:
+- crypto_finalize_ablkcipher_request
+- crypto_finalize_aead_request
+- crypto_finalize_akcipher_request
+- crypto_finalize_hash_request
+- crypto_finalize_skcipher_request

Documentation/crypto/devel-algos.rst

@@ -236,6 +236,14 @@ when used from another part of the kernel.
                                |
                                '---------------> HASH2
 
+Note that it is perfectly legal to "abandon" a request object:
+- call .init() and then (as many times) .update()
+- _not_ call any of .final(), .finup() or .export() at any point in future
+
+In other words implementations should mind the resource allocation and clean-up.
+No resources related to request objects should remain allocated after a call
+to .init() or .update(), since there might be no chance to free them.
+
 
 Specifics Of Asynchronous HASH Transformation
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Documentation/dev-tools/kmemleak.rst

@@ -8,7 +8,7 @@ with the difference that the orphan objects are not freed but only
 reported via /sys/kernel/debug/kmemleak. A similar method is used by the
 Valgrind tool (``memcheck --leak-check``) to detect the memory leaks in
 user-space applications.
-Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, ppc, mips, s390, metag and tile.
+Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, ppc, mips, s390 and tile.
 
 Usage
 -----

Documentation/dev-tools/sparse.rst

@@ -67,7 +67,7 @@ __releases - The specified lock is held on function entry, but not exit.
 
 If the function enters and exits without the lock held, acquiring and
 releasing the lock inside the function in a balanced way, no
-annotation is needed.  The tree annotations above are for cases where
+annotation is needed.  The three annotations above are for cases where
 sparse would otherwise report a context imbalance.
 
 Getting sparse

Documentation/device-mapper/verity.txt

@@ -109,6 +109,17 @@ fec_start <offset>
     This is the offset, in <data_block_size> blocks, from the start of the
     FEC device to the beginning of the encoding data.
 
+check_at_most_once
+    Verify data blocks only the first time they are read from the data device,
+    rather than every time.  This reduces the overhead of dm-verity so that it
+    can be used on systems that are memory and/or CPU constrained.  However, it
+    provides a reduced level of security because only offline tampering of the
+    data device's content will be detected, not online tampering.
+
+    Hash blocks are still verified each time they are read from the hash device,
+    since verification of hash blocks is less performance critical than data
+    blocks, and a hash block will not be verified any more after all the data
+    blocks it covers have been verified anyway.
 
 Theory of operation
 ===================

Documentation/devicetree/bindings/arm/arm,scmi.txt

@@ -0,0 +1,179 @@
+System Control and Management Interface (SCMI) Message Protocol
+----------------------------------------------------------
+
+The SCMI is intended to allow agents such as OSPM to manage various functions
+that are provided by the hardware platform it is running on, including power
+and performance functions.
+
+This binding is intended to define the interface the firmware implementing
+the SCMI as described in ARM document number ARM DUI 0922B ("ARM System Control
+and Management Interface Platform Design Document")[0] provide for OSPM in
+the device tree.
+
+Required properties:
+
+The scmi node with the following properties shall be under the /firmware/ node.
+
+- compatible : shall be "arm,scmi"
+- mboxes: List of phandle and mailbox channel specifiers. It should contain
+	  exactly one or two mailboxes, one for transmitting messages("tx")
+	  and another optional for receiving the notifications("rx") if
+	  supported.
+- shmem : List of phandle pointing to the shared memory(SHM) area as per
+	  generic mailbox client binding.
+- #address-cells : should be '1' if the device has sub-nodes, maps to
+	  protocol identifier for a given sub-node.
+- #size-cells : should be '0' as 'reg' property doesn't have any size
+	  associated with it.
+
+Optional properties:
+
+- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
+
+See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
+about the generic mailbox controller and client driver bindings.
+
+The mailbox is the only permitted method of calling the SCMI firmware.
+Mailbox doorbell is used as a mechanism to alert the presence of a
+messages and/or notification.
+
+Each protocol supported shall have a sub-node with corresponding compatible
+as described in the following sections. If the platform supports dedicated
+communication channel for a particular protocol, the 3 properties namely:
+mboxes, mbox-names and shmem shall be present in the sub-node corresponding
+to that protocol.
+
+Clock/Performance bindings for the clocks/OPPs based on SCMI Message Protocol
+------------------------------------------------------------
+
+This binding uses the common clock binding[1].
+
+Required properties:
+- #clock-cells : Should be 1. Contains the Clock ID value used by SCMI commands.
+
+Power domain bindings for the power domains based on SCMI Message Protocol
+------------------------------------------------------------
+
+This binding for the SCMI power domain providers uses the generic power
+domain binding[2].
+
+Required properties:
+ - #power-domain-cells : Should be 1. Contains the device or the power
+			 domain ID value used by SCMI commands.
+
+Sensor bindings for the sensors based on SCMI Message Protocol
+--------------------------------------------------------------
+SCMI provides an API to access the various sensors on the SoC.
+
+Required properties:
+- #thermal-sensor-cells: should be set to 1. This property follows the
+			 thermal device tree bindings[3].
+
+			 Valid cell values are raw identifiers (Sensor ID)
+			 as used by the firmware. Refer to  platform details
+			 for your implementation for the IDs to use.
+
+SRAM and Shared Memory for SCMI
+-------------------------------
+
+A small area of SRAM is reserved for SCMI communication between application
+processors and SCP.
+
+The properties should follow the generic mmio-sram description found in [4]
+
+Each sub-node represents the reserved area for SCMI.
+
+Required sub-node properties:
+- reg : The base offset and size of the reserved area with the SRAM
+- compatible : should be "arm,scmi-shmem" for Non-secure SRAM based
+	       shared memory
+
+[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/power/power_domain.txt
+[3] Documentation/devicetree/bindings/thermal/thermal.txt
+[4] Documentation/devicetree/bindings/sram/sram.txt
+
+Example:
+
+sram@50000000 {
+	compatible = "mmio-sram";
+	reg = <0x0 0x50000000 0x0 0x10000>;
+
+	#address-cells = <1>;
+	#size-cells = <1>;
+	ranges = <0 0x0 0x50000000 0x10000>;
+
+	cpu_scp_lpri: scp-shmem@0 {
+		compatible = "arm,scmi-shmem";
+		reg = <0x0 0x200>;
+	};
+
+	cpu_scp_hpri: scp-shmem@200 {
+		compatible = "arm,scmi-shmem";
+		reg = <0x200 0x200>;
+	};
+};
+
+mailbox@40000000 {
+	....
+	#mbox-cells = <1>;
+	reg = <0x0 0x40000000 0x0 0x10000>;
+};
+
+firmware {
+
+	...
+
+	scmi {
+		compatible = "arm,scmi";
+		mboxes = <&mailbox 0 &mailbox 1>;
+		mbox-names = "tx", "rx";
+		shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		scmi_devpd: protocol@11 {
+			reg = <0x11>;
+			#power-domain-cells = <1>;
+		};
+
+		scmi_dvfs: protocol@13 {
+			reg = <0x13>;
+			#clock-cells = <1>;
+		};
+
+		scmi_clk: protocol@14 {
+			reg = <0x14>;
+			#clock-cells = <1>;
+		};
+
+		scmi_sensors0: protocol@15 {
+			reg = <0x15>;
+			#thermal-sensor-cells = <1>;
+		};
+	};
+};
+
+cpu@0 {
+	...
+	reg = <0 0>;
+	clocks = <&scmi_dvfs 0>;
+};
+
+hdlcd@7ff60000 {
+	...
+	reg = <0 0x7ff60000 0 0x1000>;
+	clocks = <&scmi_clk 4>;
+	power-domains = <&scmi_devpd 1>;
+};
+
+thermal-zones {
+	soc_thermal {
+		polling-delay-passive = <100>;
+		polling-delay = <1000>;
+					/* sensor ID */
+		thermal-sensors = <&scmi_sensors0 3>;
+		...
+	};
+};

Documentation/devicetree/bindings/arm/cpu-enable-method/nuvoton,npcm750-smp

@@ -0,0 +1,42 @@
+=========================================================
+Secondary CPU enable-method "nuvoton,npcm750-smp" binding
+=========================================================
+
+To apply to all CPUs, a single "nuvoton,npcm750-smp" enable method should be
+defined in the "cpus" node.
+
+Enable method name:	"nuvoton,npcm750-smp"
+Compatible machines:	"nuvoton,npcm750"
+Compatible CPUs:	"arm,cortex-a9"
+Related properties:	(none)
+
+Note:
+This enable method needs valid nodes compatible with "arm,cortex-a9-scu" and
+"nuvoton,npcm750-gcr".
+
+Example:
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		enable-method = "nuvoton,npcm750-smp";
+
+		cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			clocks = <&clk NPCM7XX_CLK_CPU>;
+			clock-names = "clk_cpu";
+			reg = <0>;
+			next-level-cache = <&L2>;
+		};
+
+		cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			clocks = <&clk NPCM7XX_CLK_CPU>;
+			clock-names = "clk_cpu";
+			reg = <1>;
+			next-level-cache = <&L2>;
+		};
+	};
+

Documentation/devicetree/bindings/arm/cpus.txt

@@ -185,6 +185,7 @@ described below.
 			    "nvidia,tegra186-denver"
 			    "qcom,krait"
 			    "qcom,kryo"
+			    "qcom,kryo385"
 			    "qcom,scorpion"
 	- enable-method
 		Value type: <stringlist>
@@ -198,6 +199,7 @@ described below.
 			    "actions,s500-smp"
 			    "allwinner,sun6i-a31"
 			    "allwinner,sun8i-a23"
+			    "allwinner,sun9i-a80-smp"
 			    "amlogic,meson8-smp"
 			    "amlogic,meson8b-smp"
 			    "arm,realview-smp"

Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt

@@ -0,0 +1,33 @@
+Hisilicon Hip06 Low Pin Count device
+  Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
+  provides I/O access to some legacy ISA devices.
+  Hip06 is based on arm64 architecture where there is no I/O space. So, the
+  I/O ports here are not CPU addresses, and there is no 'ranges' property in
+  LPC device node.
+
+Required properties:
+- compatible:  value should be as follows:
+	(a) "hisilicon,hip06-lpc"
+	(b) "hisilicon,hip07-lpc"
+- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
+- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
+- reg: base memory range where the LPC register set is mapped.
+
+Note:
+  The node name before '@' must be "isa" to represent the binding stick to the
+  ISA/EISA binding specification.
+
+Example:
+
+isa@a01b0000 {
+	compatible = "hisilicon,hip06-lpc";
+	#address-cells = <2>;
+	#size-cells = <1>;
+	reg = <0x0 0xa01b0000 0x0 0x1000>;
+
+	ipmi0: bt@e4 {
+		compatible = "ipmi-bt";
+		device_type = "ipmi";
+		reg = <0x01 0xe4 0x04>;
+	};
+};

Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt

@@ -74,6 +74,29 @@ Example:
 		reboot-offset = <0x4>;
 	};
 
+-----------------------------------------------------------------------
+Hisilicon Hi3798CV200 Peripheral Controller
+
+The Hi3798CV200 Peripheral Controller controls peripherals, queries
+their status, and configures some functions of peripherals.
+
+Required properties:
+- compatible: Should contain "hisilicon,hi3798cv200-perictrl", "syscon"
+  and "simple-mfd".
+- reg: Register address and size of Peripheral Controller.
+- #address-cells: Should be 1.
+- #size-cells: Should be 1.
+
+Examples:
+
+	perictrl: peripheral-controller@8a20000 {
+		compatible = "hisilicon,hi3798cv200-perictrl", "syscon",
+			     "simple-mfd";
+		reg = <0x8a20000 0x1000>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+	};
+
 -----------------------------------------------------------------------
 Hisilicon Hi6220 system controller
 

Documentation/devicetree/bindings/arm/mediatek.txt

@@ -50,6 +50,15 @@ Supported boards:
 - Reference board variant 1 for MT7622:
     Required root node properties:
       - compatible = "mediatek,mt7622-rfb1", "mediatek,mt7622";
+- Reference board for MT7623a with eMMC:
+    Required root node properties:
+      - compatible = "mediatek,mt7623a-rfb-emmc", "mediatek,mt7623";
+- Reference board for MT7623a with NAND:
+    Required root node properties:
+      - compatible = "mediatek,mt7623a-rfb-nand", "mediatek,mt7623";
+- Reference board for MT7623n with eMMC:
+    Required root node properties:
+      - compatible = "mediatek,mt7623n-rfb-emmc", "mediatek,mt7623";
 - Reference  board for MT7623n with NAND:
     Required root node properties:
       - compatible = "mediatek,mt7623n-rfb-nand", "mediatek,mt7623";

Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt

@@ -6,6 +6,7 @@ The MediaTek AUDSYS controller provides various clocks to the system.
 Required Properties:
 
 - compatible: Should be one of:
+	- "mediatek,mt2701-audsys", "syscon"
 	- "mediatek,mt7622-audsys", "syscon"
 - #clock-cells: Must be 1
 
@@ -13,10 +14,19 @@ The AUDSYS controller uses the common clk binding from
 Documentation/devicetree/bindings/clock/clock-bindings.txt
 The available clocks are defined in dt-bindings/clock/mt*-clk.h.
 
+Required sub-nodes:
+-------
+For common binding part and usage, refer to
+../sonud/mt2701-afe-pcm.txt.
+
 Example:
 
-audsys: audsys@11220000 {
-	compatible = "mediatek,mt7622-audsys", "syscon";
-	reg = <0 0x11220000 0 0x1000>;
-	#clock-cells = <1>;
-};
+	audsys: clock-controller@11220000 {
+		compatible = "mediatek,mt7622-audsys", "syscon";
+		reg = <0 0x11220000 0 0x2000>;
+		#clock-cells = <1>;
+
+		afe: audio-controller {
+			...
+		};
+	};

Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt

@@ -9,6 +9,7 @@ Required Properties:
 	- "mediatek,mt2701-ethsys", "syscon"
 	- "mediatek,mt7622-ethsys", "syscon"
 - #clock-cells: Must be 1
+- #reset-cells: Must be 1
 
 The ethsys controller uses the common clk binding from
 Documentation/devicetree/bindings/clock/clock-bindings.txt

Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt

@@ -8,6 +8,7 @@ Required Properties:
 - compatible: Should be:
 	- "mediatek,mt7622-pciesys", "syscon"
 - #clock-cells: Must be 1
+- #reset-cells: Must be 1
 
 The PCIESYS controller uses the common clk binding from
 Documentation/devicetree/bindings/clock/clock-bindings.txt
@@ -19,4 +20,5 @@ pciesys: pciesys@1a100800 {
 	compatible = "mediatek,mt7622-pciesys", "syscon";
 	reg = <0 0x1a100800 0 0x1000>;
 	#clock-cells = <1>;
+	#reset-cells = <1>;
 };

Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt

@@ -8,6 +8,7 @@ Required Properties:
 - compatible: Should be:
 	- "mediatek,mt7622-ssusbsys", "syscon"
 - #clock-cells: Must be 1
+- #reset-cells: Must be 1
 
 The SSUSBSYS controller uses the common clk binding from
 Documentation/devicetree/bindings/clock/clock-bindings.txt
@@ -19,4 +20,5 @@ ssusbsys: ssusbsys@1a000000 {
 	compatible = "mediatek,mt7622-ssusbsys", "syscon";
 	reg = <0 0x1a000000 0 0x1000>;
 	#clock-cells = <1>;
+	#reset-cells = <1>;
 };

Documentation/devicetree/bindings/arm/npcm/npcm.txt

@@ -0,0 +1,6 @@
+NPCM Platforms Device Tree Bindings
+-----------------------------------
+NPCM750 SoC
+Required root node properties:
+	- compatible = "nuvoton,npcm750";
+

Documentation/devicetree/bindings/arm/omap/ctrl.txt

@@ -25,6 +25,7 @@ Required properties:
 		"ti,omap4-scm-padconf-wkup"
 		"ti,omap5-scm-core"
 		"ti,omap5-scm-padconf-core"
+		"ti,omap5-scm-wkup-pad-conf"
 		"ti,dra7-scm-core"
 - reg:		Contains Control Module register address range
 		(base address and length)

Documentation/devicetree/bindings/arm/omap/mpu.txt

@@ -13,6 +13,13 @@ Required properties:
 Optional properties:
 - sram:	Phandle to the ocmcram node
 
+am335x and am437x only:
+- pm-sram: Phandles to ocmcram nodes to be used for power management.
+	   First should be type 'protect-exec' for the driver to use to copy
+	   and run PM functions, second should be regular pool to be used for
+	   data region for code. See Documentation/devicetree/bindings/sram/sram.txt
+	   for more details.
+
 Examples:
 
 - For an OMAP5 SMP system:
@@ -36,3 +43,12 @@ mpu {
     compatible = "ti,omap3-mpu";
     ti,hwmods = "mpu";
 };
+
+- For an AM335x system:
+
+mpu {
+	compatible = "ti,omap3-mpu";
+	ti,hwmods = "mpu";
+	pm-sram = <&pm_sram_code
+		   &pm_sram_data>;
+};

Documentation/devicetree/bindings/arm/qcom.txt

@@ -26,6 +26,7 @@ The 'SoC' element must be one of the following strings:
 	msm8996
 	mdm9615
 	ipq8074
+	sdm845
 
 The 'board' element must be one of the following strings:
 

Documentation/devicetree/bindings/arm/rockchip.txt

@@ -50,6 +50,10 @@ Rockchip platforms device tree bindings
     Required root node properties:
       - compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
 
+- Firefly roc-rk3328-cc board:
+    Required root node properties:
+      - compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
+
 - ChipSPARK PopMetal-RK3288 board:
     Required root node properties:
       - compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
@@ -181,10 +185,18 @@ Rockchip platforms device tree bindings
     Required root node properties:
       - compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
 
+- Rockchip RK3399 Sapphire board standalone:
+    Required root node properties:
+      - compatible = "rockchip,rk3399-sapphire", "rockchip,rk3399";
+
 - Rockchip RK3399 Sapphire Excavator board:
     Required root node properties:
       - compatible = "rockchip,rk3399-sapphire-excavator", "rockchip,rk3399";
 
+- Theobroma Systems RK3368-uQ7 Haikou Baseboard:
+    Required root node properties:
+      - compatible = "tsd,rk3368-uq7-haikou", "rockchip,rk3368";
+
 - Theobroma Systems RK3399-Q7 Haikou Baseboard:
     Required root node properties:
       - compatible = "tsd,rk3399-q7-haikou", "rockchip,rk3399";

Documentation/devicetree/bindings/arm/samsung/pmu.txt

@@ -43,6 +43,12 @@ following properties:
 - interrupt-parent: a phandle indicating which interrupt controller
   this PMU signals interrupts to.
 
+
+Optional nodes:
+
+- nodes defining the restart and poweroff syscon children
+
+
 Example :
 pmu_system_controller: system-controller@10040000 {
 	compatible = "samsung,exynos5250-pmu", "syscon";