1. 05 1月, 2020 12 次提交
  2. 01 1月, 2020 9 次提交
  3. 09 11月, 2019 1 次提交
  4. 08 11月, 2019 1 次提交
  5. 01 11月, 2019 1 次提交
    • L
      igb/igc: Don't warn on fatal read failures when the device is removed · 94bc1e52
      Lyude Paul 提交于
      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: NLyude Paul <lyude@redhat.com>
      Fixes: 47e16692 ("igb/igc: warn when fatal read failure happens")
      Acked-by: NSasha Neftin <sasha.neftin@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Acked-by: NFeng Tang <feng.tang@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      94bc1e52
  6. 22 10月, 2019 4 次提交
  7. 10 9月, 2019 2 次提交
  8. 23 8月, 2019 1 次提交
  9. 25 7月, 2019 1 次提交
  10. 23 7月, 2019 1 次提交
  11. 22 7月, 2019 1 次提交
  12. 29 5月, 2019 2 次提交
  13. 24 4月, 2019 1 次提交
    • S
      net: pass net_device argument to the eth_get_headlen · c43f1255
      Stanislav Fomichev 提交于
      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: NStanislav Fomichev <sdf@google.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      c43f1255
  14. 08 4月, 2019 1 次提交
    • W
      drivers: Remove explicit invocations of mmiowb() · fb24ea52
      Will Deacon 提交于
      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: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      fb24ea52
  15. 02 4月, 2019 1 次提交
    • F
      net: move skb->xmit_more hint to softnet data · 6b16f9ee
      Florian Westphal 提交于
      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: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6b16f9ee
  16. 20 3月, 2019 1 次提交