Loading CREDITS +4 −0 Original line number Diff line number Diff line Loading @@ -2204,6 +2204,10 @@ S: Post Office Box 371 S: North Little Rock, Arkansas 72115 S: USA N: Christopher Li E: sparse@chrisli.org D: Sparse maintainer 2009 - 2018 N: Stephan Linz E: linz@mazet.de E: Stephan.Linz@gmx.de Loading Documentation/core-api/xarray.rst +41 −11 Original line number Diff line number Diff line Loading @@ -74,7 +74,8 @@ using :c:func:`xa_load`. xa_store will overwrite any entry with the new entry and return the previous entry stored at that index. You can use :c:func:`xa_erase` instead of calling :c:func:`xa_store` with a ``NULL`` entry. There is no difference between an entry that has never been stored to and one that has most recently had ``NULL`` stored to it. been stored to, one that has been erased and one that has most recently had ``NULL`` stored to it. You can conditionally replace an entry at an index by using :c:func:`xa_cmpxchg`. Like :c:func:`cmpxchg`, it will only succeed if Loading Loading @@ -105,23 +106,44 @@ may result in the entry being marked at some, but not all of the other indices. Storing into one index may result in the entry retrieved by some, but not all of the other indices changing. Sometimes you need to ensure that a subsequent call to :c:func:`xa_store` will not need to allocate memory. The :c:func:`xa_reserve` function will store a reserved entry at the indicated index. Users of the normal API will see this entry as containing ``NULL``. If you do not need to use the reserved entry, you can call :c:func:`xa_release` to remove the unused entry. If another user has stored to the entry in the meantime, :c:func:`xa_release` will do nothing; if instead you want the entry to become ``NULL``, you should use :c:func:`xa_erase`. If all entries in the array are ``NULL``, the :c:func:`xa_empty` function will return ``true``. Finally, you can remove all entries from an XArray by calling :c:func:`xa_destroy`. If the XArray entries are pointers, you may wish to free the entries first. You can do this by iterating over all present entries in the XArray using the :c:func:`xa_for_each` iterator. ID assignment ------------- Allocating XArrays ------------------ If you use :c:func:`DEFINE_XARRAY_ALLOC` to define the XArray, or initialise it by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`, the XArray changes to track whether entries are in use or not. You can call :c:func:`xa_alloc` to store the entry at any unused index in the XArray. If you need to modify the array from interrupt context, you can use :c:func:`xa_alloc_bh` or :c:func:`xa_alloc_irq` to disable interrupts while allocating the ID. Unlike :c:func:`xa_store`, allocating a ``NULL`` pointer does not delete an entry. Instead it reserves an entry like :c:func:`xa_reserve` and you can release it using either :c:func:`xa_erase` or :c:func:`xa_release`. To use ID assignment, the XArray must be defined with :c:func:`DEFINE_XARRAY_ALLOC`, or initialised by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`, interrupts while allocating the ID. Using :c:func:`xa_store`, :c:func:`xa_cmpxchg` or :c:func:`xa_insert` will mark the entry as being allocated. Unlike a normal XArray, storing ``NULL`` will mark the entry as being in use, like :c:func:`xa_reserve`. To free an entry, use :c:func:`xa_erase` (or :c:func:`xa_release` if you only want to free the entry if it's ``NULL``). You cannot use ``XA_MARK_0`` with an allocating XArray as this mark is used to track whether an entry is free or not. The other marks are available for your use. Memory allocation ----------------- Loading Loading @@ -158,6 +180,8 @@ Takes RCU read lock: Takes xa_lock internally: * :c:func:`xa_store` * :c:func:`xa_store_bh` * :c:func:`xa_store_irq` * :c:func:`xa_insert` * :c:func:`xa_erase` * :c:func:`xa_erase_bh` Loading @@ -167,6 +191,9 @@ Takes xa_lock internally: * :c:func:`xa_alloc` * :c:func:`xa_alloc_bh` * :c:func:`xa_alloc_irq` * :c:func:`xa_reserve` * :c:func:`xa_reserve_bh` * :c:func:`xa_reserve_irq` * :c:func:`xa_destroy` * :c:func:`xa_set_mark` * :c:func:`xa_clear_mark` Loading @@ -177,6 +204,7 @@ Assumes xa_lock held on entry: * :c:func:`__xa_erase` * :c:func:`__xa_cmpxchg` * :c:func:`__xa_alloc` * :c:func:`__xa_reserve` * :c:func:`__xa_set_mark` * :c:func:`__xa_clear_mark` Loading Loading @@ -234,7 +262,8 @@ Sharing the XArray with interrupt context is also possible, either using :c:func:`xa_lock_irqsave` in both the interrupt handler and process context, or :c:func:`xa_lock_irq` in process context and :c:func:`xa_lock` in the interrupt handler. Some of the more common patterns have helper functions such as :c:func:`xa_erase_bh` and :c:func:`xa_erase_irq`. functions such as :c:func:`xa_store_bh`, :c:func:`xa_store_irq`, :c:func:`xa_erase_bh` and :c:func:`xa_erase_irq`. Sometimes you need to protect access to the XArray with a mutex because that lock sits above another mutex in the locking hierarchy. That does Loading Loading @@ -322,7 +351,8 @@ to :c:func:`xas_retry`, and retry the operation if it returns ``true``. - :c:func:`xa_is_zero` - Zero entries appear as ``NULL`` through the Normal API, but occupy an entry in the XArray which can be used to reserve the index for future use. future use. This is used by allocating XArrays for allocated entries which are ``NULL``. Other internal entries may be added in the future. As far as possible, they will be handled by :c:func:`xas_retry`. Loading Documentation/devicetree/bindings/spi/spi-uniphier.txt +8 −6 Original line number Diff line number Diff line Loading @@ -5,18 +5,20 @@ UniPhier SoCs have SCSSI which supports SPI single channel. Required properties: - compatible: should be "socionext,uniphier-scssi" - reg: address and length of the spi master registers - #address-cells: must be <1>, see spi-bus.txt - #size-cells: must be <0>, see spi-bus.txt - clocks: A phandle to the clock for the device. - resets: A phandle to the reset control for the device. - interrupts: a single interrupt specifier - pinctrl-names: should be "default" - pinctrl-0: pin control state for the default mode - clocks: a phandle to the clock for the device - resets: a phandle to the reset control for the device Example: spi0: spi@54006000 { compatible = "socionext,uniphier-scssi"; reg = <0x54006000 0x100>; #address-cells = <1>; #size-cells = <0>; interrupts = <0 39 4>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_spi0>; clocks = <&peri_clk 11>; resets = <&peri_rst 11>; }; Documentation/input/event-codes.rst +1 −10 Original line number Diff line number Diff line Loading @@ -190,16 +190,7 @@ A few EV_REL codes have special meanings: * REL_WHEEL, REL_HWHEEL: - These codes are used for vertical and horizontal scroll wheels, respectively. The value is the number of "notches" moved on the wheel, the physical size of which varies by device. For high-resolution wheels (which report multiple events for each notch of movement, or do not have notches) this may be an approximation based on the high-resolution scroll events. * REL_WHEEL_HI_RES: - If a vertical scroll wheel supports high-resolution scrolling, this code will be emitted in addition to REL_WHEEL. The value is the (approximate) distance travelled by the user's finger, in microns. respectively. EV_ABS ------ Loading MAINTAINERS +63 −3 Original line number Diff line number Diff line Loading @@ -2801,7 +2801,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git T: git git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git Q: https://patchwork.ozlabs.org/project/netdev/list/?delegate=77147 S: Supported F: arch/x86/net/bpf_jit* F: arch/*/net/* F: Documentation/networking/filter.txt F: Documentation/bpf/ F: include/linux/bpf* Loading @@ -2821,6 +2821,67 @@ F: tools/bpf/ F: tools/lib/bpf/ F: tools/testing/selftests/bpf/ BPF JIT for ARM M: Shubham Bansal <illusionist.neo@gmail.com> L: netdev@vger.kernel.org S: Maintained F: arch/arm/net/ BPF JIT for ARM64 M: Daniel Borkmann <daniel@iogearbox.net> M: Alexei Starovoitov <ast@kernel.org> M: Zi Shen Lim <zlim.lnx@gmail.com> L: netdev@vger.kernel.org S: Supported F: arch/arm64/net/ BPF JIT for MIPS (32-BIT AND 64-BIT) M: Paul Burton <paul.burton@mips.com> L: netdev@vger.kernel.org S: Maintained F: arch/mips/net/ BPF JIT for NFP NICs M: Jakub Kicinski <jakub.kicinski@netronome.com> L: netdev@vger.kernel.org S: Supported F: drivers/net/ethernet/netronome/nfp/bpf/ BPF JIT for POWERPC (32-BIT AND 64-BIT) M: Naveen N. Rao <naveen.n.rao@linux.ibm.com> M: Sandipan Das <sandipan@linux.ibm.com> L: netdev@vger.kernel.org S: Maintained F: arch/powerpc/net/ BPF JIT for S390 M: Martin Schwidefsky <schwidefsky@de.ibm.com> M: Heiko Carstens <heiko.carstens@de.ibm.com> L: netdev@vger.kernel.org S: Maintained F: arch/s390/net/ X: arch/s390/net/pnet.c BPF JIT for SPARC (32-BIT AND 64-BIT) M: David S. Miller <davem@davemloft.net> L: netdev@vger.kernel.org S: Maintained F: arch/sparc/net/ BPF JIT for X86 32-BIT M: Wang YanQing <udknight@gmail.com> L: netdev@vger.kernel.org S: Maintained F: arch/x86/net/bpf_jit_comp32.c BPF JIT for X86 64-BIT M: Alexei Starovoitov <ast@kernel.org> M: Daniel Borkmann <daniel@iogearbox.net> L: netdev@vger.kernel.org S: Supported F: arch/x86/net/ X: arch/x86/net/bpf_jit_comp32.c BROADCOM B44 10/100 ETHERNET DRIVER M: Michael Chan <michael.chan@broadcom.com> L: netdev@vger.kernel.org Loading Loading @@ -13997,11 +14058,10 @@ F: drivers/tty/serial/sunzilog.h F: drivers/tty/vcc.c SPARSE CHECKER M: "Christopher Li" <sparse@chrisli.org> M: "Luc Van Oostenryck" <luc.vanoostenryck@gmail.com> L: linux-sparse@vger.kernel.org W: https://sparse.wiki.kernel.org/ T: git git://git.kernel.org/pub/scm/devel/sparse/sparse.git T: git git://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git S: Maintained F: include/linux/compiler.h Loading Loading
CREDITS +4 −0 Original line number Diff line number Diff line Loading @@ -2204,6 +2204,10 @@ S: Post Office Box 371 S: North Little Rock, Arkansas 72115 S: USA N: Christopher Li E: sparse@chrisli.org D: Sparse maintainer 2009 - 2018 N: Stephan Linz E: linz@mazet.de E: Stephan.Linz@gmx.de Loading
Documentation/core-api/xarray.rst +41 −11 Original line number Diff line number Diff line Loading @@ -74,7 +74,8 @@ using :c:func:`xa_load`. xa_store will overwrite any entry with the new entry and return the previous entry stored at that index. You can use :c:func:`xa_erase` instead of calling :c:func:`xa_store` with a ``NULL`` entry. There is no difference between an entry that has never been stored to and one that has most recently had ``NULL`` stored to it. been stored to, one that has been erased and one that has most recently had ``NULL`` stored to it. You can conditionally replace an entry at an index by using :c:func:`xa_cmpxchg`. Like :c:func:`cmpxchg`, it will only succeed if Loading Loading @@ -105,23 +106,44 @@ may result in the entry being marked at some, but not all of the other indices. Storing into one index may result in the entry retrieved by some, but not all of the other indices changing. Sometimes you need to ensure that a subsequent call to :c:func:`xa_store` will not need to allocate memory. The :c:func:`xa_reserve` function will store a reserved entry at the indicated index. Users of the normal API will see this entry as containing ``NULL``. If you do not need to use the reserved entry, you can call :c:func:`xa_release` to remove the unused entry. If another user has stored to the entry in the meantime, :c:func:`xa_release` will do nothing; if instead you want the entry to become ``NULL``, you should use :c:func:`xa_erase`. If all entries in the array are ``NULL``, the :c:func:`xa_empty` function will return ``true``. Finally, you can remove all entries from an XArray by calling :c:func:`xa_destroy`. If the XArray entries are pointers, you may wish to free the entries first. You can do this by iterating over all present entries in the XArray using the :c:func:`xa_for_each` iterator. ID assignment ------------- Allocating XArrays ------------------ If you use :c:func:`DEFINE_XARRAY_ALLOC` to define the XArray, or initialise it by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`, the XArray changes to track whether entries are in use or not. You can call :c:func:`xa_alloc` to store the entry at any unused index in the XArray. If you need to modify the array from interrupt context, you can use :c:func:`xa_alloc_bh` or :c:func:`xa_alloc_irq` to disable interrupts while allocating the ID. Unlike :c:func:`xa_store`, allocating a ``NULL`` pointer does not delete an entry. Instead it reserves an entry like :c:func:`xa_reserve` and you can release it using either :c:func:`xa_erase` or :c:func:`xa_release`. To use ID assignment, the XArray must be defined with :c:func:`DEFINE_XARRAY_ALLOC`, or initialised by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`, interrupts while allocating the ID. Using :c:func:`xa_store`, :c:func:`xa_cmpxchg` or :c:func:`xa_insert` will mark the entry as being allocated. Unlike a normal XArray, storing ``NULL`` will mark the entry as being in use, like :c:func:`xa_reserve`. To free an entry, use :c:func:`xa_erase` (or :c:func:`xa_release` if you only want to free the entry if it's ``NULL``). You cannot use ``XA_MARK_0`` with an allocating XArray as this mark is used to track whether an entry is free or not. The other marks are available for your use. Memory allocation ----------------- Loading Loading @@ -158,6 +180,8 @@ Takes RCU read lock: Takes xa_lock internally: * :c:func:`xa_store` * :c:func:`xa_store_bh` * :c:func:`xa_store_irq` * :c:func:`xa_insert` * :c:func:`xa_erase` * :c:func:`xa_erase_bh` Loading @@ -167,6 +191,9 @@ Takes xa_lock internally: * :c:func:`xa_alloc` * :c:func:`xa_alloc_bh` * :c:func:`xa_alloc_irq` * :c:func:`xa_reserve` * :c:func:`xa_reserve_bh` * :c:func:`xa_reserve_irq` * :c:func:`xa_destroy` * :c:func:`xa_set_mark` * :c:func:`xa_clear_mark` Loading @@ -177,6 +204,7 @@ Assumes xa_lock held on entry: * :c:func:`__xa_erase` * :c:func:`__xa_cmpxchg` * :c:func:`__xa_alloc` * :c:func:`__xa_reserve` * :c:func:`__xa_set_mark` * :c:func:`__xa_clear_mark` Loading Loading @@ -234,7 +262,8 @@ Sharing the XArray with interrupt context is also possible, either using :c:func:`xa_lock_irqsave` in both the interrupt handler and process context, or :c:func:`xa_lock_irq` in process context and :c:func:`xa_lock` in the interrupt handler. Some of the more common patterns have helper functions such as :c:func:`xa_erase_bh` and :c:func:`xa_erase_irq`. functions such as :c:func:`xa_store_bh`, :c:func:`xa_store_irq`, :c:func:`xa_erase_bh` and :c:func:`xa_erase_irq`. Sometimes you need to protect access to the XArray with a mutex because that lock sits above another mutex in the locking hierarchy. That does Loading Loading @@ -322,7 +351,8 @@ to :c:func:`xas_retry`, and retry the operation if it returns ``true``. - :c:func:`xa_is_zero` - Zero entries appear as ``NULL`` through the Normal API, but occupy an entry in the XArray which can be used to reserve the index for future use. future use. This is used by allocating XArrays for allocated entries which are ``NULL``. Other internal entries may be added in the future. As far as possible, they will be handled by :c:func:`xas_retry`. Loading
Documentation/devicetree/bindings/spi/spi-uniphier.txt +8 −6 Original line number Diff line number Diff line Loading @@ -5,18 +5,20 @@ UniPhier SoCs have SCSSI which supports SPI single channel. Required properties: - compatible: should be "socionext,uniphier-scssi" - reg: address and length of the spi master registers - #address-cells: must be <1>, see spi-bus.txt - #size-cells: must be <0>, see spi-bus.txt - clocks: A phandle to the clock for the device. - resets: A phandle to the reset control for the device. - interrupts: a single interrupt specifier - pinctrl-names: should be "default" - pinctrl-0: pin control state for the default mode - clocks: a phandle to the clock for the device - resets: a phandle to the reset control for the device Example: spi0: spi@54006000 { compatible = "socionext,uniphier-scssi"; reg = <0x54006000 0x100>; #address-cells = <1>; #size-cells = <0>; interrupts = <0 39 4>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_spi0>; clocks = <&peri_clk 11>; resets = <&peri_rst 11>; };
Documentation/input/event-codes.rst +1 −10 Original line number Diff line number Diff line Loading @@ -190,16 +190,7 @@ A few EV_REL codes have special meanings: * REL_WHEEL, REL_HWHEEL: - These codes are used for vertical and horizontal scroll wheels, respectively. The value is the number of "notches" moved on the wheel, the physical size of which varies by device. For high-resolution wheels (which report multiple events for each notch of movement, or do not have notches) this may be an approximation based on the high-resolution scroll events. * REL_WHEEL_HI_RES: - If a vertical scroll wheel supports high-resolution scrolling, this code will be emitted in addition to REL_WHEEL. The value is the (approximate) distance travelled by the user's finger, in microns. respectively. EV_ABS ------ Loading
MAINTAINERS +63 −3 Original line number Diff line number Diff line Loading @@ -2801,7 +2801,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git T: git git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git Q: https://patchwork.ozlabs.org/project/netdev/list/?delegate=77147 S: Supported F: arch/x86/net/bpf_jit* F: arch/*/net/* F: Documentation/networking/filter.txt F: Documentation/bpf/ F: include/linux/bpf* Loading @@ -2821,6 +2821,67 @@ F: tools/bpf/ F: tools/lib/bpf/ F: tools/testing/selftests/bpf/ BPF JIT for ARM M: Shubham Bansal <illusionist.neo@gmail.com> L: netdev@vger.kernel.org S: Maintained F: arch/arm/net/ BPF JIT for ARM64 M: Daniel Borkmann <daniel@iogearbox.net> M: Alexei Starovoitov <ast@kernel.org> M: Zi Shen Lim <zlim.lnx@gmail.com> L: netdev@vger.kernel.org S: Supported F: arch/arm64/net/ BPF JIT for MIPS (32-BIT AND 64-BIT) M: Paul Burton <paul.burton@mips.com> L: netdev@vger.kernel.org S: Maintained F: arch/mips/net/ BPF JIT for NFP NICs M: Jakub Kicinski <jakub.kicinski@netronome.com> L: netdev@vger.kernel.org S: Supported F: drivers/net/ethernet/netronome/nfp/bpf/ BPF JIT for POWERPC (32-BIT AND 64-BIT) M: Naveen N. Rao <naveen.n.rao@linux.ibm.com> M: Sandipan Das <sandipan@linux.ibm.com> L: netdev@vger.kernel.org S: Maintained F: arch/powerpc/net/ BPF JIT for S390 M: Martin Schwidefsky <schwidefsky@de.ibm.com> M: Heiko Carstens <heiko.carstens@de.ibm.com> L: netdev@vger.kernel.org S: Maintained F: arch/s390/net/ X: arch/s390/net/pnet.c BPF JIT for SPARC (32-BIT AND 64-BIT) M: David S. Miller <davem@davemloft.net> L: netdev@vger.kernel.org S: Maintained F: arch/sparc/net/ BPF JIT for X86 32-BIT M: Wang YanQing <udknight@gmail.com> L: netdev@vger.kernel.org S: Maintained F: arch/x86/net/bpf_jit_comp32.c BPF JIT for X86 64-BIT M: Alexei Starovoitov <ast@kernel.org> M: Daniel Borkmann <daniel@iogearbox.net> L: netdev@vger.kernel.org S: Supported F: arch/x86/net/ X: arch/x86/net/bpf_jit_comp32.c BROADCOM B44 10/100 ETHERNET DRIVER M: Michael Chan <michael.chan@broadcom.com> L: netdev@vger.kernel.org Loading Loading @@ -13997,11 +14058,10 @@ F: drivers/tty/serial/sunzilog.h F: drivers/tty/vcc.c SPARSE CHECKER M: "Christopher Li" <sparse@chrisli.org> M: "Luc Van Oostenryck" <luc.vanoostenryck@gmail.com> L: linux-sparse@vger.kernel.org W: https://sparse.wiki.kernel.org/ T: git git://git.kernel.org/pub/scm/devel/sparse/sparse.git T: git git://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git S: Maintained F: include/linux/compiler.h Loading