1. 16 Nov, 2021 20 commits
  2. 15 Nov, 2021 20 commits
    • Jakub Kicinski's avatar
      Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next · a5bdc363
      Jakub Kicinski authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf-next 2021-11-15
      
      We've added 72 non-merge commits during the last 13 day(s) which contain
      a total of 171 files changed, 2728 insertions(+), 1143 deletions(-).
      
      The main changes are:
      
      1) Add btf_type_tag attributes to bring kernel annotations like __user/__rcu to
         BTF such that BPF verifier will be able to detect misuse, from Yonghong Song.
      
      2) Big batch of libbpf improvements including various fixes, future proofing APIs,
         and adding a unified, OPTS-based bpf_prog_load() low-level API, from Andrii Nakryiko.
      
      3) Add ingress_ifindex to BPF_SK_LOOKUP program type for selectively applying the
         programmable socket lookup logic to packets from a given netdev, from Mark Pashmfouroush.
      
      4) Remove the 128M upper JIT limit for BPF programs on arm64 and add selftest to
         ensure exception handling still works, from Russell King and Alan Maguire.
      
      5) Add a new bpf_find_vma() helper for tracing to map an address to the backing
         file such as shared library, from Song Liu.
      
      6) Batch of various misc fixes to bpftool, fixing a memory leak in BPF program dump,
         updating documentation and bash-completion among others, from Quentin Monnet.
      
      7) Deprecate libbpf bpf_program__get_prog_info_linear() API and migrate its users as
         the API is heavily tailored around perf and is non-generic, from Dave Marchevsky.
      
      8) Enable libbpf's strict mode by default in bpftool and add a --legacy option as an
         opt-out for more relaxed BPF program requirements, from Stanislav Fomichev.
      
      9) Fix bpftool to use libbpf_get_error() to check for errors, from Hengqi Chen.
      
      * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (72 commits)
        bpftool: Use libbpf_get_error() to check error
        bpftool: Fix mixed indentation in documentation
        bpftool: Update the lists of names for maps and prog-attach types
        bpftool: Fix indent in option lists in the documentation
        bpftool: Remove inclusion of utilities.mak from Makefiles
        bpftool: Fix memory leak in prog_dump()
        selftests/bpf: Fix a tautological-constant-out-of-range-compare compiler warning
        selftests/bpf: Fix an unused-but-set-variable compiler warning
        bpf: Introduce btf_tracing_ids
        bpf: Extend BTF_ID_LIST_GLOBAL with parameter for number of IDs
        bpftool: Enable libbpf's strict mode by default
        docs/bpf: Update documentation for BTF_KIND_TYPE_TAG support
        selftests/bpf: Clarify llvm dependency with btf_tag selftest
        selftests/bpf: Add a C test for btf_type_tag
        selftests/bpf: Rename progs/tag.c to progs/btf_decl_tag.c
        selftests/bpf: Test BTF_KIND_DECL_TAG for deduplication
        selftests/bpf: Add BTF_KIND_TYPE_TAG unit tests
        selftests/bpf: Test libbpf API function btf__add_type_tag()
        bpftool: Support BTF_KIND_TYPE_TAG
        libbpf: Support BTF_KIND_TYPE_TAG
        ...
      ====================
      
      Link: https://lore.kernel.org/r/20211115162008.25916-1-daniel@iogearbox.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a5bdc363
    • Jakub Kicinski's avatar
      Revert "Merge branch 'mctp-i2c-driver'" · 2f6a470d
      Jakub Kicinski authored
      This reverts commit 71812af7, reversing
      changes made to cc0be1ad.
      
      Wolfram Sang says:
      
      Please revert. Besides the driver in net, it modifies the I2C core
      code. This has not been acked by the I2C maintainer (in this case me).
      So, please don't pull this in via the net tree. The question raised here
      (extending SMBus calls to 255 byte) is complicated because we need ABI
      backwards compatibility.
      
      Link: https://lore.kernel.org/all/YZJ9H4eM%2FM7OXVN0@shikoro/Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2f6a470d
    • David S. Miller's avatar
      Merge branch 'generic-phylink-validation' · 6d3b1b06
      David S. Miller authored
      Russell King says:
      
      ====================
      introduce generic phylink validation
      
      The various validate method implementations we have in phylink users
      have been quite repetitive but also prone to bugs. These patches
      introduce a generic implementation which relies solely on the
      supported_interfaces bitmap introduced during last cycle, and in the
      first patch, a bit array of MAC capabilities.
      
      MAC drivers are free to continue to do their own thing if they have
      special requirements - such as mvneta and mvpp2 which do not support
      1000base-X without AN enabled. Most implementations currently in the
      kernel can be converted to call phylink_generic_validate() directly
      from the phylink MAC operations structure once they fill in the
      supported_interfaces and mac_capabilities members of phylink_config.
      
      This series introduces the generic implementation, and converts mvneta
      and mvpp2 to use it.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6d3b1b06
    • Russell King (Oracle)'s avatar
      net: mvpp2: use phylink_generic_validate() · 5038ffea
      Russell King (Oracle) authored
      Convert mvpp2 to use phylink_generic_validate() for the bulk of its
      validate() implementation. This network adapter has a restriction
      that for 802.3z links, autonegotiation must be enabled.
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5038ffea
    • Russell King (Oracle)'s avatar
      net: mvneta: use phylink_generic_validate() · 02a0988b
      Russell King (Oracle) authored
      Convert mvneta to use phylink_generic_validate() for the bulk of its
      validate() implementation. This network adapter has a restriction
      that for 802.3z links, autonegotiation must be enabled.
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      02a0988b
    • Russell King (Oracle)'s avatar
      net: phylink: add generic validate implementation · 34ae2c09
      Russell King (Oracle) authored
      Add a generic validate() implementation using the supported_interfaces
      and a bitmask of MAC pause/speed/duplex capabilities. This allows us
      to entirely eliminate many driver private validate() implementations.
      
      We expose the underlying phylink_get_linkmodes() function so that
      drivers which have special needs can still benefit from conversion.
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      34ae2c09
    • Christophe Leroy's avatar
      net/wan/fsl_ucc_hdlc: fix sparse warnings · 5cf46d8e
      Christophe Leroy authored
      CHECK   drivers/net/wan/fsl_ucc_hdlc.c
      drivers/net/wan/fsl_ucc_hdlc.c:309:57: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:309:57:    expected void [noderef] __iomem *
      drivers/net/wan/fsl_ucc_hdlc.c:309:57:    got restricted __be16 *
      drivers/net/wan/fsl_ucc_hdlc.c:311:46: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:311:46:    expected void [noderef] __iomem *
      drivers/net/wan/fsl_ucc_hdlc.c:311:46:    got restricted __be32 *
      drivers/net/wan/fsl_ucc_hdlc.c:320:57: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:320:57:    expected void [noderef] __iomem *
      drivers/net/wan/fsl_ucc_hdlc.c:320:57:    got restricted __be16 *
      drivers/net/wan/fsl_ucc_hdlc.c:322:46: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:322:46:    expected void [noderef] __iomem *
      drivers/net/wan/fsl_ucc_hdlc.c:322:46:    got restricted __be32 *
      drivers/net/wan/fsl_ucc_hdlc.c:372:29: warning: incorrect type in assignment (different base types)
      drivers/net/wan/fsl_ucc_hdlc.c:372:29:    expected unsigned short [usertype]
      drivers/net/wan/fsl_ucc_hdlc.c:372:29:    got restricted __be16 [usertype]
      drivers/net/wan/fsl_ucc_hdlc.c:379:36: warning: restricted __be16 degrades to integer
      drivers/net/wan/fsl_ucc_hdlc.c:402:12: warning: incorrect type in assignment (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:402:12:    expected struct qe_bd [noderef] __iomem *bd
      drivers/net/wan/fsl_ucc_hdlc.c:402:12:    got struct qe_bd *curtx_bd
      drivers/net/wan/fsl_ucc_hdlc.c:425:20: warning: incorrect type in assignment (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:425:20:    expected struct qe_bd [noderef] __iomem *[assigned] bd
      drivers/net/wan/fsl_ucc_hdlc.c:425:20:    got struct qe_bd *tx_bd_base
      drivers/net/wan/fsl_ucc_hdlc.c:427:16: error: incompatible types in comparison expression (different address spaces):
      drivers/net/wan/fsl_ucc_hdlc.c:427:16:    struct qe_bd [noderef] __iomem *
      drivers/net/wan/fsl_ucc_hdlc.c:427:16:    struct qe_bd *
      drivers/net/wan/fsl_ucc_hdlc.c:462:33: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:506:41: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:528:33: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:552:38: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:596:67: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:611:41: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:851:38: warning: incorrect type in initializer (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:854:40: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:855:40: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:858:39: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:861:37: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:866:38: warning: incorrect type in initializer (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:868:21: warning: incorrect type in argument 1 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:870:40: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:871:40: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:873:39: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:993:57: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:995:46: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:1004:57: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:1006:46: warning: incorrect type in argument 2 (different address spaces)
      drivers/net/wan/fsl_ucc_hdlc.c:412:35: warning: dereference of noderef expression
      drivers/net/wan/fsl_ucc_hdlc.c:412:35: warning: dereference of noderef expression
      drivers/net/wan/fsl_ucc_hdlc.c:724:29: warning: dereference of noderef expression
      drivers/net/wan/fsl_ucc_hdlc.c:815:21: warning: dereference of noderef expression
      drivers/net/wan/fsl_ucc_hdlc.c:1021:29: warning: dereference of noderef expression
      
      Most of the warnings are due to DMA memory being incorrectly handled as IO memory.
      Fix it by doing direct read/write and doing proper dma_rmb() / dma_wmb().
      
      Other problems are type mismatches or lack of use of IO accessors.
      
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Link: https://lkml.org/lkml/2021/11/12/647Signed-off-by: default avatarChristophe Leroy <christophe.leroy@csgroup.eu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5cf46d8e
    • Yihao Han's avatar
      net: fddi: use swap() to make code cleaner · 311107bd
      Yihao Han authored
      Use the macro 'swap()' defined in 'include/linux/minmax.h' to avoid
      opencoding it.
      Signed-off-by: default avatarYihao Han <hanyihao@vivo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      311107bd
    • Guo Zhengkui's avatar
      hinic: use ARRAY_SIZE instead of ARRAY_LEN · 9ed94117
      Guo Zhengkui authored
      ARRAY_SIZE defined in <linux/kernel.h> is safer than self-defined
      macros to get size of an array such as ARRAY_LEN used here. Because
      ARRAY_SIZE uses __must_be_array(arr) to ensure arr is really an array.
      Reported-by: default avatarAlejandro Colomar <colomar.6.4.3@gmail.com>
      Signed-off-by: default avatarGuo Zhengkui <guozhengkui@vivo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9ed94117
    • Jacky Chou's avatar
      net: usb: ax88179_178a: add TSO feature · 16b1c4e0
      Jacky Chou authored
      On low-effciency embedded platforms, transmission performance is poor
      due to on Bulk-out with single packet.
      Adding TSO feature improves the transmission performance and reduces
      the number of interrupt caused by Bulk-out complete.
      
      Reference to module, net: usb: aqc111.
      Signed-off-by: default avatarJacky Chou <jackychou@asix.com.tw>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      16b1c4e0
    • David S. Miller's avatar
      Merge branch 'mctp-i2c-driver' · 71812af7
      David S. Miller authored
      Matt Johnston says:
      
      ====================
      MCTP I2C driver
      
      This patch series adds a netdev driver providing MCTP transport over
      I2C.
      
      It applies against net-next using recent MCTP changes there, though also
      has I2C core changes for review. I'll leave it to maintainers where it
      should be applied - please let me know if it needs to be submitted
      differently.
      
      The I2C patches were previously sent as RFC though the only feedback
      there was an ack to 255 bytes for aspeed.
      
      The dt-bindings patch went through review on the list.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      71812af7
    • Matt Johnston's avatar
      mctp i2c: MCTP I2C binding driver · 80be9b2c
      Matt Johnston authored
      Provides MCTP network transport over an I2C bus, as specified in
      DMTF DSP0237. All messages between nodes are sent as SMBus Block Writes.
      
      Each I2C bus to be used for MCTP is flagged in devicetree by a
      'mctp-controller' property on the bus node. Each flagged bus gets a
      mctpi2cX net device created based on the bus number. A
      'mctp-i2c-controller' I2C client needs to be added under the adapter. In
      an I2C mux situation the mctp-i2c-controller node must be attached only
      to the root I2C bus. The I2C client will handle incoming I2C slave block
      write data for subordinate busses as well as its own bus.
      
      In configurations without devicetree a driver instance can be attached
      to a bus using the I2C slave new_device mechanism.
      
      The MCTP core will hold/release the MCTP I2C device while responses
      are pending (a 6 second timeout or once a socket is closed, response
      received etc). While held the MCTP I2C driver will lock the I2C bus so
      that the correct I2C mux remains selected while responses are received.
      
      (Ideally we would just lock the mux to keep the current bus selected for
      the response rather than a full I2C bus lock, but that isn't exposed in
      the I2C mux API)
      
      This driver requires I2C adapters that allow 255 byte transfers
      (SMBus 3.0) as the specification requires a minimum MTU of 68 bytes.
      Signed-off-by: default avatarMatt Johnston <matt@codeconstruct.com.au>
      Signed-off-by: default avatarJeremy Kerr <jk@codeconstruct.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      80be9b2c
    • Matt Johnston's avatar
      dt-bindings: net: New binding mctp-i2c-controller · 0b6141eb
      Matt Johnston authored
      Used to define a local endpoint to communicate with MCTP peripherals
      attached to an I2C bus. This I2C endpoint can communicate with remote
      MCTP devices on the I2C bus.
      
      In the example I2C topology below (matching the second yaml example) we
      have MCTP devices on busses i2c1 and i2c6. MCTP-supporting busses are
      indicated by the 'mctp-controller' DT property on an I2C bus node.
      
      A mctp-i2c-controller I2C client DT node is placed at the top of the
      mux topology, since only the root I2C adapter will support I2C slave
      functionality.
                                                     .-------.
                                                     |eeprom |
          .------------.     .------.               /'-------'
          | adapter    |     | mux  --@0,i2c5------'
          | i2c1       ----.*|      --@1,i2c6--.--.
          |............|    \'------'           \  \  .........
          | mctp-i2c-  |     \                   \  \ .mctpB  .
          | controller |      \                   \  '.0x30   .
          |            |       \  .........        \  '.......'
          | 0x50       |        \ .mctpA  .         \ .........
          '------------'         '.0x1d   .          '.mctpC  .
                                  '.......'          '.0x31   .
                                                      '.......'
      (mctpX boxes above are remote MCTP devices not included in the DT at
      present, they can be hotplugged/probed at runtime. A DT binding for
      specific fixed MCTP devices could be added later if required)
      Signed-off-by: default avatarMatt Johnston <matt@codeconstruct.com.au>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b6141eb
    • Matt Johnston's avatar
      i2c: npcm7xx: Allow 255 byte block SMBus transfers · 3ef2de27
      Matt Johnston authored
      255 byte support has been tested on a npcm750 board
      Signed-off-by: default avatarMatt Johnston <matt@codeconstruct.com.au>
      Reviewed-by: default avatarTali Perry <tali.perry1@gmail.com>
      Reviewed-by: default avatarPatrick Venture <venture@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ef2de27
    • Matt Johnston's avatar
      i2c: aspeed: Allow 255 byte block transfers · 1b2ba1f5
      Matt Johnston authored
      255 byte transfers have been tested on an AST2500 board
      Signed-off-by: default avatarMatt Johnston <matt@codeconstruct.com.au>
      Reviewed-by: default avatarBrendan Higgins <brendanhiggins@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1b2ba1f5
    • Matt Johnston's avatar
      i2c: dev: Handle 255 byte blocks for i2c ioctl · 84a107e6
      Matt Johnston authored
      I2C_SMBUS is limited to 32 bytes due to compatibility with the
      32 byte i2c_smbus_data.block
      
      I2C_RDWR allows larger transfers if sufficient sized buffers are passed.
      Signed-off-by: default avatarMatt Johnston <matt@codeconstruct.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      84a107e6
    • Matt Johnston's avatar
      i2c: core: Allow 255 byte transfers for SMBus 3.x · 13cae4a1
      Matt Johnston authored
      SMBus 3.0 increased the maximum block transfer size from 32 bytes to
      255 bytes. We increase the size of struct i2c_smbus_data's block[]
      member.
      
      i2c_smbus_xfer() and i2c_smbus_xfer_emulated() now support 255 byte
      block operations, other block functions remain limited to 32 bytes for
      compatibility with existing callers.
      
      We allow adapters to indicate support for the larger size with
      I2C_FUNC_SMBUS_V3_BLOCK. Most emulated drivers should be able to use 255
      byte blocks by replacing I2C_SMBUS_BLOCK_MAX with I2C_SMBUS_V3_BLOCK_MAX
      though some will have hardware limitations that need testing.
      Signed-off-by: default avatarMatt Johnston <matt@codeconstruct.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13cae4a1
    • Christophe JAILLET's avatar
      net: bridge: Slightly optimize 'find_portno()' · cc0be1ad
      Christophe JAILLET authored
      The 'inuse' bitmap is local to this function. So we can use the
      non-atomic '__set_bit()' to save a few cycles.
      
      While at it, also remove some useless {}.
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cc0be1ad
    • Harshit Mogalapalli's avatar
      net: sched: sch_netem: Refactor code in 4-state loss generator · cb3ef7b0
      Harshit Mogalapalli authored
      Fixed comments to match description with variable names and
      refactored code to match the convention as per [1].
      
      To match the convention mapping is done as follows:
      State 3 - LOST_IN_BURST_PERIOD
      State 4 - LOST_IN_GAP_PERIOD
      
      [1] S. Salsano, F. Ludovici, A. Ordine, "Definition of a general
      and intuitive loss model for packet networks and its implementation
      in the Netem module in the Linux kernel"
      
      Fixes: a6e2fe17 ("sch_netem: replace magic numbers with enumerate")
      Signed-off-by: default avatarHarshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
      Acked-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cb3ef7b0
    • Uwe Kleine-König's avatar
      net: dsa: vsc73xxx: Make vsc73xx_remove() return void · e99fa423
      Uwe Kleine-König authored
      vsc73xx_remove() returns zero unconditionally and no caller checks the
      returned value. So convert the function to return no value.
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e99fa423