1. 19 Feb, 2020 1 commit
  2. 18 Feb, 2020 8 commits
    • Edward Cree's avatar
      sfc: elide assignment of skb · 00796b92
      Edward Cree authored
      Instead of assigning skb = segments before the loop, just pass
       segments directly as the first argument to skb_list_walk_safe().
      Signed-off-by: default avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      00796b92
    • Fabio Estevam's avatar
      net: fec: Prevent unbind operation · 272bb0e9
      Fabio Estevam authored
      After performing an unbind/bind operation the network is no longer
      functional on i.MX6 (which has a single FEC instance):
      
      # echo 2188000.ethernet > /sys/bus/platform/drivers/fec/unbind
      # echo 2188000.ethernet > /sys/bus/platform/drivers/fec/bind
      [   10.756519] pps pps0: new PPS source ptp0
      [   10.792626] libphy: fec_enet_mii_bus: probed
      [   10.799330] fec 2188000.ethernet eth0: registered PHC device 1
      # udhcpc -i eth0
      udhcpc: started, v1.31.1
      [   14.985211] fec 2188000.ethernet eth0: no PHY, assuming direct connection to switch
      [   14.993140] libphy: PHY fixed-0:00 not found
      [   14.997643] fec 2188000.ethernet eth0: could not attach to PHY
      
      On SoCs with two FEC instances there are some cases where one FEC instance
      depends on the other one being present. One such example is i.MX28, which
      has the following FEC dependency as noted in the comments:
      
      	/*
      	 * The i.MX28 dual fec interfaces are not equal.
      	 * Here are the differences:
      	 *
      	 *  - fec0 supports MII & RMII modes while fec1 only supports RMII
      	 *  - fec0 acts as the 1588 time master while fec1 is slave
      	 *  - external phys can only be configured by fec0
      	 *
      	 * That is to say fec1 can not work independently. It only works
      	 * when fec0 is working. The reason behind this design is that the
      	 * second interface is added primarily for Switch mode.
      	 *
      	 * Because of the last point above, both phys are attached on fec0
      	 * mdio interface in board design, and need to be configured by
      	 * fec0 mii_bus.
      	 */
      
      Prevent the unbind operation to avoid these issues.
      Signed-off-by: default avatarFabio Estevam <festevam@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      272bb0e9
    • YueHaibing's avatar
      net: ena: remove set but not used variable 'hash_key' · b182a667
      YueHaibing authored
      drivers/net/ethernet/amazon/ena/ena_com.c: In function ena_com_hash_key_allocate:
      drivers/net/ethernet/amazon/ena/ena_com.c:1070:50:
       warning: variable hash_key set but not used [-Wunused-but-set-variable]
      
      commit 6a4f7dc8 ("net: ena: rss: do not allocate key when not supported")
      introduced this, but not used, so remove it.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b182a667
    • Gustavo A. R. Silva's avatar
      net: netlink: Replace zero-length array with flexible-array member · 2b738124
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b738124
    • Gustavo A. R. Silva's avatar
      net: switchdev: Replace zero-length array with flexible-array member · fbfc8502
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbfc8502
    • Gustavo A. R. Silva's avatar
      bpf, sockmap: Replace zero-length array with flexible-array member · 45a4296b
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      45a4296b
    • Gustavo A. R. Silva's avatar
      NFC: digital: Replace zero-length array with flexible-array member · 9814428a
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9814428a
    • Gustavo A. R. Silva's avatar
      net: usb: cdc-phonet: Replace zero-length array with flexible-array member · dc3cc347
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dc3cc347
  3. 17 Feb, 2020 31 commits