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.
Reviewed-by: Ethan Zhao
Thank yo
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
; olouvig...@gmail.com;
jaya...@goubiq.com; ehabk...@redhat.com; postmoder
On 22/02/2019 6:09, Florian Fainelli wrote:
Provide precision hints to snprintf() since we know the destination
buffer size of the RX/TX ring names are IFNAMSIZ + 5 - 1. This fixes the
following warnings:
drivers/net/ethernet/intel/e1000e/netdev.c: In function
'e1000_request_msix':
drivers/net/e
On 12/10/2020 07:28, Neftin, Sasha wrote:
On 12/10/2020 04:24, Alexander Duyck wrote:
On Wed, Dec 9, 2020 at 6:44 AM Hans de Goede wrote:
Hi,
On 12/8/20 5:14 PM, Alexander Duyck wrote:
On Tue, Dec 8, 2020 at 1:30 AM Hans de Goede
wrote:
Hi,
On 12/8/20 6:08 AM, Neftin, Sasha wrote:
On
On 12/7/2020 17:41, Limonciello, Mario wrote:
First of all thank you for working on this.
I must say though that I don't like the approach taken here very
much.
This is not so much a criticism of this series as it is a criticism
of the earlier decision to simply disable s0ix on all devices
with
On 12/10/2020 04:24, Alexander Duyck wrote:
On Wed, Dec 9, 2020 at 6:44 AM Hans de Goede wrote:
Hi,
On 12/8/20 5:14 PM, Alexander Duyck wrote:
On Tue, Dec 8, 2020 at 1:30 AM Hans de Goede wrote:
Hi,
On 12/8/20 6:08 AM, Neftin, Sasha wrote:
On 12/7/2020 17:41, Limonciello, Mario wrote
On 12/2/2020 09:50, Kai-Heng Feng wrote:
Similar to commit 165ae7a8feb5 ("igb: Report speed and duplex as unknown
when device is runtime suspended"), if we try to read speed and duplex
sysfs while the device is runtime suspeneded, igc will complain and
stops working:
[ 123.449883] igc :03:0
On 3/5/2021 21:06, David E. Box wrote:
Due to a HW limitation, the Latency Tolerance Reporting (LTR) value
programmed in the Tiger Lake GBE controller is not large enough to allow
the platform to enter Package C10, which in turn prevents the platform from
achieving its low power target during sus
On 2/28/2021 11:44, Dinghao Liu wrote:
There is one e1e_wphy() call in e1000_set_d0_lplu_state_82571
that we have caught its return value but lack further handling.
Check and terminate the execution flow just like other e1e_wphy()
in this function.
Signed-off-by: Dinghao Liu
---
drivers/net/e
On 12/14/2020 20:40, Mark Pearson wrote:
Thanks Hans
On 14/12/2020 13:31, Mark Pearson wrote:
*From:* Hans de Goede
*Sent:* December 14, 2020 13:24
*To:* Mario Limonciello ; Jeff Kirsher
; Tony Nguyen ;
intel-wired-...@
On 12/15/2020 19:20, Limonciello, Mario wrote:
Absolutely - I'll ask them to look into this again.
we need to explain why on Windows systems required 1s and on Linux
systems up to 2.5s - otherwise it is not reliable approach - you will
encounter others buggy system.
(ME not POR on the Linux s
On 8/22/2019 21:33, Lyude Paul wrote:
Fatal read errors are worth warning about, unless of course the device
was just unplugged from the machine - something that's a rather normal
occurence when the igb/igc adapter is located on a Thunderbolt dock. So,
let's only WARN() if there's a fatal read er
On 1/14/2019 15:29, Konstantin Khlebnikov wrote:
I'm seeing series of e1000e resets (sometimes endless) at system boot
if something generates tx traffic at this time. In my case this is
netconsole who sends message "e1000e :02:00.0: Some CPU C-states
have been disabled in order to enable jumb
On 8/6/2019 18:53, mario.limoncie...@dell.com wrote:
-Original Message-
From: Paul Menzel
Sent: Tuesday, August 6, 2019 10:36 AM
To: Jeff Kirsher
Cc: intel-wired-...@lists.osuosl.org; Linux Kernel Mailing List; Limonciello,
Mario
Subject: MDI errors during resume from ACPI S3 (suspend t
On 8/7/2019 17:55, Paul Menzel wrote:
Dear Sasha,
On 07.08.19 09:23, Neftin, Sasha wrote:
On 8/6/2019 18:53, mario.limoncie...@dell.com wrote:
-Original Message-
From: Paul Menzel
Sent: Tuesday, August 6, 2019 10:36 AM
To: Jeff Kirsher
Cc: intel-wired-...@lists.osuosl.org; Linux
On 6/24/2019 10:03, Kai-Heng Feng wrote:
Hi Jeffrey,
at 19:08, Kai-Heng Feng wrote:
Hi Jeffrey,
There are several platforms that uses e1000e can’t enter Opportunistic
S0ix (PC10) when the ethernet has a link partner.
This behavior also exits in out-of-tree e1000e driver 3.4.2.1, but
seem
On 6/24/2019 18:06, Kai-Heng Feng wrote:
at 19:56, Neftin, Sasha wrote:
On 6/24/2019 10:03, Kai-Heng Feng wrote:
Hi Jeffrey,
at 19:08, Kai-Heng Feng wrote:
Hi Jeffrey,
There are several platforms that uses e1000e can’t enter
Opportunistic S0ix (PC10) when the ethernet has a link partner
On 6/26/2019 09:14, Kai Heng Feng wrote:
Hi Sasha
at 5:09 PM, Kai-Heng Feng wrote:
Hi Jeffrey,
We’ve encountered another issue, which causes multiple CRC errors and
renders ethernet completely useless, here’s the network stats:
I also tried ignore_ltr for this issue, seems like it allevia
On 3/7/2019 09:29, David Miller wrote:
From: Arnd Bergmann
Date: Thu, 7 Mar 2019 10:29:57 +0100
clang points out that the igc_priv_flags_strings[] array is never
referenced, aside from being used for calculating its length:
drivers/net/ethernet/intel/igc/igc_ethtool.c:9:19: error: variable
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
---
drivers/net/ethernet/inte
> -Original Message-
> From: Baicar, Tyler [mailto:tbai...@codeaurora.org]
> Sent: Tuesday, November 15, 2016 11:50 PM
> To: Neftin, Sasha ; Kirsher, Jeffrey T
> ; intel-wired-...@lists.osuosl.org;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; ok...@cod
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
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 rel
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 e1000e dr
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
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 PM, Neftin,
On 3/14/2017 03:20, Brown, Aaron F wrote:
From: Bjørn Mork [mailto:bj...@mork.no]
Sent: Monday, March 13, 2017 9:46 AM
To: Borislav Petkov
Cc: Andy Shevchenko ; l...@pengaru.com;
linux-kernel ; vcap...@pengaru.com; linux-
p...@vger.kernel.org; intel-wired-...@lists.osuosl.org; khalidm
; David Si
-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
Behalf Of Brown, Aaron F
Sent: Wednesday, November 02, 2016 11:20 PM
To: Jack Suter ; Kirsher, Jeffrey T
Cc: bpoir...@suse.com; jhod...@ucdavis.edu; intel-wired-...@lists.osuosl.org;
linux-kerne
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 up
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
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
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
On 2/1/2017 00:01, Philippe Reynes wrote:
Hi Sasha,
On 1/31/17, Neftin, Sasha 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 shift implementation to e1000e
Hello Denis,
In case this reset help you fix initialization error of I218 you can use it
locally on your system. How many system with I218 encountered with
initialization error on your side?
Thanks,
Sasha
-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuo
On 6/10/2020 04:49, Palmer Dabbelt wrote:
From: Palmer Dabbelt
e1000e_check_me is only used under CONFIG_PM_SLEEP but exists
unconditionally, which triggers a warning.
Signed-off-by: Palmer Dabbelt
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++
1 file changed, 2 insertions(+)
diff
On 9/28/2020 11:36, Kai-Heng Feng wrote:
We are seeing the following error after S3 resume:
[ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete
[ 704.902817] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.903075]
Hello Kai-Heng,
On 9/29/2020 16:31, Kai-Heng Feng wrote:
Hi Sasha,
On Sep 29, 2020, at 21:08, Neftin, Sasha wrote:
On 9/28/2020 11:36, Kai-Heng Feng wrote:
We are seeing the following error after S3 resume:
[ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.844232] e1000e
On 7/17/2020 05:12, Nathan Chancellor wrote:
On Thu, Jul 16, 2020 at 07:29:03PM +0300, Neftin, Sasha wrote:
On 7/16/2020 07:49, Nathan Chancellor wrote:
Clang warns:
Hello Nathan,
Thanks for tracking our code.Please, look at
https://patchwork.ozlabs.org/project/intel-wired-lan/patch
On 7/16/2020 07:49, Nathan Chancellor wrote:
Clang warns:
Hello Nathan,
Thanks for tracking our code.Please, look at
https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20200709073416.14126-1-sasha.nef...@intel.com/
- I hope this patch already address this Clang warns - please, let me
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.
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
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 check
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 foll
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
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 to
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 T
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] returns -2
[ 430.955454] dpm_run
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;
48 matches
Mail list logo
