Re: [net-next 12/12] igc: Clean up code

On 11/8/2018 13:00, Joe Perches wrote: On Wed, 2018-11-07 at 14:48 -0800, Jeff Kirsher wrote: From: Sasha Neftin Address few community comments. Remove unused code, will be added per demand. Remove blank lines and unneeded includes. Signed-off-by: Sasha Neftin Tested-by: Aaron Brown

Re: [net-next 03/11] igc: Add netdev

On 10/18/2018 20:15, Jakub Kicinski wrote: On Wed, 17 Oct 2018 15:23:14 -0700, Jeff Kirsher wrote: +/** + * igc_ioctl - I/O control method + * @netdev: network interface device structure + * @ifreq: frequency Is it? :) Ah... Good catch. I will fix that and submit patch. + * @cmd: command +

Re: [PATCH][next] igc: fix error return handling from call to netif_set_real_num_tx_queues

On 10/19/2018 21:16, Colin King wrote: From: Colin Ian King The call to netif_set_real_num_tx_queues is not assigning the error return to variable err even though the next line checks err for an error. Fix this by adding the missing err assignment. Detected by CoverityScan, CID#1474551

Re: [PATCH net-next] igc: Remove set but not used variables 'ctrl_ext, link_mode'

On 10/19/2018 15:40, YueHaibing wrote: Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/intel/igc/igc_base.c: In function 'igc_init_phy_params_base': drivers/net/ethernet/intel/igc/igc_base.c:240:6: warning: variable 'ctrl_ext' set but not used [-Wunused-but-set-variable]

Re: [PATCH net-next] igc: Remove set but not used variable 'pci_using_dac'

On 10/19/2018 15:48, YueHaibing wrote: Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/intel/igc/igc_main.c: In function 'igc_probe': drivers/net/ethernet/intel/igc/igc_main.c:3535:11: warning: variable 'pci_using_dac' set but not used [-Wunused-but-set-variable] It never

Re: [net-next 01/11] igc: Add skeletal frame for Intel(R) 2.5G Ethernet Controller support

On 10/18/2018 20:14, Jakub Kicinski wrote: On Wed, 17 Oct 2018 15:23:12 -0700, Jeff Kirsher wrote: From: Sasha Neftin This patch adds the beginning framework onto which I am going to add the igc driver which supports the Intel(R) I225-LM/I225-V 2.5G Ethernet Controller. Signed-off-by: Sasha

Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection

On 8/8/2018 17:24, Neftin, Sasha wrote: On 8/7/2018 09:42, Camille Bordignon wrote: Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit : On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon wrote: Hello, Recently we experienced some issues with intel NIC (I219-LM and I219-V

Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection

On 8/7/2018 09:42, Camille Bordignon wrote: Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit : On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon wrote: Hello, Recently we experienced some issues with intel NIC (I219-LM and I219-V). It seems that after a wire reconnection,

Re: [Intel-wired-lan] [PATCH] e1000e: Ignore TSYNCRXCTL when getting I219 clock attributes

On 5/10/2018 21:42, Keller, Jacob E wrote: -Original Message- From: Benjamin Poirier [mailto:bpoir...@suse.com] Sent: Thursday, May 10, 2018 12:29 AM To: Kirsher, Jeffrey T Cc: Keller, Jacob E ; Achim Mildenberger

Re: [Intel-wired-lan] [PATCH net-queue] e1000e: Fix check_for_link return value with autoneg off.

On 2/19/2018 22:12, Benjamin Poirier wrote: When autoneg is off, the .check_for_link callback functions clear the get_link_status flag and systematically return a "pseudo-error". This means that the link is not detected as up until the next execution of the e1000_watchdog_task() 2 seconds later.

Re: [Intel-wired-lan] [PATCH] e1000e: allocate ring descriptors with dma_zalloc_coherent

On 1/26/2018 12:24, Pierre-Yves Kerbrat wrote: Descriptor rings were not initialized at zero when allocated When area contained garbage data, it caused skb_over_panic in e1000_clean_rx_irq (if data had E1000_RXD_STAT_DD bit set) This patch makes use of dma_zalloc_coherent to make sure the ring

Re: e1000e hardware unit hangs

On 1/24/2018 20:41, Ben Greear wrote: On 01/24/2018 10:38 AM, Denys Fedoryshchenko wrote: On 2018-01-24 20:31, Ben Greear wrote: On 01/24/2018 08:34 AM, Neftin, Sasha wrote: On 1/24/2018 18:11, Alexander Duyck wrote: On Tue, Jan 23, 2018 at 3:46 PM, Ben Greear <gree...@candelatech.com>

Re: e1000e hardware unit hangs

On 1/24/2018 18:11, Alexander Duyck wrote: On Tue, Jan 23, 2018 at 3:46 PM, Ben Greear wrote: Hello, Anyone have any more suggestions for making e1000e work better? This is from a 4.9.65+ kernel, with these additional e1000e patches applied: e1000e: Fix error path

Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working

On 20/12/2017 18:01, Pavel Machek wrote: On Wed 2017-12-20 16:54:21, Pavel Machek wrote: Hi! Before ask for reverting 19110cfbb..., please, check if follow patch of Benjamin work for you http://patchwork.ozlabs.org/patch/846825/ Pavel, before ask for revert - let's check Benjamin's patch

Re: [Intel-wired-lan] [PATCH] e1000e: Fix e1000_check_for_copper_link_ich8lan return value.

On 11/12/2017 9:26, Benjamin Poirier wrote: e1000e_check_for_copper_link() and e1000_check_for_copper_link_ich8lan() are the two functions that may be assigned to mac.ops.check_for_link when phy.media_type == e1000_media_type_copper. Commit 19110cfbb34d ("e1000e: Separate signaling for link

Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working

On 12/18/2017 17:50, Neftin, Sasha wrote: On 12/18/2017 13:58, Pavel Machek wrote: On Mon 2017-12-18 13:24:40, Neftin, Sasha wrote: On 12/18/2017 12:26, Pavel Machek wrote: Hi! In v4.15-rc2+, network manager can not see my ethernet card, and manual attempts to ifconfig it up did not really

Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working

On 12/18/2017 13:58, Pavel Machek wrote: On Mon 2017-12-18 13:24:40, Neftin, Sasha wrote: On 12/18/2017 12:26, Pavel Machek wrote: Hi! In v4.15-rc2+, network manager can not see my ethernet card, and manual attempts to ifconfig it up did not really help, either. Card is: 02:00.0 Ethernet

Re: [net-next 6/9] e1000e: fix buffer overrun while the I219 is processing DMA transactions

On 10/11/2017 12:07, David Laight wrote: From: Jeff Kirsher Sent: 10 October 2017 18:22 Intel 100/200 Series Chipset platforms reduced the round-trip latency for the LAN Controller DMA accesses, causing in some high performance cases a buffer overrun while the I219 LAN Connected Device is

Re: [net-next 6/9] e1000e: fix buffer overrun while the I219 is processing DMA transactions

On 10/11/2017 12:07, David Laight wrote: From: Jeff Kirsher Sent: 10 October 2017 18:22 Intel 100/200 Series Chipset platforms reduced the round-trip latency for the LAN Controller DMA accesses, causing in some high performance cases a buffer overrun while the I219 LAN Connected Device is

Re: [Intel-wired-lan] [PATCH net-next v3] e1000e: Be drop monitor friendly

On 8/26/2017 04:14, Florian Fainelli wrote: e1000e_put_txbuf() can be called from normal reclamation path as well as when a DMA mapping failure, so we need to differentiate these two cases when freeing SKBs to be drop monitor friendly. e1000e_tx_hwtstamp_work() and e1000_remove() are processing

Re: [Intel-wired-lan] [PATCH] e1000e: changed some expensive calls of udelay to usleep_range

On 8/23/2017 18:59, Matthew Tan wrote: Calls to udelay are not preemtable by userspace so userspace applications experience a large (~200us) latency when running on core 0. Instead usleep_range can be used to be more friendly to userspace since it is preemtable. This is due

Re: [Intel-wired-lan] [PATCH] e1000e: apply burst mode settings only on default

On 8/27/2017 11:32, Neftin, Sasha wrote: On 8/27/2017 11:30, Neftin, Sasha wrote: On 8/25/2017 18:06, Willem de Bruijn wrote: From: Willem de Bruijn <will...@google.com> Devices that support FLAG2_DMA_BURST have different default values for RDTR and RADV. Apply burst mode default se

Re: [Intel-wired-lan] [PATCH] e1000e: apply burst mode settings only on default

On 8/27/2017 11:30, Neftin, Sasha wrote: On 8/25/2017 18:06, Willem de Bruijn wrote: From: Willem de Bruijn <will...@google.com> Devices that support FLAG2_DMA_BURST have different default values for RDTR and RADV. Apply burst mode default settings only when no explicit value was

Re: [Intel-wired-lan] [PATCH] e1000e: apply burst mode settings only on default

On 8/25/2017 18:06, Willem de Bruijn wrote: From: Willem de Bruijn Devices that support FLAG2_DMA_BURST have different default values for RDTR and RADV. Apply burst mode default settings only when no explicit value was passed at module load. The RDTR default is zero. If

Re: [Intel-wired-lan] [PATCH 4/5] e1000e: Separate signaling for link check/link up

On 7/21/2017 21:36, Benjamin Poirier wrote: Lennart reported the following race condition: \ e1000_watchdog_task \ e1000e_has_link \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link /* link is up */ mac->get_link_status = false;

