An error occurred fetching the project authors.
- 13 Dec, 2015 38 commits
-
-
Jacob Keller authored
Rather than wrapping fm10k_dcbnl.c and fm10k_debugfs.c support with #ifdef blocks, just conditionally include the .o files in the Makefile. Also, since we're modifying it, update the copyright year on the Makefile. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
Bruce Allan <bruce.w.allan@intel.com> Tested-by:
Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Jacob Keller authored
We haven't bumped the driver version in a while despite many fixes being pulled in from the out-of-tree Sourceforge driver. Update the version to match. Signed-off-by:
-
Jacob Keller authored
Instead of using lowercase vlan, vid, or VID, always use VLAN or VLAN ID in comments when referring to VLANs. The original driver code was consistent, but recent patches have not been as consistent with this naming scheme. Signed-off-by:
-
Jacob Keller authored
Signed-off-by:
-
Jacob Keller authored
Improve code style by removing the unnecessary else block of an if statement which immediately returns. Signed-off-by:
-
Jacob Keller authored
Avoid the use of CamelCase for some variable names that previously slipped through review. Reported-by:
-
Jacob Keller authored
Use the ether_addr_copy function instead of copying byte-by-byte in a for-loop by hand. Reported-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 1GbE Intel Wired LAN Driver Updates 2015-12-12 This series contains updates to e1000, e1000e and igb. Joern Engel fixes up the e1000 driver to reduce scheduler latencies by making the eeprom read/write functions scheduler friendly by using a mutex lock instead of a spin lock. Todd adds code for igb to initialize the 88E1543 PHY properly. Then fixed igb to use the correct i210 register for EEMNGCTL, since the i210 has two EEPROM access registers (EEARBC and EEMNGCTL). Dmitry Vyukov provides a fix for e1000 to resolve a data race found with KernelThreadSanitizer (KTSAN), where no memory barriers were being used when buffers get recycled, so the recycled buffers can be corrupted. So use smp_store_release() to update tx_ring->next_to_clean and smp_load_acquire() to read tx_ring->next_to_clean to properly hand off buffers from e1000_clean_tx_irq() to e1000_xmit_frame(). Jarod Wilson fixes igb so that we do not try to unmap a NULL hw_addr. Then cleaned up array_rd32() so that it uses igb_rd32() the same as rd32() and use io_addr() in more places so that we do not have to call E1000_REMOVED(). Janusz Wolak cleans up the e1000 driver by correcting warnings produced by checkpatch.pl for the driver. Jean Sacren provides several patches with general cleanups for e1000 and e1000e, which include code comment fix-ups and cleanup of local variables not needed. Dmitry Fleytman fixes a possible division by zero in the receive interrupt handler for e1000e when working without adaptive interrupt moderation, which is typically disabled on jumbo MTUs. Raanan increases the timeout of the polling bit due to timing changes to the ME firmware on a platform, so increase the timeout to 300ms. Added initial support for i219-LM, which is a LOM that will be available on systems with the Lewisburg Platform Controller HUB (PCH) chipset. Jan Beulich fixes a NULL dereference in igb, due to the adapter->vf _data being NULL while adapter->vfs_allocated_count is non-zero. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Raanan Avargil authored
i219-LM (3) is a LOM that will be available on systems with the Lewisburg Platform Controller Hub (PCH) chipset from Intel. This patch provides the initial support for the device. Signed-off-by:
Raanan Avargil <raanan.avargil@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
-
Jarod Wilson authored
Clean up array_rd32 so that it uses igb_rd32 the same as rd32, per the suggestion of Alexander Duyck, and use io_addr in more places, so that we don't have the need to call E1000_REMOVED (which simply looks for a null hw_addr) nearly as much. Signed-off-by:
Jarod Wilson <jarod@redhat.com> Acked-by:
Alexander Duyck <aduyck@mirantis.com> Tested-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 40GbE Intel Wired LAN Driver Updates 2015-12-12 This series contains updates to i40e and i40evf only. Jesse fixes some trivial static analyzer warnings where BIT() can be used instead of BIT_ULL(). Mitch fixes the virtual channel interface which was using incorrect semantics to remove MAC addresses and would leave incorrect filters active when using VLANs. Also fixes an issue that when VF's are created, the MAC address defaults to all zeros, indicating to the VF driver that it should use a random MAC address. However, the PF driver was incorrectly adding this zero MAC to the filter table, so check for a good address before adding the default filter. Adds a check to make sure that the Tx and Rx rings actually exist before dereferencing them to free resources. Re-classifies several messages which are really for debugging purposes, especially since the driver can fully recover from any of these. Fixed up the VF version strings to match the PF driver. Anjali adds a virtchnl offload to support the expanded version of TCP/UDP PCTYPES for RSS. Shannon fixes i40e to clean the whole MAC filter list when resetting after an intermediate add or delete push to the firmware. v2: added blank line after variable declaration in patch 9 based on feedback from Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> ==================== Signed-off-by: -
Jan Beulich authored
The combined effect of commits 6423fc34 ("igb: do not re-init SR-IOV during probe") and ceee3450 ("igb: make sure SR-IOV init uses the right number of queues") causes VFs no longer getting set up, leading to NULL pointer dereferences due to the adapter's ->vf_data being NULL while ->vfs_allocated_count is non-zero. The first commit not only neglected the side effect of igb_sriov_reinit() that the second commit tried to account for, but also that of setting IGB_FLAG_HAS_MSIX, without which igb_enable_sriov() is effectively a no-op. Calling igb_{,re}set_interrupt_capability() as done here seems to address this, but I'm not sure whether this is better than sinply reverting the other two commits. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Tested-by:
-
Raanan Avargil authored
Due to timing changes to the ME firmware in Skylake, this timer needs to be increased to 300ms. Signed-off-by:
-
Dmitry Fleytman authored
This patch fixes possible division by zero in receive interrupt handler when working without adaptive interrupt moderation. The adaptive interrupt moderation mechanism is typically disabled on jumbo MTUs. Signed-off-by:
Dmitry Fleytman <dmitry@daynix.com> Signed-off-by:
Leonid Bloch <leonid@daynix.com> Tested-by:
-
Janusz Wolak authored
Signed-off-by:
Janusz Wolak <januszvdm@gmail.com> Acked-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by:
-
Jean Sacren authored
By using goto statement, we can achieve sharing the same exit path so that code duplication could be minimized. Signed-off-by:
Jean Sacren <sakiwit@gmail.com> Tested-by:
-
Jean Sacren authored
Due to historical reason, 'phy_data' has never been included in the kernel doc. Fix it so that the requirement could be fulfilled. Signed-off-by:
-
Jean Sacren authored
The local variable 'ret' doesn't serve much purpose so we might as well clean it up. Signed-off-by:
-
Jean Sacren authored
Use 'That' to replace 'The' so that the comment would make sense. Signed-off-by:
-
Jean Sacren authored
The checking logic needed some clean-up work, so we rewrite it by checking for break first. With that change in place, we can even move the second check for goto statement outside of the loop. As this is merely a cleanup, no functional change is involved. The questionable 'tmp != 0xFF' is intentionally left alone. Mark Rustad and Alexander Duyck contributed to this patch. CC: Mark Rustad <mark.d.rustad@intel.com> CC: Alex Duyck <aduyck@mirantis.com> Signed-off-by:
-
Todd Fujinaka authored
The i210 has two EEPROM access registers that are located in non-standard offsets: EEARBC and EEMNGCTL. EEARBC was fixed previously and EEMNGCTL should also be corrected. Reported-by:
Roman Hodek <roman.aud@siemens.com> Signed-off-by:
Todd Fujinaka <todd.fujinaka@intel.com> Tested-by:
-
Janusz Wolak authored
Signed-off-by:
-
Jarod Wilson authored
I've got a startech thunderbolt dock someone loaned me, which among other things, has the following device in it: 08:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) This hotplugs just fine (kernel 4.2.0 plus a patch or two here): [ 863.020315] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.2.18-k [ 863.020316] igb: Copyright (c) 2007-2014 Intel Corporation. [ 863.028657] igb 0000:08:00.0: enabling device (0000 -> 0002) [ 863.062089] igb 0000:08:00.0: added PHC on eth0 [ 863.062090] igb 0000:08:00.0: Intel(R) Gigabit Ethernet Network Connection [ 863.062091] igb 0000:08:00.0: eth0: (PCIe:2.5Gb/s:Width x1) e8:ea:6a:00:1b:2a [ 863.062194] igb 0000:08:00.0: eth0: PBA No: 000200-000 [ 863.062196] igb 0000:08:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s) [ 863.064889] igb 0000:08:00.0 enp8s0: renamed from eth0 But disconnecting it is another story: [ 1002.807932] igb 0000:08:00.0: removed PHC on enp8s0 [ 1002.807944] igb 0000:08:00.0 enp8s0: PCIe link lost, device now detached [ 1003.341141] ------------[ cut here ]------------ [ 1003.341148] WARNING: CPU: 0 PID: 199 at lib/iomap.c:43 bad_io_access+0x38/0x40() [ 1003.341149] Bad IO access at port 0x0 () [ 1003.342767] Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi igb dca firewire_ohci firewire_core crc_itu_t rfcomm ctr ccm arc4 iwlmvm mac80211 fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter bnep dm_mirror dm_region_hash dm_log dm_mod coretemp x86_pkg_temp_thermal intel_powerclamp kvm_intel snd_hda_codec_hdmi kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drbg [ 1003.342793] ansi_cprng aesni_intel hp_wmi aes_x86_64 iTCO_wdt lrw iTCO_vendor_support ppdev gf128mul sparse_keymap glue_helper ablk_helper cryptd snd_hda_codec_realtek snd_hda_codec_generic microcode snd_hda_intel uvcvideo iwlwifi snd_hda_codec videobuf2_vmalloc videobuf2_memops snd_hda_core videobuf2_core snd_hwdep btusb v4l2_common btrtl snd_seq btbcm btintel videodev cfg80211 snd_seq_device rtsx_pci_ms bluetooth pcspkr input_leds i2c_i801 media parport_pc memstick rfkill sg lpc_ich snd_pcm 8250_fintek parport joydev snd_timer snd soundcore hp_accel ie31200_edac mei_me lis3lv02d edac_core input_polldev mei hp_wireless shpchp tpm_infineon sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables autofs4 xfs libcrc32c sd_mod sr_mod cdrom rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci [ 1003.342822] nouveau ahci libahci mxm_wmi e1000e xhci_pci hwmon ptp drm_kms_helper pps_core xhci_hcd ttm wmi video ipv6 [ 1003.342839] CPU: 0 PID: 199 Comm: kworker/0:2 Not tainted 4.2.0-2.el7_UNSUPPORTED.x86_64 #1 [ 1003.342840] Hardware name: Hewlett-Packard HP ZBook 15 G2/2253, BIOS M70 Ver. 01.07 02/26/2015 [ 1003.342843] Workqueue: pciehp-3 pciehp_power_thread [ 1003.342844] ffffffff81a90655 ffff8804866d3b48 ffffffff8164763a 0000000000000000 [ 1003.342846] ffff8804866d3b98 ffff8804866d3b88 ffffffff8107134a ffff8804866d3b88 [ 1003.342847] ffff880486f46000 ffff88046c8a8000 ffff880486f46840 ffff88046c8a8098 [ 1003.342848] Call Trace: [ 1003.342852] [<ffffffff8164763a>] dump_stack+0x45/0x57 [ 1003.342855] [<ffffffff8107134a>] warn_slowpath_common+0x8a/0xc0 [ 1003.342857] [<ffffffff810713c6>] warn_slowpath_fmt+0x46/0x50 [ 1003.342859] [<ffffffff8133719e>] ? pci_disable_msix+0x3e/0x50 [ 1003.342860] [<ffffffff812f6328>] bad_io_access+0x38/0x40 [ 1003.342861] [<ffffffff812f6567>] pci_iounmap+0x27/0x40 [ 1003.342865] [<ffffffffa0b728d7>] igb_remove+0xc7/0x160 [igb] [ 1003.342867] [<ffffffff8132189f>] pci_device_remove+0x3f/0xc0 [ 1003.342869] [<ffffffff81433426>] __device_release_driver+0x96/0x130 [ 1003.342870] [<ffffffff814334e3>] device_release_driver+0x23/0x30 [ 1003.342871] [<ffffffff8131b404>] pci_stop_bus_device+0x94/0xa0 [ 1003.342872] [<ffffffff8131b3ad>] pci_stop_bus_device+0x3d/0xa0 [ 1003.342873] [<ffffffff8131b3ad>] pci_stop_bus_device+0x3d/0xa0 [ 1003.342874] [<ffffffff8131b516>] pci_stop_and_remove_bus_device+0x16/0x30 [ 1003.342876] [<ffffffff81333f5b>] pciehp_unconfigure_device+0x9b/0x180 [ 1003.342877] [<ffffffff81333a73>] pciehp_disable_slot+0x43/0xb0 [ 1003.342878] [<ffffffff81333b6d>] pciehp_power_thread+0x8d/0xb0 [ 1003.342885] [<ffffffff810881b2>] process_one_work+0x152/0x3d0 [ 1003.342886] [<ffffffff8108854a>] worker_thread+0x11a/0x460 [ 1003.342887] [<ffffffff81088430>] ? process_one_work+0x3d0/0x3d0 [ 1003.342890] [<ffffffff8108ddd9>] kthread+0xc9/0xe0 [ 1003.342891] [<ffffffff8108dd10>] ? kthread_create_on_node+0x180/0x180 [ 1003.342893] [<ffffffff8164e29f>] ret_from_fork+0x3f/0x70 [ 1003.342894] [<ffffffff8108dd10>] ? kthread_create_on_node+0x180/0x180 [ 1003.342895] ---[ end trace 65a77e06d5aa9358 ]--- Upon looking at the igb driver, I see that igb_rd32() attempted to read from hw_addr and failed, so it set hw->hw_addr to NULL and spit out the message in the log output above, "PCIe link lost, device now detached". Well, now that hw_addr is NULL, the attempt to call pci_iounmap is obviously not going to go well. As suggested by Mark Rustad, do something similar to what ixgbe does, and save a copy of hw_addr as adapter->io_addr, so we can still call pci_iounmap on it on teardown. Additionally, for consistency, make the pci_iomap call assignment directly to io_addr, so map and unmap match. Signed-off-by:
-
Dmitriy Vyukov authored
e1000_clean_tx_irq cleans buffers and sets tx_ring->next_to_clean, then e1000_xmit_frame reuses the cleaned buffers. But there are no memory barriers when buffers gets recycled, so the recycled buffers can be corrupted. Use smp_store_release to update tx_ring->next_to_clean and smp_load_acquire to read tx_ring->next_to_clean to properly hand off buffers from e1000_clean_tx_irq to e1000_xmit_frame. The data race was found with KernelThreadSanitizer (KTSAN). Signed-off-by:
Dmitry Vyukov <dvyukov@google.com> Tested-by:
-
Todd Fujinaka authored
Initialize the 88E1543 PHY. Signed-off-by:
-
Joern Engel authored
Code was responsible for ~150ms scheduler latencies. Signed-off-by:
Joern Engel <joern@logfs.org> Signed-off-by:
Spencer Baugh <sbaugh@catern.com> Tested-by:
-
Catherine Sullivan authored
Bump. Change-ID: I2b8976bde070244de144e2ed8990b083de39f332 Signed-off-by:
Catherine Sullivan <catherine.sullivan@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
-
Mitch Williams authored
Generate version strings like the PF driver does. This gives us more flexibility to add suffixes to the version string at build time. Change-ID: I0a5ca0783dd8fb849516bfc1e37ea070127847bd Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Tested-by:
-
Shannon Nelson authored
Clean the whole mac filter list when resetting after an intermediate add or delete push to the firmware. The code had evolved from using a list from the stack to a heap allocation, but the memset() didn't follow the change correctly. This now cleans the whole list rather that just part of the first element. Change-ID: I4cd03d5a103b7407dd8556a3a231e800f2d6f2d5 Reported-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
Shannon Nelson <shannon.nelson@intel.com> Tested-by:
-
Anjali Singhai Jain authored
X722 supports Expanded version of TCP, UDP PCTYPES for RSS. Add a Virtchnl offload to support this. Without this patch with X722 devices, driver will set wrong PCTYPES for VF and UDP flows will not fan out. Change-ID: I04fe4988253b7cd108c9179a643c969764efcb76 Signed-off-by:
Anjali Singhai Jain <anjali.singhai@intel.com> Tested-by:
-
Mitch Williams authored
These messages seem big and scary, but they're really not. The driver can fully recover from any of these. The overflow error in particular can happen when enabling a bunch of VFs and the VF driver is not blacklisted. Since these messages are really for debugging purposes, reclassify them as such. Change-ID: I628d0f5e135e7063450ba05393a50b7af23aa6d7 Signed-off-by:
-
Michal Kosiarz authored
This is a part of implementation which contains data structures and opcode for new AQ command. There's a new ARQ message that gets sent near the end of the NVM update process that the driver should recognize and ignore, rather than printing an Unknown Event error. Change-ID: I04830a5bcae14823e16b9424cc4165e169336c1f Signed-off-by:
Michal Kosiarz <michal.kosiarz@intel.com> Acked-by:
-
Kamil Krawczyk authored
Current implementation generates compilation warnings. Change-ID: Icceefb50fe62aefaf90a64afb7192e08355a4ec5 Signed-off-by:
Kamil Krawczyk <kamil.krawczyk@intel.com> Acked-by:
-
Mitch Williams authored
If the driver gets unloaded during reset recovery, it's possible that it will attempt to free resources when they're already free. Add a check to make sure that the Tx and Rx rings actually exist before dereferencing them to free resources. Change-ID: I4d2b7e9ede49f634d421a4c5deaa5446bc755eee Signed-off-by:
-
Mitch Williams authored
When VFs are created, the MAC address defaults to all zeros, indicating to the VF driver that it should use a random MAC address. However, the PF driver was incorrectly adding this zero MAC to the filter table, along with the VF's randomly generated MAC address. Check for a good address before adding the default filter. While we're at it, make the error message a bit more useful. Change-ID: Ia100947d68140e0f73a19ba755cbffc3e79a8fcf Signed-off-by:
-
Mitch Williams authored
The virtual channel interface was using incorrect semantics to remove MAC addresses, which would leave incorrect filters active when using VLANs. To correct this, add a new function that unconditionally removes MAC addresses from all VLANs, and call this function when the VF requests a MAC filter removal. Change-ID: I69826908ae4f6c847f5bf9b32f11faa760189c74 Signed-off-by:
-
Jesse Brandeburg authored
BIT_ULL was used on a u32 or less where it can simply be BIT. This fixes some trivial static analyzer warnings. Chomp, chomp. Tested with objdump of binary before and after, no changes to code. Change-ID: I6245e9abd447192dbde1669c747aeb2878126c7d Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 10GbE Intel Wired LAN Driver Updates 2015-12-12 This series contains updates to ixgbe only. Alex Duyck provides almost off of the changes in this series. First, add a check to make sure mac_table was actually allocated and is not NULL to ensure we do not get a NULL pointer dereference further down the line. Fixed SR-IOV VLAN pool configuration since the code for checking the PF bit in ixgbe_set_vf_vlan_msg() was using the wrong offset. Cleanup/simplify the logic for setting the VFTA register by removing the number of conditional checks needed. Fixed a number of issues within the VLVF and VLFB configuration by simplifying the code. Added support for bypassing the VLVF entry creation when the PF is adding a new VLAN. Reduced the complexity of the search function used for finding a VLVF entry associated with a given VLAN ID. Added support for VLAN promiscuous with SR-IOV enabled by setting all the bits in the VFTA and all of the VLVF bits associated with teh pool belonging to the PF, in addition to cleaning up those same bits in the event of promiscuous mode being disabled. Fixed and issue where we ran the risk of leaking an address into pool 0 which really belongs to VF 0 when SR-IOV is enabled. Emil fixes an issue with some X550 devices which can connect at 2.5Gbps, but only with certain link partners during fail-over, so to avoid confusion, we do not report it as supported. ==================== Signed-off-by:
-
- 12 Dec, 2015 2 commits
-
-
Daniel Borkmann authored
Add support for renaming and hard links to the fs. Most of this can be implemented by using simple library operations under the same constraints that we don't use a reserved name like elsewhere. Linking can be useful to share/manage things like maps across subsystem users. It works within the file system boundary, but is not allowed for directories. Symbolic links are explicitly not implemented here, as it can be better done already by doing bind mounts inside bpf fs to set up shared directories f.e. useful when using volumes in docker containers that map a private working directory into /sys/fs/bpf/ which contains itself a bind mounted path from the host's /sys/fs/bpf/ mount that is shared among multiple containers. For single maps instead of whole directory, hard links can be easily used to do the same. Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Emil Tantilov authored
Some X550 devices can connect at 2.5Gbps during fail-over, but only with certain link partners. Also setting the advertised speed will not work so we do not report it as supported to avoid confusion. Signed-off-by:
Emil Tantilov <emil.s.tantilov@intel.com> Tested-by:
Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by:
-
