1. 12 6月, 2017 9 次提交
  2. 11 6月, 2017 13 次提交
  3. 10 6月, 2017 2 次提交
  4. 09 6月, 2017 9 次提交
  5. 08 6月, 2017 7 次提交
    • S
      netvsc: move filter setting to rndis_device · 4f19c0d8
      stephen hemminger 提交于
      The work queue and handling of network filter parameters should
      be in rndis_device. This gets rid of warning from RCU checks,
      eliminates a race and cleans up code.
      Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f19c0d8
    • S
      netvsc: fix net poll mode · a5ecd439
      stephen hemminger 提交于
      The ndo_poll_controller function needs to schedule NAPI to pick
      up arriving packets and send completions. Otherwise no data
      will ever be received. For simple case of netconsole, it also
      will allow send completions to happen.  Without this netpoll
      will eventually get stuck.
      Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a5ecd439
    • S
      netvsc: fix rcu dereference warning from ethtool · fbd4c7e7
      stephen hemminger 提交于
      The ethtool info command calls the netvsc get_sset_count with RTNL
      but not with RCU. Which causes warning:
      
      drivers/net/hyperv/netvsc_drv.c:1010 suspicious rcu_dereference_check() usage!
      Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbd4c7e7
    • C
      net: emac: fix and unify emac_mdio functions · 9065bc38
      Christian Lamparter 提交于
      emac_mdio_read_link() was not copying the requested phy settings
      back into the emac driver's own phy api. This has caused a link
      speed mismatch issue for the AR8035 as the emac driver kept
      trying to connect with 10/100MBps on a 1GBit/s link.
      
      This patch also unifies shared code between emac_setup_aneg()
      and emac_mdio_setup_forced(). And furthermore it removes
      a chunk of emac_mdio_init_phy(), that was copying the same
      data into itself.
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9065bc38
    • C
      net: emac: fix reset timeout with AR8035 phy · 19d90ece
      Christian Lamparter 提交于
      This patch fixes a problem where the AR8035 PHY can't be
      detected on an Cisco Meraki MR24, if the ethernet cable is
      not connected on boot.
      
      Russell Senior provided steps to reproduce the issue:
      |Disconnect ethernet cable, apply power, wait until device has booted,
      |plug in ethernet, check for interfaces, no eth0 is listed.
      |
      |This appears to be a problem during probing of the AR8035 Phy chip.
      |When ethernet has no link, the phy detection fails, and eth0 is not
      |created. Plugging ethernet later has no effect, because there is no
      |interface as far as the kernel is concerned. The relevant part of
      |the boot log looks like this:
      |this is the failing case:
      |
      |[    0.876611] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
      |[    0.882532] /plb/opb/ethernet@ef600c00: reset timeout
      |[    0.888546] /plb/opb/ethernet@ef600c00: can't find PHY!
      |and the succeeding case:
      |
      |[    0.876672] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
      |[    0.883952] eth0: EMAC-0 /plb/opb/ethernet@ef600c00, MAC 00:01:..
      |[    0.890822] eth0: found Atheros 8035 Gigabit Ethernet PHY (0x01)
      
      Based on the comment and the commit message of
      commit 23fbb5a8 ("emac: Fix EMAC soft reset on 460EX/GT").
      This is because the AR8035 PHY doesn't provide the TX Clock,
      if the ethernet cable is not attached. This causes the reset
      to timeout and the PHY detection code in emac_init_phy() is
      unable to detect the AR8035 PHY. As a result, the emac driver
      bails out early and the user left with no ethernet.
      
      In order to stay compatible with existing configurations, the driver
      tries the current reset approach at first. Only if the first attempt
      timed out, it does perform one more retry with the clock temporarily
      switched to the internal source for just the duration of the reset.
      
      LEDE-Bug: #687 <https://bugs.lede-project.org/index.php?do=details&task_id=687>
      
      Cc: Chris Blake <chrisrblake93@gmail.com>
      Reported-by: NRussell Senior <russell@personaltelco.net>
      Fixes: 23fbb5a8 ("emac: Fix EMAC soft reset on 460EX/GT")
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      19d90ece
    • D
      net: Fix inconsistent teardown and release of private netdev state. · cf124db5
      David S. Miller 提交于
      Network devices can allocate reasources and private memory using
      netdev_ops->ndo_init().  However, the release of these resources
      can occur in one of two different places.
      
      Either netdev_ops->ndo_uninit() or netdev->destructor().
      
      The decision of which operation frees the resources depends upon
      whether it is necessary for all netdev refs to be released before it
      is safe to perform the freeing.
      
      netdev_ops->ndo_uninit() presumably can occur right after the
      NETDEV_UNREGISTER notifier completes and the unicast and multicast
      address lists are flushed.
      
      netdev->destructor(), on the other hand, does not run until the
      netdev references all go away.
      
      Further complicating the situation is that netdev->destructor()
      almost universally does also a free_netdev().
      
      This creates a problem for the logic in register_netdevice().
      Because all callers of register_netdevice() manage the freeing
      of the netdev, and invoke free_netdev(dev) if register_netdevice()
      fails.
      
      If netdev_ops->ndo_init() succeeds, but something else fails inside
      of register_netdevice(), it does call ndo_ops->ndo_uninit().  But
      it is not able to invoke netdev->destructor().
      
      This is because netdev->destructor() will do a free_netdev() and
      then the caller of register_netdevice() will do the same.
      
      However, this means that the resources that would normally be released
      by netdev->destructor() will not be.
      
      Over the years drivers have added local hacks to deal with this, by
      invoking their destructor parts by hand when register_netdevice()
      fails.
      
      Many drivers do not try to deal with this, and instead we have leaks.
      
      Let's close this hole by formalizing the distinction between what
      private things need to be freed up by netdev->destructor() and whether
      the driver needs unregister_netdevice() to perform the free_netdev().
      
      netdev->priv_destructor() performs all actions to free up the private
      resources that used to be freed by netdev->destructor(), except for
      free_netdev().
      
      netdev->needs_free_netdev is a boolean that indicates whether
      free_netdev() should be done at the end of unregister_netdevice().
      
      Now, register_netdevice() can sanely release all resources after
      ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit()
      and netdev->priv_destructor().
      
      And at the end of unregister_netdevice(), we invoke
      netdev->priv_destructor() and optionally call free_netdev().
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf124db5
    • A
      net: mvpp2: do not bypass the mvpp22_port_mii_set function · e173db36
      Antoine Ténart 提交于
      The mvpp22_port_mii_set() function was added by 26975821, but the
      function directly returns without doing anything. This return was used
      when debugging and wasn't removed before sending the patch. Fix this.
      
      Fixes: 26975821 ("net: mvpp2: handle misc PPv2.1/PPv2.2 differences")
      Signed-off-by: NAntoine Tenart <antoine.tenart@free-electrons.com>
      Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e173db36