Re: [Intel-wired-lan] [PATCH] net: intel: e1000e: add check on e1e_wphy() return value

On 21/06/2017 22:52, Gustavo A. R. Silva wrote: Hi Ethan, Quoting Ethan Zhao : Gustavo, The return value of ret_val seems used to check if the access to PHY/NVM got its semaphore, generally speaking, it is needed for every PHY access of this driver.

Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

On 5/31/2017 18:50, Jani Nikula wrote: From: Chris Wilson An error during suspend (e100e_pm_suspend), [ 429.994338] ACPI : EC: event blocked [ 429.994633] e1000e: EEE TX LPI TIMER: 0011 [ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e]

Re: [Intel-wired-lan] [PATCH] e1000e: use disable_hardirq() also for MSIX vectors in e1000_netpoll()

On 5/19/2017 21:34, Cong Wang wrote: On Fri, May 19, 2017 at 12:18 AM, Konstantin Khlebnikov wrote: Replace disable_irq() which waits for threaded irq handlers with disable_hardirq() which waits only for hardirq part. Signed-off-by: Konstantin Khlebnikov

Re: [Intel-wired-lan] [PATCH 1/2] e1000e: Don't return uninitialized stats

On 4/23/2017 15:53, Neftin, Sasha wrote: -Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Benjamin Poirier Sent: Saturday, April 22, 2017 00:20 To: Kirsher, Jeffrey T <jeffrey.t.kirs...@intel.com> Cc: netdev@vger.kernel.org;

Re: [Intel-wired-lan] NFS over NAT causes e1000e transmit hangs

On 4/20/2017 00:15, Florian Fainelli wrote: On 04/19/2017 01:52 AM, Neftin, Sasha wrote: On 4/18/2017 22:05, Florian Fainelli wrote: On 04/18/2017 12:03 PM, Eric Dumazet wrote: On Tue, 2017-04-18 at 11:18 -0700, Florian Fainelli wrote: Hi, I am using NFS over a NAT with two e1000e adapters

Re: [Intel-wired-lan] NFS over NAT causes e1000e transmit hangs

On 4/18/2017 22:05, Florian Fainelli wrote: On 04/18/2017 12:03 PM, Eric Dumazet wrote: On Tue, 2017-04-18 at 11:18 -0700, Florian Fainelli wrote: Hi, I am using NFS over a NAT with two e1000e adapters and with eth1 being the LAN interface and eth0 the WAN interface. The kernel is Ubuntu's

Re: [Intel-wired-lan] [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

On 2/26/2017 11:08, Neftin, Sasha wrote: On 2/19/2017 14:55, Neftin, Sasha wrote: On 2/16/2017 20:42, Bernd Faust wrote: After an upgrade to Linux kernel v4.x the hardware timestamps of the 82579 Gigabit Ethernet Controller are different than expected. The values that are being read are almost

Re: [Intel-wired-lan] [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

On 2/26/2017 11:08, Neftin, Sasha wrote: On 2/19/2017 14:55, Neftin, Sasha wrote: On 2/16/2017 20:42, Bernd Faust wrote: After an upgrade to Linux kernel v4.x the hardware timestamps of the 82579 Gigabit Ethernet Controller are different than expected. The values that are being read are almost

Re: [Intel-wired-lan] [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

On 2/19/2017 14:55, Neftin, Sasha wrote: On 2/16/2017 20:42, Bernd Faust wrote: After an upgrade to Linux kernel v4.x the hardware timestamps of the 82579 Gigabit Ethernet Controller are different than expected. The values that are being read are almost four times as big as before the kernel

Re: [Intel-wired-lan] [PATCH] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

On 2/20/2017 15:02, Chris Wilson wrote: Chris Wilson, Intel Open Source Technology Centre Chris, Please, check patch with fewer code lines. If short patch good and works well for you, please, submit it and we will check then on our side.

Re: [Intel-wired-lan] [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

On 2/16/2017 20:42, Bernd Faust wrote: After an upgrade to Linux kernel v4.x the hardware timestamps of the 82579 Gigabit Ethernet Controller are different than expected. The values that are being read are almost four times as big as before the kernel upgrade. The difference is that after the

Re: [Intel-wired-lan] [PATCH] net: intel: e1000e: use new api ethtool_{get|set}_link_ksettings

On 2/1/2017 00:01, Philippe Reynes wrote: Hi Sasha, On 1/31/17, Neftin, Sasha <sasha.nef...@intel.com> wrote: Philippe, We will look into and try test this patch. I would like ask question. I see that this thread has been started from implementation for e1000 code. Why do you decide

Re: [Intel-wired-lan] [PATCH] net: intel: e1000e: use new api ethtool_{get|set}_link_ksettings

On 1/26/2017 23:19, Philippe Reynes wrote: The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes ---

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

Baicar, Tyler wrote: >> On 11/17/2016 6:31 AM, Neftin, Sasha wrote: >>> On 11/13/2016 10:34 AM, Neftin, Sasha wrote: >>>> On 11/11/2016 12:35 AM, Baicar, Tyler wrote: >>>>> Hello Sasha, >>>>> >>>>> On 11/9/2016 11:19

Fwd:[Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

From: Baicar, Tyler [mailto:tbai...@codeaurora.org] Sent: Tuesday, November 15, 2016 11:50 PM To: Neftin, Sasha <sasha.nef...@intel.com>; Kirsher, Jeffrey T <jeffrey.t.kirs...@intel.com>; intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; linux-ker...@vger.kernel.org; ok...@co

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

On 11/13/2016 10:34 AM, Neftin, Sasha wrote: > On 11/11/2016 12:35 AM, Baicar, Tyler wrote: >> Hello Sasha, >> >> On 11/9/2016 11:19 PM, Neftin, Sasha wrote: >>> On 11/9/2016 11:41 PM, Tyler Baicar wrote: >>>> Move IRQ free code so that it will happ

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

On 11/13/2016 10:34 AM, Neftin, Sasha wrote: > On 11/11/2016 12:35 AM, Baicar, Tyler wrote: >> Hello Sasha, >> >> On 11/9/2016 11:19 PM, Neftin, Sasha wrote: >>> On 11/9/2016 11:41 PM, Tyler Baicar wrote: >>>> Move IRQ free code so that it will happ

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

On 11/11/2016 12:35 AM, Baicar, Tyler wrote: > Hello Sasha, > > On 11/9/2016 11:19 PM, Neftin, Sasha wrote: >> On 11/9/2016 11:41 PM, Tyler Baicar wrote: >>> Move IRQ free code so that it will happen regardless of the >>> __E1000_DOWN bit. Currently the e1

Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN

On 11/9/2016 11:41 PM, Tyler Baicar wrote: > Move IRQ free code so that it will happen regardless of the > __E1000_DOWN bit. Currently the e1000e driver only releases its IRQ > if the __E1000_DOWN bit is cleared. This is not sufficient because > it is possible for __E1000_DOWN to be set without

RE: [net-next 5/5] PCI: disable FLR for 82579 device

wrote: > >> On Sun, Sep 25, 2016 at 10:02:43AM +0300, Neftin, Sasha wrote: >> > On 9/24/2016 12:05 AM, Jeff Kirsher wrote: >> > >On Fri, 2016-09-23 at 09:01 -0500, Bjorn Helgaas wrote: >> > >>On Thu, Sep 22, 2016 at 11:39:01PM -0700, Jeff Ki

Re: [net-next 5/5] PCI: disable FLR for 82579 device

On 9/24/2016 12:05 AM, Jeff Kirsher wrote: On Fri, 2016-09-23 at 09:01 -0500, Bjorn Helgaas wrote: On Thu, Sep 22, 2016 at 11:39:01PM -0700, Jeff Kirsher wrote: From: Sasha Neftin 82579 has a problem reattaching itself after the device is detached. The bug was