1. 20 Feb, 2020 2 commits
    • Gustavo A. R. Silva's avatar
      mlxsw: Replace zero-length array with flexible-array member · e99f8e7f
      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>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Tested-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e99f8e7f
    • Petr Oros's avatar
      phy: avoid unnecessary link-up delay in polling mode · e96bd2d3
      Petr Oros authored
      commit 93c09704 ("net: phy: consider latched link-down status in
      polling mode") removed double-read of latched link-state register for
      polling mode from genphy_update_link(). This added extra ~1s delay into
      sequence link down->up.
      Following scenario:
       - After boot link goes up
       - phy_start() is called triggering an aneg restart, hence link goes
         down and link-down info is latched.
       - After aneg has finished link goes up. In phy_state_machine is checked
         link state but it is latched "link is down". The state machine is
         scheduled after one second and there is detected "link is up". This
         extra delay can be avoided when we keep link-state register double read
         in case when link was down previously.
      
      With this solution we don't miss a link-down event in polling mode and
      link-up is faster.
      
      Details about this quirky behavior on Realtek phy:
      Without patch:
      T0:    aneg is started, link goes down, link-down status is latched
      T0+3s: state machine runs, up-to-date link-down is read
      T0+4s: state machine runs, aneg is finished (BMSR_ANEGCOMPLETE==1),
             here i read link-down (BMSR_LSTATUS==0),
      T0+5s: state machine runs, aneg is finished (BMSR_ANEGCOMPLETE==1),
             up-to-date link-up is read (BMSR_LSTATUS==1),
             phydev->link goes up, state change PHY_NOLINK to PHY_RUNNING
      
      With patch:
      T0:    aneg is started, link goes down, link-down status is latched
      T0+3s: state machine runs, up-to-date link-down is read
      T0+4s: state machine runs, aneg is finished (BMSR_ANEGCOMPLETE==1),
             first BMSR read: BMSR_ANEGCOMPLETE==1 and BMSR_LSTATUS==0,
             second BMSR read: BMSR_ANEGCOMPLETE==1 and BMSR_LSTATUS==1,
             phydev->link goes up, state change PHY_NOLINK to PHY_RUNNING
      Signed-off-by: default avatarPetr Oros <poros@redhat.com>
      Reviewed-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e96bd2d3
  2. 19 Feb, 2020 34 commits
  3. 18 Feb, 2020 4 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