Merge remote-tracking branch 'net-next/master' into mac80211-next
Bring in net-next which had pulled in net, so I have the changes from mac80211 and can apply a patch that would otherwise conflict. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This commit is contained in:
commit
dd8070bff2
7
.gitignore
vendored
7
.gitignore
vendored
|
@ -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
|
||||
|
@ -129,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
|
||||
|
|
|
@ -244,3 +244,11 @@ Description: read only
|
|||
Returns 1 if the psl timebase register is synchronized
|
||||
with the core timebase register, 0 otherwise.
|
||||
Users: https://github.com/ibm-capi/libcxl
|
||||
|
||||
What: /sys/class/cxl/<card>/tunneled_ops_supported
|
||||
Date: May 2018
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read only
|
||||
Returns 1 if tunneled operations are supported in capi mode,
|
||||
0 otherwise.
|
||||
Users: https://github.com/ibm-capi/libcxl
|
||||
|
|
|
@ -145,7 +145,7 @@ feature enabled.]
|
|||
|
||||
In this mode ``intel_pstate`` registers utilization update callbacks with the
|
||||
CPU scheduler in order to run a P-state selection algorithm, either
|
||||
``powersave`` or ``performance``, depending on the ``scaling_cur_freq`` policy
|
||||
``powersave`` or ``performance``, depending on the ``scaling_governor`` policy
|
||||
setting in ``sysfs``. The current CPU frequency information to be made
|
||||
available from the ``scaling_cur_freq`` policy attribute in ``sysfs`` is
|
||||
periodically updated by those utilization update callbacks too.
|
||||
|
|
|
@ -15,7 +15,7 @@ Sleep States That Can Be Supported
|
|||
==================================
|
||||
|
||||
Depending on its configuration and the capabilities of the platform it runs on,
|
||||
the Linux kernel can support up to four system sleep states, includig
|
||||
the Linux kernel can support up to four system sleep states, including
|
||||
hibernation and up to three variants of system suspend. The sleep states that
|
||||
can be supported by the kernel are listed below.
|
||||
|
||||
|
|
36
Documentation/bpf/README.rst
Normal file
36
Documentation/bpf/README.rst
Normal file
|
@ -0,0 +1,36 @@
|
|||
=================
|
||||
BPF documentation
|
||||
=================
|
||||
|
||||
This directory contains documentation for the BPF (Berkeley Packet
|
||||
Filter) facility, with a focus on the extended BPF version (eBPF).
|
||||
|
||||
This kernel side documentation is still work in progress. The main
|
||||
textual documentation is (for historical reasons) described in
|
||||
`Documentation/networking/filter.txt`_, which describe both classical
|
||||
and extended BPF instruction-set.
|
||||
The Cilium project also maintains a `BPF and XDP Reference Guide`_
|
||||
that goes into great technical depth about the BPF Architecture.
|
||||
|
||||
The primary info for the bpf syscall is available in the `man-pages`_
|
||||
for `bpf(2)`_.
|
||||
|
||||
|
||||
|
||||
Frequently asked questions (FAQ)
|
||||
================================
|
||||
|
||||
Two sets of Questions and Answers (Q&A) are maintained.
|
||||
|
||||
* QA for common questions about BPF see: bpf_design_QA_
|
||||
|
||||
* QA for developers interacting with BPF subsystem: bpf_devel_QA_
|
||||
|
||||
|
||||
.. Links:
|
||||
.. _bpf_design_QA: bpf_design_QA.rst
|
||||
.. _bpf_devel_QA: bpf_devel_QA.rst
|
||||
.. _Documentation/networking/filter.txt: ../networking/filter.txt
|
||||
.. _man-pages: https://www.kernel.org/doc/man-pages/
|
||||
.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html
|
||||
.. _BPF and XDP Reference Guide: http://cilium.readthedocs.io/en/latest/bpf/
|
221
Documentation/bpf/bpf_design_QA.rst
Normal file
221
Documentation/bpf/bpf_design_QA.rst
Normal file
|
@ -0,0 +1,221 @@
|
|||
==============
|
||||
BPF Design Q&A
|
||||
==============
|
||||
|
||||
BPF extensibility and applicability to networking, tracing, security
|
||||
in the linux kernel and several user space implementations of BPF
|
||||
virtual machine led to a number of misunderstanding on what BPF actually is.
|
||||
This short QA is an attempt to address that and outline a direction
|
||||
of where BPF is heading long term.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 3
|
||||
|
||||
Questions and Answers
|
||||
=====================
|
||||
|
||||
Q: Is BPF a generic instruction set similar to x64 and arm64?
|
||||
-------------------------------------------------------------
|
||||
A: NO.
|
||||
|
||||
Q: Is BPF a generic virtual machine ?
|
||||
-------------------------------------
|
||||
A: NO.
|
||||
|
||||
BPF is generic instruction set *with* C calling convention.
|
||||
-----------------------------------------------------------
|
||||
|
||||
Q: Why C calling convention was chosen?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A: Because BPF programs are designed to run in the linux kernel
|
||||
which is written in C, hence BPF defines instruction set compatible
|
||||
with two most used architectures x64 and arm64 (and takes into
|
||||
consideration important quirks of other architectures) and
|
||||
defines calling convention that is compatible with C calling
|
||||
convention of the linux kernel on those architectures.
|
||||
|
||||
Q: can multiple return values be supported in the future?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
A: NO. BPF allows only register R0 to be used as return value.
|
||||
|
||||
Q: can more than 5 function arguments be supported in the future?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
A: NO. BPF calling convention only allows registers R1-R5 to be used
|
||||
as arguments. BPF is not a standalone instruction set.
|
||||
(unlike x64 ISA that allows msft, cdecl and other conventions)
|
||||
|
||||
Q: can BPF programs access instruction pointer or return address?
|
||||
-----------------------------------------------------------------
|
||||
A: NO.
|
||||
|
||||
Q: can BPF programs access stack pointer ?
|
||||
------------------------------------------
|
||||
A: NO.
|
||||
|
||||
Only frame pointer (register R10) is accessible.
|
||||
From compiler point of view it's necessary to have stack pointer.
|
||||
For example LLVM defines register R11 as stack pointer in its
|
||||
BPF backend, but it makes sure that generated code never uses it.
|
||||
|
||||
Q: Does C-calling convention diminishes possible use cases?
|
||||
-----------------------------------------------------------
|
||||
A: YES.
|
||||
|
||||
BPF design forces addition of major functionality in the form
|
||||
of kernel helper functions and kernel objects like BPF maps with
|
||||
seamless interoperability between them. It lets kernel call into
|
||||
BPF programs and programs call kernel helpers with zero overhead.
|
||||
As all of them were native C code. That is particularly the case
|
||||
for JITed BPF programs that are indistinguishable from
|
||||
native kernel C code.
|
||||
|
||||
Q: Does it mean that 'innovative' extensions to BPF code are disallowed?
|
||||
------------------------------------------------------------------------
|
||||
A: Soft yes.
|
||||
|
||||
At least for now until BPF core has support for
|
||||
bpf-to-bpf calls, indirect calls, loops, global variables,
|
||||
jump tables, read only sections and all other normal constructs
|
||||
that C code can produce.
|
||||
|
||||
Q: Can loops be supported in a safe way?
|
||||
----------------------------------------
|
||||
A: It's not clear yet.
|
||||
|
||||
BPF developers are trying to find a way to
|
||||
support bounded loops where the verifier can guarantee that
|
||||
the program terminates in less than 4096 instructions.
|
||||
|
||||
Instruction level questions
|
||||
---------------------------
|
||||
|
||||
Q: LD_ABS and LD_IND instructions vs C code
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Q: How come LD_ABS and LD_IND instruction are present in BPF whereas
|
||||
C code cannot express them and has to use builtin intrinsics?
|
||||
|
||||
A: This is artifact of compatibility with classic BPF. Modern
|
||||
networking code in BPF performs better without them.
|
||||
See 'direct packet access'.
|
||||
|
||||
Q: BPF instructions mapping not one-to-one to native CPU
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Q: It seems not all BPF instructions are one-to-one to native CPU.
|
||||
For example why BPF_JNE and other compare and jumps are not cpu-like?
|
||||
|
||||
A: This was necessary to avoid introducing flags into ISA which are
|
||||
impossible to make generic and efficient across CPU architectures.
|
||||
|
||||
Q: why BPF_DIV instruction doesn't map to x64 div?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
A: Because if we picked one-to-one relationship to x64 it would have made
|
||||
it more complicated to support on arm64 and other archs. Also it
|
||||
needs div-by-zero runtime check.
|
||||
|
||||
Q: why there is no BPF_SDIV for signed divide operation?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
A: Because it would be rarely used. llvm errors in such case and
|
||||
prints a suggestion to use unsigned divide instead
|
||||
|
||||
Q: Why BPF has implicit prologue and epilogue?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
A: Because architectures like sparc have register windows and in general
|
||||
there are enough subtle differences between architectures, so naive
|
||||
store return address into stack won't work. Another reason is BPF has
|
||||
to be safe from division by zero (and legacy exception path
|
||||
of LD_ABS insn). Those instructions need to invoke epilogue and
|
||||
return implicitly.
|
||||
|
||||
Q: Why BPF_JLT and BPF_JLE instructions were not introduced in the beginning?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
A: Because classic BPF didn't have them and BPF authors felt that compiler
|
||||
workaround would be acceptable. Turned out that programs lose performance
|
||||
due to lack of these compare instructions and they were added.
|
||||
These two instructions is a perfect example what kind of new BPF
|
||||
instructions are acceptable and can be added in the future.
|
||||
These two already had equivalent instructions in native CPUs.
|
||||
New instructions that don't have one-to-one mapping to HW instructions
|
||||
will not be accepted.
|
||||
|
||||
Q: BPF 32-bit subregister requirements
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Q: BPF 32-bit subregisters have a requirement to zero upper 32-bits of BPF
|
||||
registers which makes BPF inefficient virtual machine for 32-bit
|
||||
CPU architectures and 32-bit HW accelerators. Can true 32-bit registers
|
||||
be added to BPF in the future?
|
||||
|
||||
A: NO. The first thing to improve performance on 32-bit archs is to teach
|
||||
LLVM to generate code that uses 32-bit subregisters. Then second step
|
||||
is to teach verifier to mark operations where zero-ing upper bits
|
||||
is unnecessary. Then JITs can take advantage of those markings and
|
||||
drastically reduce size of generated code and improve performance.
|
||||
|
||||
Q: Does BPF have a stable ABI?
|
||||
------------------------------
|
||||
A: YES. BPF instructions, arguments to BPF programs, set of helper
|
||||
functions and their arguments, recognized return codes are all part
|
||||
of ABI. However when tracing programs are using bpf_probe_read() helper
|
||||
to walk kernel internal datastructures and compile with kernel
|
||||
internal headers these accesses can and will break with newer
|
||||
kernels. The union bpf_attr -> kern_version is checked at load time
|
||||
to prevent accidentally loading kprobe-based bpf programs written
|
||||
for a different kernel. Networking programs don't do kern_version check.
|
||||
|
||||
Q: How much stack space a BPF program uses?
|
||||
-------------------------------------------
|
||||
A: Currently all program types are limited to 512 bytes of stack
|
||||
space, but the verifier computes the actual amount of stack used
|
||||
and both interpreter and most JITed code consume necessary amount.
|
||||
|
||||
Q: Can BPF be offloaded to HW?
|
||||
------------------------------
|
||||
A: YES. BPF HW offload is supported by NFP driver.
|
||||
|
||||
Q: Does classic BPF interpreter still exist?
|
||||
--------------------------------------------
|
||||
A: NO. Classic BPF programs are converted into extend BPF instructions.
|
||||
|
||||
Q: Can BPF call arbitrary kernel functions?
|
||||
-------------------------------------------
|
||||
A: NO. BPF programs can only call a set of helper functions which
|
||||
is defined for every program type.
|
||||
|
||||
Q: Can BPF overwrite arbitrary kernel memory?
|
||||
---------------------------------------------
|
||||
A: NO.
|
||||
|
||||
Tracing bpf programs can *read* arbitrary memory with bpf_probe_read()
|
||||
and bpf_probe_read_str() helpers. Networking programs cannot read
|
||||
arbitrary memory, since they don't have access to these helpers.
|
||||
Programs can never read or write arbitrary memory directly.
|
||||
|
||||
Q: Can BPF overwrite arbitrary user memory?
|
||||
-------------------------------------------
|
||||
A: Sort-of.
|
||||
|
||||
Tracing BPF programs can overwrite the user memory
|
||||
of the current task with bpf_probe_write_user(). Every time such
|
||||
program is loaded the kernel will print warning message, so
|
||||
this helper is only useful for experiments and prototypes.
|
||||
Tracing BPF programs are root only.
|
||||
|
||||
Q: bpf_trace_printk() helper warning
|
||||
------------------------------------
|
||||
Q: When bpf_trace_printk() helper is used the kernel prints nasty
|
||||
warning message. Why is that?
|
||||
|
||||
A: This is done to nudge program authors into better interfaces when
|
||||
programs need to pass data to user space. Like bpf_perf_event_output()
|
||||
can be used to efficiently stream data via perf ring buffer.
|
||||
BPF maps can be used for asynchronous data sharing between kernel
|
||||
and user space. bpf_trace_printk() should only be used for debugging.
|
||||
|
||||
Q: New functionality via kernel modules?
|
||||
----------------------------------------
|
||||
Q: Can BPF functionality such as new program or map types, new
|
||||
helpers, etc be added out of kernel module code?
|
||||
|
||||
A: NO.
|
|
@ -1,156 +0,0 @@
|
|||
BPF extensibility and applicability to networking, tracing, security
|
||||
in the linux kernel and several user space implementations of BPF
|
||||
virtual machine led to a number of misunderstanding on what BPF actually is.
|
||||
This short QA is an attempt to address that and outline a direction
|
||||
of where BPF is heading long term.
|
||||
|
||||
Q: Is BPF a generic instruction set similar to x64 and arm64?
|
||||
A: NO.
|
||||
|
||||
Q: Is BPF a generic virtual machine ?
|
||||
A: NO.
|
||||
|
||||
BPF is generic instruction set _with_ C calling convention.
|
||||
|
||||
Q: Why C calling convention was chosen?
|
||||
A: Because BPF programs are designed to run in the linux kernel
|
||||
which is written in C, hence BPF defines instruction set compatible
|
||||
with two most used architectures x64 and arm64 (and takes into
|
||||
consideration important quirks of other architectures) and
|
||||
defines calling convention that is compatible with C calling
|
||||
convention of the linux kernel on those architectures.
|
||||
|
||||
Q: can multiple return values be supported in the future?
|
||||
A: NO. BPF allows only register R0 to be used as return value.
|
||||
|
||||
Q: can more than 5 function arguments be supported in the future?
|
||||
A: NO. BPF calling convention only allows registers R1-R5 to be used
|
||||
as arguments. BPF is not a standalone instruction set.
|
||||
(unlike x64 ISA that allows msft, cdecl and other conventions)
|
||||
|
||||
Q: can BPF programs access instruction pointer or return address?
|
||||
A: NO.
|
||||
|
||||
Q: can BPF programs access stack pointer ?
|
||||
A: NO. Only frame pointer (register R10) is accessible.
|
||||
From compiler point of view it's necessary to have stack pointer.
|
||||
For example LLVM defines register R11 as stack pointer in its
|
||||
BPF backend, but it makes sure that generated code never uses it.
|
||||
|
||||
Q: Does C-calling convention diminishes possible use cases?
|
||||
A: YES. BPF design forces addition of major functionality in the form
|
||||
of kernel helper functions and kernel objects like BPF maps with
|
||||
seamless interoperability between them. It lets kernel call into
|
||||
BPF programs and programs call kernel helpers with zero overhead.
|
||||
As all of them were native C code. That is particularly the case
|
||||
for JITed BPF programs that are indistinguishable from
|
||||
native kernel C code.
|
||||
|
||||
Q: Does it mean that 'innovative' extensions to BPF code are disallowed?
|
||||
A: Soft yes. At least for now until BPF core has support for
|
||||
bpf-to-bpf calls, indirect calls, loops, global variables,
|
||||
jump tables, read only sections and all other normal constructs
|
||||
that C code can produce.
|
||||
|
||||
Q: Can loops be supported in a safe way?
|
||||
A: It's not clear yet. BPF developers are trying to find a way to
|
||||
support bounded loops where the verifier can guarantee that
|
||||
the program terminates in less than 4096 instructions.
|
||||
|
||||
Q: How come LD_ABS and LD_IND instruction are present in BPF whereas
|
||||
C code cannot express them and has to use builtin intrinsics?
|
||||
A: This is artifact of compatibility with classic BPF. Modern
|
||||
networking code in BPF performs better without them.
|
||||
See 'direct packet access'.
|
||||
|
||||
Q: It seems not all BPF instructions are one-to-one to native CPU.
|
||||
For example why BPF_JNE and other compare and jumps are not cpu-like?
|
||||
A: This was necessary to avoid introducing flags into ISA which are
|
||||
impossible to make generic and efficient across CPU architectures.
|
||||
|
||||
Q: why BPF_DIV instruction doesn't map to x64 div?
|
||||
A: Because if we picked one-to-one relationship to x64 it would have made
|
||||
it more complicated to support on arm64 and other archs. Also it
|
||||
needs div-by-zero runtime check.
|
||||
|
||||
Q: why there is no BPF_SDIV for signed divide operation?
|
||||
A: Because it would be rarely used. llvm errors in such case and
|
||||
prints a suggestion to use unsigned divide instead
|
||||
|
||||
Q: Why BPF has implicit prologue and epilogue?
|
||||
A: Because architectures like sparc have register windows and in general
|
||||
there are enough subtle differences between architectures, so naive
|
||||
store return address into stack won't work. Another reason is BPF has
|
||||
to be safe from division by zero (and legacy exception path
|
||||
of LD_ABS insn). Those instructions need to invoke epilogue and
|
||||
return implicitly.
|
||||
|
||||
Q: Why BPF_JLT and BPF_JLE instructions were not introduced in the beginning?
|
||||
A: Because classic BPF didn't have them and BPF authors felt that compiler
|
||||
workaround would be acceptable. Turned out that programs lose performance
|
||||
due to lack of these compare instructions and they were added.
|
||||
These two instructions is a perfect example what kind of new BPF
|
||||
instructions are acceptable and can be added in the future.
|
||||
These two already had equivalent instructions in native CPUs.
|
||||
New instructions that don't have one-to-one mapping to HW instructions
|
||||
will not be accepted.
|
||||
|
||||
Q: BPF 32-bit subregisters have a requirement to zero upper 32-bits of BPF
|
||||
registers which makes BPF inefficient virtual machine for 32-bit
|
||||
CPU architectures and 32-bit HW accelerators. Can true 32-bit registers
|
||||
be added to BPF in the future?
|
||||
A: NO. The first thing to improve performance on 32-bit archs is to teach
|
||||
LLVM to generate code that uses 32-bit subregisters. Then second step
|
||||
is to teach verifier to mark operations where zero-ing upper bits
|
||||
is unnecessary. Then JITs can take advantage of those markings and
|
||||
drastically reduce size of generated code and improve performance.
|
||||
|
||||
Q: Does BPF have a stable ABI?
|
||||
A: YES. BPF instructions, arguments to BPF programs, set of helper
|
||||
functions and their arguments, recognized return codes are all part
|
||||
of ABI. However when tracing programs are using bpf_probe_read() helper
|
||||
to walk kernel internal datastructures and compile with kernel
|
||||
internal headers these accesses can and will break with newer
|
||||
kernels. The union bpf_attr -> kern_version is checked at load time
|
||||
to prevent accidentally loading kprobe-based bpf programs written
|
||||
for a different kernel. Networking programs don't do kern_version check.
|
||||
|
||||
Q: How much stack space a BPF program uses?
|
||||
A: Currently all program types are limited to 512 bytes of stack
|
||||
space, but the verifier computes the actual amount of stack used
|
||||
and both interpreter and most JITed code consume necessary amount.
|
||||
|
||||
Q: Can BPF be offloaded to HW?
|
||||
A: YES. BPF HW offload is supported by NFP driver.
|
||||
|
||||
Q: Does classic BPF interpreter still exist?
|
||||
A: NO. Classic BPF programs are converted into extend BPF instructions.
|
||||
|
||||
Q: Can BPF call arbitrary kernel functions?
|
||||
A: NO. BPF programs can only call a set of helper functions which
|
||||
is defined for every program type.
|
||||
|
||||
Q: Can BPF overwrite arbitrary kernel memory?
|
||||
A: NO. Tracing bpf programs can _read_ arbitrary memory with bpf_probe_read()
|
||||
and bpf_probe_read_str() helpers. Networking programs cannot read
|
||||
arbitrary memory, since they don't have access to these helpers.
|
||||
Programs can never read or write arbitrary memory directly.
|
||||
|
||||
Q: Can BPF overwrite arbitrary user memory?
|
||||
A: Sort-of. Tracing BPF programs can overwrite the user memory
|
||||
of the current task with bpf_probe_write_user(). Every time such
|
||||
program is loaded the kernel will print warning message, so
|
||||
this helper is only useful for experiments and prototypes.
|
||||
Tracing BPF programs are root only.
|
||||
|
||||
Q: When bpf_trace_printk() helper is used the kernel prints nasty
|
||||
warning message. Why is that?
|
||||
A: This is done to nudge program authors into better interfaces when
|
||||
programs need to pass data to user space. Like bpf_perf_event_output()
|
||||
can be used to efficiently stream data via perf ring buffer.
|
||||
BPF maps can be used for asynchronous data sharing between kernel
|
||||
and user space. bpf_trace_printk() should only be used for debugging.
|
||||
|
||||
Q: Can BPF functionality such as new program or map types, new
|
||||
helpers, etc be added out of kernel module code?
|
||||
A: NO.
|
640
Documentation/bpf/bpf_devel_QA.rst
Normal file
640
Documentation/bpf/bpf_devel_QA.rst
Normal file
|
@ -0,0 +1,640 @@
|
|||
=================================
|
||||
HOWTO interact with BPF subsystem
|
||||
=================================
|
||||
|
||||
This document provides information for the BPF subsystem about various
|
||||
workflows related to reporting bugs, submitting patches, and queueing
|
||||
patches for stable kernels.
|
||||
|
||||
For general information about submitting patches, please refer to
|
||||
`Documentation/process/`_. This document only describes additional specifics
|
||||
related to BPF.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 2
|
||||
|
||||
Reporting bugs
|
||||
==============
|
||||
|
||||
Q: How do I report bugs for BPF kernel code?
|
||||
--------------------------------------------
|
||||
A: Since all BPF kernel development as well as bpftool and iproute2 BPF
|
||||
loader development happens through the netdev kernel mailing list,
|
||||
please report any found issues around BPF to the following mailing
|
||||
list:
|
||||
|
||||
netdev@vger.kernel.org
|
||||
|
||||
This may also include issues related to XDP, BPF tracing, etc.
|
||||
|
||||
Given netdev has a high volume of traffic, please also add the BPF
|
||||
maintainers to Cc (from kernel MAINTAINERS_ file):
|
||||
|
||||
* Alexei Starovoitov <ast@kernel.org>
|
||||
* Daniel Borkmann <daniel@iogearbox.net>
|
||||
|
||||
In case a buggy commit has already been identified, make sure to keep
|
||||
the actual commit authors in Cc as well for the report. They can
|
||||
typically be identified through the kernel's git tree.
|
||||
|
||||
**Please do NOT report BPF issues to bugzilla.kernel.org since it
|
||||
is a guarantee that the reported issue will be overlooked.**
|
||||
|
||||
Submitting patches
|
||||
==================
|
||||
|
||||
Q: To which mailing list do I need to submit my BPF patches?
|
||||
------------------------------------------------------------
|
||||
A: Please submit your BPF patches to the netdev kernel mailing list:
|
||||
|
||||
netdev@vger.kernel.org
|
||||
|
||||
Historically, BPF came out of networking and has always been maintained
|
||||
by the kernel networking community. Although these days BPF touches
|
||||
many other subsystems as well, the patches are still routed mainly
|
||||
through the networking community.
|
||||
|
||||
In case your patch has changes in various different subsystems (e.g.
|
||||
tracing, security, etc), make sure to Cc the related kernel mailing
|
||||
lists and maintainers from there as well, so they are able to review
|
||||
the changes and provide their Acked-by's to the patches.
|
||||
|
||||
Q: Where can I find patches currently under discussion for BPF subsystem?
|
||||
-------------------------------------------------------------------------
|
||||
A: All patches that are Cc'ed to netdev are queued for review under netdev
|
||||
patchwork project:
|
||||
|
||||
http://patchwork.ozlabs.org/project/netdev/list/
|
||||
|
||||
Those patches which target BPF, are assigned to a 'bpf' delegate for
|
||||
further processing from BPF maintainers. The current queue with
|
||||
patches under review can be found at:
|
||||
|
||||
https://patchwork.ozlabs.org/project/netdev/list/?delegate=77147
|
||||
|
||||
Once the patches have been reviewed by the BPF community as a whole
|
||||
and approved by the BPF maintainers, their status in patchwork will be
|
||||
changed to 'Accepted' and the submitter will be notified by mail. This
|
||||
means that the patches look good from a BPF perspective and have been
|
||||
applied to one of the two BPF kernel trees.
|
||||
|
||||
In case feedback from the community requires a respin of the patches,
|
||||
their status in patchwork will be set to 'Changes Requested', and purged
|
||||
from the current review queue. Likewise for cases where patches would
|
||||
get rejected or are not applicable to the BPF trees (but assigned to
|
||||
the 'bpf' delegate).
|
||||
|
||||
Q: How do the changes make their way into Linux?
|
||||
------------------------------------------------
|
||||
A: There are two BPF kernel trees (git repositories). Once patches have
|
||||
been accepted by the BPF maintainers, they will be applied to one
|
||||
of the two BPF trees:
|
||||
|
||||
* https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/
|
||||
* https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/
|
||||
|
||||
The bpf tree itself is for fixes only, whereas bpf-next for features,
|
||||
cleanups or other kind of improvements ("next-like" content). This is
|
||||
analogous to net and net-next trees for networking. Both bpf and
|
||||
bpf-next will only have a master branch in order to simplify against
|
||||
which branch patches should get rebased to.
|
||||
|
||||
Accumulated BPF patches in the bpf tree will regularly get pulled
|
||||
into the net kernel tree. Likewise, accumulated BPF patches accepted
|
||||
into the bpf-next tree will make their way into net-next tree. net and
|
||||
net-next are both run by David S. Miller. From there, they will go
|
||||
into the kernel mainline tree run by Linus Torvalds. To read up on the
|
||||
process of net and net-next being merged into the mainline tree, see
|
||||
the `netdev FAQ`_ under:
|
||||
|
||||
`Documentation/networking/netdev-FAQ.txt`_
|
||||
|
||||
Occasionally, to prevent merge conflicts, we might send pull requests
|
||||
to other trees (e.g. tracing) with a small subset of the patches, but
|
||||
net and net-next are always the main trees targeted for integration.
|
||||
|
||||
The pull requests will contain a high-level summary of the accumulated
|
||||
patches and can be searched on netdev kernel mailing list through the
|
||||
following subject lines (``yyyy-mm-dd`` is the date of the pull
|
||||
request)::
|
||||
|
||||
pull-request: bpf yyyy-mm-dd
|
||||
pull-request: bpf-next yyyy-mm-dd
|
||||
|
||||
Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
|
||||
---------------------------------------------------------------------------------
|
||||
|
||||
A: The process is the very same as described in the `netdev FAQ`_, so
|
||||
please read up on it. The subject line must indicate whether the
|
||||
patch is a fix or rather "next-like" content in order to let the
|
||||
maintainers know whether it is targeted at bpf or bpf-next.
|
||||
|
||||
For fixes eventually landing in bpf -> net tree, the subject must
|
||||
look like::
|
||||
|
||||
git format-patch --subject-prefix='PATCH bpf' start..finish
|
||||
|
||||
For features/improvements/etc that should eventually land in
|
||||
bpf-next -> net-next, the subject must look like::
|
||||
|
||||
git format-patch --subject-prefix='PATCH bpf-next' start..finish
|
||||
|
||||
If unsure whether the patch or patch series should go into bpf
|
||||
or net directly, or bpf-next or net-next directly, it is not a
|
||||
problem either if the subject line says net or net-next as target.
|
||||
It is eventually up to the maintainers to do the delegation of
|
||||
the patches.
|
||||
|
||||
If it is clear that patches should go into bpf or bpf-next tree,
|
||||
please make sure to rebase the patches against those trees in
|
||||
order to reduce potential conflicts.
|
||||
|
||||
In case the patch or patch series has to be reworked and sent out
|
||||
again in a second or later revision, it is also required to add a
|
||||
version number (``v2``, ``v3``, ...) into the subject prefix::
|
||||
|
||||
git format-patch --subject-prefix='PATCH net-next v2' start..finish
|
||||
|
||||
When changes have been requested to the patch series, always send the
|
||||
whole patch series again with the feedback incorporated (never send
|
||||
individual diffs on top of the old series).
|
||||
|
||||
Q: What does it mean when a patch gets applied to bpf or bpf-next tree?
|
||||
-----------------------------------------------------------------------
|
||||
A: It means that the patch looks good for mainline inclusion from
|
||||
a BPF point of view.
|
||||
|
||||
Be aware that this is not a final verdict that the patch will
|
||||
automatically get accepted into net or net-next trees eventually:
|
||||
|
||||
On the netdev kernel mailing list reviews can come in at any point
|
||||
in time. If discussions around a patch conclude that they cannot
|
||||
get included as-is, we will either apply a follow-up fix or drop
|
||||
them from the trees entirely. Therefore, we also reserve to rebase
|
||||
the trees when deemed necessary. After all, the purpose of the tree
|
||||
is to:
|
||||
|
||||
i) accumulate and stage BPF patches for integration into trees
|
||||
like net and net-next, and
|
||||
|
||||
ii) run extensive BPF test suite and
|
||||
workloads on the patches before they make their way any further.
|
||||
|
||||
Once the BPF pull request was accepted by David S. Miller, then
|
||||
the patches end up in net or net-next tree, respectively, and
|
||||
make their way from there further into mainline. Again, see the
|
||||
`netdev FAQ`_ for additional information e.g. on how often they are
|
||||
merged to mainline.
|
||||
|
||||
Q: How long do I need to wait for feedback on my BPF patches?
|
||||
-------------------------------------------------------------
|
||||
A: We try to keep the latency low. The usual time to feedback will
|
||||
be around 2 or 3 business days. It may vary depending on the
|
||||
complexity of changes and current patch load.
|
||||
|
||||
Q: How often do you send pull requests to major kernel trees like net or net-next?
|
||||
----------------------------------------------------------------------------------
|
||||
|
||||
A: Pull requests will be sent out rather often in order to not
|
||||
accumulate too many patches in bpf or bpf-next.
|
||||
|
||||
As a rule of thumb, expect pull requests for each tree regularly
|
||||
at the end of the week. In some cases pull requests could additionally
|
||||
come also in the middle of the week depending on the current patch
|
||||
load or urgency.
|
||||
|
||||
Q: Are patches applied to bpf-next when the merge window is open?
|
||||
-----------------------------------------------------------------
|
||||
A: For the time when the merge window is open, bpf-next will not be
|
||||
processed. This is roughly analogous to net-next patch processing,
|
||||
so feel free to read up on the `netdev FAQ`_ about further details.
|
||||
|
||||
During those two weeks of merge window, we might ask you to resend
|
||||
your patch series once bpf-next is open again. Once Linus released
|
||||
a ``v*-rc1`` after the merge window, we continue processing of bpf-next.
|
||||
|
||||
For non-subscribers to kernel mailing lists, there is also a status
|
||||
page run by David S. Miller on net-next that provides guidance:
|
||||
|
||||
http://vger.kernel.org/~davem/net-next.html
|
||||
|
||||
Q: Verifier changes and test cases
|
||||
----------------------------------
|
||||
Q: I made a BPF verifier change, do I need to add test cases for
|
||||
BPF kernel selftests_?
|
||||
|
||||
A: If the patch has changes to the behavior of the verifier, then yes,
|
||||
it is absolutely necessary to add test cases to the BPF kernel
|
||||
selftests_ suite. If they are not present and we think they are
|
||||
needed, then we might ask for them before accepting any changes.
|
||||
|
||||
In particular, test_verifier.c is tracking a high number of BPF test
|
||||
cases, including a lot of corner cases that LLVM BPF back end may
|
||||
generate out of the restricted C code. Thus, adding test cases is
|
||||
absolutely crucial to make sure future changes do not accidentally
|
||||
affect prior use-cases. Thus, treat those test cases as: verifier
|
||||
behavior that is not tracked in test_verifier.c could potentially
|
||||
be subject to change.
|
||||
|
||||
Q: samples/bpf preference vs selftests?
|
||||
---------------------------------------
|
||||
Q: When should I add code to `samples/bpf/`_ and when to BPF kernel
|
||||
selftests_ ?
|
||||
|
||||
A: In general, we prefer additions to BPF kernel selftests_ rather than
|
||||
`samples/bpf/`_. The rationale is very simple: kernel selftests are
|
||||
regularly run by various bots to test for kernel regressions.
|
||||
|
||||
The more test cases we add to BPF selftests, the better the coverage
|
||||
and the less likely it is that those could accidentally break. It is
|
||||
not that BPF kernel selftests cannot demo how a specific feature can
|
||||
be used.
|
||||
|
||||
That said, `samples/bpf/`_ may be a good place for people to get started,
|
||||
so it might be advisable that simple demos of features could go into
|
||||
`samples/bpf/`_, but advanced functional and corner-case testing rather
|
||||
into kernel selftests.
|
||||
|
||||
If your sample looks like a test case, then go for BPF kernel selftests
|
||||
instead!
|
||||
|
||||
Q: When should I add code to the bpftool?
|
||||
-----------------------------------------
|
||||
A: The main purpose of bpftool (under tools/bpf/bpftool/) is to provide
|
||||
a central user space tool for debugging and introspection of BPF programs
|
||||
and maps that are active in the kernel. If UAPI changes related to BPF
|
||||
enable for dumping additional information of programs or maps, then
|
||||
bpftool should be extended as well to support dumping them.
|
||||
|
||||
Q: When should I add code to iproute2's BPF loader?
|
||||
---------------------------------------------------
|
||||
A: For UAPI changes related to the XDP or tc layer (e.g. ``cls_bpf``),
|
||||
the convention is that those control-path related changes are added to
|
||||
iproute2's BPF loader as well from user space side. This is not only
|
||||
useful to have UAPI changes properly designed to be usable, but also
|
||||
to make those changes available to a wider user base of major
|
||||
downstream distributions.
|
||||
|
||||
Q: Do you accept patches as well for iproute2's BPF loader?
|
||||
-----------------------------------------------------------
|
||||
A: Patches for the iproute2's BPF loader have to be sent to:
|
||||
|
||||
netdev@vger.kernel.org
|
||||
|
||||
While those patches are not processed by the BPF kernel maintainers,
|
||||
please keep them in Cc as well, so they can be reviewed.
|
||||
|
||||
The official git repository for iproute2 is run by Stephen Hemminger
|
||||
and can be found at:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/
|
||||
|
||||
The patches need to have a subject prefix of '``[PATCH iproute2
|
||||
master]``' or '``[PATCH iproute2 net-next]``'. '``master``' or
|
||||
'``net-next``' describes the target branch where the patch should be
|
||||
applied to. Meaning, if kernel changes went into the net-next kernel
|
||||
tree, then the related iproute2 changes need to go into the iproute2
|
||||
net-next branch, otherwise they can be targeted at master branch. The
|
||||
iproute2 net-next branch will get merged into the master branch after
|
||||
the current iproute2 version from master has been released.
|
||||
|
||||
Like BPF, the patches end up in patchwork under the netdev project and
|
||||
are delegated to 'shemminger' for further processing:
|
||||
|
||||
http://patchwork.ozlabs.org/project/netdev/list/?delegate=389
|
||||
|
||||
Q: What is the minimum requirement before I submit my BPF patches?
|
||||
------------------------------------------------------------------
|
||||
A: When submitting patches, always take the time and properly test your
|
||||
patches *prior* to submission. Never rush them! If maintainers find
|
||||
that your patches have not been properly tested, it is a good way to
|
||||
get them grumpy. Testing patch submissions is a hard requirement!
|
||||
|
||||
Note, fixes that go to bpf tree *must* have a ``Fixes:`` tag included.
|
||||
The same applies to fixes that target bpf-next, where the affected
|
||||
commit is in net-next (or in some cases bpf-next). The ``Fixes:`` tag is
|
||||
crucial in order to identify follow-up commits and tremendously helps
|
||||
for people having to do backporting, so it is a must have!
|
||||
|
||||
We also don't accept patches with an empty commit message. Take your
|
||||
time and properly write up a high quality commit message, it is
|
||||
essential!
|
||||
|
||||
Think about it this way: other developers looking at your code a month
|
||||
from now need to understand *why* a certain change has been done that
|
||||
way, and whether there have been flaws in the analysis or assumptions
|
||||
that the original author did. Thus providing a proper rationale and
|
||||
describing the use-case for the changes is a must.
|
||||
|
||||
Patch submissions with >1 patch must have a cover letter which includes
|
||||
a high level description of the series. This high level summary will
|
||||
then be placed into the merge commit by the BPF maintainers such that
|
||||
it is also accessible from the git log for future reference.
|
||||
|
||||
Q: Features changing BPF JIT and/or LLVM
|
||||
----------------------------------------
|
||||
Q: What do I need to consider when adding a new instruction or feature
|
||||
that would require BPF JIT and/or LLVM integration as well?
|
||||
|
||||
A: We try hard to keep all BPF JITs up to date such that the same user
|
||||
experience can be guaranteed when running BPF programs on different
|
||||
architectures without having the program punt to the less efficient
|
||||
interpreter in case the in-kernel BPF JIT is enabled.
|
||||
|
||||
If you are unable to implement or test the required JIT changes for
|
||||
certain architectures, please work together with the related BPF JIT
|
||||
developers in order to get the feature implemented in a timely manner.
|
||||
Please refer to the git log (``arch/*/net/``) to locate the necessary
|
||||
people for helping out.
|
||||
|
||||
Also always make sure to add BPF test cases (e.g. test_bpf.c and
|
||||
test_verifier.c) for new instructions, so that they can receive
|
||||
broad test coverage and help run-time testing the various BPF JITs.
|
||||
|
||||
In case of new BPF instructions, once the changes have been accepted
|
||||
into the Linux kernel, please implement support into LLVM's BPF back
|
||||
end. See LLVM_ section below for further information.
|
||||
|
||||
Stable submission
|
||||
=================
|
||||
|
||||
Q: I need a specific BPF commit in stable kernels. What should I do?
|
||||
--------------------------------------------------------------------
|
||||
A: In case you need a specific fix in stable kernels, first check whether
|
||||
the commit has already been applied in the related ``linux-*.y`` branches:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/
|
||||
|
||||
If not the case, then drop an email to the BPF maintainers with the
|
||||
netdev kernel mailing list in Cc and ask for the fix to be queued up:
|
||||
|
||||
netdev@vger.kernel.org
|
||||
|
||||
The process in general is the same as on netdev itself, see also the
|
||||
`netdev FAQ`_ document.
|
||||
|
||||
Q: Do you also backport to kernels not currently maintained as stable?
|
||||
----------------------------------------------------------------------
|
||||
A: No. If you need a specific BPF commit in kernels that are currently not
|
||||
maintained by the stable maintainers, then you are on your own.
|
||||
|
||||
The current stable and longterm stable kernels are all listed here:
|
||||
|
||||
https://www.kernel.org/
|
||||
|
||||
Q: The BPF patch I am about to submit needs to go to stable as well
|
||||
-------------------------------------------------------------------
|
||||
What should I do?
|
||||
|
||||
A: The same rules apply as with netdev patch submissions in general, see
|
||||
`netdev FAQ`_ under:
|
||||
|
||||
`Documentation/networking/netdev-FAQ.txt`_
|
||||
|
||||
Never add "``Cc: stable@vger.kernel.org``" to the patch description, but
|
||||
ask the BPF maintainers to queue the patches instead. This can be done
|
||||
with a note, for example, under the ``---`` part of the patch which does
|
||||
not go into the git log. Alternatively, this can be done as a simple
|
||||
request by mail instead.
|
||||
|
||||
Q: Queue stable patches
|
||||
-----------------------
|
||||
Q: Where do I find currently queued BPF patches that will be submitted
|
||||
to stable?
|
||||
|
||||
A: Once patches that fix critical bugs got applied into the bpf tree, they
|
||||
are queued up for stable submission under:
|
||||
|
||||
http://patchwork.ozlabs.org/bundle/bpf/stable/?state=*
|
||||
|
||||
They will be on hold there at minimum until the related commit made its
|
||||
way into the mainline kernel tree.
|
||||
|
||||
After having been under broader exposure, the queued patches will be
|
||||
submitted by the BPF maintainers to the stable maintainers.
|
||||
|
||||
Testing patches
|
||||
===============
|
||||
|
||||
Q: How to run BPF selftests
|
||||
---------------------------
|
||||
A: After you have booted into the newly compiled kernel, navigate to
|
||||
the BPF selftests_ suite in order to test BPF functionality (current
|
||||
working directory points to the root of the cloned git tree)::
|
||||
|
||||
$ cd tools/testing/selftests/bpf/
|
||||
$ make
|
||||
|
||||
To run the verifier tests::
|
||||
|
||||
$ sudo ./test_verifier
|
||||
|
||||
The verifier tests print out all the current checks being
|
||||
performed. The summary at the end of running all tests will dump
|
||||
information of test successes and failures::
|
||||
|
||||
Summary: 418 PASSED, 0 FAILED
|
||||
|
||||
In order to run through all BPF selftests, the following command is
|
||||
needed::
|
||||
|
||||
$ sudo make run_tests
|
||||
|
||||
See the kernels selftest `Documentation/dev-tools/kselftest.rst`_
|
||||
document for further documentation.
|
||||
|
||||
Q: Which BPF kernel selftests version should I run my kernel against?
|
||||
---------------------------------------------------------------------
|
||||
A: If you run a kernel ``xyz``, then always run the BPF kernel selftests
|
||||
from that kernel ``xyz`` as well. Do not expect that the BPF selftest
|
||||
from the latest mainline tree will pass all the time.
|
||||
|
||||
In particular, test_bpf.c and test_verifier.c have a large number of
|
||||
test cases and are constantly updated with new BPF test sequences, or
|
||||
existing ones are adapted to verifier changes e.g. due to verifier
|
||||
becoming smarter and being able to better track certain things.
|
||||
|
||||
LLVM
|
||||
====
|
||||
|
||||
Q: Where do I find LLVM with BPF support?
|
||||
-----------------------------------------
|
||||
A: The BPF back end for LLVM is upstream in LLVM since version 3.7.1.
|
||||
|
||||
All major distributions these days ship LLVM with BPF back end enabled,
|
||||
so for the majority of use-cases it is not required to compile LLVM by
|
||||
hand anymore, just install the distribution provided package.
|
||||
|
||||
LLVM's static compiler lists the supported targets through
|
||||
``llc --version``, make sure BPF targets are listed. Example::
|
||||
|
||||
$ llc --version
|
||||
LLVM (http://llvm.org/):
|
||||
LLVM version 6.0.0svn
|
||||
Optimized build.
|
||||
Default target: x86_64-unknown-linux-gnu
|
||||
Host CPU: skylake
|
||||
|
||||
Registered Targets:
|
||||
bpf - BPF (host endian)
|
||||
bpfeb - BPF (big endian)
|
||||
bpfel - BPF (little endian)
|
||||
x86 - 32-bit X86: Pentium-Pro and above
|
||||
x86-64 - 64-bit X86: EM64T and AMD64
|
||||
|
||||
For developers in order to utilize the latest features added to LLVM's
|
||||
BPF back end, it is advisable to run the latest LLVM releases. Support
|
||||
for new BPF kernel features such as additions to the BPF instruction
|
||||
set are often developed together.
|
||||
|
||||
All LLVM releases can be found at: http://releases.llvm.org/
|
||||
|
||||
Q: Got it, so how do I build LLVM manually anyway?
|
||||
--------------------------------------------------
|
||||
A: You need cmake and gcc-c++ as build requisites for LLVM. Once you have
|
||||
that set up, proceed with building the latest LLVM and clang version
|
||||
from the git repositories::
|
||||
|
||||
$ git clone http://llvm.org/git/llvm.git
|
||||
$ cd llvm/tools
|
||||
$ git clone --depth 1 http://llvm.org/git/clang.git
|
||||
$ cd ..; mkdir build; cd build
|
||||
$ cmake .. -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
|
||||
-DBUILD_SHARED_LIBS=OFF \
|
||||
-DCMAKE_BUILD_TYPE=Release \
|
||||
-DLLVM_BUILD_RUNTIME=OFF
|
||||
$ make -j $(getconf _NPROCESSORS_ONLN)
|
||||
|
||||
The built binaries can then be found in the build/bin/ directory, where
|
||||
you can point the PATH variable to.
|
||||
|
||||
Q: Reporting LLVM BPF issues
|
||||
----------------------------
|
||||
Q: Should I notify BPF kernel maintainers about issues in LLVM's BPF code
|
||||
generation back end or about LLVM generated code that the verifier
|
||||
refuses to accept?
|
||||
|
||||
A: Yes, please do!
|
||||
|
||||
LLVM's BPF back end is a key piece of the whole BPF
|
||||
infrastructure and it ties deeply into verification of programs from the
|
||||
kernel side. Therefore, any issues on either side need to be investigated
|
||||
and fixed whenever necessary.
|
||||
|
||||
Therefore, please make sure to bring them up at netdev kernel mailing
|
||||
list and Cc BPF maintainers for LLVM and kernel bits:
|
||||
|
||||
* Yonghong Song <yhs@fb.com>
|
||||
* Alexei Starovoitov <ast@kernel.org>
|
||||
* Daniel Borkmann <daniel@iogearbox.net>
|
||||
|
||||
LLVM also has an issue tracker where BPF related bugs can be found:
|
||||
|
||||
https://bugs.llvm.org/buglist.cgi?quicksearch=bpf
|
||||
|
||||
However, it is better to reach out through mailing lists with having
|
||||
maintainers in Cc.
|
||||
|
||||
Q: New BPF instruction for kernel and LLVM
|
||||
------------------------------------------
|
||||
Q: I have added a new BPF instruction to the kernel, how can I integrate
|
||||
it into LLVM?
|
||||
|
||||
A: LLVM has a ``-mcpu`` selector for the BPF back end in order to allow
|
||||
the selection of BPF instruction set extensions. By default the
|
||||
``generic`` processor target is used, which is the base instruction set
|
||||
(v1) of BPF.
|
||||
|
||||
LLVM has an option to select ``-mcpu=probe`` where it will probe the host
|
||||
kernel for supported BPF instruction set extensions and selects the
|
||||
optimal set automatically.
|
||||
|
||||
For cross-compilation, a specific version can be select manually as well ::
|
||||
|
||||
$ llc -march bpf -mcpu=help
|
||||
Available CPUs for this target:
|
||||
|
||||
generic - Select the generic processor.
|
||||
probe - Select the probe processor.
|
||||
v1 - Select the v1 processor.
|
||||
v2 - Select the v2 processor.
|
||||
[...]
|
||||
|
||||
Newly added BPF instructions to the Linux kernel need to follow the same
|
||||
scheme, bump the instruction set version and implement probing for the
|
||||
extensions such that ``-mcpu=probe`` users can benefit from the
|
||||
optimization transparently when upgrading their kernels.
|
||||
|
||||
If you are unable to implement support for the newly added BPF instruction
|
||||
please reach out to BPF developers for help.
|
||||
|
||||
By the way, the BPF kernel selftests run with ``-mcpu=probe`` for better
|
||||
test coverage.
|
||||
|
||||
Q: clang flag for target bpf?
|
||||
-----------------------------
|
||||
Q: In some cases clang flag ``-target bpf`` is used but in other cases the
|
||||
default clang target, which matches the underlying architecture, is used.
|
||||
What is the difference and when I should use which?
|
||||
|
||||
A: Although LLVM IR generation and optimization try to stay architecture
|
||||
independent, ``-target <arch>`` still has some impact on generated code:
|
||||
|
||||
- BPF program may recursively include header file(s) with file scope
|
||||
inline assembly codes. The default target can handle this well,
|
||||
while ``bpf`` target may fail if bpf backend assembler does not
|
||||
understand these assembly codes, which is true in most cases.
|
||||
|
||||
- When compiled without ``-g``, additional elf sections, e.g.,
|
||||
.eh_frame and .rela.eh_frame, may be present in the object file
|
||||
with default target, but not with ``bpf`` target.
|
||||
|
||||
- The default target may turn a C switch statement into a switch table
|
||||
lookup and jump operation. Since the switch table is placed
|
||||
in the global readonly section, the bpf program will fail to load.
|
||||
The bpf target does not support switch table optimization.
|
||||
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
|
||||
pulls in some header files containing file scope host assembly codes.
|
||||
|
||||
- You can add ``-fno-jump-tables`` to work around the switch table issue.
|
||||
|
||||
Otherwise, you can use ``bpf`` target. Additionally, you *must* use bpf target
|
||||
when:
|
||||
|
||||
- Your program uses data structures with pointer or long / unsigned long
|
||||
types that interface with BPF helpers or context data structures. Access
|
||||
into these structures is verified by the BPF verifier and may result
|
||||
in verification failures if the native architecture is not aligned with
|
||||
the BPF architecture, e.g. 64-bit. An example of this is
|
||||
BPF_PROG_TYPE_SK_MSG require ``-target bpf``
|
||||
|
||||
|
||||
.. Links
|
||||
.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
|
||||
.. _MAINTAINERS: ../../MAINTAINERS
|
||||
.. _Documentation/networking/netdev-FAQ.txt: ../networking/netdev-FAQ.txt
|
||||
.. _netdev FAQ: ../networking/netdev-FAQ.txt
|
||||
.. _samples/bpf/: ../../samples/bpf/
|
||||
.. _selftests: ../../tools/testing/selftests/bpf/
|
||||
.. _Documentation/dev-tools/kselftest.rst:
|
||||
https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
|
||||
|
||||
Happy BPF hacking!
|
|
@ -1,562 +0,0 @@
|
|||
This document provides information for the BPF subsystem about various
|
||||
workflows related to reporting bugs, submitting patches, and queueing
|
||||
patches for stable kernels.
|
||||
|
||||
For general information about submitting patches, please refer to
|
||||
Documentation/process/. This document only describes additional specifics
|
||||
related to BPF.
|
||||
|
||||
Reporting bugs:
|
||||
---------------
|
||||
|
||||
Q: How do I report bugs for BPF kernel code?
|
||||
|
||||
A: Since all BPF kernel development as well as bpftool and iproute2 BPF
|
||||
loader development happens through the netdev kernel mailing list,
|
||||
please report any found issues around BPF to the following mailing
|
||||
list:
|
||||
|
||||
netdev@vger.kernel.org
|
||||
|
||||
This may also include issues related to XDP, BPF tracing, etc.
|
||||
|
||||
Given netdev has a high volume of traffic, please also add the BPF
|
||||
maintainers to Cc (from kernel MAINTAINERS file):
|
||||
|
||||
Alexei Starovoitov <ast@kernel.org>
|
||||
Daniel Borkmann <daniel@iogearbox.net>
|
||||
|
||||
In case a buggy commit has already been identified, make sure to keep
|
||||
the actual commit authors in Cc as well for the report. They can
|
||||
typically be identified through the kernel's git tree.
|
||||
|
||||
Please do *not* report BPF issues to bugzilla.kernel.org since it
|
||||
is a guarantee that the reported issue will be overlooked.
|
||||
|
||||
Submitting patches:
|
||||
-------------------
|
||||
|
||||
Q: To which mailing list do I need to submit my BPF patches?
|
||||
|
||||
A: Please submit your BPF patches to the netdev kernel mailing list:
|
||||
|
||||
netdev@vger.kernel.org
|
||||
|
||||
Historically, BPF came out of networking and has always been maintained
|
||||
by the kernel networking community. Although these days BPF touches
|
||||
many other subsystems as well, the patches are still routed mainly
|
||||
through the networking community.
|
||||
|
||||
In case your patch has changes in various different subsystems (e.g.
|
||||
tracing, security, etc), make sure to Cc the related kernel mailing
|
||||
lists and maintainers from there as well, so they are able to review
|
||||
the changes and provide their Acked-by's to the patches.
|
||||
|
||||
Q: Where can I find patches currently under discussion for BPF subsystem?
|
||||
|
||||
A: All patches that are Cc'ed to netdev are queued for review under netdev
|
||||
patchwork project:
|
||||
|
||||
http://patchwork.ozlabs.org/project/netdev/list/
|
||||
|
||||
Those patches which target BPF, are assigned to a 'bpf' delegate for
|
||||
further processing from BPF maintainers. The current queue with
|
||||
patches under review can be found at:
|
||||
|
||||
https://patchwork.ozlabs.org/project/netdev/list/?delegate=77147
|
||||
|
||||
Once the patches have been reviewed by the BPF community as a whole
|
||||
and approved by the BPF maintainers, their status in patchwork will be
|
||||
changed to 'Accepted' and the submitter will be notified by mail. This
|
||||
means that the patches look good from a BPF perspective and have been
|
||||
applied to one of the two BPF kernel trees.
|
||||
|
||||
In case feedback from the community requires a respin of the patches,
|
||||
their status in patchwork will be set to 'Changes Requested', and purged
|
||||
from the current review queue. Likewise for cases where patches would
|
||||
get rejected or are not applicable to the BPF trees (but assigned to
|
||||
the 'bpf' delegate).
|
||||
|
||||
Q: How do the changes make their way into Linux?
|
||||
|
||||
A: There are two BPF kernel trees (git repositories). Once patches have
|
||||
been accepted by the BPF maintainers, they will be applied to one
|
||||
of the two BPF trees:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/
|
||||
|
||||
The bpf tree itself is for fixes only, whereas bpf-next for features,
|
||||
cleanups or other kind of improvements ("next-like" content). This is
|
||||
analogous to net and net-next trees for networking. Both bpf and
|
||||
bpf-next will only have a master branch in order to simplify against
|
||||
which branch patches should get rebased to.
|
||||
|
||||
Accumulated BPF patches in the bpf tree will regularly get pulled
|
||||
into the net kernel tree. Likewise, accumulated BPF patches accepted
|
||||
into the bpf-next tree will make their way into net-next tree. net and
|
||||
net-next are both run by David S. Miller. From there, they will go
|
||||
into the kernel mainline tree run by Linus Torvalds. To read up on the
|
||||
process of net and net-next being merged into the mainline tree, see
|
||||
the netdev FAQ under:
|
||||
|
||||
Documentation/networking/netdev-FAQ.txt
|
||||
|
||||
Occasionally, to prevent merge conflicts, we might send pull requests
|
||||
to other trees (e.g. tracing) with a small subset of the patches, but
|
||||
net and net-next are always the main trees targeted for integration.
|
||||
|
||||
The pull requests will contain a high-level summary of the accumulated
|
||||
patches and can be searched on netdev kernel mailing list through the
|
||||
following subject lines (yyyy-mm-dd is the date of the pull request):
|
||||
|
||||
pull-request: bpf yyyy-mm-dd
|
||||
pull-request: bpf-next yyyy-mm-dd
|
||||
|
||||
Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be
|
||||
applied to?
|
||||
|
||||
A: The process is the very same as described in the netdev FAQ, so
|
||||
please read up on it. The subject line must indicate whether the
|
||||
patch is a fix or rather "next-like" content in order to let the
|
||||
maintainers know whether it is targeted at bpf or bpf-next.
|
||||
|
||||
For fixes eventually landing in bpf -> net tree, the subject must
|
||||
look like:
|
||||
|
||||
git format-patch --subject-prefix='PATCH bpf' start..finish
|
||||
|
||||
For features/improvements/etc that should eventually land in
|
||||
bpf-next -> net-next, the subject must look like:
|
||||
|
||||
git format-patch --subject-prefix='PATCH bpf-next' start..finish
|
||||
|
||||
If unsure whether the patch or patch series should go into bpf
|
||||
or net directly, or bpf-next or net-next directly, it is not a
|
||||
problem either if the subject line says net or net-next as target.
|
||||
It is eventually up to the maintainers to do the delegation of
|
||||
the patches.
|
||||
|
||||
If it is clear that patches should go into bpf or bpf-next tree,
|
||||
please make sure to rebase the patches against those trees in
|
||||
order to reduce potential conflicts.
|
||||
|
||||
In case the patch or patch series has to be reworked and sent out
|
||||
again in a second or later revision, it is also required to add a
|
||||
version number (v2, v3, ...) into the subject prefix:
|
||||
|
||||
git format-patch --subject-prefix='PATCH net-next v2' start..finish
|
||||
|
||||
When changes have been requested to the patch series, always send the
|
||||
whole patch series again with the feedback incorporated (never send
|
||||
individual diffs on top of the old series).
|
||||
|
||||
Q: What does it mean when a patch gets applied to bpf or bpf-next tree?
|
||||
|
||||
A: It means that the patch looks good for mainline inclusion from
|
||||
a BPF point of view.
|
||||
|
||||
Be aware that this is not a final verdict that the patch will
|
||||
automatically get accepted into net or net-next trees eventually:
|
||||
|
||||
On the netdev kernel mailing list reviews can come in at any point
|
||||
in time. If discussions around a patch conclude that they cannot
|
||||
get included as-is, we will either apply a follow-up fix or drop
|
||||
them from the trees entirely. Therefore, we also reserve to rebase
|
||||
the trees when deemed necessary. After all, the purpose of the tree
|
||||
is to i) accumulate and stage BPF patches for integration into trees
|
||||
like net and net-next, and ii) run extensive BPF test suite and
|
||||
workloads on the patches before they make their way any further.
|
||||
|
||||
Once the BPF pull request was accepted by David S. Miller, then
|
||||
the patches end up in net or net-next tree, respectively, and
|
||||
make their way from there further into mainline. Again, see the
|
||||
netdev FAQ for additional information e.g. on how often they are
|
||||
merged to mainline.
|
||||
|
||||
Q: How long do I need to wait for feedback on my BPF patches?
|
||||
|
||||
A: We try to keep the latency low. The usual time to feedback will
|
||||
be around 2 or 3 business days. It may vary depending on the
|
||||
complexity of changes and current patch load.
|
||||
|
||||
Q: How often do you send pull requests to major kernel trees like
|
||||
net or net-next?
|
||||
|
||||
A: Pull requests will be sent out rather often in order to not
|
||||
accumulate too many patches in bpf or bpf-next.
|
||||
|
||||
As a rule of thumb, expect pull requests for each tree regularly
|
||||
at the end of the week. In some cases pull requests could additionally
|
||||
come also in the middle of the week depending on the current patch
|
||||
load or urgency.
|
||||
|
||||
Q: Are patches applied to bpf-next when the merge window is open?
|
||||
|
||||
A: For the time when the merge window is open, bpf-next will not be
|
||||
processed. This is roughly analogous to net-next patch processing,
|
||||
so feel free to read up on the netdev FAQ about further details.
|
||||
|
||||
During those two weeks of merge window, we might ask you to resend
|
||||
your patch series once bpf-next is open again. Once Linus released
|
||||
a v*-rc1 after the merge window, we continue processing of bpf-next.
|
||||
|
||||
For non-subscribers to kernel mailing lists, there is also a status
|
||||
page run by David S. Miller on net-next that provides guidance:
|
||||
|
||||
http://vger.kernel.org/~davem/net-next.html
|
||||
|
||||
Q: I made a BPF verifier change, do I need to add test cases for
|
||||
BPF kernel selftests?
|
||||
|
||||
A: If the patch has changes to the behavior of the verifier, then yes,
|
||||
it is absolutely necessary to add test cases to the BPF kernel
|
||||
selftests suite. If they are not present and we think they are
|
||||
needed, then we might ask for them before accepting any changes.
|
||||
|
||||
In particular, test_verifier.c is tracking a high number of BPF test
|
||||
cases, including a lot of corner cases that LLVM BPF back end may
|
||||
generate out of the restricted C code. Thus, adding test cases is
|
||||
absolutely crucial to make sure future changes do not accidentally
|
||||
affect prior use-cases. Thus, treat those test cases as: verifier
|
||||
behavior that is not tracked in test_verifier.c could potentially
|
||||
be subject to change.
|
||||
|
||||
Q: When should I add code to samples/bpf/ and when to BPF kernel
|
||||
selftests?
|
||||
|
||||
A: In general, we prefer additions to BPF kernel selftests rather than
|
||||
samples/bpf/. The rationale is very simple: kernel selftests are
|
||||
regularly run by various bots to test for kernel regressions.
|
||||
|
||||
The more test cases we add to BPF selftests, the better the coverage
|
||||
and the less likely it is that those could accidentally break. It is
|
||||
not that BPF kernel selftests cannot demo how a specific feature can
|
||||
be used.
|
||||
|
||||
That said, samples/bpf/ may be a good place for people to get started,
|
||||
so it might be advisable that simple demos of features could go into
|
||||
samples/bpf/, but advanced functional and corner-case testing rather
|
||||
into kernel selftests.
|
||||
|
||||
If your sample looks like a test case, then go for BPF kernel selftests
|
||||
instead!
|
||||
|
||||
Q: When should I add code to the bpftool?
|
||||
|
||||
A: The main purpose of bpftool (under tools/bpf/bpftool/) is to provide
|
||||
a central user space tool for debugging and introspection of BPF programs
|
||||
and maps that are active in the kernel. If UAPI changes related to BPF
|
||||
enable for dumping additional information of programs or maps, then
|
||||
bpftool should be extended as well to support dumping them.
|
||||
|
||||
Q: When should I add code to iproute2's BPF loader?
|
||||
|
||||
A: For UAPI changes related to the XDP or tc layer (e.g. cls_bpf), the
|
||||
convention is that those control-path related changes are added to
|
||||
iproute2's BPF loader as well from user space side. This is not only
|
||||
useful to have UAPI changes properly designed to be usable, but also
|
||||
to make those changes available to a wider user base of major
|
||||
downstream distributions.
|
||||
|
||||
Q: Do you accept patches as well for iproute2's BPF loader?
|
||||
|
||||
A: Patches for the iproute2's BPF loader have to be sent to:
|
||||
|
||||
netdev@vger.kernel.org
|
||||
|
||||
While those patches are not processed by the BPF kernel maintainers,
|
||||
please keep them in Cc as well, so they can be reviewed.
|
||||
|
||||
The official git repository for iproute2 is run by Stephen Hemminger
|
||||
and can be found at:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/
|
||||
|
||||
The patches need to have a subject prefix of '[PATCH iproute2 master]'
|
||||
or '[PATCH iproute2 net-next]'. 'master' or 'net-next' describes the
|
||||
target branch where the patch should be applied to. Meaning, if kernel
|
||||
changes went into the net-next kernel tree, then the related iproute2
|
||||
changes need to go into the iproute2 net-next branch, otherwise they
|
||||
can be targeted at master branch. The iproute2 net-next branch will get
|
||||
merged into the master branch after the current iproute2 version from
|
||||
master has been released.
|
||||
|
||||
Like BPF, the patches end up in patchwork under the netdev project and
|
||||
are delegated to 'shemminger' for further processing:
|
||||
|
||||
http://patchwork.ozlabs.org/project/netdev/list/?delegate=389
|
||||
|
||||
Q: What is the minimum requirement before I submit my BPF patches?
|
||||
|
||||
A: When submitting patches, always take the time and properly test your
|
||||
patches *prior* to submission. Never rush them! If maintainers find
|
||||
that your patches have not been properly tested, it is a good way to
|
||||
get them grumpy. Testing patch submissions is a hard requirement!
|
||||
|
||||
Note, fixes that go to bpf tree *must* have a Fixes: tag included. The
|
||||
same applies to fixes that target bpf-next, where the affected commit
|
||||
is in net-next (or in some cases bpf-next). The Fixes: tag is crucial
|
||||
in order to identify follow-up commits and tremendously helps for people
|
||||
having to do backporting, so it is a must have!
|
||||
|
||||
We also don't accept patches with an empty commit message. Take your
|
||||
time and properly write up a high quality commit message, it is
|
||||
essential!
|
||||
|
||||
Think about it this way: other developers looking at your code a month
|
||||
from now need to understand *why* a certain change has been done that
|
||||
way, and whether there have been flaws in the analysis or assumptions
|
||||
that the original author did. Thus providing a proper rationale and
|
||||
describing the use-case for the changes is a must.
|
||||
|
||||
Patch submissions with >1 patch must have a cover letter which includes
|
||||
a high level description of the series. This high level summary will
|
||||
then be placed into the merge commit by the BPF maintainers such that
|
||||
it is also accessible from the git log for future reference.
|
||||
|
||||
Q: What do I need to consider when adding a new instruction or feature
|
||||
that would require BPF JIT and/or LLVM integration as well?
|
||||
|
||||
A: We try hard to keep all BPF JITs up to date such that the same user
|
||||
experience can be guaranteed when running BPF programs on different
|
||||
architectures without having the program punt to the less efficient
|
||||
interpreter in case the in-kernel BPF JIT is enabled.
|
||||
|
||||
If you are unable to implement or test the required JIT changes for
|
||||
certain architectures, please work together with the related BPF JIT
|
||||
developers in order to get the feature implemented in a timely manner.
|
||||
Please refer to the git log (arch/*/net/) to locate the necessary
|
||||
people for helping out.
|
||||
|
||||
Also always make sure to add BPF test cases (e.g. test_bpf.c and
|
||||
test_verifier.c) for new instructions, so that they can receive
|
||||
broad test coverage and help run-time testing the various BPF JITs.
|
||||
|
||||
In case of new BPF instructions, once the changes have been accepted
|
||||
into the Linux kernel, please implement support into LLVM's BPF back
|
||||
end. See LLVM section below for further information.
|
||||
|
||||
Stable submission:
|
||||
------------------
|
||||
|
||||
Q: I need a specific BPF commit in stable kernels. What should I do?
|
||||
|
||||
A: In case you need a specific fix in stable kernels, first check whether
|
||||
the commit has already been applied in the related linux-*.y branches:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/
|
||||
|
||||
If not the case, then drop an email to the BPF maintainers with the
|
||||
netdev kernel mailing list in Cc and ask for the fix to be queued up:
|
||||
|
||||
netdev@vger.kernel.org
|
||||
|
||||
The process in general is the same as on netdev itself, see also the
|
||||
netdev FAQ document.
|
||||
|
||||
Q: Do you also backport to kernels not currently maintained as stable?
|
||||
|
||||
A: No. If you need a specific BPF commit in kernels that are currently not
|
||||
maintained by the stable maintainers, then you are on your own.
|
||||
|
||||
The current stable and longterm stable kernels are all listed here:
|
||||
|
||||
https://www.kernel.org/
|
||||
|
||||
Q: The BPF patch I am about to submit needs to go to stable as well. What
|
||||
should I do?
|
||||
|
||||
A: The same rules apply as with netdev patch submissions in general, see
|
||||
netdev FAQ under:
|
||||
|
||||
Documentation/networking/netdev-FAQ.txt
|
||||
|
||||
Never add "Cc: stable@vger.kernel.org" to the patch description, but
|
||||
ask the BPF maintainers to queue the patches instead. This can be done
|
||||
with a note, for example, under the "---" part of the patch which does
|
||||
not go into the git log. Alternatively, this can be done as a simple
|
||||
request by mail instead.
|
||||
|
||||
Q: Where do I find currently queued BPF patches that will be submitted
|
||||
to stable?
|
||||
|
||||
A: Once patches that fix critical bugs got applied into the bpf tree, they
|
||||
are queued up for stable submission under:
|
||||
|
||||
http://patchwork.ozlabs.org/bundle/bpf/stable/?state=*
|
||||
|
||||
They will be on hold there at minimum until the related commit made its
|
||||
way into the mainline kernel tree.
|
||||
|
||||
After having been under broader exposure, the queued patches will be
|
||||
submitted by the BPF maintainers to the stable maintainers.
|
||||
|
||||
Testing patches:
|
||||
----------------
|
||||
|
||||
Q: Which BPF kernel selftests version should I run my kernel against?
|
||||
|
||||
A: If you run a kernel xyz, then always run the BPF kernel selftests from
|
||||
that kernel xyz as well. Do not expect that the BPF selftest from the
|
||||
latest mainline tree will pass all the time.
|
||||
|
||||
In particular, test_bpf.c and test_verifier.c have a large number of
|
||||
test cases and are constantly updated with new BPF test sequences, or
|
||||
existing ones are adapted to verifier changes e.g. due to verifier
|
||||
becoming smarter and being able to better track certain things.
|
||||
|
||||
LLVM:
|
||||
-----
|
||||
|
||||
Q: Where do I find LLVM with BPF support?
|
||||
|
||||
A: The BPF back end for LLVM is upstream in LLVM since version 3.7.1.
|
||||
|
||||
All major distributions these days ship LLVM with BPF back end enabled,
|
||||
so for the majority of use-cases it is not required to compile LLVM by
|
||||
hand anymore, just install the distribution provided package.
|
||||
|
||||
LLVM's static compiler lists the supported targets through 'llc --version',
|
||||
make sure BPF targets are listed. Example:
|
||||
|
||||
$ llc --version
|
||||
LLVM (http://llvm.org/):
|
||||
LLVM version 6.0.0svn
|
||||
Optimized build.
|
||||
Default target: x86_64-unknown-linux-gnu
|
||||
Host CPU: skylake
|
||||
|
||||
Registered Targets:
|
||||
bpf - BPF (host endian)
|
||||
bpfeb - BPF (big endian)
|
||||
bpfel - BPF (little endian)
|
||||
x86 - 32-bit X86: Pentium-Pro and above
|
||||
x86-64 - 64-bit X86: EM64T and AMD64
|
||||
|
||||
For developers in order to utilize the latest features added to LLVM's
|
||||
BPF back end, it is advisable to run the latest LLVM releases. Support
|
||||
for new BPF kernel features such as additions to the BPF instruction
|
||||
set are often developed together.
|
||||
|
||||
All LLVM releases can be found at: http://releases.llvm.org/
|
||||
|
||||
Q: Got it, so how do I build LLVM manually anyway?
|
||||
|
||||
A: You need cmake and gcc-c++ as build requisites for LLVM. Once you have
|
||||
that set up, proceed with building the latest LLVM and clang version
|
||||
from the git repositories:
|
||||
|
||||
$ git clone http://llvm.org/git/llvm.git
|
||||
$ cd llvm/tools
|
||||
$ git clone --depth 1 http://llvm.org/git/clang.git
|
||||
$ cd ..; mkdir build; cd build
|
||||
$ cmake .. -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
|
||||
-DBUILD_SHARED_LIBS=OFF \
|
||||
-DCMAKE_BUILD_TYPE=Release \
|
||||
-DLLVM_BUILD_RUNTIME=OFF
|
||||
$ make -j $(getconf _NPROCESSORS_ONLN)
|
||||
|
||||
The built binaries can then be found in the build/bin/ directory, where
|
||||
you can point the PATH variable to.
|
||||
|
||||
Q: Should I notify BPF kernel maintainers about issues in LLVM's BPF code
|
||||
generation back end or about LLVM generated code that the verifier
|
||||
refuses to accept?
|
||||
|
||||
A: Yes, please do! LLVM's BPF back end is a key piece of the whole BPF
|
||||
infrastructure and it ties deeply into verification of programs from the
|
||||
kernel side. Therefore, any issues on either side need to be investigated
|
||||
and fixed whenever necessary.
|
||||
|
||||
Therefore, please make sure to bring them up at netdev kernel mailing
|
||||
list and Cc BPF maintainers for LLVM and kernel bits:
|
||||
|
||||
Yonghong Song <yhs@fb.com>
|
||||
Alexei Starovoitov <ast@kernel.org>
|
||||
Daniel Borkmann <daniel@iogearbox.net>
|
||||
|
||||
LLVM also has an issue tracker where BPF related bugs can be found:
|
||||
|
||||
https://bugs.llvm.org/buglist.cgi?quicksearch=bpf
|
||||
|
||||
However, it is better to reach out through mailing lists with having
|
||||
maintainers in Cc.
|
||||
|
||||
Q: I have added a new BPF instruction to the kernel, how can I integrate
|
||||
it into LLVM?
|
||||
|
||||
A: LLVM has a -mcpu selector for the BPF back end in order to allow the
|
||||
selection of BPF instruction set extensions. By default the 'generic'
|
||||
processor target is used, which is the base instruction set (v1) of BPF.
|
||||
|
||||
LLVM has an option to select -mcpu=probe where it will probe the host
|
||||
kernel for supported BPF instruction set extensions and selects the
|
||||
optimal set automatically.
|
||||
|
||||
For cross-compilation, a specific version can be select manually as well.
|
||||
|
||||
$ llc -march bpf -mcpu=help
|
||||
Available CPUs for this target:
|
||||
|
||||
generic - Select the generic processor.
|
||||
probe - Select the probe processor.
|
||||
v1 - Select the v1 processor.
|
||||
v2 - Select the v2 processor.
|
||||
[...]
|
||||
|
||||
Newly added BPF instructions to the Linux kernel need to follow the same
|
||||
scheme, bump the instruction set version and implement probing for the
|
||||
extensions such that -mcpu=probe users can benefit from the optimization
|
||||
transparently when upgrading their kernels.
|
||||
|
||||
If you are unable to implement support for the newly added BPF instruction
|
||||
please reach out to BPF developers for help.
|
||||
|
||||
By the way, the BPF kernel selftests run with -mcpu=probe for better
|
||||
test coverage.
|
||||
|
||||
Q: In some cases clang flag "-target bpf" is used but in other cases the
|
||||
default clang target, which matches the underlying architecture, is used.
|
||||
What is the difference and when I should use which?
|
||||
|
||||
A: Although LLVM IR generation and optimization try to stay architecture
|
||||
independent, "-target <arch>" still has some impact on generated code:
|
||||
|
||||
- BPF program may recursively include header file(s) with file scope
|
||||
inline assembly codes. The default target can handle this well,
|
||||
while bpf target may fail if bpf backend assembler does not
|
||||
understand these assembly codes, which is true in most cases.
|
||||
|
||||
- When compiled without -g, additional elf sections, e.g.,
|
||||
.eh_frame and .rela.eh_frame, may be present in the object file
|
||||
with default target, but not with bpf target.
|
||||
|
||||
- The default target may turn a C switch statement into a switch table
|
||||
lookup and jump operation. Since the switch table is placed
|
||||
in the global readonly section, the bpf program will fail to load.
|
||||
The bpf target does not support switch table optimization.
|
||||
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
|
||||
pulls in some header files containing file scope host assembly codes.
|
||||
- You can add "-fno-jump-tables" to work around the switch table issue.
|
||||
|
||||
Otherwise, you can use bpf target.
|
||||
|
||||
Happy BPF hacking!
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
---------
|
||||
|
||||
|
|
|
@ -264,7 +264,10 @@ i) Constructor
|
|||
data device, but just remove the mapping.
|
||||
|
||||
read_only: Don't allow any changes to be made to the pool
|
||||
metadata.
|
||||
metadata. This mode is only available after the
|
||||
thin-pool has been created and first used in full
|
||||
read/write mode. It cannot be specified on initial
|
||||
thin-pool creation.
|
||||
|
||||
error_if_no_space: Error IOs, instead of queueing, if no space.
|
||||
|
||||
|
|
|
@ -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 {
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
|
@ -30,7 +30,6 @@ compatible:
|
|||
Optional properties:
|
||||
- dma-coherent : Present if dma operations are coherent
|
||||
- clocks : a list of phandle + clock specifier pairs
|
||||
- resets : a list of phandle + reset specifier pairs
|
||||
- target-supply : regulator for SATA target power
|
||||
- phys : reference to the SATA PHY node
|
||||
- phy-names : must be "sata-phy"
|
||||
|
|
36
Documentation/devicetree/bindings/clock/imx6sll-clock.txt
Normal file
36
Documentation/devicetree/bindings/clock/imx6sll-clock.txt
Normal file
|
@ -0,0 +1,36 @@
|
|||
* Clock bindings for Freescale i.MX6 SLL
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx6sll-ccm"
|
||||
- reg: Address and length of the register set
|
||||
- #clock-cells: Should be <1>
|
||||
- clocks: list of clock specifiers, must contain an entry for each required
|
||||
entry in clock-names
|
||||
- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6sll-clock.h
|
||||
for the full list of i.MX6 SLL clock IDs.
|
||||
|
||||
Examples:
|
||||
|
||||
#include <dt-bindings/clock/imx6sll-clock.h>
|
||||
|
||||
clks: clock-controller@20c4000 {
|
||||
compatible = "fsl,imx6sll-ccm";
|
||||
reg = <0x020c4000 0x4000>;
|
||||
interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
|
||||
#clock-cells = <1>;
|
||||
clocks = <&ckil>, <&osc>, <&ipp_di0>, <&ipp_di1>;
|
||||
clock-names = "ckil", "osc", "ipp_di0", "ipp_di1";
|
||||
};
|
||||
|
||||
uart1: serial@2020000 {
|
||||
compatible = "fsl,imx6sl-uart", "fsl,imx6q-uart", "fsl,imx21-uart";
|
||||
reg = <0x02020000 0x4000>;
|
||||
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&clks IMX6SLL_CLK_UART1_IPG>,
|
||||
<&clks IMX6SLL_CLK_UART1_SERIAL>;
|
||||
clock-names = "ipg", "per";
|
||||
};
|
20
Documentation/devicetree/bindings/clock/intc_stratix10.txt
Normal file
20
Documentation/devicetree/bindings/clock/intc_stratix10.txt
Normal file
|
@ -0,0 +1,20 @@
|
|||
Device Tree Clock bindings for Intel's SoCFPGA Stratix10 platform
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be
|
||||
"intel,stratix10-clkmgr"
|
||||
|
||||
- reg : shall be the control register offset from CLOCK_MANAGER's base for the clock.
|
||||
|
||||
- #clock-cells : from common clock binding, shall be set to 1.
|
||||
|
||||
Example:
|
||||
clkmgr: clock-controller@ffd10000 {
|
||||
compatible = "intel,stratix10-clkmgr";
|
||||
reg = <0xffd10000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
|
@ -22,7 +22,9 @@ Required Properties:
|
|||
- "renesas,r8a7794-cpg-mssr" for the r8a7794 SoC (R-Car E2)
|
||||
- "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3)
|
||||
- "renesas,r8a7796-cpg-mssr" for the r8a7796 SoC (R-Car M3-W)
|
||||
- "renesas,r8a77965-cpg-mssr" for the r8a77965 SoC (R-Car M3-N)
|
||||
- "renesas,r8a77970-cpg-mssr" for the r8a77970 SoC (R-Car V3M)
|
||||
- "renesas,r8a77980-cpg-mssr" for the r8a77980 SoC (R-Car V3H)
|
||||
- "renesas,r8a77995-cpg-mssr" for the r8a77995 SoC (R-Car D3)
|
||||
|
||||
- reg: Base address and length of the memory resource used by the CPG/MSSR
|
||||
|
@ -32,8 +34,8 @@ Required Properties:
|
|||
clock-names
|
||||
- clock-names: List of external parent clock names. Valid names are:
|
||||
- "extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7792, r8a7793, r8a7794,
|
||||
r8a7795, r8a7796, r8a77970, r8a77995)
|
||||
- "extalr" (r8a7795, r8a7796, r8a77970)
|
||||
r8a7795, r8a7796, r8a77965, r8a77970, r8a77980, r8a77995)
|
||||
- "extalr" (r8a7795, r8a7796, r8a77965, r8a77970, r8a77980)
|
||||
- "usb_extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7793, r8a7794)
|
||||
|
||||
- #clock-cells: Must be 2
|
||||
|
|
|
@ -32,6 +32,7 @@ clock-output-names:
|
|||
- "clkin_i2s" - external I2S clock - optional,
|
||||
- "gmac_clkin" - external GMAC clock - optional
|
||||
- "phy_50m_out" - output clock of the pll in the mac phy
|
||||
- "hdmi_phy" - output clock of the hdmi phy pll - optional
|
||||
|
||||
Example: Clock controller node:
|
||||
|
||||
|
|
25
Documentation/devicetree/bindings/clock/silabs,si544.txt
Normal file
25
Documentation/devicetree/bindings/clock/silabs,si544.txt
Normal file
|
@ -0,0 +1,25 @@
|
|||
Binding for Silicon Labs 544 programmable I2C clock generator.
|
||||
|
||||
Reference
|
||||
This binding uses the common clock binding[1]. Details about the device can be
|
||||
found in the datasheet[2].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
[2] Si544 datasheet
|
||||
https://www.silabs.com/documents/public/data-sheets/si544-datasheet.pdf
|
||||
|
||||
Required properties:
|
||||
- compatible: One of "silabs,si514a", "silabs,si514b" "silabs,si514c" according
|
||||
to the speed grade of the chip.
|
||||
- reg: I2C device address.
|
||||
- #clock-cells: From common clock bindings: Shall be 0.
|
||||
|
||||
Optional properties:
|
||||
- clock-output-names: From common clock bindings. Recommended to be "si544".
|
||||
|
||||
Example:
|
||||
si544: clock-controller@55 {
|
||||
reg = <0x55>;
|
||||
#clock-cells = <0>;
|
||||
compatible = "silabs,si544b";
|
||||
};
|
60
Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.txt
Normal file
60
Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.txt
Normal file
|
@ -0,0 +1,60 @@
|
|||
STMicroelectronics STM32 Peripheral Reset Clock Controller
|
||||
==========================================================
|
||||
|
||||
The RCC IP is both a reset and a clock controller.
|
||||
|
||||
RCC makes also power management (resume/supend and wakeup interrupt).
|
||||
|
||||
Please also refer to reset.txt for common reset controller binding usage.
|
||||
|
||||
Please also refer to clock-bindings.txt for common clock controller
|
||||
binding usage.
|
||||
|
||||
|
||||
Required properties:
|
||||
- compatible: "st,stm32mp1-rcc", "syscon"
|
||||
- reg: should be register base and length as documented in the datasheet
|
||||
- #clock-cells: 1, device nodes should specify the clock in their
|
||||
"clocks" property, containing a phandle to the clock device node,
|
||||
an index specifying the clock to use.
|
||||
- #reset-cells: Shall be 1
|
||||
- interrupts: Should contain a general interrupt line and a interrupt line
|
||||
to the wake-up of processor (CSTOP).
|
||||
|
||||
Example:
|
||||
rcc: rcc@50000000 {
|
||||
compatible = "st,stm32mp1-rcc", "syscon";
|
||||
reg = <0x50000000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>,
|
||||
<GIC_SPI 145 IRQ_TYPE_NONE>;
|
||||
};
|
||||
|
||||
Specifying clocks
|
||||
=================
|
||||
|
||||
All available clocks are defined as preprocessor macros in
|
||||
dt-bindings/clock/stm32mp1-clks.h header and can be used in device
|
||||
tree sources.
|
||||
|
||||
Specifying softreset control of devices
|
||||
=======================================
|
||||
|
||||
Device nodes should specify the reset channel required in their "resets"
|
||||
property, containing a phandle to the reset device node and an index specifying
|
||||
which channel to use.
|
||||
The index is the bit number within the RCC registers bank, starting from RCC
|
||||
base address.
|
||||
It is calculated as: index = register_offset / 4 * 32 + bit_offset.
|
||||
Where bit_offset is the bit offset within the register.
|
||||
|
||||
For example on STM32MP1, for LTDC reset:
|
||||
ltdc = APB4_RSTSETR_offset / 4 * 32 + LTDC_bit_offset
|
||||
= 0x180 / 4 * 32 + 0 = 3072
|
||||
|
||||
The list of valid indices for STM32MP1 is available in:
|
||||
include/dt-bindings/reset-controller/stm32mp1-resets.h
|
||||
|
||||
This file implements defines like:
|
||||
#define LTDC_R 3072
|
|
@ -20,6 +20,7 @@ Required properties :
|
|||
- "allwinner,sun50i-a64-ccu"
|
||||
- "allwinner,sun50i-a64-r-ccu"
|
||||
- "allwinner,sun50i-h5-ccu"
|
||||
- "allwinner,sun50i-h6-ccu"
|
||||
- "nextthing,gr8-ccu"
|
||||
|
||||
- reg: Must contain the registers base address and length
|
||||
|
@ -31,6 +32,9 @@ Required properties :
|
|||
- #clock-cells : must contain 1
|
||||
- #reset-cells : must contain 1
|
||||
|
||||
For the main CCU on H6, one more clock is needed:
|
||||
- "iosc": the SoC's internal frequency oscillator
|
||||
|
||||
For the PRCM CCUs on A83T/H3/A64, two more clocks are needed:
|
||||
- "pll-periph": the SoC's peripheral PLL from the main CCU
|
||||
- "iosc": the SoC's internal frequency oscillator
|
||||
|
|
|
@ -0,0 +1,93 @@
|
|||
Binding for TI DA8XX/OMAP-L13X/AM17XX/AM18XX CFGCHIP clocks
|
||||
|
||||
TI DA8XX/OMAP-L13X/AM17XX/AM18XX SoCs contain a general purpose set of
|
||||
registers call CFGCHIPn. Some of these registers function as clock
|
||||
gates. This document describes the bindings for those clocks.
|
||||
|
||||
All of the clock nodes described below must be child nodes of a CFGCHIP node
|
||||
(compatible = "ti,da830-cfgchip").
|
||||
|
||||
USB PHY clocks
|
||||
--------------
|
||||
Required properties:
|
||||
- compatible: shall be "ti,da830-usb-phy-clocks".
|
||||
- #clock-cells: from common clock binding; shall be set to 1.
|
||||
- clocks: phandles to the parent clocks corresponding to clock-names
|
||||
- clock-names: shall be "fck", "usb_refclkin", "auxclk"
|
||||
|
||||
This node provides two clocks. The clock at index 0 is the USB 2.0 PHY 48MHz
|
||||
clock and the clock at index 1 is the USB 1.1 PHY 48MHz clock.
|
||||
|
||||
eHRPWM Time Base Clock (TBCLK)
|
||||
------------------------------
|
||||
Required properties:
|
||||
- compatible: shall be "ti,da830-tbclksync".
|
||||
- #clock-cells: from common clock binding; shall be set to 0.
|
||||
- clocks: phandle to the parent clock
|
||||
- clock-names: shall be "fck"
|
||||
|
||||
PLL DIV4.5 divider
|
||||
------------------
|
||||
Required properties:
|
||||
- compatible: shall be "ti,da830-div4p5ena".
|
||||
- #clock-cells: from common clock binding; shall be set to 0.
|
||||
- clocks: phandle to the parent clock
|
||||
- clock-names: shall be "pll0_pllout"
|
||||
|
||||
EMIFA clock source (ASYNC1)
|
||||
---------------------------
|
||||
Required properties:
|
||||
- compatible: shall be "ti,da850-async1-clksrc".
|
||||
- #clock-cells: from common clock binding; shall be set to 0.
|
||||
- clocks: phandles to the parent clocks corresponding to clock-names
|
||||
- clock-names: shall be "pll0_sysclk3", "div4.5"
|
||||
|
||||
ASYNC3 clock source
|
||||
-------------------
|
||||
Required properties:
|
||||
- compatible: shall be "ti,da850-async3-clksrc".
|
||||
- #clock-cells: from common clock binding; shall be set to 0.
|
||||
- clocks: phandles to the parent clocks corresponding to clock-names
|
||||
- clock-names: shall be "pll0_sysclk2", "pll1_sysclk2"
|
||||
|
||||
Examples:
|
||||
|
||||
cfgchip: syscon@1417c {
|
||||
compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
|
||||
reg = <0x1417c 0x14>;
|
||||
|
||||
usb_phy_clk: usb-phy-clocks {
|
||||
compatible = "ti,da830-usb-phy-clocks";
|
||||
#clock-cells = <1>;
|
||||
clocks = <&psc1 1>, <&usb_refclkin>, <&pll0_auxclk>;
|
||||
clock-names = "fck", "usb_refclkin", "auxclk";
|
||||
};
|
||||
ehrpwm_tbclk: ehrpwm_tbclk {
|
||||
compatible = "ti,da830-tbclksync";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&psc1 17>;
|
||||
clock-names = "fck";
|
||||
};
|
||||
div4p5_clk: div4.5 {
|
||||
compatible = "ti,da830-div4p5ena";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&pll0_pllout>;
|
||||
clock-names = "pll0_pllout";
|
||||
};
|
||||
async1_clk: async1 {
|
||||
compatible = "ti,da850-async1-clksrc";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&pll0_sysclk 3>, <&div4p5_clk>;
|
||||
clock-names = "pll0_sysclk3", "div4.5";
|
||||
};
|
||||
async3_clk: async3 {
|
||||
compatible = "ti,da850-async3-clksrc";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&pll0_sysclk 2>, <&pll1_sysclk 2>;
|
||||
clock-names = "pll0_sysclk2", "pll1_sysclk2";
|
||||
};
|
||||
};
|
||||
|
||||
Also see:
|
||||
- Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
96
Documentation/devicetree/bindings/clock/ti/davinci/pll.txt
Normal file
96
Documentation/devicetree/bindings/clock/ti/davinci/pll.txt
Normal file
|
@ -0,0 +1,96 @@
|
|||
Binding for TI DaVinci PLL Controllers
|
||||
|
||||
The PLL provides clocks to most of the components on the SoC. In addition
|
||||
to the PLL itself, this controller also contains bypasses, gates, dividers,
|
||||
an multiplexers for various clock signals.
|
||||
|
||||
Required properties:
|
||||
- compatible: shall be one of:
|
||||
- "ti,da850-pll0" for PLL0 on DA850/OMAP-L138/AM18XX
|
||||
- "ti,da850-pll1" for PLL1 on DA850/OMAP-L138/AM18XX
|
||||
- reg: physical base address and size of the controller's register area.
|
||||
- clocks: phandles corresponding to the clock names
|
||||
- clock-names: names of the clock sources - depends on compatible string
|
||||
- for "ti,da850-pll0", shall be "clksrc", "extclksrc"
|
||||
- for "ti,da850-pll1", shall be "clksrc"
|
||||
|
||||
Optional properties:
|
||||
- ti,clkmode-square-wave: Indicates that the the board is supplying a square
|
||||
wave input on the OSCIN pin instead of using a crystal oscillator.
|
||||
This property is only valid when compatible = "ti,da850-pll0".
|
||||
|
||||
|
||||
Optional child nodes:
|
||||
|
||||
pllout
|
||||
Describes the main PLL clock output (before POSTDIV). The node name must
|
||||
be "pllout".
|
||||
|
||||
Required properties:
|
||||
- #clock-cells: shall be 0
|
||||
|
||||
sysclk
|
||||
Describes the PLLDIVn divider clocks that provide the SYSCLKn clock
|
||||
domains. The node name must be "sysclk". Consumers of this node should
|
||||
use "n" in "SYSCLKn" as the index parameter for the clock cell.
|
||||
|
||||
Required properties:
|
||||
- #clock-cells: shall be 1
|
||||
|
||||
auxclk
|
||||
Describes the AUXCLK output of the PLL. The node name must be "auxclk".
|
||||
This child node is only valid when compatible = "ti,da850-pll0".
|
||||
|
||||
Required properties:
|
||||
- #clock-cells: shall be 0
|
||||
|
||||
obsclk
|
||||
Describes the OBSCLK output of the PLL. The node name must be "obsclk".
|
||||
|
||||
Required properties:
|
||||
- #clock-cells: shall be 0
|
||||
|
||||
|
||||
Examples:
|
||||
|
||||
pll0: clock-controller@11000 {
|
||||
compatible = "ti,da850-pll0";
|
||||
reg = <0x11000 0x1000>;
|
||||
clocks = <&ref_clk>, <&pll1_sysclk 3>;
|
||||
clock-names = "clksrc", "extclksrc";
|
||||
ti,clkmode-square-wave;
|
||||
|
||||
pll0_pllout: pllout {
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
|
||||
pll0_sysclk: sysclk {
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
pll0_auxclk: auxclk {
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
|
||||
pll0_obsclk: obsclk {
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
};
|
||||
|
||||
pll1: clock-controller@21a000 {
|
||||
compatible = "ti,da850-pll1";
|
||||
reg = <0x21a000 0x1000>;
|
||||
clocks = <&ref_clk>;
|
||||
clock-names = "clksrc";
|
||||
|
||||
pll0_sysclk: sysclk {
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
pll0_obsclk: obsclk {
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
};
|
||||
|
||||
Also see:
|
||||
- Documentation/devicetree/bindings/clock/clock-bindings.txt
|
71
Documentation/devicetree/bindings/clock/ti/davinci/psc.txt
Normal file
71
Documentation/devicetree/bindings/clock/ti/davinci/psc.txt
Normal file
|
@ -0,0 +1,71 @@
|
|||
Binding for TI DaVinci Power Sleep Controller (PSC)
|
||||
|
||||
The PSC provides power management, clock gating and reset functionality. It is
|
||||
primarily used for clocking.
|
||||
|
||||
Required properties:
|
||||
- compatible: shall be one of:
|
||||
- "ti,da850-psc0" for PSC0 on DA850/OMAP-L138/AM18XX
|
||||
- "ti,da850-psc1" for PSC1 on DA850/OMAP-L138/AM18XX
|
||||
- reg: physical base address and size of the controller's register area
|
||||
- #clock-cells: from common clock binding; shall be set to 1
|
||||
- #power-domain-cells: from generic power domain binding; shall be set to 1.
|
||||
- clocks: phandles to clocks corresponding to the clock-names property
|
||||
- clock-names: list of parent clock names - depends on compatible value
|
||||
- for "ti,da850-psc0", shall be "pll0_sysclk1", "pll0_sysclk2",
|
||||
"pll0_sysclk4", "pll0_sysclk6", "async1"
|
||||
- for "ti,da850-psc1", shall be "pll0_sysclk2", "pll0_sysclk4", "async3"
|
||||
|
||||
Optional properties:
|
||||
- #reset-cells: from reset binding; shall be set to 1 - only applicable when
|
||||
at least one local domain provides a local reset.
|
||||
|
||||
Consumers:
|
||||
|
||||
Clock, power domain and reset consumers shall use the local power domain
|
||||
module ID (LPSC) as the index corresponding to the clock cell. Refer to
|
||||
the device-specific datasheet to find these numbers. NB: Most local
|
||||
domains only provide a clock/power domain and not a reset.
|
||||
|
||||
Examples:
|
||||
|
||||
psc0: clock-controller@10000 {
|
||||
compatible = "ti,da850-psc0";
|
||||
reg = <0x10000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
clocks = <&pll0_sysclk 1>, <&pll0_sysclk 2>,
|
||||
<&pll0_sysclk 4>, <&pll0_sysclk 6>, <&async1_clk>;
|
||||
clock_names = "pll0_sysclk1", "pll0_sysclk2",
|
||||
"pll0_sysclk4", "pll0_sysclk6", "async1";
|
||||
};
|
||||
psc1: clock-controller@227000 {
|
||||
compatible = "ti,da850-psc1";
|
||||
reg = <0x227000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
clocks = <&pll0_sysclk 2>, <&pll0_sysclk 4>, <&async3_clk>;
|
||||
clock_names = "pll0_sysclk2", "pll0_sysclk4", "async3";
|
||||
};
|
||||
|
||||
/* consumer */
|
||||
dsp: dsp@11800000 {
|
||||
compatible = "ti,da850-dsp";
|
||||
reg = <0x11800000 0x40000>,
|
||||
<0x11e00000 0x8000>,
|
||||
<0x11f00000 0x8000>,
|
||||
<0x01c14044 0x4>,
|
||||
<0x01c14174 0x8>;
|
||||
reg-names = "l2sram", "l1pram", "l1dram", "host1cfg", "chipsig";
|
||||
interrupt-parent = <&intc>;
|
||||
interrupts = <28>;
|
||||
clocks = <&psc0 15>;
|
||||
power-domains = <&psc0 15>;
|
||||
resets = <&psc0 15>;
|
||||
};
|
||||
|
||||
Also see:
|
||||
- Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
- Documentation/devicetree/bindings/power/power_domain.txt
|
||||
- Documentation/devicetree/bindings/reset/reset.txt
|
|
@ -75,6 +75,9 @@ Optional properties:
|
|||
- ti,invert-autoidle-bit : autoidle is enabled by setting the bit to 0,
|
||||
see [2]
|
||||
- ti,set-rate-parent : clk_set_rate is propagated to parent
|
||||
- ti,latch-bit : latch the divider value to HW, only needed if the register
|
||||
access requires this. As an example dra76x DPLL_GMAC H14 divider implements
|
||||
such behavior.
|
||||
|
||||
Examples:
|
||||
dpll_usb_m2_ck: dpll_usb_m2_ck@4a008190 {
|
||||
|
|
|
@ -48,6 +48,9 @@ Optional properties:
|
|||
zero
|
||||
- ti,set-rate-parent : clk_set_rate is propagated to parent clock,
|
||||
not supported by the composite-mux-clock subtype
|
||||
- ti,latch-bit : latch the mux value to HW, only needed if the register
|
||||
access requires this. As an example, dra7x DPLL_GMAC H14 muxing
|
||||
implements such behavior.
|
||||
|
||||
Examples:
|
||||
|
||||
|
|
|
@ -38,7 +38,7 @@ Display Timings
|
|||
require specific display timings. The panel-timing subnode expresses those
|
||||
timings as specified in the timing subnode section of the display timing
|
||||
bindings defined in
|
||||
Documentation/devicetree/bindings/display/display-timing.txt.
|
||||
Documentation/devicetree/bindings/display/panel/display-timing.txt.
|
||||
|
||||
|
||||
Connectivity
|
||||
|
|
|
@ -26,6 +26,7 @@ Required Properties:
|
|||
- "renesas,dmac-r8a7794" (R-Car E2)
|
||||
- "renesas,dmac-r8a7795" (R-Car H3)
|
||||
- "renesas,dmac-r8a7796" (R-Car M3-W)
|
||||
- "renesas,dmac-r8a77965" (R-Car M3-N)
|
||||
- "renesas,dmac-r8a77970" (R-Car V3M)
|
||||
- "renesas,dmac-r8a77980" (R-Car V3H)
|
||||
|
||||
|
|
|
@ -4,6 +4,13 @@ Required properties:
|
|||
- compatible:
|
||||
atmel,maxtouch
|
||||
|
||||
The following compatibles have been used in various products but are
|
||||
deprecated:
|
||||
atmel,qt602240_ts
|
||||
atmel,atmel_mxt_ts
|
||||
atmel,atmel_mxt_tp
|
||||
atmel,mXT224
|
||||
|
||||
- reg: The I2C address of the device
|
||||
|
||||
- interrupts: The sink for the touchpad's IRQ output
|
||||
|
|
|
@ -5,7 +5,9 @@ Required properties:
|
|||
- compatible: Must contain one or more of the following:
|
||||
- "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
|
||||
- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
|
||||
- "renesas,r8a7796-canfd" for R8A7796 (R-Car M3) compatible controller.
|
||||
- "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller.
|
||||
- "renesas,r8a77970-canfd" for R8A77970 (R-Car V3M) compatible controller.
|
||||
- "renesas,r8a77980-canfd" for R8A77980 (R-Car V3H) compatible controller.
|
||||
|
||||
When compatible with the generic version, nodes must list the
|
||||
SoC-specific version corresponding to the platform first, followed by the
|
||||
|
|
|
@ -82,8 +82,6 @@ linked into one DSA cluster.
|
|||
|
||||
switch0: switch0@0 {
|
||||
compatible = "marvell,mv88e6085";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0>;
|
||||
|
||||
dsa,member = <0 0>;
|
||||
|
@ -135,8 +133,6 @@ linked into one DSA cluster.
|
|||
|
||||
switch1: switch1@0 {
|
||||
compatible = "marvell,mv88e6085";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0>;
|
||||
|
||||
dsa,member = <0 1>;
|
||||
|
@ -204,8 +200,6 @@ linked into one DSA cluster.
|
|||
|
||||
switch2: switch2@0 {
|
||||
compatible = "marvell,mv88e6085";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0>;
|
||||
|
||||
dsa,member = <0 2>;
|
||||
|
|
|
@ -7,6 +7,7 @@ Required properties:
|
|||
- compatible: must be one of the following string:
|
||||
"allwinner,sun8i-a83t-emac"
|
||||
"allwinner,sun8i-h3-emac"
|
||||
"allwinner,sun8i-r40-gmac"
|
||||
"allwinner,sun8i-v3s-emac"
|
||||
"allwinner,sun50i-a64-emac"
|
||||
- reg: address and length of the register for the device.
|
||||
|
@ -20,18 +21,18 @@ Required properties:
|
|||
- phy-handle: See ethernet.txt
|
||||
- #address-cells: shall be 1
|
||||
- #size-cells: shall be 0
|
||||
- syscon: A phandle to the syscon of the SoC with one of the following
|
||||
compatible string:
|
||||
- allwinner,sun8i-h3-system-controller
|
||||
- allwinner,sun8i-v3s-system-controller
|
||||
- allwinner,sun50i-a64-system-controller
|
||||
- allwinner,sun8i-a83t-system-controller
|
||||
- syscon: A phandle to the device containing the EMAC or GMAC clock register
|
||||
|
||||
Optional properties:
|
||||
- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
|
||||
- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
|
||||
Both delay properties need to be a multiple of 100. They control the delay for
|
||||
external PHY.
|
||||
- allwinner,tx-delay-ps: TX clock delay chain value in ps.
|
||||
Range is 0-700. Default is 0.
|
||||
Unavailable for allwinner,sun8i-r40-gmac
|
||||
- allwinner,rx-delay-ps: RX clock delay chain value in ps.
|
||||
Range is 0-3100. Default is 0.
|
||||
Range is 0-700 for allwinner,sun8i-r40-gmac
|
||||
Both delay properties need to be a multiple of 100. They control the
|
||||
clock delay for external RGMII PHY. They do not apply to the internal
|
||||
PHY or external non-RGMII PHYs.
|
||||
|
||||
Optional properties for the following compatibles:
|
||||
- "allwinner,sun8i-h3-emac",
|
||||
|
|
|
@ -21,9 +21,10 @@ Required properties:
|
|||
- main controller clock (for both armada-375-pp2 and armada-7k-pp2)
|
||||
- GOP clock (for both armada-375-pp2 and armada-7k-pp2)
|
||||
- MG clock (only for armada-7k-pp2)
|
||||
- MG Core clock (only for armada-7k-pp2)
|
||||
- AXI clock (only for armada-7k-pp2)
|
||||
- clock-names: names of used clocks, must be "pp_clk", "gop_clk", "mg_clk"
|
||||
and "axi_clk" (the 2 latter only for armada-7k-pp2).
|
||||
- clock-names: names of used clocks, must be "pp_clk", "gop_clk", "mg_clk",
|
||||
"mg_core_clk" and "axi_clk" (the 3 latter only for armada-7k-pp2).
|
||||
|
||||
The ethernet ports are represented by subnodes. At least one port is
|
||||
required.
|
||||
|
@ -80,8 +81,8 @@ cpm_ethernet: ethernet@0 {
|
|||
compatible = "marvell,armada-7k-pp22";
|
||||
reg = <0x0 0x100000>, <0x129000 0xb000>;
|
||||
clocks = <&cpm_syscon0 1 3>, <&cpm_syscon0 1 9>,
|
||||
<&cpm_syscon0 1 5>, <&cpm_syscon0 1 18>;
|
||||
clock-names = "pp_clk", "gop_clk", "gp_clk", "axi_clk";
|
||||
<&cpm_syscon0 1 5>, <&cpm_syscon0 1 6>, <&cpm_syscon0 1 18>;
|
||||
clock-names = "pp_clk", "gop_clk", "mg_clk", "mg_core_clk", "axi_clk";
|
||||
|
||||
eth0: eth0 {
|
||||
interrupts = <ICU_GRP_NSR 39 IRQ_TYPE_LEVEL_HIGH>,
|
||||
|
|
|
@ -11,6 +11,7 @@ Required properties on all platforms:
|
|||
- "amlogic,meson8b-dwmac"
|
||||
- "amlogic,meson8m2-dwmac"
|
||||
- "amlogic,meson-gxbb-dwmac"
|
||||
- "amlogic,meson-axg-dwmac"
|
||||
Additionally "snps,dwmac" and any applicable more
|
||||
detailed version number described in net/stmmac.txt
|
||||
should be used.
|
||||
|
|
|
@ -57,6 +57,13 @@ KSZ9031:
|
|||
- txd2-skew-ps : Skew control of TX data 2 pad
|
||||
- txd3-skew-ps : Skew control of TX data 3 pad
|
||||
|
||||
- micrel,force-master:
|
||||
Boolean, force phy to master mode. Only set this option if the phy
|
||||
reference clock provided at CLK125_NDO pin is used as MAC reference
|
||||
clock because the clock jitter in slave mode is to high (errata#2).
|
||||
Attention: The link partner must be configurable as slave otherwise
|
||||
no link will be established.
|
||||
|
||||
Examples:
|
||||
|
||||
mdio {
|
||||
|
|
54
Documentation/devicetree/bindings/net/microchip,lan78xx.txt
Normal file
54
Documentation/devicetree/bindings/net/microchip,lan78xx.txt
Normal file
|
@ -0,0 +1,54 @@
|
|||
Microchip LAN78xx Gigabit Ethernet controller
|
||||
|
||||
The LAN78XX devices are usually configured by programming their OTP or with
|
||||
an external EEPROM, but some platforms (e.g. Raspberry Pi 3 B+) have neither.
|
||||
The Device Tree properties, if present, override the OTP and EEPROM.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be one of "usb424,7800", "usb424,7801" or "usb424,7850".
|
||||
|
||||
Optional properties:
|
||||
- local-mac-address: see ethernet.txt
|
||||
- mac-address: see ethernet.txt
|
||||
|
||||
Optional properties of the embedded PHY:
|
||||
- microchip,led-modes: a 0..4 element vector, with each element configuring
|
||||
the operating mode of an LED. Omitted LEDs are turned off. Allowed values
|
||||
are defined in "include/dt-bindings/net/microchip-lan78xx.h".
|
||||
|
||||
Example:
|
||||
|
||||
/* Based on the configuration for a Raspberry Pi 3 B+ */
|
||||
&usb {
|
||||
usb-port@1 {
|
||||
compatible = "usb424,2514";
|
||||
reg = <1>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
usb-port@1 {
|
||||
compatible = "usb424,2514";
|
||||
reg = <1>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
ethernet: ethernet@1 {
|
||||
compatible = "usb424,7800";
|
||||
reg = <1>;
|
||||
local-mac-address = [ 00 11 22 33 44 55 ];
|
||||
|
||||
mdio {
|
||||
#address-cells = <0x1>;
|
||||
#size-cells = <0x0>;
|
||||
eth_phy: ethernet-phy@1 {
|
||||
reg = <1>;
|
||||
microchip,led-modes = <
|
||||
LAN78XX_LINK_1000_ACTIVITY
|
||||
LAN78XX_LINK_10_100_ACTIVITY
|
||||
>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
26
Documentation/devicetree/bindings/net/mscc-miim.txt
Normal file
26
Documentation/devicetree/bindings/net/mscc-miim.txt
Normal file
|
@ -0,0 +1,26 @@
|
|||
Microsemi MII Management Controller (MIIM) / MDIO
|
||||
=================================================
|
||||
|
||||
Properties:
|
||||
- compatible: must be "mscc,ocelot-miim"
|
||||
- reg: The base address of the MDIO bus controller register bank. Optionally, a
|
||||
second register bank can be defined if there is an associated reset register
|
||||
for internal PHYs
|
||||
- #address-cells: Must be <1>.
|
||||
- #size-cells: Must be <0>. MDIO addresses have no size component.
|
||||
- interrupts: interrupt specifier (refer to the interrupt binding)
|
||||
|
||||
Typically an MDIO bus might have several children.
|
||||
|
||||
Example:
|
||||
mdio@107009c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "mscc,ocelot-miim";
|
||||
reg = <0x107009c 0x36>, <0x10700f0 0x8>;
|
||||
interrupts = <14>;
|
||||
|
||||
phy0: ethernet-phy@0 {
|
||||
reg = <0>;
|
||||
};
|
||||
};
|
82
Documentation/devicetree/bindings/net/mscc-ocelot.txt
Normal file
82
Documentation/devicetree/bindings/net/mscc-ocelot.txt
Normal file
|
@ -0,0 +1,82 @@
|
|||
Microsemi Ocelot network Switch
|
||||
===============================
|
||||
|
||||
The Microsemi Ocelot network switch can be found on Microsemi SoCs (VSC7513,
|
||||
VSC7514)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "mscc,vsc7514-switch"
|
||||
- reg: Must contain an (offset, length) pair of the register set for each
|
||||
entry in reg-names.
|
||||
- reg-names: Must include the following entries:
|
||||
- "sys"
|
||||
- "rew"
|
||||
- "qs"
|
||||
- "hsio"
|
||||
- "qsys"
|
||||
- "ana"
|
||||
- "portX" with X from 0 to the number of last port index available on that
|
||||
switch
|
||||
- interrupts: Should contain the switch interrupts for frame extraction and
|
||||
frame injection
|
||||
- interrupt-names: should contain the interrupt names: "xtr", "inj"
|
||||
- ethernet-ports: A container for child nodes representing switch ports.
|
||||
|
||||
The ethernet-ports container has the following properties
|
||||
|
||||
Required properties:
|
||||
|
||||
- #address-cells: Must be 1
|
||||
- #size-cells: Must be 0
|
||||
|
||||
Each port node must have the following mandatory properties:
|
||||
- reg: Describes the port address in the switch
|
||||
|
||||
Port nodes may also contain the following optional standardised
|
||||
properties, described in binding documents:
|
||||
|
||||
- phy-handle: Phandle to a PHY on an MDIO bus. See
|
||||
Documentation/devicetree/bindings/net/ethernet.txt for details.
|
||||
|
||||
Example:
|
||||
|
||||
switch@1010000 {
|
||||
compatible = "mscc,vsc7514-switch";
|
||||
reg = <0x1010000 0x10000>,
|
||||
<0x1030000 0x10000>,
|
||||
<0x1080000 0x100>,
|
||||
<0x10d0000 0x10000>,
|
||||
<0x11e0000 0x100>,
|
||||
<0x11f0000 0x100>,
|
||||
<0x1200000 0x100>,
|
||||
<0x1210000 0x100>,
|
||||
<0x1220000 0x100>,
|
||||
<0x1230000 0x100>,
|
||||
<0x1240000 0x100>,
|
||||
<0x1250000 0x100>,
|
||||
<0x1260000 0x100>,
|
||||
<0x1270000 0x100>,
|
||||
<0x1280000 0x100>,
|
||||
<0x1800000 0x80000>,
|
||||
<0x1880000 0x10000>;
|
||||
reg-names = "sys", "rew", "qs", "hsio", "port0",
|
||||
"port1", "port2", "port3", "port4", "port5",
|
||||
"port6", "port7", "port8", "port9", "port10",
|
||||
"qsys", "ana";
|
||||
interrupts = <21 22>;
|
||||
interrupt-names = "xtr", "inj";
|
||||
|
||||
ethernet-ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port0: port@0 {
|
||||
reg = <0>;
|
||||
phy-handle = <&phy0>;
|
||||
};
|
||||
port1: port@1 {
|
||||
reg = <1>;
|
||||
phy-handle = <&phy1>;
|
||||
};
|
||||
};
|
||||
};
|
30
Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
Normal file
30
Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
Normal file
|
@ -0,0 +1,30 @@
|
|||
Qualcomm Bluetooth Chips
|
||||
---------------------
|
||||
|
||||
This documents the binding structure and common properties for serial
|
||||
attached Qualcomm devices.
|
||||
|
||||
Serial attached Qualcomm devices shall be a child node of the host UART
|
||||
device the slave device is attached to.
|
||||
|
||||
Required properties:
|
||||
- compatible: should contain one of the following:
|
||||
* "qcom,qca6174-bt"
|
||||
|
||||
Optional properties:
|
||||
- enable-gpios: gpio specifier used to enable chip
|
||||
- clocks: clock provided to the controller (SUSCLK_32KHZ)
|
||||
|
||||
Example:
|
||||
|
||||
serial@7570000 {
|
||||
label = "BT-UART";
|
||||
status = "okay";
|
||||
|
||||
bluetooth {
|
||||
compatible = "qcom,qca6174-bt";
|
||||
|
||||
enable-gpios = <&pm8994_gpios 19 GPIO_ACTIVE_HIGH>;
|
||||
clocks = <&divclk4>;
|
||||
};
|
||||
};
|
|
@ -18,6 +18,7 @@ Required properties:
|
|||
|
||||
- "renesas,etheravb-r8a7795" for the R8A7795 SoC.
|
||||
- "renesas,etheravb-r8a7796" for the R8A7796 SoC.
|
||||
- "renesas,etheravb-r8a77965" for the R8A77965 SoC.
|
||||
- "renesas,etheravb-r8a77970" for the R8A77970 SoC.
|
||||
- "renesas,etheravb-r8a77980" for the R8A77980 SoC.
|
||||
- "renesas,etheravb-r8a77995" for the R8A77995 SoC.
|
||||
|
|
|
@ -14,6 +14,7 @@ Required properties:
|
|||
"renesas,ether-r8a7791" if the device is a part of R8A7791 SoC.
|
||||
"renesas,ether-r8a7793" if the device is a part of R8A7793 SoC.
|
||||
"renesas,ether-r8a7794" if the device is a part of R8A7794 SoC.
|
||||
"renesas,gether-r8a77980" if the device is a part of R8A77980 SoC.
|
||||
"renesas,ether-r7s72100" if the device is a part of R7S72100 SoC.
|
||||
"renesas,rcar-gen1-ether" for a generic R-Car Gen1 device.
|
||||
"renesas,rcar-gen2-ether" for a generic R-Car Gen2 or RZ/G1
|
||||
|
|
|
@ -13,13 +13,25 @@ Required properties:
|
|||
- reg: Address where registers are mapped and size of region.
|
||||
- interrupts: Should contain the MAC interrupt.
|
||||
- phy-mode: See ethernet.txt in the same directory. Allow to choose
|
||||
"rgmii", "rmii", or "mii" according to the PHY.
|
||||
"rgmii", "rmii", "mii", or "internal" according to the PHY.
|
||||
The acceptable mode is SoC-dependent.
|
||||
- phy-handle: Should point to the external phy device.
|
||||
See ethernet.txt file in the same directory.
|
||||
- clocks: A phandle to the clock for the MAC.
|
||||
For Pro4 SoC, that is "socionext,uniphier-pro4-ave4",
|
||||
another MAC clock, GIO bus clock and PHY clock are also required.
|
||||
- clock-names: Should contain
|
||||
- "ether", "ether-gb", "gio", "ether-phy" for Pro4 SoC
|
||||
- "ether" for others
|
||||
- resets: A phandle to the reset control for the MAC. For Pro4 SoC,
|
||||
GIO bus reset is also required.
|
||||
- reset-names: Should contain
|
||||
- "ether", "gio" for Pro4 SoC
|
||||
- "ether" for others
|
||||
- socionext,syscon-phy-mode: A phandle to syscon with one argument
|
||||
that configures phy mode. The argument is the ID of MAC instance.
|
||||
|
||||
Optional properties:
|
||||
- resets: A phandle to the reset control for the MAC.
|
||||
- local-mac-address: See ethernet.txt in the same directory.
|
||||
|
||||
Required subnode:
|
||||
|
@ -34,8 +46,11 @@ Example:
|
|||
interrupts = <0 66 4>;
|
||||
phy-mode = "rgmii";
|
||||
phy-handle = <ðphy>;
|
||||
clock-names = "ether";
|
||||
clocks = <&sys_clk 6>;
|
||||
reset-names = "ether";
|
||||
resets = <&sys_rst 6>;
|
||||
socionext,syscon-phy-mode = <&soc_glue 0>;
|
||||
local-mac-address = [00 00 00 00 00 00];
|
||||
|
||||
mdio {
|
||||
|
|
|
@ -4,6 +4,7 @@ Required properties:
|
|||
- compatible: Should be one of the following:
|
||||
* "qcom,ath10k"
|
||||
* "qcom,ipq4019-wifi"
|
||||
* "qcom,wcn3990-wifi"
|
||||
|
||||
PCI based devices uses compatible string "qcom,ath10k" and takes calibration
|
||||
data along with board specific data via "qcom,ath10k-calibration-data".
|
||||
|
@ -18,8 +19,12 @@ In general, entry "qcom,ath10k-pre-calibration-data" and
|
|||
"qcom,ath10k-calibration-data" conflict with each other and only one
|
||||
can be provided per device.
|
||||
|
||||
SNOC based devices (i.e. wcn3990) uses compatible string "qcom,wcn3990-wifi".
|
||||
|
||||
Optional properties:
|
||||
- reg: Address and length of the register set for the device.
|
||||
- reg-names: Must include the list of following reg names,
|
||||
"membase"
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reseti.txt for details.
|
||||
- reset-names: Must include the list of following reset names,
|
||||
|
@ -49,6 +54,8 @@ Optional properties:
|
|||
hw versions.
|
||||
- qcom,ath10k-pre-calibration-data : pre calibration data as an array,
|
||||
the length can vary between hw versions.
|
||||
- <supply-name>-supply: handle to the regulator device tree node
|
||||
optional "supply-name" is "vdd-0.8-cx-mx".
|
||||
|
||||
Example (to supply the calibration data alone):
|
||||
|
||||
|
@ -119,3 +126,27 @@ wifi0: wifi@a000000 {
|
|||
qcom,msi_base = <0x40>;
|
||||
qcom,ath10k-pre-calibration-data = [ 01 02 03 ... ];
|
||||
};
|
||||
|
||||
Example (to supply wcn3990 SoC wifi block details):
|
||||
|
||||
wifi@18000000 {
|
||||
compatible = "qcom,wcn3990-wifi";
|
||||
reg = <0x18800000 0x800000>;
|
||||
reg-names = "membase";
|
||||
clocks = <&clock_gcc clk_aggre2_noc_clk>;
|
||||
clock-names = "smmu_aggre2_noc_clk"
|
||||
interrupts =
|
||||
<0 130 0 /* CE0 */ >,
|
||||
<0 131 0 /* CE1 */ >,
|
||||
<0 132 0 /* CE2 */ >,
|
||||
<0 133 0 /* CE3 */ >,
|
||||
<0 134 0 /* CE4 */ >,
|
||||
<0 135 0 /* CE5 */ >,
|
||||
<0 136 0 /* CE6 */ >,
|
||||
<0 137 0 /* CE7 */ >,
|
||||
<0 138 0 /* CE8 */ >,
|
||||
<0 139 0 /* CE9 */ >,
|
||||
<0 140 0 /* CE10 */ >,
|
||||
<0 141 0 /* CE11 */ >;
|
||||
vdd-0.8-cx-mx-supply = <&pm8998_l5>;
|
||||
};
|
||||
|
|
|
@ -56,9 +56,9 @@ pins it needs, and how they should be configured, with regard to muxer
|
|||
configuration, drive strength and pullups. If one of these options is
|
||||
not set, its actual value will be unspecified.
|
||||
|
||||
This driver supports the generic pin multiplexing and configuration
|
||||
bindings. For details on each properties, you can refer to
|
||||
./pinctrl-bindings.txt.
|
||||
Allwinner A1X Pin Controller supports the generic pin multiplexing and
|
||||
configuration bindings. For details on each properties, you can refer to
|
||||
./pinctrl-bindings.txt.
|
||||
|
||||
Required sub-node properties:
|
||||
- pins
|
||||
|
|
25
Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt
Normal file
25
Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt
Normal file
|
@ -0,0 +1,25 @@
|
|||
Ingenic JZ47xx PWM Controller
|
||||
=============================
|
||||
|
||||
Required properties:
|
||||
- compatible: One of:
|
||||
* "ingenic,jz4740-pwm"
|
||||
* "ingenic,jz4770-pwm"
|
||||
* "ingenic,jz4780-pwm"
|
||||
- #pwm-cells: Should be 3. See pwm.txt in this directory for a description
|
||||
of the cells format.
|
||||
- clocks : phandle to the external clock.
|
||||
- clock-names : Should be "ext".
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
pwm: pwm@10002000 {
|
||||
compatible = "ingenic,jz4740-pwm";
|
||||
reg = <0x10002000 0x1000>;
|
||||
|
||||
#pwm-cells = <3>;
|
||||
|
||||
clocks = <&ext>;
|
||||
clock-names = "ext";
|
||||
};
|
|
@ -7,6 +7,8 @@ See ../mfd/stm32-lptimer.txt for details about the parent node.
|
|||
|
||||
Required parameters:
|
||||
- compatible: Must be "st,stm32-pwm-lp".
|
||||
- #pwm-cells: Should be set to 3. This PWM chip uses the default 3 cells
|
||||
bindings defined in pwm.txt.
|
||||
|
||||
Optional properties:
|
||||
- pinctrl-names: Set to "default".
|
||||
|
@ -18,6 +20,7 @@ Example:
|
|||
...
|
||||
pwm {
|
||||
compatible = "st,stm32-pwm-lp";
|
||||
#pwm-cells = <3>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&lppwm1_pins>;
|
||||
};
|
||||
|
|
|
@ -7,6 +7,8 @@ Required properties:
|
|||
- "allwinner,sun5i-a13-pwm"
|
||||
- "allwinner,sun7i-a20-pwm"
|
||||
- "allwinner,sun8i-h3-pwm"
|
||||
- "allwinner,sun50i-a64-pwm", "allwinner,sun5i-a13-pwm"
|
||||
- "allwinner,sun50i-h5-pwm", "allwinner,sun5i-a13-pwm"
|
||||
- reg: physical base address and length of the controller's registers
|
||||
- #pwm-cells: should be 3. See pwm.txt in this directory for a description of
|
||||
the cells format.
|
||||
|
|
|
@ -2,6 +2,8 @@
|
|||
|
||||
Required Properties:
|
||||
- compatible: should be "renesas,pwm-rcar" and one of the following.
|
||||
- "renesas,pwm-r8a7743": for RZ/G1M
|
||||
- "renesas,pwm-r8a7745": for RZ/G1E
|
||||
- "renesas,pwm-r8a7778": for R-Car M1A
|
||||
- "renesas,pwm-r8a7779": for R-Car H1
|
||||
- "renesas,pwm-r8a7790": for R-Car H2
|
||||
|
@ -9,6 +11,7 @@ Required Properties:
|
|||
- "renesas,pwm-r8a7794": for R-Car E2
|
||||
- "renesas,pwm-r8a7795": for R-Car H3
|
||||
- "renesas,pwm-r8a7796": for R-Car M3-W
|
||||
- "renesas,pwm-r8a77965": for R-Car M3-N
|
||||
- "renesas,pwm-r8a77995": for R-Car D3
|
||||
- reg: base address and length of the registers block for the PWM.
|
||||
- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
|
||||
|
@ -17,13 +20,15 @@ Required Properties:
|
|||
- pinctrl-0: phandle, referring to a default pin configuration node.
|
||||
- pinctrl-names: Set to "default".
|
||||
|
||||
Example: R8A7790 (R-Car H2) PWM Timer node
|
||||
Example: R8A7743 (RZ/G1M) PWM Timer node
|
||||
|
||||
pwm0: pwm@e6e30000 {
|
||||
compatible = "renesas,pwm-r8a7790", "renesas,pwm-rcar";
|
||||
compatible = "renesas,pwm-r8a7743", "renesas,pwm-rcar";
|
||||
reg = <0 0xe6e30000 0 0x8>;
|
||||
clocks = <&cpg CPG_MOD 523>;
|
||||
power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
|
||||
resets = <&cpg 523>;
|
||||
#pwm-cells = <2>;
|
||||
clocks = <&mstp5_clks R8A7790_CLK_PWM>;
|
||||
pinctrl-0 = <&pwm0_pins>;
|
||||
pinctrl-names = "default";
|
||||
};
|
||||
|
|
|
@ -3,10 +3,12 @@
|
|||
Required Properties:
|
||||
|
||||
- compatible: should be one of the following.
|
||||
- "renesas,tpu-r8a73a4": for R8A77A4 (R-Mobile APE6) compatible PWM controller.
|
||||
- "renesas,tpu-r8a73a4": for R8A73A4 (R-Mobile APE6) compatible PWM controller.
|
||||
- "renesas,tpu-r8a7740": for R8A7740 (R-Mobile A1) compatible PWM controller.
|
||||
- "renesas,tpu-r8a7743": for R8A7743 (RZ/G1M) compatible PWM controller.
|
||||
- "renesas,tpu-r8a7745": for R8A7745 (RZ/G1E) compatible PWM controller.
|
||||
- "renesas,tpu-r8a7790": for R8A7790 (R-Car H2) compatible PWM controller.
|
||||
- "renesas,tpu": for generic R-Car TPU PWM controller.
|
||||
- "renesas,tpu": for generic R-Car and RZ/G1 TPU PWM controller.
|
||||
|
||||
- reg: Base address and length of each memory resource used by the PWM
|
||||
controller hardware module.
|
||||
|
@ -18,10 +20,10 @@ Required Properties:
|
|||
Please refer to pwm.txt in this directory for details of the common PWM bindings
|
||||
used by client devices.
|
||||
|
||||
Example: R8A7740 (R-Car A1) TPU controller node
|
||||
Example: R8A7740 (R-Mobile A1) TPU controller node
|
||||
|
||||
tpu: pwm@e6600000 {
|
||||
compatible = "renesas,tpu-r8a7740", "renesas,tpu";
|
||||
reg = <0xe6600000 0x100>;
|
||||
reg = <0xe6600000 0x148>;
|
||||
#pwm-cells = <3>;
|
||||
};
|
||||
|
|
|
@ -21,7 +21,7 @@ Required properties:
|
|||
- interrupts : identifier to the device interrupt
|
||||
- clocks : a list of phandle + clock-specifier pairs, one for each
|
||||
entry in clock names.
|
||||
- clocks-names :
|
||||
- clock-names :
|
||||
* "xtal" for external xtal clock identifier
|
||||
* "pclk" for the bus core clock, either the clk81 clock or the gate clock
|
||||
* "baud" for the source of the baudrate generator, can be either the xtal
|
||||
|
|
|
@ -24,7 +24,7 @@ Required properties:
|
|||
- Must contain two elements for the extended variant of the IP
|
||||
(marvell,armada-3700-uart-ext): "uart-tx" and "uart-rx",
|
||||
respectively the UART TX interrupt and the UART RX interrupt. A
|
||||
corresponding interrupts-names property must be defined.
|
||||
corresponding interrupt-names property must be defined.
|
||||
- For backward compatibility reasons, a single element interrupts
|
||||
property is also supported for the standard variant of the IP,
|
||||
containing only the UART sum interrupt. This form is deprecated
|
||||
|
|
|
@ -17,6 +17,8 @@ Required properties:
|
|||
- "renesas,scifa-r8a7745" for R8A7745 (RZ/G1E) SCIFA compatible UART.
|
||||
- "renesas,scifb-r8a7745" for R8A7745 (RZ/G1E) SCIFB compatible UART.
|
||||
- "renesas,hscif-r8a7745" for R8A7745 (RZ/G1E) HSCIF compatible UART.
|
||||
- "renesas,scif-r8a77470" for R8A77470 (RZ/G1C) SCIF compatible UART.
|
||||
- "renesas,hscif-r8a77470" for R8A77470 (RZ/G1C) HSCIF compatible UART.
|
||||
- "renesas,scif-r8a7778" for R8A7778 (R-Car M1) SCIF compatible UART.
|
||||
- "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART.
|
||||
- "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART.
|
||||
|
@ -41,6 +43,8 @@ Required properties:
|
|||
- "renesas,hscif-r8a7795" for R8A7795 (R-Car H3) HSCIF compatible UART.
|
||||
- "renesas,scif-r8a7796" for R8A7796 (R-Car M3-W) SCIF compatible UART.
|
||||
- "renesas,hscif-r8a7796" for R8A7796 (R-Car M3-W) HSCIF compatible UART.
|
||||
- "renesas,scif-r8a77965" for R8A77965 (R-Car M3-N) SCIF compatible UART.
|
||||
- "renesas,hscif-r8a77965" for R8A77965 (R-Car M3-N) HSCIF compatible UART.
|
||||
- "renesas,scif-r8a77970" for R8A77970 (R-Car V3M) SCIF compatible UART.
|
||||
- "renesas,hscif-r8a77970" for R8A77970 (R-Car V3M) HSCIF compatible UART.
|
||||
- "renesas,scif-r8a77980" for R8A77980 (R-Car V3H) SCIF compatible UART.
|
||||
|
|
|
@ -49,19 +49,6 @@ on the SoC (only first trip points defined in DT will be configured):
|
|||
- samsung,exynos5433-tmu: 8
|
||||
- samsung,exynos7-tmu: 8
|
||||
|
||||
Following properties are mandatory (depending on SoC):
|
||||
- samsung,tmu_gain: Gain value for internal TMU operation.
|
||||
- samsung,tmu_reference_voltage: Value of TMU IP block's reference voltage
|
||||
- samsung,tmu_noise_cancel_mode: Mode for noise cancellation
|
||||
- samsung,tmu_efuse_value: Default level of temperature - it is needed when
|
||||
in factory fusing produced wrong value
|
||||
- samsung,tmu_min_efuse_value: Minimum temperature fused value
|
||||
- samsung,tmu_max_efuse_value: Maximum temperature fused value
|
||||
- samsung,tmu_first_point_trim: First point trimming value
|
||||
- samsung,tmu_second_point_trim: Second point trimming value
|
||||
- samsung,tmu_default_temp_offset: Default temperature offset
|
||||
- samsung,tmu_cal_type: Callibration type
|
||||
|
||||
** Optional properties:
|
||||
|
||||
- vtmu-supply: This entry is optional and provides the regulator node supplying
|
||||
|
@ -78,7 +65,7 @@ Example 1):
|
|||
clocks = <&clock 383>;
|
||||
clock-names = "tmu_apbif";
|
||||
vtmu-supply = <&tmu_regulator_node>;
|
||||
#include "exynos4412-tmu-sensor-conf.dtsi"
|
||||
#thermal-sensor-cells = <0>;
|
||||
};
|
||||
|
||||
Example 2):
|
||||
|
@ -89,7 +76,7 @@ Example 2):
|
|||
interrupts = <0 58 0>;
|
||||
clocks = <&clock 21>;
|
||||
clock-names = "tmu_apbif";
|
||||
#include "exynos5440-tmu-sensor-conf.dtsi"
|
||||
#thermal-sensor-cells = <0>;
|
||||
};
|
||||
|
||||
Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
|
||||
|
@ -99,7 +86,7 @@ Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
|
|||
interrupts = <0 184 0>;
|
||||
clocks = <&clock 318>, <&clock 318>;
|
||||
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
|
||||
#include "exynos4412-tmu-sensor-conf.dtsi"
|
||||
#thermal-sensor-cells = <0>;
|
||||
};
|
||||
|
||||
tmu_cpu3: tmu@1006c000 {
|
||||
|
@ -108,7 +95,7 @@ Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
|
|||
interrupts = <0 185 0>;
|
||||
clocks = <&clock 318>, <&clock 319>;
|
||||
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
|
||||
#include "exynos4412-tmu-sensor-conf.dtsi"
|
||||
#thermal-sensor-cells = <0>;
|
||||
};
|
||||
|
||||
tmu_gpu: tmu@100a0000 {
|
||||
|
@ -117,7 +104,7 @@ Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
|
|||
interrupts = <0 215 0>;
|
||||
clocks = <&clock 319>, <&clock 318>;
|
||||
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
|
||||
#include "exynos4412-tmu-sensor-conf.dtsi"
|
||||
#thermal-sensor-cells = <0>;
|
||||
};
|
||||
|
||||
Note: For multi-instance tmu each instance should have an alias correctly
|
||||
|
|
|
@ -55,8 +55,7 @@ of heat dissipation). For example a fan's cooling states correspond to
|
|||
the different fan speeds possible. Cooling states are referred to by
|
||||
single unsigned integers, where larger numbers mean greater heat
|
||||
dissipation. The precise set of cooling states associated with a device
|
||||
(as referred to by the cooling-min-level and cooling-max-level
|
||||
properties) should be defined in a particular device's binding.
|
||||
should be defined in a particular device's binding.
|
||||
For more examples of cooling devices, refer to the example sections below.
|
||||
|
||||
Required properties:
|
||||
|
@ -69,15 +68,6 @@ Required properties:
|
|||
See Cooling device maps section below for more details
|
||||
on how consumers refer to cooling devices.
|
||||
|
||||
Optional properties:
|
||||
- cooling-min-level: An integer indicating the smallest
|
||||
Type: unsigned cooling state accepted. Typically 0.
|
||||
Size: one cell
|
||||
|
||||
- cooling-max-level: An integer indicating the largest
|
||||
Type: unsigned cooling state accepted.
|
||||
Size: one cell
|
||||
|
||||
* Trip points
|
||||
|
||||
The trip node is a node to describe a point in the temperature domain
|
||||
|
@ -226,8 +216,6 @@ cpus {
|
|||
396000 950000
|
||||
198000 850000
|
||||
>;
|
||||
cooling-min-level = <0>;
|
||||
cooling-max-level = <3>;
|
||||
#cooling-cells = <2>; /* min followed by max */
|
||||
};
|
||||
...
|
||||
|
@ -241,8 +229,6 @@ cpus {
|
|||
*/
|
||||
fan0: fan@48 {
|
||||
...
|
||||
cooling-min-level = <0>;
|
||||
cooling-max-level = <9>;
|
||||
#cooling-cells = <2>; /* min followed by max */
|
||||
};
|
||||
};
|
||||
|
|
|
@ -0,0 +1,21 @@
|
|||
Nuvoton NPCM7xx timer
|
||||
|
||||
Nuvoton NPCM7xx have three timer modules, each timer module provides five 24-bit
|
||||
timer counters.
|
||||
|
||||
Required properties:
|
||||
- compatible : "nuvoton,npcm750-timer" for Poleg NPCM750.
|
||||
- reg : Offset and length of the register set for the device.
|
||||
- interrupts : Contain the timer interrupt with flags for
|
||||
falling edge.
|
||||
- clocks : phandle of timer reference clock (usually a 25 MHz clock).
|
||||
|
||||
Example:
|
||||
|
||||
timer@f0008000 {
|
||||
compatible = "nuvoton,npcm750-timer";
|
||||
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
|
||||
reg = <0xf0008000 0x50>;
|
||||
clocks = <&clk NPCM7XX_CLK_TIMER>;
|
||||
};
|
||||
|
|
@ -15,7 +15,7 @@ Required properties:
|
|||
- interrupts : Should be the clock event device interrupt.
|
||||
- clocks : The clocks provided by the SoC to drive the timer, must contain
|
||||
an entry for each entry in clock-names.
|
||||
- clock-names : Must include the following entries: "igp" and "per".
|
||||
- clock-names : Must include the following entries: "ipg" and "per".
|
||||
|
||||
Example:
|
||||
tpm5: tpm@40260000 {
|
||||
|
|
|
@ -28,7 +28,10 @@ Required properties:
|
|||
- interrupts: one XHCI interrupt should be described here.
|
||||
|
||||
Optional properties:
|
||||
- clocks: reference to a clock
|
||||
- clocks: reference to the clocks
|
||||
- clock-names: mandatory if there is a second clock, in this case
|
||||
the name must be "core" for the first clock and "reg" for the
|
||||
second one
|
||||
- usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
|
||||
- usb3-lpm-capable: determines if platform is USB3 LPM capable
|
||||
- quirk-broken-port-ped: set if the controller has broken port disable mechanism
|
||||
|
|
|
@ -182,6 +182,7 @@ karo Ka-Ro electronics GmbH
|
|||
keithkoep Keith & Koep GmbH
|
||||
keymile Keymile GmbH
|
||||
khadas Khadas
|
||||
kiebackpeter Kieback & Peter GmbH
|
||||
kinetic Kinetic Technologies
|
||||
kingnovel Kingnovel Technology Co., Ltd.
|
||||
kosagi Sutajio Ko-Usagi PTE Ltd.
|
||||
|
|
|
@ -11,6 +11,7 @@ Optional properties:
|
|||
detail please see: Documentation/devicetree/bindings/regmap/regmap.txt.
|
||||
- fsl,ext-reset-output: If present the watchdog device is configured to
|
||||
assert its external reset (WDOG_B) instead of issuing a software reset.
|
||||
- timeout-sec : Contains the watchdog timeout in seconds
|
||||
|
||||
Examples:
|
||||
|
||||
|
@ -19,4 +20,5 @@ wdt@73f98000 {
|
|||
reg = <0x73f98000 0x4000>;
|
||||
interrupts = <58>;
|
||||
big-endian;
|
||||
timeout-sec = <20>;
|
||||
};
|
||||
|
|
|
@ -9,9 +9,13 @@ Required properties:
|
|||
"amlogic,meson8m2-wdt" and "amlogic,meson8b-wdt" on Meson8m2 SoCs
|
||||
- reg : Specifies base physical address and size of the registers.
|
||||
|
||||
Optional properties:
|
||||
- timeout-sec: contains the watchdog timeout in seconds.
|
||||
|
||||
Example:
|
||||
|
||||
wdt: watchdog@c1109900 {
|
||||
compatible = "amlogic,meson6-wdt";
|
||||
reg = <0xc1109900 0x8>;
|
||||
timeout-sec = <10>;
|
||||
};
|
||||
|
|
|
@ -11,9 +11,13 @@ Required properties:
|
|||
|
||||
- reg : Specifies base physical address and size of the registers.
|
||||
|
||||
Optional properties:
|
||||
- timeout-sec: contains the watchdog timeout in seconds.
|
||||
|
||||
Example:
|
||||
|
||||
wdt: watchdog@10000000 {
|
||||
compatible = "mediatek,mt6589-wdt";
|
||||
reg = <0x10000000 0x18>;
|
||||
timeout-sec = <10>;
|
||||
};
|
||||
|
|
|
@ -0,0 +1,28 @@
|
|||
Nuvoton NPCM Watchdog
|
||||
|
||||
Nuvoton NPCM timer module provides five 24-bit timer counters, and a watchdog.
|
||||
The watchdog supports a pre-timeout interrupt that fires 10ms before the
|
||||
expiry.
|
||||
|
||||
Required properties:
|
||||
- compatible : "nuvoton,npcm750-wdt" for NPCM750 (Poleg).
|
||||
- reg : Offset and length of the register set for the device.
|
||||
- interrupts : Contain the timer interrupt with flags for
|
||||
falling edge.
|
||||
|
||||
Required clocking property, have to be one of:
|
||||
- clocks : phandle of timer reference clock.
|
||||
- clock-frequency : The frequency in Hz of the clock that drives the NPCM7xx
|
||||
timer (usually 25000000).
|
||||
|
||||
Optional properties:
|
||||
- timeout-sec : Contains the watchdog timeout in seconds
|
||||
|
||||
Example:
|
||||
|
||||
timer@f000801c {
|
||||
compatible = "nuvoton,npcm750-wdt";
|
||||
interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
|
||||
reg = <0xf000801c 0x4>;
|
||||
clocks = <&clk NPCM7XX_CLK_TIMER>;
|
||||
};
|
|
@ -5,10 +5,14 @@ Required properties:
|
|||
- reg: Address range of tick timer/WDT register set
|
||||
- interrupts: interrupt number to the cpu
|
||||
|
||||
Optional properties:
|
||||
- timeout-sec : Contains the watchdog timeout in seconds
|
||||
|
||||
Example:
|
||||
|
||||
timer@b0020000 {
|
||||
compatible = "sirf,prima2-tick";
|
||||
reg = <0xb0020000 0x1000>;
|
||||
interrupts = <0>;
|
||||
timeout-sec = <30>;
|
||||
};
|
||||
|
|
|
@ -8,9 +8,13 @@ Required properties:
|
|||
"allwinner,sun50i-a64-wdt","allwinner,sun6i-a31-wdt"
|
||||
- reg : Specifies base physical address and size of the registers.
|
||||
|
||||
Optional properties:
|
||||
- timeout-sec : Contains the watchdog timeout in seconds
|
||||
|
||||
Example:
|
||||
|
||||
wdt: watchdog@1c20c90 {
|
||||
compatible = "allwinner,sun4i-a10-wdt";
|
||||
reg = <0x01c20c90 0x10>;
|
||||
timeout-sec = <10>;
|
||||
};
|
||||
|
|
|
@ -98,6 +98,14 @@ Finally, if you need to remove all overlays in one-go, just call
|
|||
of_overlay_remove_all() which will remove every single one in the correct
|
||||
order.
|
||||
|
||||
In addition, there is the option to register notifiers that get called on
|
||||
overlay operations. See of_overlay_notifier_register/unregister and
|
||||
enum of_overlay_notify_action for details.
|
||||
|
||||
Note that a notifier callback is not supposed to store pointers to a device
|
||||
tree node or its content beyond OF_OVERLAY_POST_REMOVE corresponding to the
|
||||
respective node it received.
|
||||
|
||||
Overlay DTS Format
|
||||
------------------
|
||||
|
||||
|
|
|
@ -177,14 +177,14 @@ BUGS
|
|||
****
|
||||
|
||||
|
||||
Report bugs to Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
Report bugs to Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
|
||||
|
||||
COPYRIGHT
|
||||
*********
|
||||
|
||||
|
||||
Copyright (c) 2016 by Mauro Carvalho Chehab <mchehab@s-opensource.com>.
|
||||
Copyright (c) 2016 by Mauro Carvalho Chehab <mchehab+samsung@kernel.org>.
|
||||
|
||||
License GPLv2: GNU GPL version 2 <http://gnu.org/licenses/gpl.html>.
|
||||
|
||||
|
|
|
@ -17,17 +17,17 @@ an error is returned.
|
|||
|
||||
request_firmware
|
||||
----------------
|
||||
.. kernel-doc:: drivers/base/firmware_class.c
|
||||
.. kernel-doc:: drivers/base/firmware_loader/main.c
|
||||
:functions: request_firmware
|
||||
|
||||
request_firmware_direct
|
||||
-----------------------
|
||||
.. kernel-doc:: drivers/base/firmware_class.c
|
||||
.. kernel-doc:: drivers/base/firmware_loader/main.c
|
||||
:functions: request_firmware_direct
|
||||
|
||||
request_firmware_into_buf
|
||||
-------------------------
|
||||
.. kernel-doc:: drivers/base/firmware_class.c
|
||||
.. kernel-doc:: drivers/base/firmware_loader/main.c
|
||||
:functions: request_firmware_into_buf
|
||||
|
||||
Asynchronous firmware requests
|
||||
|
@ -41,7 +41,7 @@ in atomic contexts.
|
|||
|
||||
request_firmware_nowait
|
||||
-----------------------
|
||||
.. kernel-doc:: drivers/base/firmware_class.c
|
||||
.. kernel-doc:: drivers/base/firmware_loader/main.c
|
||||
:functions: request_firmware_nowait
|
||||
|
||||
Special optimizations on reboot
|
||||
|
@ -50,12 +50,12 @@ Special optimizations on reboot
|
|||
Some devices have an optimization in place to enable the firmware to be
|
||||
retained during system reboot. When such optimizations are used the driver
|
||||
author must ensure the firmware is still available on resume from suspend,
|
||||
this can be done with firmware_request_cache() insted of requesting for the
|
||||
firmare to be loaded.
|
||||
this can be done with firmware_request_cache() instead of requesting for the
|
||||
firmware to be loaded.
|
||||
|
||||
firmware_request_cache()
|
||||
-----------------------
|
||||
.. kernel-doc:: drivers/base/firmware_class.c
|
||||
------------------------
|
||||
.. kernel-doc:: drivers/base/firmware_loader/main.c
|
||||
:functions: firmware_request_cache
|
||||
|
||||
request firmware API expected driver use
|
||||
|
|
|
@ -28,7 +28,7 @@ Device Drivers Base
|
|||
.. kernel-doc:: drivers/base/node.c
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/base/firmware_class.c
|
||||
.. kernel-doc:: drivers/base/firmware_loader/main.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: drivers/base/transport_class.c
|
||||
|
|
|
@ -210,7 +210,7 @@ If the connector is dual-role capable, there may also be a switch for the data
|
|||
role. USB Type-C Connector Class does not supply separate API for them. The
|
||||
port drivers can use USB Role Class API with those.
|
||||
|
||||
Illustration of the muxes behind a connector that supports an alternate mode:
|
||||
Illustration of the muxes behind a connector that supports an alternate mode::
|
||||
|
||||
------------------------
|
||||
| Connector |
|
||||
|
|
|
@ -11,7 +11,7 @@ Contents:
|
|||
- Proc filesystem.
|
||||
- The cell database.
|
||||
- Security.
|
||||
- Examples.
|
||||
- The @sys substitution.
|
||||
|
||||
|
||||
========
|
||||
|
@ -230,3 +230,29 @@ If a file is opened with a particular key and then the file descriptor is
|
|||
passed to a process that doesn't have that key (perhaps over an AF_UNIX
|
||||
socket), then the operations on the file will be made with key that was used to
|
||||
open the file.
|
||||
|
||||
|
||||
=====================
|
||||
THE @SYS SUBSTITUTION
|
||||
=====================
|
||||
|
||||
The list of up to 16 @sys substitutions for the current network namespace can
|
||||
be configured by writing a list to /proc/fs/afs/sysname:
|
||||
|
||||
[root@andromeda ~]# echo foo amd64_linux_26 >/proc/fs/afs/sysname
|
||||
|
||||
or cleared entirely by writing an empty list:
|
||||
|
||||
[root@andromeda ~]# echo >/proc/fs/afs/sysname
|
||||
|
||||
The current list for current network namespace can be retrieved by:
|
||||
|
||||
[root@andromeda ~]# cat /proc/fs/afs/sysname
|
||||
foo
|
||||
amd64_linux_26
|
||||
|
||||
When @sys is being substituted for, each element of the list is tried in the
|
||||
order given.
|
||||
|
||||
By default, the list will contain one item that conforms to the pattern
|
||||
"<arch>_linux_26", amd64 being the name for x86_64.
|
||||
|
|
|
@ -100,14 +100,15 @@ indicates that it is caching uptodate data.
|
|||
|
||||
Glock locking order within GFS2:
|
||||
|
||||
1. i_mutex (if required)
|
||||
1. i_rwsem (if required)
|
||||
2. Rename glock (for rename only)
|
||||
3. Inode glock(s)
|
||||
(Parents before children, inodes at "same level" with same parent in
|
||||
lock number order)
|
||||
4. Rgrp glock(s) (for (de)allocation operations)
|
||||
5. Transaction glock (via gfs2_trans_begin) for non-read operations
|
||||
6. Page lock (always last, very important!)
|
||||
6. i_rw_mutex (if required)
|
||||
7. Page lock (always last, very important!)
|
||||
|
||||
There are two glocks per inode. One deals with access to the inode
|
||||
itself (locking order as above), and the other, known as the iopen
|
||||
|
|
|
@ -5,6 +5,7 @@ Written 1996 by Gero Kuhlmann <gero@gkminix.han.de>
|
|||
Updated 1997 by Martin Mares <mj@atrey.karlin.mff.cuni.cz>
|
||||
Updated 2006 by Nico Schottelius <nico-kernel-nfsroot@schottelius.org>
|
||||
Updated 2006 by Horms <horms@verge.net.au>
|
||||
Updated 2018 by Chris Novakovic <chris@chrisn.me.uk>
|
||||
|
||||
|
||||
|
||||
|
@ -79,7 +80,7 @@ nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
|
|||
|
||||
|
||||
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
|
||||
<dns0-ip>:<dns1-ip>
|
||||
<dns0-ip>:<dns1-ip>:<ntp0-ip>
|
||||
|
||||
This parameter tells the kernel how to configure IP addresses of devices
|
||||
and also how to set up the IP routing table. It was originally called
|
||||
|
@ -110,6 +111,9 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
|
|||
will not be triggered if it is missing and NFS root is not
|
||||
in operation.
|
||||
|
||||
Value is exported to /proc/net/pnp with the prefix "bootserver "
|
||||
(see below).
|
||||
|
||||
Default: Determined using autoconfiguration.
|
||||
The address of the autoconfiguration server is used.
|
||||
|
||||
|
@ -123,10 +127,13 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
|
|||
|
||||
Default: Determined using autoconfiguration.
|
||||
|
||||
<hostname> Name of the client. May be supplied by autoconfiguration,
|
||||
but its absence will not trigger autoconfiguration.
|
||||
If specified and DHCP is used, the user provided hostname will
|
||||
be carried in the DHCP request to hopefully update DNS record.
|
||||
<hostname> Name of the client. If a '.' character is present, anything
|
||||
before the first '.' is used as the client's hostname, and anything
|
||||
after it is used as its NIS domain name. May be supplied by
|
||||
autoconfiguration, but its absence will not trigger autoconfiguration.
|
||||
If specified and DHCP is used, the user-provided hostname (and NIS
|
||||
domain name, if present) will be carried in the DHCP request; this
|
||||
may cause a DNS record to be created or updated for the client.
|
||||
|
||||
Default: Client IP address is used in ASCII notation.
|
||||
|
||||
|
@ -162,12 +169,55 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
|
|||
|
||||
Default: any
|
||||
|
||||
<dns0-ip> IP address of first nameserver.
|
||||
Value gets exported by /proc/net/pnp which is often linked
|
||||
on embedded systems by /etc/resolv.conf.
|
||||
<dns0-ip> IP address of primary nameserver.
|
||||
Value is exported to /proc/net/pnp with the prefix "nameserver "
|
||||
(see below).
|
||||
|
||||
<dns1-ip> IP address of second nameserver.
|
||||
Same as above.
|
||||
Default: None if not using autoconfiguration; determined
|
||||
automatically if using autoconfiguration.
|
||||
|
||||
<dns1-ip> IP address of secondary nameserver.
|
||||
See <dns0-ip>.
|
||||
|
||||
<ntp0-ip> IP address of a Network Time Protocol (NTP) server.
|
||||
Value is exported to /proc/net/ipconfig/ntp_servers, but is
|
||||
otherwise unused (see below).
|
||||
|
||||
Default: None if not using autoconfiguration; determined
|
||||
automatically if using autoconfiguration.
|
||||
|
||||
After configuration (whether manual or automatic) is complete, two files
|
||||
are created in the following format; lines are omitted if their respective
|
||||
value is empty following configuration:
|
||||
|
||||
- /proc/net/pnp:
|
||||
|
||||
#PROTO: <DHCP|BOOTP|RARP|MANUAL> (depending on configuration method)
|
||||
domain <dns-domain> (if autoconfigured, the DNS domain)
|
||||
nameserver <dns0-ip> (primary name server IP)
|
||||
nameserver <dns1-ip> (secondary name server IP)
|
||||
nameserver <dns2-ip> (tertiary name server IP)
|
||||
bootserver <server-ip> (NFS server IP)
|
||||
|
||||
- /proc/net/ipconfig/ntp_servers:
|
||||
|
||||
<ntp0-ip> (NTP server IP)
|
||||
<ntp1-ip> (NTP server IP)
|
||||
<ntp2-ip> (NTP server IP)
|
||||
|
||||
<dns-domain> and <dns2-ip> (in /proc/net/pnp) and <ntp1-ip> and <ntp2-ip>
|
||||
(in /proc/net/ipconfig/ntp_servers) are requested during autoconfiguration;
|
||||
they cannot be specified as part of the "ip=" kernel command line parameter.
|
||||
|
||||
Because the "domain" and "nameserver" options are recognised by DNS
|
||||
resolvers, /etc/resolv.conf is often linked to /proc/net/pnp on systems
|
||||
that use an NFS root filesystem.
|
||||
|
||||
Note that the kernel will not synchronise the system time with any NTP
|
||||
servers it discovers; this is the responsibility of a user space process
|
||||
(e.g. an initrd/initramfs script that passes the IP addresses listed in
|
||||
/proc/net/ipconfig/ntp_servers to an NTP client before mounting the real
|
||||
root filesystem if it is on NFS).
|
||||
|
||||
|
||||
nfsrootdebug
|
||||
|
|
|
@ -14,9 +14,13 @@ The result will inevitably fail to look exactly like a normal
|
|||
filesystem for various technical reasons. The expectation is that
|
||||
many use cases will be able to ignore these differences.
|
||||
|
||||
This approach is 'hybrid' because the objects that appear in the
|
||||
filesystem do not all appear to belong to that filesystem. In many
|
||||
cases an object accessed in the union will be indistinguishable
|
||||
|
||||
Overlay objects
|
||||
---------------
|
||||
|
||||
The overlay filesystem approach is 'hybrid', because the objects that
|
||||
appear in the filesystem do not always appear to belong to that filesystem.
|
||||
In many cases, an object accessed in the union will be indistinguishable
|
||||
from accessing the corresponding object from the original filesystem.
|
||||
This is most obvious from the 'st_dev' field returned by stat(2).
|
||||
|
||||
|
@ -34,6 +38,19 @@ make the overlay mount more compliant with filesystem scanners and
|
|||
overlay objects will be distinguishable from the corresponding
|
||||
objects in the original filesystem.
|
||||
|
||||
On 64bit systems, even if all overlay layers are not on the same
|
||||
underlying filesystem, the same compliant behavior could be achieved
|
||||
with the "xino" feature. The "xino" feature composes a unique object
|
||||
identifier from the real object st_ino and an underlying fsid index.
|
||||
If all underlying filesystems support NFS file handles and export file
|
||||
handles with 32bit inode number encoding (e.g. ext4), overlay filesystem
|
||||
will use the high inode number bits for fsid. Even when the underlying
|
||||
filesystem uses 64bit inode numbers, users can still enable the "xino"
|
||||
feature with the "-o xino=on" overlay mount option. That is useful for the
|
||||
case of underlying filesystems like xfs and tmpfs, which use 64bit inode
|
||||
numbers, but are very unlikely to use the high inode number bit.
|
||||
|
||||
|
||||
Upper and Lower
|
||||
---------------
|
||||
|
||||
|
@ -290,10 +307,19 @@ Non-standard behavior
|
|||
---------------------
|
||||
|
||||
The copy_up operation essentially creates a new, identical file and
|
||||
moves it over to the old name. The new file may be on a different
|
||||
filesystem, so both st_dev and st_ino of the file may change.
|
||||
moves it over to the old name. Any open files referring to this inode
|
||||
will access the old data.
|
||||
|
||||
Any open files referring to this inode will access the old data.
|
||||
The new file may be on a different filesystem, so both st_dev and st_ino
|
||||
of the real file may change. The values of st_dev and st_ino returned by
|
||||
stat(2) on an overlay object are often not the same as the real file
|
||||
stat(2) values to prevent the values from changing on copy_up.
|
||||
|
||||
Unless "xino" feature is enabled, when overlay layers are not all on the
|
||||
same underlying filesystem, the value of st_dev may be different for two
|
||||
non-directory objects in the same overlay filesystem and the value of
|
||||
st_ino for directory objects may be non persistent and could change even
|
||||
while the overlay filesystem is still mounted.
|
||||
|
||||
Unless "inode index" feature is enabled, if a file with multiple hard
|
||||
links is copied up, then this will "break" the link. Changes will not be
|
||||
|
@ -302,6 +328,7 @@ propagated to other names referring to the same inode.
|
|||
Unless "redirect_dir" feature is enabled, rename(2) on a lower or merged
|
||||
directory will fail with EXDEV.
|
||||
|
||||
|
||||
Changes to underlying filesystems
|
||||
---------------------------------
|
||||
|
||||
|
|
|
@ -9,8 +9,8 @@ i2c adapters present on your system at a given time. i2cdetect is part of
|
|||
the i2c-tools package.
|
||||
|
||||
I2C device files are character device files with major device number 89
|
||||
and a minor device number corresponding to the number assigned as
|
||||
explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
|
||||
and a minor device number corresponding to the number assigned as
|
||||
explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
|
||||
i2c-10, ...). All 256 minor device numbers are reserved for i2c.
|
||||
|
||||
|
||||
|
@ -23,11 +23,6 @@ First, you need to include these two headers:
|
|||
#include <linux/i2c-dev.h>
|
||||
#include <i2c/smbus.h>
|
||||
|
||||
(Please note that there are two files named "i2c-dev.h" out there. One is
|
||||
distributed with the Linux kernel and the other one is included in the
|
||||
source tree of i2c-tools. They used to be different in content but since 2012
|
||||
they're identical. You should use "linux/i2c-dev.h").
|
||||
|
||||
Now, you have to decide which adapter you want to access. You should
|
||||
inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
|
||||
Adapter numbers are assigned somewhat dynamically, so you can not
|
||||
|
@ -38,7 +33,7 @@ Next thing, open the device file, as follows:
|
|||
int file;
|
||||
int adapter_nr = 2; /* probably dynamically determined */
|
||||
char filename[20];
|
||||
|
||||
|
||||
snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
|
||||
file = open(filename, O_RDWR);
|
||||
if (file < 0) {
|
||||
|
@ -72,8 +67,10 @@ the device supports them. Both are illustrated below.
|
|||
/* res contains the read word */
|
||||
}
|
||||
|
||||
/* Using I2C Write, equivalent of
|
||||
i2c_smbus_write_word_data(file, reg, 0x6543) */
|
||||
/*
|
||||
* Using I2C Write, equivalent of
|
||||
* i2c_smbus_write_word_data(file, reg, 0x6543)
|
||||
*/
|
||||
buf[0] = reg;
|
||||
buf[1] = 0x43;
|
||||
buf[2] = 0x65;
|
||||
|
@ -140,14 +137,14 @@ ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset)
|
|||
set in each message, overriding the values set with the above ioctl's.
|
||||
|
||||
ioctl(file, I2C_SMBUS, struct i2c_smbus_ioctl_data *args)
|
||||
Not meant to be called directly; instead, use the access functions
|
||||
below.
|
||||
If possible, use the provided i2c_smbus_* methods described below instead
|
||||
of issuing direct ioctls.
|
||||
|
||||
You can do plain i2c transactions by using read(2) and write(2) calls.
|
||||
You do not need to pass the address byte; instead, set it through
|
||||
ioctl I2C_SLAVE before you try to access the device.
|
||||
|
||||
You can do SMBus level transactions (see documentation file smbus-protocol
|
||||
You can do SMBus level transactions (see documentation file smbus-protocol
|
||||
for details) through the following functions:
|
||||
__s32 i2c_smbus_write_quick(int file, __u8 value);
|
||||
__s32 i2c_smbus_read_byte(int file);
|
||||
|
@ -158,7 +155,7 @@ for details) through the following functions:
|
|||
__s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
|
||||
__s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
|
||||
__s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);
|
||||
__s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
|
||||
__s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
|
||||
__u8 *values);
|
||||
All these transactions return -1 on failure; you can read errno to see
|
||||
what happened. The 'write' transactions return 0 on success; the
|
||||
|
@ -166,10 +163,9 @@ what happened. The 'write' transactions return 0 on success; the
|
|||
returns the number of values read. The block buffers need not be longer
|
||||
than 32 bytes.
|
||||
|
||||
The above functions are all inline functions, that resolve to calls to
|
||||
the i2c_smbus_access function, that on its turn calls a specific ioctl
|
||||
with the data in a specific format. Read the source code if you
|
||||
want to know what happens behind the screens.
|
||||
The above functions are made available by linking against the libi2c library,
|
||||
which is provided by the i2c-tools project. See:
|
||||
https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/.
|
||||
|
||||
|
||||
Implementation details
|
||||
|
|
|
@ -217,7 +217,6 @@ Code Seq#(hex) Include File Comments
|
|||
'd' 02-40 pcmcia/ds.h conflict!
|
||||
'd' F0-FF linux/digi1.h
|
||||
'e' all linux/digi1.h conflict!
|
||||
'e' 00-1F drivers/net/irda/irtty-sir.h conflict!
|
||||
'f' 00-1F linux/ext2_fs.h conflict!
|
||||
'f' 00-1F linux/ext3_fs.h conflict!
|
||||
'f' 00-0F fs/jfs/jfs_dinode.h conflict!
|
||||
|
@ -247,7 +246,6 @@ Code Seq#(hex) Include File Comments
|
|||
'm' all linux/synclink.h conflict!
|
||||
'm' 00-19 drivers/message/fusion/mptctl.h conflict!
|
||||
'm' 00 drivers/scsi/megaraid/megaraid_ioctl.h conflict!
|
||||
'm' 00-1F net/irda/irmod.h conflict!
|
||||
'n' 00-7F linux/ncp_fs.h and fs/ncpfs/ioctl.c
|
||||
'n' 80-8F uapi/linux/nilfs2_api.h NILFS2
|
||||
'n' E0-FF linux/matroxfb.h matroxfb
|
||||
|
|
|
@ -34,9 +34,13 @@ meta-data and shadow-data:
|
|||
- data[] - storage for shadow data
|
||||
|
||||
It is important to note that the klp_shadow_alloc() and
|
||||
klp_shadow_get_or_alloc() calls, described below, store a *copy* of the
|
||||
data that the functions are provided. Callers should provide whatever
|
||||
mutual exclusion is required of the shadow data.
|
||||
klp_shadow_get_or_alloc() are zeroing the variable by default.
|
||||
They also allow to call a custom constructor function when a non-zero
|
||||
value is needed. Callers should provide whatever mutual exclusion
|
||||
is required.
|
||||
|
||||
Note that the constructor is called under klp_shadow_lock spinlock. It allows
|
||||
to do actions that can be done only once when a new variable is allocated.
|
||||
|
||||
* klp_shadow_get() - retrieve a shadow variable data pointer
|
||||
- search hashtable for <obj, id> pair
|
||||
|
@ -47,7 +51,7 @@ mutual exclusion is required of the shadow data.
|
|||
- WARN and return NULL
|
||||
- if <obj, id> doesn't already exist
|
||||
- allocate a new shadow variable
|
||||
- copy data into the new shadow variable
|
||||
- initialize the variable using a custom constructor and data when provided
|
||||
- add <obj, id> to the global hashtable
|
||||
|
||||
* klp_shadow_get_or_alloc() - get existing or alloc a new shadow variable
|
||||
|
@ -56,16 +60,20 @@ mutual exclusion is required of the shadow data.
|
|||
- return existing shadow variable
|
||||
- if <obj, id> doesn't already exist
|
||||
- allocate a new shadow variable
|
||||
- copy data into the new shadow variable
|
||||
- initialize the variable using a custom constructor and data when provided
|
||||
- add <obj, id> pair to the global hashtable
|
||||
|
||||
* klp_shadow_free() - detach and free a <obj, id> shadow variable
|
||||
- find and remove a <obj, id> reference from global hashtable
|
||||
- if found, free shadow variable
|
||||
- if found
|
||||
- call destructor function if defined
|
||||
- free shadow variable
|
||||
|
||||
* klp_shadow_free_all() - detach and free all <*, id> shadow variables
|
||||
- find and remove any <*, id> references from global hashtable
|
||||
- if found, free shadow variable
|
||||
- if found
|
||||
- call destructor function if defined
|
||||
- free shadow variable
|
||||
|
||||
|
||||
2. Use cases
|
||||
|
@ -107,7 +115,8 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,
|
|||
sta = kzalloc(sizeof(*sta) + hw->sta_data_size, gfp);
|
||||
|
||||
/* Attach a corresponding shadow variable, then initialize it */
|
||||
ps_lock = klp_shadow_alloc(sta, PS_LOCK, NULL, sizeof(*ps_lock), gfp);
|
||||
ps_lock = klp_shadow_alloc(sta, PS_LOCK, sizeof(*ps_lock), gfp,
|
||||
NULL, NULL);
|
||||
if (!ps_lock)
|
||||
goto shadow_fail;
|
||||
spin_lock_init(ps_lock);
|
||||
|
@ -131,7 +140,7 @@ variable:
|
|||
|
||||
void sta_info_free(struct ieee80211_local *local, struct sta_info *sta)
|
||||
{
|
||||
klp_shadow_free(sta, PS_LOCK);
|
||||
klp_shadow_free(sta, PS_LOCK, NULL);
|
||||
kfree(sta);
|
||||
...
|
||||
|
||||
|
@ -148,16 +157,24 @@ shadow variables to parents already in-flight.
|
|||
For commit 1d147bfa6429, a good spot to allocate a shadow spinlock is
|
||||
inside ieee80211_sta_ps_deliver_wakeup():
|
||||
|
||||
int ps_lock_shadow_ctor(void *obj, void *shadow_data, void *ctor_data)
|
||||
{
|
||||
spinlock_t *lock = shadow_data;
|
||||
|
||||
spin_lock_init(lock);
|
||||
return 0;
|
||||
}
|
||||
|
||||
#define PS_LOCK 1
|
||||
void ieee80211_sta_ps_deliver_wakeup(struct sta_info *sta)
|
||||
{
|
||||
DEFINE_SPINLOCK(ps_lock_fallback);
|
||||
spinlock_t *ps_lock;
|
||||
|
||||
/* sync with ieee80211_tx_h_unicast_ps_buf */
|
||||
ps_lock = klp_shadow_get_or_alloc(sta, PS_LOCK,
|
||||
&ps_lock_fallback, sizeof(ps_lock_fallback),
|
||||
GFP_ATOMIC);
|
||||
sizeof(*ps_lock), GFP_ATOMIC,
|
||||
ps_lock_shadow_ctor, NULL);
|
||||
|
||||
if (ps_lock)
|
||||
spin_lock(ps_lock);
|
||||
...
|
||||
|
|
|
@ -7,7 +7,7 @@ file: uapi/v4l/keytable.c
|
|||
|
||||
/* keytable.c - This program allows checking/replacing keys at IR
|
||||
|
||||
Copyright (C) 2006-2009 Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
Copyright (C) 2006-2009 Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
|
||||
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
|
||||
|
|
|
@ -6,7 +6,7 @@ file: media/v4l/v4l2grab.c
|
|||
.. code-block:: c
|
||||
|
||||
/* V4L2 video picture grabber
|
||||
Copyright (C) 2009 Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
Copyright (C) 2009 Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
|
||||
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
|
||||
|
|
297
Documentation/networking/af_xdp.rst
Normal file
297
Documentation/networking/af_xdp.rst
Normal file
|
@ -0,0 +1,297 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
======
|
||||
AF_XDP
|
||||
======
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
AF_XDP is an address family that is optimized for high performance
|
||||
packet processing.
|
||||
|
||||
This document assumes that the reader is familiar with BPF and XDP. If
|
||||
not, the Cilium project has an excellent reference guide at
|
||||
http://cilium.readthedocs.io/en/doc-1.0/bpf/.
|
||||
|
||||
Using the XDP_REDIRECT action from an XDP program, the program can
|
||||
redirect ingress frames to other XDP enabled netdevs, using the
|
||||
bpf_redirect_map() function. AF_XDP sockets enable the possibility for
|
||||
XDP programs to redirect frames to a memory buffer in a user-space
|
||||
application.
|
||||
|
||||
An AF_XDP socket (XSK) is created with the normal socket()
|
||||
syscall. Associated with each XSK are two rings: the RX ring and the
|
||||
TX ring. A socket can receive packets on the RX ring and it can send
|
||||
packets on the TX ring. These rings are registered and sized with the
|
||||
setsockopts XDP_RX_RING and XDP_TX_RING, respectively. It is mandatory
|
||||
to have at least one of these rings for each socket. An RX or TX
|
||||
descriptor ring points to a data buffer in a memory area called a
|
||||
UMEM. RX and TX can share the same UMEM so that a packet does not have
|
||||
to be copied between RX and TX. Moreover, if a packet needs to be kept
|
||||
for a while due to a possible retransmit, the descriptor that points
|
||||
to that packet can be changed to point to another and reused right
|
||||
away. This again avoids copying data.
|
||||
|
||||
The UMEM consists of a number of equally size frames and each frame
|
||||
has a unique frame id. A descriptor in one of the rings references a
|
||||
frame by referencing its frame id. The user space allocates memory for
|
||||
this UMEM using whatever means it feels is most appropriate (malloc,
|
||||
mmap, huge pages, etc). This memory area is then registered with the
|
||||
kernel using the new setsockopt XDP_UMEM_REG. The UMEM also has two
|
||||
rings: the FILL ring and the COMPLETION ring. The fill ring is used by
|
||||
the application to send down frame ids for the kernel to fill in with
|
||||
RX packet data. References to these frames will then appear in the RX
|
||||
ring once each packet has been received. The completion ring, on the
|
||||
other hand, contains frame ids that the kernel has transmitted
|
||||
completely and can now be used again by user space, for either TX or
|
||||
RX. Thus, the frame ids appearing in the completion ring are ids that
|
||||
were previously transmitted using the TX ring. In summary, the RX and
|
||||
FILL rings are used for the RX path and the TX and COMPLETION rings
|
||||
are used for the TX path.
|
||||
|
||||
The socket is then finally bound with a bind() call to a device and a
|
||||
specific queue id on that device, and it is not until bind is
|
||||
completed that traffic starts to flow.
|
||||
|
||||
The UMEM can be shared between processes, if desired. If a process
|
||||
wants to do this, it simply skips the registration of the UMEM and its
|
||||
corresponding two rings, sets the XDP_SHARED_UMEM flag in the bind
|
||||
call and submits the XSK of the process it would like to share UMEM
|
||||
with as well as its own newly created XSK socket. The new process will
|
||||
then receive frame id references in its own RX ring that point to this
|
||||
shared UMEM. Note that since the ring structures are single-consumer /
|
||||
single-producer (for performance reasons), the new process has to
|
||||
create its own socket with associated RX and TX rings, since it cannot
|
||||
share this with the other process. This is also the reason that there
|
||||
is only one set of FILL and COMPLETION rings per UMEM. It is the
|
||||
responsibility of a single process to handle the UMEM.
|
||||
|
||||
How is then packets distributed from an XDP program to the XSKs? There
|
||||
is a BPF map called XSKMAP (or BPF_MAP_TYPE_XSKMAP in full). The
|
||||
user-space application can place an XSK at an arbitrary place in this
|
||||
map. The XDP program can then redirect a packet to a specific index in
|
||||
this map and at this point XDP validates that the XSK in that map was
|
||||
indeed bound to that device and ring number. If not, the packet is
|
||||
dropped. If the map is empty at that index, the packet is also
|
||||
dropped. This also means that it is currently mandatory to have an XDP
|
||||
program loaded (and one XSK in the XSKMAP) to be able to get any
|
||||
traffic to user space through the XSK.
|
||||
|
||||
AF_XDP can operate in two different modes: XDP_SKB and XDP_DRV. If the
|
||||
driver does not have support for XDP, or XDP_SKB is explicitly chosen
|
||||
when loading the XDP program, XDP_SKB mode is employed that uses SKBs
|
||||
together with the generic XDP support and copies out the data to user
|
||||
space. A fallback mode that works for any network device. On the other
|
||||
hand, if the driver has support for XDP, it will be used by the AF_XDP
|
||||
code to provide better performance, but there is still a copy of the
|
||||
data into user space.
|
||||
|
||||
Concepts
|
||||
========
|
||||
|
||||
In order to use an AF_XDP socket, a number of associated objects need
|
||||
to be setup.
|
||||
|
||||
Jonathan Corbet has also written an excellent article on LWN,
|
||||
"Accelerating networking with AF_XDP". It can be found at
|
||||
https://lwn.net/Articles/750845/.
|
||||
|
||||
UMEM
|
||||
----
|
||||
|
||||
UMEM is a region of virtual contiguous memory, divided into
|
||||
equal-sized frames. An UMEM is associated to a netdev and a specific
|
||||
queue id of that netdev. It is created and configured (frame size,
|
||||
frame headroom, start address and size) by using the XDP_UMEM_REG
|
||||
setsockopt system call. A UMEM is bound to a netdev and queue id, via
|
||||
the bind() system call.
|
||||
|
||||
An AF_XDP is socket linked to a single UMEM, but one UMEM can have
|
||||
multiple AF_XDP sockets. To share an UMEM created via one socket A,
|
||||
the next socket B can do this by setting the XDP_SHARED_UMEM flag in
|
||||
struct sockaddr_xdp member sxdp_flags, and passing the file descriptor
|
||||
of A to struct sockaddr_xdp member sxdp_shared_umem_fd.
|
||||
|
||||
The UMEM has two single-producer/single-consumer rings, that are used
|
||||
to transfer ownership of UMEM frames between the kernel and the
|
||||
user-space application.
|
||||
|
||||
Rings
|
||||
-----
|
||||
|
||||
There are a four different kind of rings: Fill, Completion, RX and
|
||||
TX. All rings are single-producer/single-consumer, so the user-space
|
||||
application need explicit synchronization of multiple
|
||||
processes/threads are reading/writing to them.
|
||||
|
||||
The UMEM uses two rings: Fill and Completion. Each socket associated
|
||||
with the UMEM must have an RX queue, TX queue or both. Say, that there
|
||||
is a setup with four sockets (all doing TX and RX). Then there will be
|
||||
one Fill ring, one Completion ring, four TX rings and four RX rings.
|
||||
|
||||
The rings are head(producer)/tail(consumer) based rings. A producer
|
||||
writes the data ring at the index pointed out by struct xdp_ring
|
||||
producer member, and increasing the producer index. A consumer reads
|
||||
the data ring at the index pointed out by struct xdp_ring consumer
|
||||
member, and increasing the consumer index.
|
||||
|
||||
The rings are configured and created via the _RING setsockopt system
|
||||
calls and mmapped to user-space using the appropriate offset to mmap()
|
||||
(XDP_PGOFF_RX_RING, XDP_PGOFF_TX_RING, XDP_UMEM_PGOFF_FILL_RING and
|
||||
XDP_UMEM_PGOFF_COMPLETION_RING).
|
||||
|
||||
The size of the rings need to be of size power of two.
|
||||
|
||||
UMEM Fill Ring
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
The Fill ring is used to transfer ownership of UMEM frames from
|
||||
user-space to kernel-space. The UMEM indicies are passed in the
|
||||
ring. As an example, if the UMEM is 64k and each frame is 4k, then the
|
||||
UMEM has 16 frames and can pass indicies between 0 and 15.
|
||||
|
||||
Frames passed to the kernel are used for the ingress path (RX rings).
|
||||
|
||||
The user application produces UMEM indicies to this ring.
|
||||
|
||||
UMEM Completetion Ring
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The Completion Ring is used transfer ownership of UMEM frames from
|
||||
kernel-space to user-space. Just like the Fill ring, UMEM indicies are
|
||||
used.
|
||||
|
||||
Frames passed from the kernel to user-space are frames that has been
|
||||
sent (TX ring) and can be used by user-space again.
|
||||
|
||||
The user application consumes UMEM indicies from this ring.
|
||||
|
||||
|
||||
RX Ring
|
||||
~~~~~~~
|
||||
|
||||
The RX ring is the receiving side of a socket. Each entry in the ring
|
||||
is a struct xdp_desc descriptor. The descriptor contains UMEM index
|
||||
(idx), the length of the data (len), the offset into the frame
|
||||
(offset).
|
||||
|
||||
If no frames have been passed to kernel via the Fill ring, no
|
||||
descriptors will (or can) appear on the RX ring.
|
||||
|
||||
The user application consumes struct xdp_desc descriptors from this
|
||||
ring.
|
||||
|
||||
TX Ring
|
||||
~~~~~~~
|
||||
|
||||
The TX ring is used to send frames. The struct xdp_desc descriptor is
|
||||
filled (index, length and offset) and passed into the ring.
|
||||
|
||||
To start the transfer a sendmsg() system call is required. This might
|
||||
be relaxed in the future.
|
||||
|
||||
The user application produces struct xdp_desc descriptors to this
|
||||
ring.
|
||||
|
||||
XSKMAP / BPF_MAP_TYPE_XSKMAP
|
||||
----------------------------
|
||||
|
||||
On XDP side there is a BPF map type BPF_MAP_TYPE_XSKMAP (XSKMAP) that
|
||||
is used in conjunction with bpf_redirect_map() to pass the ingress
|
||||
frame to a socket.
|
||||
|
||||
The user application inserts the socket into the map, via the bpf()
|
||||
system call.
|
||||
|
||||
Note that if an XDP program tries to redirect to a socket that does
|
||||
not match the queue configuration and netdev, the frame will be
|
||||
dropped. E.g. an AF_XDP socket is bound to netdev eth0 and
|
||||
queue 17. Only the XDP program executing for eth0 and queue 17 will
|
||||
successfully pass data to the socket. Please refer to the sample
|
||||
application (samples/bpf/) in for an example.
|
||||
|
||||
Usage
|
||||
=====
|
||||
|
||||
In order to use AF_XDP sockets there are two parts needed. The
|
||||
user-space application and the XDP program. For a complete setup and
|
||||
usage example, please refer to the sample application. The user-space
|
||||
side is xdpsock_user.c and the XDP side xdpsock_kern.c.
|
||||
|
||||
Naive ring dequeue and enqueue could look like this::
|
||||
|
||||
// typedef struct xdp_rxtx_ring RING;
|
||||
// typedef struct xdp_umem_ring RING;
|
||||
|
||||
// typedef struct xdp_desc RING_TYPE;
|
||||
// typedef __u32 RING_TYPE;
|
||||
|
||||
int dequeue_one(RING *ring, RING_TYPE *item)
|
||||
{
|
||||
__u32 entries = ring->ptrs.producer - ring->ptrs.consumer;
|
||||
|
||||
if (entries == 0)
|
||||
return -1;
|
||||
|
||||
// read-barrier!
|
||||
|
||||
*item = ring->desc[ring->ptrs.consumer & (RING_SIZE - 1)];
|
||||
ring->ptrs.consumer++;
|
||||
return 0;
|
||||
}
|
||||
|
||||
int enqueue_one(RING *ring, const RING_TYPE *item)
|
||||
{
|
||||
u32 free_entries = RING_SIZE - (ring->ptrs.producer - ring->ptrs.consumer);
|
||||
|
||||
if (free_entries == 0)
|
||||
return -1;
|
||||
|
||||
ring->desc[ring->ptrs.producer & (RING_SIZE - 1)] = *item;
|
||||
|
||||
// write-barrier!
|
||||
|
||||
ring->ptrs.producer++;
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
||||
For a more optimized version, please refer to the sample application.
|
||||
|
||||
Sample application
|
||||
==================
|
||||
|
||||
There is a xdpsock benchmarking/test application included that
|
||||
demonstrates how to use AF_XDP sockets with both private and shared
|
||||
UMEMs. Say that you would like your UDP traffic from port 4242 to end
|
||||
up in queue 16, that we will enable AF_XDP on. Here, we use ethtool
|
||||
for this::
|
||||
|
||||
ethtool -N p3p2 rx-flow-hash udp4 fn
|
||||
ethtool -N p3p2 flow-type udp4 src-port 4242 dst-port 4242 \
|
||||
action 16
|
||||
|
||||
Running the rxdrop benchmark in XDP_DRV mode can then be done
|
||||
using::
|
||||
|
||||
samples/bpf/xdpsock -i p3p2 -q 16 -r -N
|
||||
|
||||
For XDP_SKB mode, use the switch "-S" instead of "-N" and all options
|
||||
can be displayed with "-h", as usual.
|
||||
|
||||
Credits
|
||||
=======
|
||||
|
||||
- Björn Töpel (AF_XDP core)
|
||||
- Magnus Karlsson (AF_XDP core)
|
||||
- Alexander Duyck
|
||||
- Alexei Starovoitov
|
||||
- Daniel Borkmann
|
||||
- Jesper Dangaard Brouer
|
||||
- John Fastabend
|
||||
- Jonathan Corbet (LWN coverage)
|
||||
- Michael S. Tsirkin
|
||||
- Qi Z Zhang
|
||||
- Willem de Bruijn
|
||||
|
|
@ -140,7 +140,7 @@ bonding module at load time, or are specified via sysfs.
|
|||
|
||||
Module options may be given as command line arguments to the
|
||||
insmod or modprobe command, but are usually specified in either the
|
||||
/etc/modrobe.d/*.conf configuration files, or in a distro-specific
|
||||
/etc/modprobe.d/*.conf configuration files, or in a distro-specific
|
||||
configuration file (some of which are detailed in the next section).
|
||||
|
||||
Details on bonding support for sysfs is provided in the
|
||||
|
|
|
@ -169,7 +169,7 @@ access to BPF code as well.
|
|||
BPF engine and instruction set
|
||||
------------------------------
|
||||
|
||||
Under tools/net/ there's a small helper tool called bpf_asm which can
|
||||
Under tools/bpf/ there's a small helper tool called bpf_asm which can
|
||||
be used to write low-level filters for example scenarios mentioned in the
|
||||
previous section. Asm-like syntax mentioned here has been implemented in
|
||||
bpf_asm and will be used for further explanations (instead of dealing with
|
||||
|
@ -359,7 +359,7 @@ $ ./bpf_asm -c foo
|
|||
In particular, as usage with xt_bpf or cls_bpf can result in more complex BPF
|
||||
filters that might not be obvious at first, it's good to test filters before
|
||||
attaching to a live system. For that purpose, there's a small tool called
|
||||
bpf_dbg under tools/net/ in the kernel source directory. This debugger allows
|
||||
bpf_dbg under tools/bpf/ in the kernel source directory. This debugger allows
|
||||
for testing BPF filters against given pcap files, single stepping through the
|
||||
BPF code on the pcap's packets and to do BPF machine register dumps.
|
||||
|
||||
|
@ -483,7 +483,13 @@ Example output from dmesg:
|
|||
[ 3389.935851] JIT code: 00000030: 00 e8 28 94 ff e0 83 f8 01 75 07 b8 ff ff 00 00
|
||||
[ 3389.935852] JIT code: 00000040: eb 02 31 c0 c9 c3
|
||||
|
||||
In the kernel source tree under tools/net/, there's bpf_jit_disasm for
|
||||
When CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is permanently set to 1 and
|
||||
setting any other value than that will return in failure. This is even the case for
|
||||
setting bpf_jit_enable to 2, since dumping the final JIT image into the kernel log
|
||||
is discouraged and introspection through bpftool (under tools/bpf/bpftool/) is the
|
||||
generally recommended approach instead.
|
||||
|
||||
In the kernel source tree under tools/bpf/, there's bpf_jit_disasm for
|
||||
generating disassembly out of the kernel log's hexdump:
|
||||
|
||||
# ./bpf_jit_disasm
|
||||
|
@ -1136,6 +1142,7 @@ into a register from memory, the register's top 56 bits are known zero, while
|
|||
the low 8 are unknown - which is represented as the tnum (0x0; 0xff). If we
|
||||
then OR this with 0x40, we get (0x40; 0xbf), then if we add 1 we get (0x0;
|
||||
0x1ff), because of potential carries.
|
||||
|
||||
Besides arithmetic, the register state can also be updated by conditional
|
||||
branches. For instance, if a SCALAR_VALUE is compared > 8, in the 'true' branch
|
||||
it will have a umin_value (unsigned minimum value) of 9, whereas in the 'false'
|
||||
|
@ -1144,14 +1151,16 @@ BPF_JSGE) would instead update the signed minimum/maximum values. Information
|
|||
from the signed and unsigned bounds can be combined; for instance if a value is
|
||||
first tested < 8 and then tested s> 4, the verifier will conclude that the value
|
||||
is also > 4 and s< 8, since the bounds prevent crossing the sign boundary.
|
||||
|
||||
PTR_TO_PACKETs with a variable offset part have an 'id', which is common to all
|
||||
pointers sharing that same variable offset. This is important for packet range
|
||||
checks: after adding some variable to a packet pointer, if you then copy it to
|
||||
another register and (say) add a constant 4, both registers will share the same
|
||||
'id' but one will have a fixed offset of +4. Then if it is bounds-checked and
|
||||
found to be less than a PTR_TO_PACKET_END, the other register is now known to
|
||||
have a safe range of at least 4 bytes. See 'Direct packet access', below, for
|
||||
more on PTR_TO_PACKET ranges.
|
||||
checks: after adding a variable to a packet pointer register A, if you then copy
|
||||
it to another register B and then add a constant 4 to A, both registers will
|
||||
share the same 'id' but the A will have a fixed offset of +4. Then if A is
|
||||
bounds-checked and found to be less than a PTR_TO_PACKET_END, the register B is
|
||||
now known to have a safe range of at least 4 bytes. See 'Direct packet access',
|
||||
below, for more on PTR_TO_PACKET ranges.
|
||||
|
||||
The 'id' field is also used on PTR_TO_MAP_VALUE_OR_NULL, common to all copies of
|
||||
the pointer returned from a map lookup. This means that when one copy is
|
||||
checked and found to be non-NULL, all copies can become PTR_TO_MAP_VALUEs.
|
||||
|
|
|
@ -6,6 +6,7 @@ Contents:
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
af_xdp
|
||||
batman-adv
|
||||
can
|
||||
dpaa2/index
|
||||
|
|
|
@ -449,8 +449,10 @@ tcp_recovery - INTEGER
|
|||
features.
|
||||
|
||||
RACK: 0x1 enables the RACK loss detection for fast detection of lost
|
||||
retransmissions and tail drops.
|
||||
retransmissions and tail drops. It also subsumes and disables
|
||||
RFC6675 recovery for SACK connections.
|
||||
RACK: 0x2 makes RACK's reordering window static (min_rtt/4).
|
||||
RACK: 0x4 disables RACK's DUPACK threshold heuristic
|
||||
|
||||
Default: 0x1
|
||||
|
||||
|
@ -523,6 +525,19 @@ tcp_rmem - vector of 3 INTEGERs: min, default, max
|
|||
tcp_sack - BOOLEAN
|
||||
Enable select acknowledgments (SACKS).
|
||||
|
||||
tcp_comp_sack_delay_ns - LONG INTEGER
|
||||
TCP tries to reduce number of SACK sent, using a timer
|
||||
based on 5% of SRTT, capped by this sysctl, in nano seconds.
|
||||
The default is 1ms, based on TSO autosizing period.
|
||||
|
||||
Default : 1,000,000 ns (1 ms)
|
||||
|
||||
tcp_comp_sack_nr - INTEGER
|
||||
Max numer of SACK that can be compressed.
|
||||
Using 0 disables SACK compression.
|
||||
|
||||
Detault : 44
|
||||
|
||||
tcp_slow_start_after_idle - BOOLEAN
|
||||
If set, provide RFC2861 behavior and time out the congestion
|
||||
window after an idle period. An idle period is defined at
|
||||
|
@ -1390,26 +1405,26 @@ mld_qrv - INTEGER
|
|||
Default: 2 (as specified by RFC3810 9.1)
|
||||
Minimum: 1 (as specified by RFC6636 4.5)
|
||||
|
||||
max_dst_opts_cnt - INTEGER
|
||||
max_dst_opts_number - INTEGER
|
||||
Maximum number of non-padding TLVs allowed in a Destination
|
||||
options extension header. If this value is less than zero
|
||||
then unknown options are disallowed and the number of known
|
||||
TLVs allowed is the absolute value of this number.
|
||||
Default: 8
|
||||
|
||||
max_hbh_opts_cnt - INTEGER
|
||||
max_hbh_opts_number - INTEGER
|
||||
Maximum number of non-padding TLVs allowed in a Hop-by-Hop
|
||||
options extension header. If this value is less than zero
|
||||
then unknown options are disallowed and the number of known
|
||||
TLVs allowed is the absolute value of this number.
|
||||
Default: 8
|
||||
|
||||
max dst_opts_len - INTEGER
|
||||
max_dst_opts_length - INTEGER
|
||||
Maximum length allowed for a Destination options extension
|
||||
header.
|
||||
Default: INT_MAX (unlimited)
|
||||
|
||||
max hbh_opts_len - INTEGER
|
||||
max_hbh_length - INTEGER
|
||||
Maximum length allowed for a Hop-by-Hop options extension
|
||||
header.
|
||||
Default: INT_MAX (unlimited)
|
||||
|
@ -1428,6 +1443,19 @@ ip6frag_low_thresh - INTEGER
|
|||
ip6frag_time - INTEGER
|
||||
Time in seconds to keep an IPv6 fragment in memory.
|
||||
|
||||
IPv6 Segment Routing:
|
||||
|
||||
seg6_flowlabel - INTEGER
|
||||
Controls the behaviour of computing the flowlabel of outer
|
||||
IPv6 header in case of SR T.encaps
|
||||
|
||||
-1 set flowlabel to zero.
|
||||
0 copy flowlabel from Inner packet in case of Inner IPv6
|
||||
(Set flowlabel to 0 in case IPv4/L2)
|
||||
1 Compute the flowlabel using seg6_make_flowlabel()
|
||||
|
||||
Default is 0.
|
||||
|
||||
conf/default/*:
|
||||
Change the interface-specific default settings.
|
||||
|
||||
|
@ -2126,18 +2154,3 @@ max_dgram_qlen - INTEGER
|
|||
|
||||
Default: 10
|
||||
|
||||
|
||||
UNDOCUMENTED:
|
||||
|
||||
/proc/sys/net/irda/*
|
||||
fast_poll_increase FIXME
|
||||
warn_noreply_time FIXME
|
||||
discovery_slots FIXME
|
||||
slot_timeout FIXME
|
||||
max_baud_rate FIXME
|
||||
discovery_timeout FIXME
|
||||
lap_keepalive_time FIXME
|
||||
max_noreply_time FIXME
|
||||
max_tx_data_size FIXME
|
||||
max_tx_window FIXME
|
||||
min_tx_turn_time FIXME
|
||||
|
|
|
@ -113,6 +113,13 @@ whatever headers there might be.
|
|||
NETIF_F_TSO_ECN means that hardware can properly split packets with CWR bit
|
||||
set, be it TCPv4 (when NETIF_F_TSO is enabled) or TCPv6 (NETIF_F_TSO6).
|
||||
|
||||
* Transmit UDP segmentation offload
|
||||
|
||||
NETIF_F_GSO_UDP_GSO_L4 accepts a single UDP header with a payload that exceeds
|
||||
gso_size. On segmentation, it segments the payload on gso_size boundaries and
|
||||
replicates the network and UDP headers (fixing up the last one if less than
|
||||
gso_size).
|
||||
|
||||
* Transmit DMA from high memory
|
||||
|
||||
On platforms where this is relevant, NETIF_F_HIGHDMA signals that
|
||||
|
|
|
@ -168,7 +168,7 @@ update on the CPUs, as discussed below:
|
|||
|
||||
[Please bear in mind that the kernel requests the microcode images from
|
||||
userspace, using the request_firmware() function defined in
|
||||
drivers/base/firmware_class.c]
|
||||
drivers/base/firmware_loader/main.c]
|
||||
|
||||
|
||||
a. When all the CPUs are identical:
|
||||
|
|
|
@ -360,7 +360,7 @@ First, the entry in ``arch/x86/entry/syscalls/syscall_32.tbl`` gets an extra
|
|||
column to indicate that a 32-bit userspace program running on a 64-bit kernel
|
||||
should hit the compat entry point::
|
||||
|
||||
380 i386 xyzzy sys_xyzzy compat_sys_xyzzy
|
||||
380 i386 xyzzy sys_xyzzy __ia32_compat_sys_xyzzy
|
||||
|
||||
Second, you need to figure out what should happen for the x32 ABI version of
|
||||
the new system call. There's a choice here: the layout of the arguments
|
||||
|
@ -373,7 +373,7 @@ the compatibility wrapper::
|
|||
|
||||
333 64 xyzzy sys_xyzzy
|
||||
...
|
||||
555 x32 xyzzy compat_sys_xyzzy
|
||||
555 x32 xyzzy __x32_compat_sys_xyzzy
|
||||
|
||||
If no pointers are involved, then it is preferable to re-use the 64-bit system
|
||||
call for the x32 ABI (and consequently the entry in
|
||||
|
|
|
@ -157,8 +157,5 @@ memory management. See ``include/sound/sndmagic.h`` for complete list of them. M
|
|||
OSS sound drivers have their magic numbers constructed from the soundcard PCI
|
||||
ID - these are not listed here as well.
|
||||
|
||||
IrDA subsystem also uses large number of own magic numbers, see
|
||||
``include/net/irda/irda.h`` for a complete list of them.
|
||||
|
||||
HFS is another larger user of magic numbers - you can find them in
|
||||
``fs/hfs/hfs.h``.
|
||||
|
|
|
@ -387,11 +387,11 @@ tree for more details.
|
|||
|
||||
=head1 BUGS
|
||||
|
||||
Report bugs to Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
Report bugs to Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
|
||||
=head1 COPYRIGHT
|
||||
|
||||
Copyright (c) 2016 by Mauro Carvalho Chehab <mchehab@s-opensource.com>.
|
||||
Copyright (c) 2016 by Mauro Carvalho Chehab <mchehab+samsung@kernel.org>.
|
||||
|
||||
License GPLv2: GNU GPL version 2 <http://gnu.org/licenses/gpl.html>.
|
||||
|
||||
|
|
|
@ -45,6 +45,7 @@ through bpf(2) and passing a verifier in the kernel, a JIT will then
|
|||
translate these BPF proglets into native CPU instructions. There are
|
||||
two flavors of JITs, the newer eBPF JIT currently supported on:
|
||||
- x86_64
|
||||
- x86_32
|
||||
- arm64
|
||||
- arm32
|
||||
- ppc64
|
||||
|
|
|
@ -255,6 +255,7 @@ temperature) and throttle appropriate devices.
|
|||
2. sysfs attributes structure
|
||||
|
||||
RO read only value
|
||||
WO write only value
|
||||
RW read/write value
|
||||
|
||||
Thermal sysfs attributes will be represented under /sys/class/thermal.
|
||||
|
@ -286,6 +287,11 @@ Thermal cooling device sys I/F, created once it's registered:
|
|||
|---type: Type of the cooling device(processor/fan/...)
|
||||
|---max_state: Maximum cooling state of the cooling device
|
||||
|---cur_state: Current cooling state of the cooling device
|
||||
|---stats: Directory containing cooling device's statistics
|
||||
|---stats/reset: Writing any value resets the statistics
|
||||
|---stats/time_in_state_ms: Time (msec) spent in various cooling states
|
||||
|---stats/total_trans: Total number of times cooling state is changed
|
||||
|---stats/trans_table: Cooing state transition table
|
||||
|
||||
|
||||
Then next two dynamic attributes are created/removed in pairs. They represent
|
||||
|
@ -490,6 +496,31 @@ cur_state
|
|||
- cur_state == max_state means the maximum cooling.
|
||||
RW, Required
|
||||
|
||||
stats/reset
|
||||
Writing any value resets the cooling device's statistics.
|
||||
WO, Required
|
||||
|
||||
stats/time_in_state_ms:
|
||||
The amount of time spent by the cooling device in various cooling
|
||||
states. The output will have "<state> <time>" pair in each line, which
|
||||
will mean this cooling device spent <time> msec of time at <state>.
|
||||
Output will have one line for each of the supported states. usertime
|
||||
units here is 10mS (similar to other time exported in /proc).
|
||||
RO, Required
|
||||
|
||||
stats/total_trans:
|
||||
A single positive value showing the total number of times the state of a
|
||||
cooling device is changed.
|
||||
RO, Required
|
||||
|
||||
stats/trans_table:
|
||||
This gives fine grained information about all the cooling state
|
||||
transitions. The cat output here is a two dimensional matrix, where an
|
||||
entry <i,j> (row i, column j) represents the number of transitions from
|
||||
State_i to State_j. If the transition table is bigger than PAGE_SIZE,
|
||||
reading this will return an -EFBIG error.
|
||||
RO, Required
|
||||
|
||||
3. A simple implementation
|
||||
|
||||
ACPI thermal zone may support multiple trip points like critical, hot,
|
||||
|
|
|
@ -461,9 +461,17 @@ of ftrace. Here is a list of some of the key files:
|
|||
and ticks at the same rate as the hardware clocksource.
|
||||
|
||||
boot:
|
||||
Same as mono. Used to be a separate clock which accounted
|
||||
for the time spent in suspend while CLOCK_MONOTONIC did
|
||||
not.
|
||||
This is the boot clock (CLOCK_BOOTTIME) and is based on the
|
||||
fast monotonic clock, but also accounts for time spent in
|
||||
suspend. Since the clock access is designed for use in
|
||||
tracing in the suspend path, some side effects are possible
|
||||
if clock is accessed after the suspend time is accounted before
|
||||
the fast mono clock is updated. In this case, the clock update
|
||||
appears to happen slightly sooner than it normally would have.
|
||||
Also on 32-bit systems, it's possible that the 64-bit boot offset
|
||||
sees a partial update. These effects are rare and post
|
||||
processing should be able to handle them. See comments in the
|
||||
ktime_get_boot_fast_ns() function for more information.
|
||||
|
||||
To set a clock, simply echo the clock name into this file::
|
||||
|
||||
|
|
|
@ -6,7 +6,7 @@ communicating in English you can also ask the Chinese maintainer for
|
|||
help. Contact the Chinese maintainer if this translation is outdated
|
||||
or if there is a problem with the translation.
|
||||
|
||||
Maintainer: Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
Maintainer: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
Chinese maintainer: Fu Wei <tekkamanninja@gmail.com>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/video4linux/v4l2-framework.txt 的中文翻译
|
||||
|
@ -14,7 +14,7 @@ Documentation/video4linux/v4l2-framework.txt 的中文翻译
|
|||
如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
译存在问题,请联系中文版维护者。
|
||||
英文版维护者: Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
英文版维护者: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
中文版维护者: 傅炜 Fu Wei <tekkamanninja@gmail.com>
|
||||
中文版翻译者: 傅炜 Fu Wei <tekkamanninja@gmail.com>
|
||||
中文版校译者: 傅炜 Fu Wei <tekkamanninja@gmail.com>
|
||||
|
|
|
@ -1960,6 +1960,9 @@ ARM 32-bit VFP control registers have the following id bit patterns:
|
|||
ARM 64-bit FP registers have the following id bit patterns:
|
||||
0x4030 0000 0012 0 <regno:12>
|
||||
|
||||
ARM firmware pseudo-registers have the following bit pattern:
|
||||
0x4030 0000 0014 <regno:16>
|
||||
|
||||
|
||||
arm64 registers are mapped using the lower 32 bits. The upper 16 of
|
||||
that is the register group type, or coprocessor number:
|
||||
|
@ -1976,6 +1979,9 @@ arm64 CCSIDR registers are demultiplexed by CSSELR value:
|
|||
arm64 system registers have the following id bit patterns:
|
||||
0x6030 0000 0013 <op0:2> <op1:3> <crn:4> <crm:4> <op2:3>
|
||||
|
||||
arm64 firmware pseudo-registers have the following bit pattern:
|
||||
0x6030 0000 0014 <regno:16>
|
||||
|
||||
|
||||
MIPS registers are mapped using the lower 32 bits. The upper 16 of that is
|
||||
the register group type:
|
||||
|
@ -2510,7 +2516,8 @@ Possible features:
|
|||
and execute guest code when KVM_RUN is called.
|
||||
- KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
|
||||
Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
|
||||
- KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for the CPU.
|
||||
- KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 (or a future revision
|
||||
backward compatible with v0.2) for the CPU.
|
||||
Depends on KVM_CAP_ARM_PSCI_0_2.
|
||||
- KVM_ARM_VCPU_PMU_V3: Emulate PMUv3 for the CPU.
|
||||
Depends on KVM_CAP_ARM_PMU_V3.
|
||||
|
|
30
Documentation/virtual/kvm/arm/psci.txt
Normal file
30
Documentation/virtual/kvm/arm/psci.txt
Normal file
|
@ -0,0 +1,30 @@
|
|||
KVM implements the PSCI (Power State Coordination Interface)
|
||||
specification in order to provide services such as CPU on/off, reset
|
||||
and power-off to the guest.
|
||||
|
||||
The PSCI specification is regularly updated to provide new features,
|
||||
and KVM implements these updates if they make sense from a virtualization
|
||||
point of view.
|
||||
|
||||
This means that a guest booted on two different versions of KVM can
|
||||
observe two different "firmware" revisions. This could cause issues if
|
||||
a given guest is tied to a particular PSCI revision (unlikely), or if
|
||||
a migration causes a different PSCI version to be exposed out of the
|
||||
blue to an unsuspecting guest.
|
||||
|
||||
In order to remedy this situation, KVM exposes a set of "firmware
|
||||
pseudo-registers" that can be manipulated using the GET/SET_ONE_REG
|
||||
interface. These registers can be saved/restored by userspace, and set
|
||||
to a convenient value if required.
|
||||
|
||||
The following register is defined:
|
||||
|
||||
* KVM_REG_ARM_PSCI_VERSION:
|
||||
|
||||
- Only valid if the vcpu has the KVM_ARM_VCPU_PSCI_0_2 feature set
|
||||
(and thus has already been initialized)
|
||||
- Returns the current PSCI version on GET_ONE_REG (defaulting to the
|
||||
highest PSCI version implemented by KVM and compatible with v0.2)
|
||||
- Allows any PSCI version implemented by KVM and compatible with
|
||||
v0.2 to be set with SET_ONE_REG
|
||||
- Affects the whole VM (even if the register view is per-vcpu)
|
|
@ -72,8 +72,8 @@ KVM_FEATURE_CLOCKSOURCE_STABLE_BIT || 24 || host will warn if no guest-side
|
|||
|
||||
flag || value || meaning
|
||||
==================================================================================
|
||||
KVM_HINTS_DEDICATED || 0 || guest checks this feature bit to
|
||||
|| || determine if there is vCPU pinning
|
||||
|| || and there is no vCPU over-commitment,
|
||||
KVM_HINTS_REALTIME || 0 || guest checks this feature bit to
|
||||
|| || determine that vCPUs are never
|
||||
|| || preempted for an unlimited time,
|
||||
|| || allowing optimizations
|
||||
----------------------------------------------------------------------------------
|
||||
|
|
|
@ -20,7 +20,7 @@ ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
|
|||
ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
|
||||
... unused hole ...
|
||||
ffffffff80000000 - ffffffff9fffffff (=512 MB) kernel text mapping, from phys 0
|
||||
ffffffffa0000000 - [fixmap start] (~1526 MB) module mapping space (variable)
|
||||
ffffffffa0000000 - fffffffffeffffff (1520 MB) module mapping space
|
||||
[fixmap start] - ffffffffff5fffff kernel-internal fixmap range
|
||||
ffffffffff600000 - ffffffffff600fff (=4 kB) legacy vsyscall ABI
|
||||
ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
|
||||
|
|
232
MAINTAINERS
232
MAINTAINERS
|
@ -137,9 +137,9 @@ Maintainers List (try to look for most precise areas first)
|
|||
-----------------------------------
|
||||
|
||||
3C59X NETWORK DRIVER
|
||||
M: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
|
||||
M: Steffen Klassert <klassert@kernel.org>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
S: Odd Fixes
|
||||
F: Documentation/networking/vortex.txt
|
||||
F: drivers/net/ethernet/3com/3c59x.c
|
||||
|
||||
|
@ -564,8 +564,9 @@ S: Maintained
|
|||
F: drivers/media/dvb-frontends/af9033*
|
||||
|
||||
AFFS FILE SYSTEM
|
||||
M: David Sterba <dsterba@suse.com>
|
||||
L: linux-fsdevel@vger.kernel.org
|
||||
S: Orphan
|
||||
S: Odd Fixes
|
||||
F: Documentation/filesystems/affs.txt
|
||||
F: fs/affs/
|
||||
|
||||
|
@ -905,6 +906,8 @@ ANDROID ION DRIVER
|
|||
M: Laura Abbott <labbott@redhat.com>
|
||||
M: Sumit Semwal <sumit.semwal@linaro.org>
|
||||
L: devel@driverdev.osuosl.org
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
L: linaro-mm-sig@lists.linaro.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
F: drivers/staging/android/ion
|
||||
F: drivers/staging/android/uapi/ion.h
|
||||
|
@ -934,8 +937,8 @@ F: drivers/char/apm-emulation.c
|
|||
APPARMOR SECURITY MODULE
|
||||
M: John Johansen <john.johansen@canonical.com>
|
||||
L: apparmor@lists.ubuntu.com (subscribers-only, general discussion)
|
||||
W: apparmor.wiki.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev.git
|
||||
W: wiki.apparmor.net
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor
|
||||
S: Supported
|
||||
F: security/apparmor/
|
||||
F: Documentation/admin-guide/LSM/apparmor.rst
|
||||
|
@ -1208,7 +1211,6 @@ F: drivers/*/*alpine*
|
|||
ARM/ARTPEC MACHINE SUPPORT
|
||||
M: Jesper Nilsson <jesper.nilsson@axis.com>
|
||||
M: Lars Persson <lars.persson@axis.com>
|
||||
M: Niklas Cassel <niklas.cassel@axis.com>
|
||||
S: Maintained
|
||||
L: linux-arm-kernel@axis.com
|
||||
F: arch/arm/mach-artpec
|
||||
|
@ -1373,7 +1375,8 @@ F: arch/arm/mach-ebsa110/
|
|||
F: drivers/net/ethernet/amd/am79c961a.*
|
||||
|
||||
ARM/ENERGY MICRO (SILICON LABS) EFM32 SUPPORT
|
||||
M: Uwe Kleine-König <kernel@pengutronix.de>
|
||||
M: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
R: Pengutronix Kernel Team <kernel@pengutronix.de>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
N: efm32
|
||||
|
@ -1401,7 +1404,8 @@ F: arch/arm/mach-footbridge/
|
|||
|
||||
ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
|
||||
M: Shawn Guo <shawnguo@kernel.org>
|
||||
M: Sascha Hauer <kernel@pengutronix.de>
|
||||
M: Sascha Hauer <s.hauer@pengutronix.de>
|
||||
R: Pengutronix Kernel Team <kernel@pengutronix.de>
|
||||
R: Fabio Estevam <fabio.estevam@nxp.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
|
@ -1416,7 +1420,8 @@ F: include/soc/imx/
|
|||
|
||||
ARM/FREESCALE VYBRID ARM ARCHITECTURE
|
||||
M: Shawn Guo <shawnguo@kernel.org>
|
||||
M: Sascha Hauer <kernel@pengutronix.de>
|
||||
M: Sascha Hauer <s.hauer@pengutronix.de>
|
||||
R: Pengutronix Kernel Team <kernel@pengutronix.de>
|
||||
R: Stefan Agner <stefan@agner.ch>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
|
@ -2426,7 +2431,6 @@ T: git git://github.com/ndyer/linux.git
|
|||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/input/atmel,maxtouch.txt
|
||||
F: drivers/input/touchscreen/atmel_mxt_ts.c
|
||||
F: include/linux/platform_data/atmel_mxt_ts.h
|
||||
|
||||
ATMEL SAMA5D2 ADC DRIVER
|
||||
M: Ludovic Desroches <ludovic.desroches@microchip.com>
|
||||
|
@ -2550,7 +2554,6 @@ F: Documentation/devicetree/bindings/sound/axentia,*
|
|||
F: sound/soc/atmel/tse850-pcm5142.c
|
||||
|
||||
AZ6007 DVB DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
|
@ -2615,7 +2618,7 @@ S: Maintained
|
|||
F: drivers/net/hamradio/baycom*
|
||||
|
||||
BCACHE (BLOCK LAYER CACHE)
|
||||
M: Michael Lyle <mlyle@lyle.org>
|
||||
M: Coly Li <colyli@suse.de>
|
||||
M: Kent Overstreet <kent.overstreet@gmail.com>
|
||||
L: linux-bcache@vger.kernel.org
|
||||
W: http://bcache.evilpiepirate.org
|
||||
|
@ -2725,7 +2728,6 @@ F: Documentation/networking/filter.txt
|
|||
F: Documentation/bpf/
|
||||
F: include/linux/bpf*
|
||||
F: include/linux/filter.h
|
||||
F: include/trace/events/bpf.h
|
||||
F: include/trace/events/xdp.h
|
||||
F: include/uapi/linux/bpf*
|
||||
F: include/uapi/linux/filter.h
|
||||
|
@ -3079,7 +3081,6 @@ F: include/linux/btrfs*
|
|||
F: include/uapi/linux/btrfs*
|
||||
|
||||
BTTV VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
|
@ -3689,7 +3690,6 @@ F: drivers/cpufreq/arm_big_little_dt.c
|
|||
|
||||
CPU POWER MONITORING SUBSYSTEM
|
||||
M: Thomas Renninger <trenn@suse.com>
|
||||
M: Shuah Khan <shuahkh@osg.samsung.com>
|
||||
M: Shuah Khan <shuah@kernel.org>
|
||||
L: linux-pm@vger.kernel.org
|
||||
S: Maintained
|
||||
|
@ -3808,7 +3808,6 @@ S: Maintained
|
|||
F: drivers/media/dvb-frontends/cx24120*
|
||||
|
||||
CX88 VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
|
@ -4246,6 +4245,9 @@ F: include/trace/events/fs_dax.h
|
|||
|
||||
DEVICE DIRECT ACCESS (DAX)
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
M: Dave Jiang <dave.jiang@intel.com>
|
||||
M: Ross Zwisler <ross.zwisler@linux.intel.com>
|
||||
M: Vishal Verma <vishal.l.verma@intel.com>
|
||||
L: linux-nvdimm@lists.01.org
|
||||
S: Supported
|
||||
F: drivers/dax/
|
||||
|
@ -4306,7 +4308,7 @@ F: Documentation/driver-api/dma-buf.rst
|
|||
T: git git://anongit.freedesktop.org/drm/drm-misc
|
||||
|
||||
DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
|
||||
M: Vinod Koul <vinod.koul@intel.com>
|
||||
M: Vinod Koul <vkoul@kernel.org>
|
||||
L: dmaengine@vger.kernel.org
|
||||
Q: https://patchwork.kernel.org/project/linux-dmaengine/list/
|
||||
S: Maintained
|
||||
|
@ -5046,7 +5048,6 @@ F: drivers/edac/thunderx_edac*
|
|||
|
||||
EDAC-CORE
|
||||
M: Borislav Petkov <bp@alien8.de>
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-edac@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git for-next
|
||||
|
@ -5075,7 +5076,6 @@ S: Maintained
|
|||
F: drivers/edac/fsl_ddr_edac.*
|
||||
|
||||
EDAC-GHES
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-edac@vger.kernel.org
|
||||
S: Maintained
|
||||
|
@ -5092,21 +5092,18 @@ S: Maintained
|
|||
F: drivers/edac/i5000_edac.c
|
||||
|
||||
EDAC-I5400
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-edac@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/edac/i5400_edac.c
|
||||
|
||||
EDAC-I7300
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-edac@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/edac/i7300_edac.c
|
||||
|
||||
EDAC-I7CORE
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-edac@vger.kernel.org
|
||||
S: Maintained
|
||||
|
@ -5156,7 +5153,6 @@ S: Maintained
|
|||
F: drivers/edac/r82600_edac.c
|
||||
|
||||
EDAC-SBRIDGE
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-edac@vger.kernel.org
|
||||
S: Maintained
|
||||
|
@ -5215,7 +5211,6 @@ S: Maintained
|
|||
F: drivers/net/ethernet/ibm/ehea/
|
||||
|
||||
EM28XX VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
|
@ -5321,7 +5316,6 @@ F: include/linux/*mdio*.h
|
|||
F: include/linux/of_net.h
|
||||
F: include/linux/phy.h
|
||||
F: include/linux/phy_fixed.h
|
||||
F: include/linux/platform_data/mdio-gpio.h
|
||||
F: include/linux/platform_data/mdio-bcm-unimac.h
|
||||
F: include/trace/events/mdio.h
|
||||
F: include/uapi/linux/mdio.h
|
||||
|
@ -5653,7 +5647,8 @@ F: drivers/net/ethernet/freescale/fec.h
|
|||
F: Documentation/devicetree/bindings/net/fsl-fec.txt
|
||||
|
||||
FREESCALE IMX / MXC FRAMEBUFFER DRIVER
|
||||
M: Sascha Hauer <kernel@pengutronix.de>
|
||||
M: Sascha Hauer <s.hauer@pengutronix.de>
|
||||
R: Pengutronix Kernel Team <kernel@pengutronix.de>
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
|
@ -5785,6 +5780,14 @@ F: fs/crypto/
|
|||
F: include/linux/fscrypt*.h
|
||||
F: Documentation/filesystems/fscrypt.rst
|
||||
|
||||
FSNOTIFY: FILESYSTEM NOTIFICATION INFRASTRUCTURE
|
||||
M: Jan Kara <jack@suse.cz>
|
||||
R: Amir Goldstein <amir73il@gmail.com>
|
||||
L: linux-fsdevel@vger.kernel.org
|
||||
S: Maintained
|
||||
F: fs/notify/
|
||||
F: include/linux/fsnotify*.h
|
||||
|
||||
FUJITSU LAPTOP EXTRAS
|
||||
M: Jonathan Woithe <jwoithe@just42.net>
|
||||
L: platform-driver-x86@vger.kernel.org
|
||||
|
@ -5843,7 +5846,7 @@ F: scripts/Makefile.gcc-plugins
|
|||
F: Documentation/gcc-plugins.txt
|
||||
|
||||
GCOV BASED KERNEL PROFILING
|
||||
M: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
|
||||
M: Peter Oberparleiter <oberpar@linux.ibm.com>
|
||||
S: Maintained
|
||||
F: kernel/gcov/
|
||||
F: Documentation/dev-tools/gcov.rst
|
||||
|
@ -5911,6 +5914,11 @@ S: Supported
|
|||
F: drivers/phy/
|
||||
F: include/linux/phy/
|
||||
|
||||
GENERIC PINCTRL I2C DEMULTIPLEXER DRIVER
|
||||
M: Wolfram Sang <wsa+renesas@sang-engineering.com>
|
||||
S: Supported
|
||||
F: drivers/i2c/muxes/i2c-demux-pinctrl.c
|
||||
|
||||
GENERIC PM DOMAINS
|
||||
M: "Rafael J. Wysocki" <rjw@rjwysocki.net>
|
||||
M: Kevin Hilman <khilman@kernel.org>
|
||||
|
@ -6252,7 +6260,7 @@ S: Odd Fixes
|
|||
F: drivers/media/usb/hdpvr/
|
||||
|
||||
HEWLETT PACKARD ENTERPRISE ILO NMI WATCHDOG DRIVER
|
||||
M: Jimmy Vance <jimmy.vance@hpe.com>
|
||||
M: Jerry Hoemann <jerry.hoemann@hpe.com>
|
||||
S: Supported
|
||||
F: Documentation/watchdog/hpwdt.txt
|
||||
F: drivers/watchdog/hpwdt.c
|
||||
|
@ -6586,15 +6594,25 @@ W: https://i2c.wiki.kernel.org/
|
|||
Q: https://patchwork.ozlabs.org/project/linux-i2c/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/i2c/
|
||||
F: Documentation/devicetree/bindings/i2c/i2c.txt
|
||||
F: Documentation/i2c/
|
||||
F: drivers/i2c/
|
||||
F: drivers/i2c/*/
|
||||
F: drivers/i2c/*
|
||||
F: include/linux/i2c.h
|
||||
F: include/linux/i2c-*.h
|
||||
F: include/linux/i2c-dev.h
|
||||
F: include/linux/i2c-smbus.h
|
||||
F: include/uapi/linux/i2c.h
|
||||
F: include/uapi/linux/i2c-*.h
|
||||
|
||||
I2C SUBSYSTEM HOST DRIVERS
|
||||
L: linux-i2c@vger.kernel.org
|
||||
W: https://i2c.wiki.kernel.org/
|
||||
Q: https://patchwork.ozlabs.org/project/linux-i2c/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
|
||||
S: Odd Fixes
|
||||
F: Documentation/devicetree/bindings/i2c/
|
||||
F: drivers/i2c/algos/
|
||||
F: drivers/i2c/busses/
|
||||
|
||||
I2C-TAOS-EVM DRIVER
|
||||
M: Jean Delvare <jdelvare@suse.com>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
|
@ -7382,16 +7400,6 @@ S: Obsolete
|
|||
F: include/uapi/linux/ipx.h
|
||||
F: drivers/staging/ipx/
|
||||
|
||||
IRDA SUBSYSTEM
|
||||
M: Samuel Ortiz <samuel@sortiz.org>
|
||||
L: irda-users@lists.sourceforge.net (subscribers-only)
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://irda.sourceforge.net/
|
||||
S: Obsolete
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/irda-2.6.git
|
||||
F: Documentation/networking/irda.txt
|
||||
F: drivers/staging/irda/
|
||||
|
||||
IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY)
|
||||
M: Marc Zyngier <marc.zyngier@arm.com>
|
||||
S: Maintained
|
||||
|
@ -7656,9 +7664,11 @@ L: linux-kbuild@vger.kernel.org
|
|||
S: Maintained
|
||||
F: Documentation/kbuild/
|
||||
F: Makefile
|
||||
F: scripts/Makefile.*
|
||||
F: scripts/Kbuild*
|
||||
F: scripts/Makefile*
|
||||
F: scripts/basic/
|
||||
F: scripts/mk*
|
||||
F: scripts/mod/
|
||||
F: scripts/package/
|
||||
|
||||
KERNEL JANITORS
|
||||
|
@ -7683,10 +7693,10 @@ F: include/linux/sunrpc/
|
|||
F: include/uapi/linux/sunrpc/
|
||||
|
||||
KERNEL SELFTEST FRAMEWORK
|
||||
M: Shuah Khan <shuahkh@osg.samsung.com>
|
||||
M: Shuah Khan <shuah@kernel.org>
|
||||
L: linux-kselftest@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git
|
||||
Q: https://patchwork.kernel.org/project/linux-kselftest/list/
|
||||
S: Maintained
|
||||
F: tools/testing/selftests/
|
||||
F: Documentation/dev-tools/kselftest*
|
||||
|
@ -7724,7 +7734,7 @@ F: arch/x86/include/asm/svm.h
|
|||
F: arch/x86/kvm/svm.c
|
||||
|
||||
KERNEL VIRTUAL MACHINE FOR ARM (KVM/arm)
|
||||
M: Christoffer Dall <christoffer.dall@linaro.org>
|
||||
M: Christoffer Dall <christoffer.dall@arm.com>
|
||||
M: Marc Zyngier <marc.zyngier@arm.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: kvmarm@lists.cs.columbia.edu
|
||||
|
@ -7738,7 +7748,7 @@ F: virt/kvm/arm/
|
|||
F: include/kvm/arm_*
|
||||
|
||||
KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
|
||||
M: Christoffer Dall <christoffer.dall@linaro.org>
|
||||
M: Christoffer Dall <christoffer.dall@arm.com>
|
||||
M: Marc Zyngier <marc.zyngier@arm.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: kvmarm@lists.cs.columbia.edu
|
||||
|
@ -7768,7 +7778,7 @@ F: arch/powerpc/kernel/kvm*
|
|||
|
||||
KERNEL VIRTUAL MACHINE for s390 (KVM/s390)
|
||||
M: Christian Borntraeger <borntraeger@de.ibm.com>
|
||||
M: Janosch Frank <frankja@linux.vnet.ibm.com>
|
||||
M: Janosch Frank <frankja@linux.ibm.com>
|
||||
R: David Hildenbrand <david@redhat.com>
|
||||
R: Cornelia Huck <cohuck@redhat.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
|
@ -8034,6 +8044,9 @@ F: tools/lib/lockdep/
|
|||
|
||||
LIBNVDIMM BLK: MMIO-APERTURE DRIVER
|
||||
M: Ross Zwisler <ross.zwisler@linux.intel.com>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
M: Vishal Verma <vishal.l.verma@intel.com>
|
||||
M: Dave Jiang <dave.jiang@intel.com>
|
||||
L: linux-nvdimm@lists.01.org
|
||||
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
|
||||
S: Supported
|
||||
|
@ -8042,6 +8055,9 @@ F: drivers/nvdimm/region_devs.c
|
|||
|
||||
LIBNVDIMM BTT: BLOCK TRANSLATION TABLE
|
||||
M: Vishal Verma <vishal.l.verma@intel.com>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
M: Ross Zwisler <ross.zwisler@linux.intel.com>
|
||||
M: Dave Jiang <dave.jiang@intel.com>
|
||||
L: linux-nvdimm@lists.01.org
|
||||
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
|
||||
S: Supported
|
||||
|
@ -8049,6 +8065,9 @@ F: drivers/nvdimm/btt*
|
|||
|
||||
LIBNVDIMM PMEM: PERSISTENT MEMORY DRIVER
|
||||
M: Ross Zwisler <ross.zwisler@linux.intel.com>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
M: Vishal Verma <vishal.l.verma@intel.com>
|
||||
M: Dave Jiang <dave.jiang@intel.com>
|
||||
L: linux-nvdimm@lists.01.org
|
||||
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
|
||||
S: Supported
|
||||
|
@ -8064,6 +8083,9 @@ F: Documentation/devicetree/bindings/pmem/pmem-region.txt
|
|||
|
||||
LIBNVDIMM: NON-VOLATILE MEMORY DEVICE SUBSYSTEM
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
M: Ross Zwisler <ross.zwisler@linux.intel.com>
|
||||
M: Vishal Verma <vishal.l.verma@intel.com>
|
||||
M: Dave Jiang <dave.jiang@intel.com>
|
||||
L: linux-nvdimm@lists.01.org
|
||||
Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
|
||||
|
@ -8443,6 +8465,7 @@ M: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
|
|||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/dsa/mv88e6xxx/
|
||||
F: linux/platform_data/mv88e6xxx.h
|
||||
F: Documentation/devicetree/bindings/net/dsa/marvell.txt
|
||||
|
||||
MARVELL ARMADA DRM SUPPORT
|
||||
|
@ -8838,7 +8861,6 @@ F: Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
|
|||
F: drivers/staging/media/tegra-vde/
|
||||
|
||||
MEDIA INPUT INFRASTRUCTURE (V4L/DVB)
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
P: LinuxTV.org Project
|
||||
L: linux-media@vger.kernel.org
|
||||
|
@ -8997,26 +9019,17 @@ W: http://www.mellanox.com
|
|||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
F: drivers/net/ethernet/mellanox/mlx5/core/en_*
|
||||
|
||||
MELLANOX ETHERNET INNOVA DRIVER
|
||||
M: Ilan Tayari <ilant@mellanox.com>
|
||||
R: Boris Pismenny <borisp@mellanox.com>
|
||||
MELLANOX ETHERNET INNOVA DRIVERS
|
||||
M: Boris Pismenny <borisp@mellanox.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.mellanox.com
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
F: drivers/net/ethernet/mellanox/mlx5/core/en_accel/*
|
||||
F: drivers/net/ethernet/mellanox/mlx5/core/accel/*
|
||||
F: drivers/net/ethernet/mellanox/mlx5/core/fpga/*
|
||||
F: include/linux/mlx5/mlx5_ifc_fpga.h
|
||||
|
||||
MELLANOX ETHERNET INNOVA IPSEC DRIVER
|
||||
M: Ilan Tayari <ilant@mellanox.com>
|
||||
R: Boris Pismenny <borisp@mellanox.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://www.mellanox.com
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
F: drivers/net/ethernet/mellanox/mlx5/core/en_ipsec/*
|
||||
F: drivers/net/ethernet/mellanox/mlx5/core/ipsec*
|
||||
|
||||
MELLANOX ETHERNET SWITCH DRIVERS
|
||||
M: Jiri Pirko <jiri@mellanox.com>
|
||||
M: Ido Schimmel <idosch@mellanox.com>
|
||||
|
@ -9266,6 +9279,12 @@ F: include/linux/cciss*.h
|
|||
F: include/uapi/linux/cciss*.h
|
||||
F: Documentation/scsi/smartpqi.txt
|
||||
|
||||
MICROSEMI ETHERNET SWITCH DRIVER
|
||||
M: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/mscc/
|
||||
|
||||
MICROSOFT SURFACE PRO 3 BUTTON DRIVER
|
||||
M: Chen Yu <yu.c.chen@intel.com>
|
||||
L: platform-driver-x86@vger.kernel.org
|
||||
|
@ -9692,6 +9711,7 @@ W: https://fedorahosted.org/dropwatch/
|
|||
F: net/core/drop_monitor.c
|
||||
|
||||
NETWORKING DRIVERS
|
||||
M: "David S. Miller" <davem@davemloft.net>
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://www.linuxfoundation.org/en/Net
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
|
@ -9751,6 +9771,7 @@ F: include/uapi/linux/net_namespace.h
|
|||
F: tools/testing/selftests/net/
|
||||
F: lib/net_utils.c
|
||||
F: lib/random32.c
|
||||
F: Documentation/networking/
|
||||
|
||||
NETWORKING [IPSEC]
|
||||
M: Steffen Klassert <steffen.klassert@secunet.com>
|
||||
|
@ -9807,7 +9828,7 @@ F: net/netfilter/xt_CONNSECMARK.c
|
|||
F: net/netfilter/xt_SECMARK.c
|
||||
|
||||
NETWORKING [TLS]
|
||||
M: Ilya Lesokhin <ilyal@mellanox.com>
|
||||
M: Boris Pismenny <borisp@mellanox.com>
|
||||
M: Aviad Yehezkel <aviadye@mellanox.com>
|
||||
M: Dave Watson <davejwatson@fb.com>
|
||||
L: netdev@vger.kernel.org
|
||||
|
@ -9847,7 +9868,7 @@ F: include/linux/platform_data/nxp-nci.h
|
|||
F: Documentation/devicetree/bindings/net/nfc/
|
||||
|
||||
NFS, SUNRPC, AND LOCKD CLIENTS
|
||||
M: Trond Myklebust <trond.myklebust@primarydata.com>
|
||||
M: Trond Myklebust <trond.myklebust@hammerspace.com>
|
||||
M: Anna Schumaker <anna.schumaker@netapp.com>
|
||||
L: linux-nfs@vger.kernel.org
|
||||
W: http://client.linux-nfs.org
|
||||
|
@ -10867,7 +10888,6 @@ F: drivers/pci/host/
|
|||
F: drivers/pci/dwc/
|
||||
|
||||
PCIE DRIVER FOR AXIS ARTPEC
|
||||
M: Niklas Cassel <niklas.cassel@axis.com>
|
||||
M: Jesper Nilsson <jesper.nilsson@axis.com>
|
||||
L: linux-arm-kernel@axis.com
|
||||
L: linux-pci@vger.kernel.org
|
||||
|
@ -11906,6 +11926,11 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git c
|
|||
S: Supported
|
||||
F: drivers/clk/renesas/
|
||||
|
||||
RENESAS EMEV2 I2C DRIVER
|
||||
M: Wolfram Sang <wsa+renesas@sang-engineering.com>
|
||||
S: Supported
|
||||
F: drivers/i2c/busses/i2c-emev2.c
|
||||
|
||||
RENESAS ETHERNET DRIVERS
|
||||
R: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
|
||||
L: netdev@vger.kernel.org
|
||||
|
@ -11921,6 +11946,12 @@ L: linux-iio@vger.kernel.org
|
|||
S: Supported
|
||||
F: drivers/iio/adc/rcar_gyro_adc.c
|
||||
|
||||
RENESAS R-CAR I2C DRIVERS
|
||||
M: Wolfram Sang <wsa+renesas@sang-engineering.com>
|
||||
S: Supported
|
||||
F: drivers/i2c/busses/i2c-rcar.c
|
||||
F: drivers/i2c/busses/i2c-sh_mobile.c
|
||||
|
||||
RENESAS USB PHY DRIVER
|
||||
M: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
|
||||
L: linux-renesas-soc@vger.kernel.org
|
||||
|
@ -12124,16 +12155,16 @@ F: Documentation/s390/
|
|||
F: Documentation/driver-api/s390-drivers.rst
|
||||
|
||||
S390 COMMON I/O LAYER
|
||||
M: Sebastian Ott <sebott@linux.vnet.ibm.com>
|
||||
M: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
|
||||
M: Sebastian Ott <sebott@linux.ibm.com>
|
||||
M: Peter Oberparleiter <oberpar@linux.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
W: http://www.ibm.com/developerworks/linux/linux390/
|
||||
S: Supported
|
||||
F: drivers/s390/cio/
|
||||
|
||||
S390 DASD DRIVER
|
||||
M: Stefan Haberland <sth@linux.vnet.ibm.com>
|
||||
M: Jan Hoeppner <hoeppner@linux.vnet.ibm.com>
|
||||
M: Stefan Haberland <sth@linux.ibm.com>
|
||||
M: Jan Hoeppner <hoeppner@linux.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
W: http://www.ibm.com/developerworks/linux/linux390/
|
||||
S: Supported
|
||||
|
@ -12148,8 +12179,8 @@ S: Supported
|
|||
F: drivers/iommu/s390-iommu.c
|
||||
|
||||
S390 IUCV NETWORK LAYER
|
||||
M: Julian Wiedmann <jwi@linux.vnet.ibm.com>
|
||||
M: Ursula Braun <ubraun@linux.vnet.ibm.com>
|
||||
M: Julian Wiedmann <jwi@linux.ibm.com>
|
||||
M: Ursula Braun <ubraun@linux.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
W: http://www.ibm.com/developerworks/linux/linux390/
|
||||
S: Supported
|
||||
|
@ -12158,15 +12189,15 @@ F: include/net/iucv/
|
|||
F: net/iucv/
|
||||
|
||||
S390 NETWORK DRIVERS
|
||||
M: Julian Wiedmann <jwi@linux.vnet.ibm.com>
|
||||
M: Ursula Braun <ubraun@linux.vnet.ibm.com>
|
||||
M: Julian Wiedmann <jwi@linux.ibm.com>
|
||||
M: Ursula Braun <ubraun@linux.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
W: http://www.ibm.com/developerworks/linux/linux390/
|
||||
S: Supported
|
||||
F: drivers/s390/net/
|
||||
|
||||
S390 PCI SUBSYSTEM
|
||||
M: Sebastian Ott <sebott@linux.vnet.ibm.com>
|
||||
M: Sebastian Ott <sebott@linux.ibm.com>
|
||||
M: Gerald Schaefer <gerald.schaefer@de.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
W: http://www.ibm.com/developerworks/linux/linux390/
|
||||
|
@ -12176,8 +12207,8 @@ F: drivers/pci/hotplug/s390_pci_hpc.c
|
|||
|
||||
S390 VFIO-CCW DRIVER
|
||||
M: Cornelia Huck <cohuck@redhat.com>
|
||||
M: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
|
||||
M: Halil Pasic <pasic@linux.vnet.ibm.com>
|
||||
M: Dong Jia Shi <bjsdjshi@linux.ibm.com>
|
||||
M: Halil Pasic <pasic@linux.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
L: kvm@vger.kernel.org
|
||||
S: Supported
|
||||
|
@ -12186,15 +12217,15 @@ F: Documentation/s390/vfio-ccw.txt
|
|||
F: include/uapi/linux/vfio_ccw.h
|
||||
|
||||
S390 ZCRYPT DRIVER
|
||||
M: Harald Freudenberger <freude@de.ibm.com>
|
||||
M: Harald Freudenberger <freude@linux.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
W: http://www.ibm.com/developerworks/linux/linux390/
|
||||
S: Supported
|
||||
F: drivers/s390/crypto/
|
||||
|
||||
S390 ZFCP DRIVER
|
||||
M: Steffen Maier <maier@linux.vnet.ibm.com>
|
||||
M: Benjamin Block <bblock@linux.vnet.ibm.com>
|
||||
M: Steffen Maier <maier@linux.ibm.com>
|
||||
M: Benjamin Block <bblock@linux.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
W: http://www.ibm.com/developerworks/linux/linux390/
|
||||
S: Supported
|
||||
|
@ -12215,7 +12246,6 @@ S: Odd Fixes
|
|||
F: drivers/media/i2c/saa6588*
|
||||
|
||||
SAA7134 VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
|
@ -12339,6 +12369,7 @@ M: Tomasz Figa <tomasz.figa@gmail.com>
|
|||
M: Chanwoo Choi <cw00.choi@samsung.com>
|
||||
S: Supported
|
||||
L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/snawrocki/clk.git
|
||||
F: drivers/clk/samsung/
|
||||
F: include/dt-bindings/clock/exynos*.h
|
||||
F: Documentation/devicetree/bindings/clock/exynos*.txt
|
||||
|
@ -12453,6 +12484,7 @@ F: drivers/scsi/st_*.h
|
|||
SCTP PROTOCOL
|
||||
M: Vlad Yasevich <vyasevich@gmail.com>
|
||||
M: Neil Horman <nhorman@tuxdriver.com>
|
||||
M: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
|
||||
L: linux-sctp@vger.kernel.org
|
||||
W: http://lksctp.sourceforge.net
|
||||
S: Maintained
|
||||
|
@ -12630,7 +12662,7 @@ S: Maintained
|
|||
F: drivers/misc/sgi-xp/
|
||||
|
||||
SHARED MEMORY COMMUNICATIONS (SMC) SOCKETS
|
||||
M: Ursula Braun <ubraun@linux.vnet.ibm.com>
|
||||
M: Ursula Braun <ubraun@linux.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
W: http://www.ibm.com/developerworks/linux/linux390/
|
||||
S: Supported
|
||||
|
@ -12718,7 +12750,6 @@ S: Maintained
|
|||
F: drivers/media/radio/si4713/radio-usb-si4713.c
|
||||
|
||||
SIANO DVB DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
|
@ -12790,7 +12821,8 @@ F: include/linux/siphash.h
|
|||
|
||||
SIOX
|
||||
M: Gavin Schenk <g.schenk@eckelmann.de>
|
||||
M: Uwe Kleine-König <kernel@pengutronix.de>
|
||||
M: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
R: Pengutronix Kernel Team <kernel@pengutronix.de>
|
||||
S: Supported
|
||||
F: drivers/siox/*
|
||||
F: include/trace/events/siox.h
|
||||
|
@ -13229,6 +13261,12 @@ M: Jan-Benedict Glaw <jbglaw@lug-owl.de>
|
|||
S: Maintained
|
||||
F: arch/alpha/kernel/srm_env.c
|
||||
|
||||
ST STM32 I2C/SMBUS DRIVER
|
||||
M: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/i2c/busses/i2c-stm32*
|
||||
|
||||
STABLE BRANCH
|
||||
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
L: stable@vger.kernel.org
|
||||
|
@ -13359,6 +13397,7 @@ F: drivers/media/usb/stk1160/
|
|||
STMMAC ETHERNET DRIVER
|
||||
M: Giuseppe Cavallaro <peppe.cavallaro@st.com>
|
||||
M: Alexandre Torgue <alexandre.torgue@st.com>
|
||||
M: Jose Abreu <joabreu@synopsys.com>
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://www.stlinux.com
|
||||
S: Supported
|
||||
|
@ -13708,7 +13747,6 @@ S: Maintained
|
|||
F: drivers/media/i2c/tda9840*
|
||||
|
||||
TEA5761 TUNER DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
|
@ -13717,7 +13755,6 @@ S: Odd fixes
|
|||
F: drivers/media/tuners/tea5761.*
|
||||
|
||||
TEA5767 TUNER DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
|
@ -13807,7 +13844,6 @@ S: Supported
|
|||
F: drivers/iommu/tegra*
|
||||
|
||||
TEGRA KBC DRIVER
|
||||
M: Rakesh Iyer <riyer@nvidia.com>
|
||||
M: Laxman Dewangan <ldewangan@nvidia.com>
|
||||
S: Supported
|
||||
F: drivers/input/keyboard/tegra-kbc.c
|
||||
|
@ -13910,7 +13946,7 @@ THUNDERBOLT DRIVER
|
|||
M: Andreas Noever <andreas.noever@gmail.com>
|
||||
M: Michael Jamet <michael.jamet@intel.com>
|
||||
M: Mika Westerberg <mika.westerberg@linux.intel.com>
|
||||
M: Yehezkel Bernat <yehezkel.bernat@intel.com>
|
||||
M: Yehezkel Bernat <YehezkelShB@gmail.com>
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git
|
||||
S: Maintained
|
||||
F: Documentation/admin-guide/thunderbolt.rst
|
||||
|
@ -13920,7 +13956,7 @@ F: include/linux/thunderbolt.h
|
|||
THUNDERBOLT NETWORK DRIVER
|
||||
M: Michael Jamet <michael.jamet@intel.com>
|
||||
M: Mika Westerberg <mika.westerberg@linux.intel.com>
|
||||
M: Yehezkel Bernat <yehezkel.bernat@intel.com>
|
||||
M: Yehezkel Bernat <YehezkelShB@gmail.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/thunderbolt.c
|
||||
|
@ -13975,6 +14011,13 @@ F: arch/arm/mach-davinci/
|
|||
F: drivers/i2c/busses/i2c-davinci.c
|
||||
F: arch/arm/boot/dts/da850*
|
||||
|
||||
TI DAVINCI SERIES CLOCK DRIVER
|
||||
M: David Lechner <david@lechnology.com>
|
||||
R: Sekhar Nori <nsekhar@ti.com>
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/clock/ti/davinci/
|
||||
F: drivers/clk/davinci/
|
||||
|
||||
TI DAVINCI SERIES GPIO DRIVER
|
||||
M: Keerthy <j-keerthy@ti.com>
|
||||
L: linux-gpio@vger.kernel.org
|
||||
|
@ -14127,7 +14170,6 @@ F: Documentation/networking/tlan.txt
|
|||
F: drivers/net/ethernet/ti/tlan.*
|
||||
|
||||
TM6000 VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
|
@ -14572,7 +14614,9 @@ M: Woojung Huh <woojung.huh@microchip.com>
|
|||
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/net/microchip,lan78xx.txt
|
||||
F: drivers/net/usb/lan78xx.*
|
||||
F: include/dt-bindings/net/microchip-lan78xx.h
|
||||
|
||||
USB MASS STORAGE DRIVER
|
||||
M: Alan Stern <stern@rowland.harvard.edu>
|
||||
|
@ -14610,7 +14654,6 @@ F: drivers/usb/common/usb-otg-fsm.c
|
|||
|
||||
USB OVER IP DRIVER
|
||||
M: Valentina Manea <valentina.manea.m@gmail.com>
|
||||
M: Shuah Khan <shuahkh@osg.samsung.com>
|
||||
M: Shuah Khan <shuah@kernel.org>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
|
@ -14965,7 +15008,7 @@ F: include/uapi/linux/virtio_crypto.h
|
|||
|
||||
VIRTIO DRIVERS FOR S390
|
||||
M: Cornelia Huck <cohuck@redhat.com>
|
||||
M: Halil Pasic <pasic@linux.vnet.ibm.com>
|
||||
M: Halil Pasic <pasic@linux.ibm.com>
|
||||
L: linux-s390@vger.kernel.org
|
||||
L: virtualization@lists.linux-foundation.org
|
||||
L: kvm@vger.kernel.org
|
||||
|
@ -15354,7 +15397,6 @@ S: Maintained
|
|||
F: arch/x86/entry/vdso/
|
||||
|
||||
XC2028/3028 TUNER DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@kernel.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: https://linuxtv.org
|
||||
|
@ -15362,6 +15404,14 @@ T: git git://linuxtv.org/media_tree.git
|
|||
S: Maintained
|
||||
F: drivers/media/tuners/tuner-xc2028.*
|
||||
|
||||
XDP SOCKETS (AF_XDP)
|
||||
M: Björn Töpel <bjorn.topel@intel.com>
|
||||
M: Magnus Karlsson <magnus.karlsson@intel.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: kernel/bpf/xskmap.c
|
||||
F: net/xdp/
|
||||
|
||||
XEN BLOCK SUBSYSTEM
|
||||
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
M: Roger Pau Monné <roger.pau@citrix.com>
|
||||
|
|
11
Makefile
11
Makefile
|
@ -1,9 +1,9 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
VERSION = 4
|
||||
PATCHLEVEL = 16
|
||||
PATCHLEVEL = 17
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION =
|
||||
NAME = Fearless Coyote
|
||||
EXTRAVERSION = -rc6
|
||||
NAME = Merciless Moray
|
||||
|
||||
# *DOCUMENTATION*
|
||||
# To see a list of typical targets execute "make help"
|
||||
|
@ -846,6 +846,9 @@ KBUILD_CFLAGS += $(call cc-option,-Werror=incompatible-pointer-types)
|
|||
# Require designated initializers for all marked structures
|
||||
KBUILD_CFLAGS += $(call cc-option,-Werror=designated-init)
|
||||
|
||||
# change __FILE__ to the relative path from the srctree
|
||||
KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
|
||||
|
||||
# use the deterministic mode of AR if available
|
||||
KBUILD_ARFLAGS := $(call ar-option,D)
|
||||
|
||||
|
@ -1615,6 +1618,8 @@ clean: $(clean-dirs)
|
|||
-o -name '*.dwo' -o -name '*.lst' \
|
||||
-o -name '*.su' \
|
||||
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
|
||||
-o -name '*.lex.c' -o -name '*.tab.[ch]' \
|
||||
-o -name '*.asn1.[ch]' \
|
||||
-o -name '*.symtypes' -o -name 'modules.order' \
|
||||
-o -name modules.builtin -o -name '.tmp_*.o.*' \
|
||||
-o -name .cache.mk \
|
||||
|
|
|
@ -464,6 +464,10 @@ config GCC_PLUGIN_LATENT_ENTROPY
|
|||
config GCC_PLUGIN_STRUCTLEAK
|
||||
bool "Force initialization of variables containing userspace addresses"
|
||||
depends on GCC_PLUGINS
|
||||
# Currently STRUCTLEAK inserts initialization out of live scope of
|
||||
# variables from KASAN point of view. This leads to KASAN false
|
||||
# positive reports. Prohibit this combination for now.
|
||||
depends on !KASAN_EXTRA
|
||||
help
|
||||
This plugin zero-initializes any structures containing a
|
||||
__user attribute. This can prevent some classes of information
|
||||
|
|
|
@ -9,8 +9,6 @@ endif
|
|||
obj-y += $(builtindtb-y).dtb.o
|
||||
dtb-y := $(builtindtb-y).dtb
|
||||
|
||||
.SECONDARY: $(obj)/$(builtindtb-y).dtb.S
|
||||
|
||||
# for CONFIG_OF_ALL_DTBS test
|
||||
dtstree := $(srctree)/$(src)
|
||||
dtb- := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard $(dtstree)/*.dts))
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue