1. 15 Nov, 2019 4 commits
  2. 09 Nov, 2019 1 commit
  3. 01 Nov, 2019 1 commit
  4. 31 Oct, 2019 2 commits
    • Manfred Rudigier's avatar
      igb: Enable media autosense for the i350. · fb2308ba
      Manfred Rudigier authored
      
      
      This patch enables the hardware feature "Media Auto Sense" also on the
      i350. It works in the same way as on the 82850 devices. Hardware designs
      using dual PHYs (fiber/copper) can enable this feature by setting the MAS
      enable bits in the NVM_COMPAT register (0x03) in the EEPROM.
      
      Signed-off-by: default avatarManfred Rudigier <manfred.rudigier@omicronenergy.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      fb2308ba
    • Lyude Paul's avatar
      igb/igc: Don't warn on fatal read failures when the device is removed · 94bc1e52
      Lyude Paul authored
      
      
      Fatal read errors are worth warning about, unless of course the device
      was just unplugged from the machine - something that's a rather normal
      occurrence when the igb/igc adapter is located on a Thunderbolt dock. So,
      let's only WARN() if there's a fatal read error while the device is
      still present.
      
      This fixes the following WARN splat that's been appearing whenever I
      unplug my Caldigit TS3 Thunderbolt dock from my laptop:
      
        igb 0000:09:00.0 enp9s0: PCIe link lost
        ------------[ cut here ]------------
        igb: Failed to read reg 0x18!
        WARNING: CPU: 7 PID: 516 at
        drivers/net/ethernet/intel/igb/igb_main.c:756 igb_rd32+0x57/0x6a [igb]
        Modules linked in: igb dca thunderbolt fuse vfat fat elan_i2c mei_wdt
        mei_hdcp i915 wmi_bmof intel_wmi_thunderbolt iTCO_wdt
        iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp joydev
        coretemp crct10dif_pclmul crc32_pclmul i2c_algo_bit ghash_clmulni_intel
        intel_cstate drm_kms_helper intel_uncore syscopyarea sysfillrect
        sysimgblt fb_sys_fops intel_rapl_perf intel_xhci_usb_role_switch mei_me
        drm roles idma64 i2c_i801 ucsi_acpi typec_ucsi mei intel_lpss_pci
        processor_thermal_device typec intel_pch_thermal intel_soc_dts_iosf
        intel_lpss int3403_thermal thinkpad_acpi wmi int340x_thermal_zone
        ledtrig_audio int3400_thermal acpi_thermal_rel acpi_pad video
        pcc_cpufreq ip_tables serio_raw nvme nvme_core crc32c_intel uas
        usb_storage e1000e i2c_dev
        CPU: 7 PID: 516 Comm: kworker/u16:3 Not tainted 5.2.0-rc1Lyude-Test+ #14
        Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018
        Workqueue: kacpi_hotplug acpi_hotplug_work_fn
        RIP: 0010:igb_rd32+0x57/0x6a [igb]
        Code: 87 b8 fc ff ff 48 c7 47 08 00 00 00 00 48 c7 c6 33 42 9b c0 4c 89
        c7 e8 47 45 cd dc 89 ee 48 c7 c7 43 42 9b c0 e8 c1 94 71 dc <0f> 0b eb
        08 8b 00 ff c0 75 b0 eb c8 44 89 e0 5d 41 5c c3 0f 1f 44
        RSP: 0018:ffffba5801cf7c48 EFLAGS: 00010286
        RAX: 0000000000000000 RBX: ffff9e7956608840 RCX: 0000000000000007
        RDX: 0000000000000000 RSI: ffffba5801cf7b24 RDI: ffff9e795e3d6a00
        RBP: 0000000000000018 R08: 000000009dec4a01 R09: ffffffff9e61018f
        R10: 0000000000000000 R11: ffffba5801cf7ae5 R12: 00000000ffffffff
        R13: ffff9e7956608840 R14: ffff9e795a6f10b0 R15: 0000000000000000
        FS:  0000000000000000(0000) GS:ffff9e795e3c0000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000564317bc4088 CR3: 000000010e00a006 CR4: 00000000003606e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
         igb_release_hw_control+0x1a/0x30 [igb]
         igb_remove+0xc5/0x14b [igb]
         pci_device_remove+0x3b/0x93
         device_release_driver_internal+0xd7/0x17e
         pci_stop_bus_device+0x36/0x75
         pci_stop_bus_device+0x66/0x75
         pci_stop_bus_device+0x66/0x75
         pci_stop_and_remove_bus_device+0xf/0x19
         trim_stale_devices+0xc5/0x13a
         ? __pm_runtime_resume+0x6e/0x7b
         trim_stale_devices+0x103/0x13a
         ? __pm_runtime_resume+0x6e/0x7b
         trim_stale_devices+0x103/0x13a
         acpiphp_check_bridge+0xd8/0xf5
         acpiphp_hotplug_notify+0xf7/0x14b
         ? acpiphp_check_bridge+0xf5/0xf5
         acpi_device_hotplug+0x357/0x3b5
         acpi_hotplug_work_fn+0x1a/0x23
         process_one_work+0x1a7/0x296
         worker_thread+0x1a8/0x24c
         ? process_scheduled_works+0x2c/0x2c
         kthread+0xe9/0xee
         ? kthread_destroy_worker+0x41/0x41
         ret_from_fork+0x35/0x40
        ---[ end trace 252bf10352c63d22 ]---
      
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Fixes: 47e16692
      
       ("igb/igc: warn when fatal read failure happens")
      Acked-by: default avatarSasha Neftin <sasha.neftin@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Acked-by: default avatarFeng Tang <feng.tang@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      94bc1e52
  5. 22 Aug, 2019 1 commit
  6. 23 Jul, 2019 2 commits
  7. 09 Jul, 2019 3 commits
  8. 28 Jun, 2019 3 commits
    • Artem Bityutskiy's avatar
      igb: add RR2DCDELAY to ethtool registers dump · cd502a7f
      Artem Bityutskiy authored
      
      
      This patch adds the RR2DCDELAY register to the ethtool registers dump.
      RR2DCDELAY exists on I210 and I211 Intel Gigabit Ethernet chips and it stands
      for "Read Request To Data Completion Delay". Here is how this register is
      described in the I210 datasheet:
      
      "This field captures the maximum PCIe split time in 16 ns units, which is the
      maximum delay between the read request to the first data completion. This is
      giving an estimation of the PCIe round trip time."
      
      In other words, whenever I210 reads from the host memory (e.g., fetches a
      descriptor from the ring), the chip measures every PCI DMA read transaction and
      captures the maximum value. So it ends up containing the longest DMA
      transaction time.
      
      This register is very useful for troubleshooting and research purposes. If you
      are dealing with time-sensitive networks, this register can help you get
      an idea of your "I210-to-ring" latency. This helps answering questions like
      "should I have PCIe ASPM enabled?" or "should I enable deep C-states?" on
      my system.
      
      It is safe to read this register at any point, reading it has no effect on
      the I210 chip functionality.
      
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      cd502a7f
    • Artem Bityutskiy's avatar
      igb: minor ethool regdump amendment · 9379b399
      Artem Bityutskiy authored
      
      
      This patch has no functional impact and it is just a preparation
      for the following patch. It removes an early return from the
      'igb_get_regs()' function by moving the 82576-only registers
      dump into an "if" block. With this preparation, we can dump more
      non-82576 registers at the end of this function.
      
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      9379b399
    • Vedang Patel's avatar
      igb: clear out skb->tstamp after reading the txtime · 1e08511d
      Vedang Patel authored
      
      
      If a packet which is utilizing the launchtime feature (via SO_TXTIME socket
      option) also requests the hardware transmit timestamp, the hardware
      timestamp is not delivered to the userspace. This is because the value in
      skb->tstamp is mistaken as the software timestamp.
      
      Applications, like ptp4l, request a hardware timestamp by setting the
      SOF_TIMESTAMPING_TX_HARDWARE socket option. Whenever a new timestamp is
      detected by the driver (this work is done in igb_ptp_tx_work() which calls
      igb_ptp_tx_hwtstamps() in igb_ptp.c[1]), it will queue the timestamp in the
      ERR_QUEUE for the userspace to read. When the userspace is ready, it will
      issue a recvmsg() call to collect this timestamp.  The problem is in this
      recvmsg() call. If the skb->tstamp is not cleared out, it will be
      interpreted as a software timestamp and the hardware tx timestamp will not
      be successfully sent to the userspace. Look at skb_is_swtx_tstamp() and the
      callee function __sock_recv_timestamp() in net/socket.c for more details.
      
      Signed-off-by: default avatarVedang Patel <vedang.patel@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e08511d
  9. 28 May, 2019 3 commits
    • Gustavo A. R. Silva's avatar
      igb: mark expected switch fall-through · 42277ced
      Gustavo A. R. Silva authored
      
      
      In preparation to enabling -Wimplicit-fallthrough, mark switch cases
      where we are expecting to fall through.
      
      This patch fixes the following warning:
      
      drivers/net/ethernet/intel/igb/e1000_82575.c: In function ‘igb_get_invariants_82575’:
      drivers/net/ethernet/intel/igb/e1000_82575.c:636:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if (igb_sgmii_uses_mdio_82575(hw)) {
            ^
      drivers/net/ethernet/intel/igb/e1000_82575.c:642:2: note: here
        case E1000_CTRL_EXT_LINK_MODE_PCIE_SERDES:
        ^~~~
      
      Warning level 3 was used: -Wimplicit-fallthrough=3
      
      Notice that, in this particular case, the code comment is modified
      in accordance with what GCC is expecting to find.
      
      This patch is part of the ongoing efforts to enable
      -Wimplicit-fallthrough.
      
      Signed-off-by: default avatar"Gustavo A. R. Silva" <gustavo@embeddedor.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      42277ced
    • Gustavo A. R. Silva's avatar
      igb: mark expected switch fall-through · b7b3ad7a
      Gustavo A. R. Silva authored
      
      
      In preparation to enabling -Wimplicit-fallthrough, mark switch cases
      where we are expecting to fall through.
      
      This patch fixes the following warning:
      
      drivers/net/ethernet/intel/igb/igb_main.c: In function ‘__igb_notify_dca’:
      drivers/net/ethernet/intel/igb/igb_main.c:6694:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if (dca_add_requester(dev) == 0) {
            ^
      drivers/net/ethernet/intel/igb/igb_main.c:6701:2: note: here
        case DCA_PROVIDER_REMOVE:
        ^~~~
      
      Warning level 3 was used: -Wimplicit-fallthrough=3
      
      Notice that, in this particular case, the code comment is modified
      in accordance with what GCC is expecting to find.
      
      This patch is part of the ongoing efforts to enable
      -Wimplicit-fallthrough.
      
      Signed-off-by: default avatar"Gustavo A. R. Silva" <gustavo@embeddedor.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b7b3ad7a
    • Feng Tang's avatar
      igb/igc: warn when fatal read failure happens · 47e16692
      Feng Tang authored
      
      
      Failed in read the HW register is very serious for igb/igc driver,
      as its hw_addr will be set to NULL and cause the adapter be seen as
      "REMOVED".
      
      We saw the error only a few times in the MTBF test for suspend/resume,
      but can hardly get any useful info to debug.
      
      Adding WARN() so that we can get the necessary information about
      where and how it happens, and use it for root causing and fixing
      this "PCIe link lost issue"
      
      This affects igb, igc.
      
      Signed-off-by: default avatarFeng Tang <feng.tang@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Acked-by: default avatarSasha Neftin <sasha.neftin@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      47e16692
  10. 23 Apr, 2019 1 commit
    • Stanislav Fomichev's avatar
      net: pass net_device argument to the eth_get_headlen · c43f1255
      Stanislav Fomichev authored
      
      
      Update all users of eth_get_headlen to pass network device, fetch
      network namespace from it and pass it down to the flow dissector.
      This commit is a noop until administrator inserts BPF flow dissector
      program.
      
      Cc: Maxim Krasnyansky <maxk@qti.qualcomm.com>
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: intel-wired-lan@lists.osuosl.org
      Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
      Cc: Salil Mehta <salil.mehta@huawei.com>
      Cc: Michael Chan <michael.chan@broadcom.com>
      Cc: Igor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      c43f1255
  11. 08 Apr, 2019 1 commit
    • Will Deacon's avatar
      drivers: Remove explicit invocations of mmiowb() · fb24ea52
      Will Deacon authored
      
      
      mmiowb() is now implied by spin_unlock() on architectures that require
      it, so there is no reason to call it from driver code. This patch was
      generated using coccinelle:
      
      	@mmiowb@
      	@@
      	- mmiowb();
      
      and invoked as:
      
      $ for d in drivers include/linux/qed sound; do \
      spatch --include-headers --sp-file mmiowb.cocci --dir $d --in-place; done
      
      NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
      spin_unlock(). However, pairing each mmiowb() removal in this patch with
      the corresponding call to spin_unlock() is not at all trivial, so there
      is a small chance that this change may regress any drivers incorrectly
      relying on mmiowb() to order MMIO writes between CPUs using lock-free
      synchronisation. If you've ended up bisecting to this commit, you can
      reintroduce the mmiowb() calls using wmb() instead, which should restore
      the old behaviour on all architectures other than some esoteric ia64
      systems.
      
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      fb24ea52
  12. 02 Apr, 2019 1 commit
    • Florian Westphal's avatar
      net: move skb->xmit_more hint to softnet data · 6b16f9ee
      Florian Westphal authored
      
      
      There are two reasons for this.
      
      First, the xmit_more flag conceptually doesn't fit into the skb, as
      xmit_more is not a property related to the skb.
      Its only a hint to the driver that the stack is about to transmit another
      packet immediately.
      
      Second, it was only done this way to not have to pass another argument
      to ndo_start_xmit().
      
      We can place xmit_more in the softnet data, next to the device recursion.
      The recursion counter is already written to on each transmit. The "more"
      indicator is placed right next to it.
      
      Drivers can use the netdev_xmit_more() helper instead of skb->xmit_more
      to check the "more packets coming" hint.
      
      skb->xmit_more is retained (but always 0) to not cause build breakage.
      
      This change takes care of the simple s/skb->xmit_more/netdev_xmit_more()/
      conversions.  Remaining drivers are converted in the next patches.
      
      Suggested-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b16f9ee
  13. 26 Mar, 2019 1 commit
    • Arvind Sankar's avatar
      igb: Fix WARN_ONCE on runtime suspend · dabb8338
      Arvind Sankar authored
      
      
      The runtime_suspend device callbacks are not supposed to save
      configuration state or change the power state. Commit fb29f76cc566
      ("igb: Fix an issue that PME is not enabled during runtime suspend")
      changed the driver to not save configuration state during runtime
      suspend, however the driver callback still put the device into a
      low-power state. This causes a warning in the pci pm core and results in
      pci_pm_runtime_suspend not calling pci_save_state or pci_finish_runtime_suspend.
      
      Fix this by not changing the power state either, leaving that to pci pm
      core, and make the same change for suspend callback as well.
      
      Also move a couple of defines into the appropriate header file instead
      of inline in the .c file.
      
      Fixes: fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend")
      Signed-off-by: default avatarArvind Sankar <niveditas98@gmail.com>
      Reviewed-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      dabb8338
  14. 19 Mar, 2019 3 commits
  15. 09 Feb, 2019 1 commit
    • Gustavo A. R. Silva's avatar
      igb: use struct_size() helper · a0feac18
      Gustavo A. R. Silva authored
      
      
      One of the more common cases of allocation size calculations is finding
      the size of a structure that has a zero-sized array at the end, along
      with memory for some number of elements for that array. For example:
      
      struct foo {
          int stuff;
          struct boo entry[];
      };
      
      size = sizeof(struct foo) + count * sizeof(struct boo);
      instance = alloc(size, GFP_KERNEL);
      
      Instead of leaving these open-coded and prone to type mistakes, we can
      now use the new struct_size() helper:
      
      size = struct_size(instance, entry, count);
      
      This code was detected with the help of Coccinelle.
      
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0feac18
  16. 06 Feb, 2019 2 commits
  17. 17 Jan, 2019 1 commit
    • Petr Machata's avatar
      net: Add extack argument to ndo_fdb_add() · 87b0984e
      Petr Machata authored
      
      
      Drivers may not be able to support certain FDB entries, and an error
      code is insufficient to give clear hints as to the reasons of rejection.
      
      In order to make it possible to communicate the rejection reason, extend
      ndo_fdb_add() with an extack argument. Adapt the existing
      implementations of ndo_fdb_add() to take the parameter (and ignore it).
      Pass the extack parameter when invoking ndo_fdb_add() from rtnl_fdb_add().
      
      Signed-off-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      87b0984e
  18. 15 Jan, 2019 1 commit
  19. 20 Dec, 2018 3 commits
  20. 28 Nov, 2018 1 commit
  21. 21 Nov, 2018 2 commits
  22. 10 Nov, 2018 1 commit
  23. 07 Nov, 2018 1 commit