1. 04 Nov, 2018 1 commit
  2. 31 Mar, 2018 1 commit
    • Florian Fainelli's avatar
      net: fec: Fix unbalanced PM runtime calls · a14b791d
      Florian Fainelli authored
      
      [ Upstream commit a069215c ]
      
      When unbinding/removing the driver, we will run into the following warnings:
      
      [  259.655198] fec 400d1000.ethernet: 400d1000.ethernet supply phy not found, using dummy regulator
      [  259.665065] fec 400d1000.ethernet: Unbalanced pm_runtime_enable!
      [  259.672770] fec 400d1000.ethernet (unnamed net_device) (uninitialized): Invalid MAC address: 00:00:00:00:00:00
      [  259.683062] fec 400d1000.ethernet (unnamed net_device) (uninitialized): Using random MAC address: f2:3e:93:b7:29:c1
      [  259.696239] libphy: fec_enet_mii_bus: probed
      
      Avoid these warnings by balancing the runtime PM calls during fec_drv_remove().
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a14b791d
  3. 17 Jan, 2018 3 commits
  4. 02 Jan, 2018 1 commit
    • Fugang Duan's avatar
      net: fec: unmap the xmit buffer that are not transferred by DMA · f55ac668
      Fugang Duan authored
      
      [ Upstream commit 178e5f57 ]
      
      The enet IP only support 32 bit, it will use swiotlb buffer to do dma
      mapping when xmit buffer DMA memory address is bigger than 4G in i.MX
      platform. After stress suspend/resume test, it will print out:
      
      log:
      [12826.352864] fec 5b040000.ethernet: swiotlb buffer is full (sz: 191 bytes)
      [12826.359676] DMA: Out of SW-IOMMU space for 191 bytes at device 5b040000.ethernet
      [12826.367110] fec 5b040000.ethernet eth0: Tx DMA memory map failed
      
      The issue is that the ready xmit buffers that are dma mapped but DMA still
      don't copy them into fifo, once MAC restart, these DMA buffers are not unmapped.
      So it should check the dma mapping buffer and unmap them.
      Signed-off-by: default avatarFugang Duan <fugang.duan@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f55ac668
  5. 20 Sep, 2017 2 commits
  6. 24 Aug, 2017 1 commit
  7. 31 Jul, 2017 2 commits
    • Andrew Lunn's avatar
      net: fec: Allow reception of frames bigger than 1522 bytes · fbbeefdd
      Andrew Lunn authored
      The FEC Receive Control Register has a 14 bit field indicating the
      longest frame that may be received. It is being set to 1522. Frames
      longer than this are discarded, but counted as being in error.
      
      When using DSA, frames from the switch has an additional header,
      either 4 or 8 bytes if a Marvell switch is used. Thus a full MTU frame
      of 1522 bytes received by the switch on a port becomes 1530 bytes when
      passed to the host via the FEC interface.
      
      Change the maximum receive size to 2048 - 64, where 64 is the maximum
      rx_alignment applied on the receive buffer for AVB capable FEC
      cores. Use this value also for the maximum receive buffer size. The
      driver is already allocating a receive SKB of 2048 bytes, so this
      change should not have any significant effects.
      
      Tested on imx51, imx6, vf610.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbbeefdd
    • Andrew Lunn's avatar
      net: fec: Issue error for missing but expected PHY · 9558df3a
      Andrew Lunn authored
      If the PHY is missing but expected, e.g. because of a typ0 in the dt
      file, it is not possible to open the interface. ip link returns:
      
      RTNETLINK answers: No such device
      
      It is not very obvious what the problem is. Add a netdev_err() in this
      case to make it easier to debug the issue.
      
      [   21.409385] fec 2188000.ethernet eth0: Unable to connect to phy
      RTNETLINK answers: No such device
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Acked-by: default avatarFugang Duan <fugang.duan@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9558df3a
  8. 10 Jun, 2017 3 commits
  9. 07 Jun, 2017 1 commit
  10. 24 May, 2017 1 commit
  11. 11 Apr, 2017 6 commits
  12. 24 Mar, 2017 1 commit
  13. 14 Feb, 2017 1 commit
  14. 30 Jan, 2017 1 commit
  15. 06 Dec, 2016 1 commit
  16. 30 Nov, 2016 2 commits
  17. 15 Nov, 2016 1 commit
  18. 23 Oct, 2016 1 commit
  19. 20 Oct, 2016 1 commit
  20. 13 Oct, 2016 1 commit
    • Jarod Wilson's avatar
      net: deprecate eth_change_mtu, remove usage · a52ad514
      Jarod Wilson authored
      With centralized MTU checking, there's nothing productive done by
      eth_change_mtu that isn't already done in dev_set_mtu, so mark it as
      deprecated and remove all usage of it in the kernel. All callers have been
      audited for calls to alloc_etherdev* or ether_setup directly, which means
      they all have a valid dev->min_mtu and dev->max_mtu. Now eth_change_mtu
      prints out a netdev_warn about being deprecated, for the benefit of
      out-of-tree drivers that might be utilizing it.
      
      Of note, dvb_net.c actually had dev->mtu = 4096, while using
      eth_change_mtu, meaning that if you ever tried changing it's mtu, you
      couldn't set it above 1500 anymore. It's now getting dev->max_mtu also set
      to 4096 to remedy that.
      
      v2: fix up lantiq_etop, missed breakage due to drive not compiling on x86
      
      CC: netdev@vger.kernel.org
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a52ad514
  21. 03 Oct, 2016 1 commit
  22. 27 Sep, 2016 3 commits
  23. 13 Aug, 2016 1 commit
  24. 27 Jun, 2016 2 commits
  25. 13 Jun, 2016 1 commit