On 7/27/2025 5:00 PM, ValdikSS wrote:
Device ID comparison in igc_is_device_id_i226 is performed before
the ID is set, resulting in always failing check.
Link:
https://lore.kernel.org/intel-wired-lan/15248b4f-3271-42dd-8e35-02bfc92b2...@intel.com
Signed-off-by: ValdikSS
Reviewed-by: Vitaly L
On 7/22/2025 11:04 PM, ValdikSS wrote:
Device ID comparison in igc_is_device_id_i226 is performed before
the ID is set, resulting in always failing check.
Link:
https://lore.kernel.org/intel-wired-lan/15248b4f-3271-42dd-8e35-02bfc92b2...@intel.com
Signed-off-by: ValdikSS
---
drivers/net/ethe
On 7/7/2025 12:17 PM, Rui Salvaterra wrote:
This is debug information, upon which the user is not expected to act. Output as
such. This avoids polluting the dmesg with full register dumps at every link
down.
Signed-off-by: Rui Salvaterra
---
This file hasn't been touched in over four years,
On 7/10/2025 1:33 PM, Loktionov, Aleksandr wrote:
-Original Message-
From: Intel-wired-lan On Behalf
Of Simon Horman
Sent: Thursday, July 10, 2025 12:25 PM
To: Markus Blöchl
Cc: Nguyen, Anthony L ; Kitszel,
Przemyslaw ; Richard Cochran
; Thomas Gleixner ;
Lakshmi Sowjanya D ; Andrew
On 7/1/2025 8:31 AM, En-Wei WU wrote:
Hi,
I'm seeing a regression on an HP ZBook using the e1000e driver
(chipset PCI ID: [8086:57a0]) -- the system can't get an IP address
after hot-plugging an Ethernet cable. In this case, the Ethernet cable
was unplugged at boot. The network interface eno1 wa
On 6/30/2025 8:00 PM, Simon Horman wrote:
On Mon, Jun 30, 2025 at 10:35:00AM +0200, Jacek Kowalski wrote:
As described by Vitaly Lifshits:
Starting from Tiger Lake, LAN NVM is locked for writes by SW, so the
driver cannot perform checksum validation and correction. This means
that all NVM imag
On 6/18/2025 7:29 PM, Alexander Lobakin wrote:
From: Colin Ian King
Date: Wed, 18 Jun 2025 14:54:08 +0100
Don't populate the const read-only array supported_sizes on the
stack at run time, instead make it static.
Signed-off-by: Colin Ian King
Reviewed-by: Alexander Lobakin
Reviewed-by
+0200, Paul Menzel wrote:
Dear Marek, dear Vitaly,
Am 09.05.25 um 00:41 schrieb Marek Marczykowski-Górecki:
On Thu, May 08, 2025 at 09:26:18AM +0300, Lifshits, Vitaly
On 4/21/2025 4:28 PM, Marek Marczykowski-Górecki wrote:
On Mon, Apr 21, 2025 at 03:19:12PM +0200, Marek Marczykowski-Górecki
On 6/5/2025 11:36 AM, Paul Menzel wrote:
[two additions]
Am 05.06.25 um 10:26 schrieb Paul Menzel:
[Cc: +i...@valdikss.org]
Remove again, as it does not seem valid anymore.
Dear Vitaly,
Thank you for your patch.
Am 05.06.25 um 09:06 schrieb Vitaly Lifshits:
I226 devices advertise supp
On 6/2/2025 9:44 PM, Vlad URSU wrote:
On 01.06.2025 13:19, Lifshits, Vitaly wrote:
On 5/15/2025 10:07 PM, Vlad URSU wrote:
On 15.05.2025 07:39, Lifshits, Vitaly wrote:
Since the checksum word is 0x which is peculiar, can you dump
the whole NVM and share with us?
Sure, here's a
On 6/1/2025 4:16 PM, ValdikSS wrote:
On 01.06.2025 1:04 PM, Lifshits, Vitaly wrote:
Hello, are there any updates on upstreaming this change?
If there haven't been much testing, could it be put behind the module
option and disabled by default?
Hello,
We've decided t
On 5/15/2025 10:07 PM, Vlad URSU wrote:
On 15.05.2025 07:39, Lifshits, Vitaly wrote:
Since the checksum word is 0x which is peculiar, can you dump the
whole NVM and share with us?
Sure, here's a dump of my NVM
Offset Values
-- --
0x: d0 8e 79 07
Hello, are there any updates on upstreaming this change?
If there haven't been much testing, could it be put behind the module
option and disabled by default?
Hello,
We've decided to pursue a different solution to the issue.
The original workaround may negatively impact system power
On 5/16/2025 3:26 PM, Simon Horman wrote:
On Tue, May 13, 2025 at 01:11:29PM +0300, Vladimir Oltean wrote:
New timestamping API was introduced in commit 66f7223039c0 ("net: add
NDOs for configuring hardware timestamping") from kernel v6.6.
It is time to convert the Intel igc driver to the ne
On 5/12/2025 8:25 PM, Vlad URSU wrote:
On 22.04.2025 10:43, Jacek Kowalski wrote:
Some Dell Tiger Lake systems have incorrect NVM checksum. These also
have a bitmask that indicates correct checksum set to "invalid".
Because it is impossible to determine whether the NVM write would finish
cor
On 4/21/2025 4:28 PM, Marek Marczykowski-Górecki wrote:
On Mon, Apr 21, 2025 at 03:19:12PM +0200, Marek Marczykowski-Górecki wrote:
On Mon, Apr 21, 2025 at 03:44:02PM +0300, Lifshits, Vitaly wrote:
On 4/16/2025 3:43 PM, Marek Marczykowski-Górecki wrote:
On Wed, Apr 16, 2025 at 03:09:39PM
On 4/28/2025 7:43 PM, Jacek Kowalski wrote:
Anyway, I think that the commit message should be precise.
How about this?
Starting from Tiger Lake, LAN NVM is locked for writes by SW, so the
driver cannot perform checksum validation and correction. This means
that all NVM images must leave the
On 4/24/2025 8:29 PM, Jacek Kowalski wrote:
Hi,
Because it is impossible to determine whether the NVM write would
finish
correctly or hang (see
https://bugzilla.kernel.org/show_bug.cgi?id=213667)
it makes sense to skip the validation completely under these
conditions.
It is not completel
On 4/24/2025 7:24 PM, Simon Horman wrote:
On Tue, Apr 22, 2025 at 09:43:01AM +0200, Jacek Kowalski wrote:
Some Dell Tiger Lake systems have incorrect NVM checksum. These also
have a bitmask that indicates correct checksum set to "invalid".
Because it is impossible to determine whether the NVM w
On 4/23/2025 7:18 AM, Przemek Kitszel wrote:
On 4/22/25 23:03, Jacob Keller wrote:
Commit 1a931c4f5e68 ("igc: add lock preventing multiple simultaneous PTM
transactions") added a new mutex to protect concurrent PTM transactions.
This lock is acquired in igc_ptp_reset() in order to ensure the P
On 4/22/2025 10:43 AM, Jacek Kowalski wrote:
Some Dell Tiger Lake systems have incorrect NVM checksum. These also
have a bitmask that indicates correct checksum set to "invalid".
Because it is impossible to determine whether the NVM write would finish
correctly or hang (see https://bugzilla.k
On 4/16/2025 3:43 PM, Marek Marczykowski-Górecki wrote:
On Wed, Apr 16, 2025 at 03:09:39PM +0300, Lifshits, Vitaly wrote:
Can you please also share the output of ethtool -i? I would like to know the
NVM version that you have on your device.
driver: e1000e
version: 6.14.1+
firmware-version
And also ethtool output if useful:
Settings for ens7:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
S
On 4/14/2025 3:18 PM, Marek Marczykowski-Górecki wrote:
Hi,
After updating to 6.14.2, the ethernet adapter is almost unusable, I get
over 30% packet loss.
Bisect says it's this commit:
commit 85f6414167da39e0da30bf370f1ecda5a58c6f7b
Author: Vitaly Lifshits
Date: Thu Mar 13
On 4/14/2025 3:58 PM, Marek Marczykowski-Górecki wrote:
On Mon, Apr 14, 2025 at 03:38:39PM +0300, Lifshits, Vitaly wrote:
Do you see the high packet loss without the virtualization?
I can't check that easily right now, will try later.
Can you please share the lspci output?
Sure
On 3/31/2025 11:36 PM, Jacek Kowalski wrote:
Hi,
Are you certain that the UEFI FW corrupts the checksum each time, or
is it just that the system left the factory with incorrect checksum?
I'm quite far from that device at the moment, but from what I remember:
- when I forced the NVM update
On 3/13/2025 11:35 AM, Rui Salvaterra wrote:
This is enabled by default in other Intel drivers I've checked (e1000, e1000e,
iavf, igb and ice). Fixes an out-of-the-box performance issue when running
OpenWrt on typical mini-PCs with igc-supported Ethernet controllers and 802.1Q
VLAN configurati
On 3/18/2025 10:46 PM, Jacek Kowalski wrote:
Many laptops and motherboards including I219-V network card have
invalid NVM checksum. While in most instances checksum is fixed by
e1000e module or by using bootutil, some setups are resistant to NVM
modifications. This result in the network card b
On 3/3/2025 5:34 AM, Mark Pearson wrote:
Hi Andrew,
On Sun, Mar 2, 2025, at 11:13 AM, Andrew Lunn wrote:
On Sun, Mar 02, 2025 at 03:09:35PM +0200, Lifshits, Vitaly wrote:
Hi Mark,
Hi Andrew
On Thu, Feb 27, 2025, at 11:07 AM, Andrew Lunn wrote:
+ e1e_rphy(hw
On 3/3/2025 5:30 PM, Paul Menzel wrote:
Dear Linux folks,
On a Dell OptiPlex 7000/0F1HC1, BIOS 1.8.2 12/08/2022 with
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet
Connection (17) I219-LM [8086:1a1c] (rev 11)
and Dell OptiPlex 7071/097YXY, BIOS 1.1.2 08/29/2019 with
Hi Mark,
Hi Andrew
On Thu, Feb 27, 2025, at 11:07 AM, Andrew Lunn wrote:
+ e1e_rphy(hw, PHY_REG(772, 26), &phy_data);
Please add some #define for these magic numbers, so we have some idea
what PHY register you are actually reading. That in itself might help
explain h
On 2/24/2025 3:53 PM, Paul Menzel wrote:
Dear Vitaly,
Thank you for your patch.
Am 24.02.25 um 11:12 schrieb Vitaly Lifshits:
LAN devices starting from Meteorlake the interface between the MAC and
Meteor Lake
the PHY has a different frequency.
The sentences reads a little strange. Ma
On 2/19/2025 1:14 PM, Mateusz Kusiak wrote:
Hi all,
I've done research regarding igc driver and I225 ethernet controller. I
established that neither igc driver nor hardware (I255) support forced
speed configuration (disabling auto-negotiation to be exact). Could
anybody please confirm this?
On 2/18/2025 5:59 PM, Paul Menzel wrote:
Dear Linux folks,
The driver e1000e has several parameters [1]:
$ modinfo e1000e
filename:
/lib/modules/6.6.35.mx64.477/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
[…]
alias: pci:v8086d105Esv*sd*bc*sc*i
On 2/18/2025 2:59 PM, Simon Horman wrote:
On Sun, Feb 16, 2025 at 04:57:28PM +0100, Piotr Wejman wrote:
Update the driver to use the new hardware timestamping API added in commit
66f7223039c0 ("net: add NDOs for configuring hardware timestamping").
Use Netlink extack for error reporting in e1
On 2/8/2025 5:43 PM, Piotr Wejman wrote:
Update the driver to use the new hardware timestamping API added in commit
66f7223039c0 ("net: add NDOs for configuring hardware timestamping").
Use Netlink extack for error reporting in e1000e_hwtstamp_set.
Align the indentation of net_device_ops.
Sig
On 2/6/2025 10:09 PM, Stephen Hemminger wrote:
On Thu, 6 Feb 2025 15:17:00 +0200
"Lifshits, Vitaly" wrote:
On 2/6/2025 6:13 AM, Stephen Hemminger wrote:
On Wed, 5 Feb 2025 12:36:31 +0200
"Lifshits, Vitaly" wrote:
On 1/31/2025 3:21 AM, Stephen Hemminger wrote:
On
On 2/6/2025 6:13 AM, Stephen Hemminger wrote:
On Wed, 5 Feb 2025 12:36:31 +0200
"Lifshits, Vitaly" wrote:
On 1/31/2025 3:21 AM, Stephen Hemminger wrote:
On Thu, 30 Jan 2025 21:17:30 +0200
"Lifshits, Vitaly" wrote:
On 1/30/2025 7:11 PM, Stephen Hemminger wrote:
On 1/31/2025 3:21 AM, Stephen Hemminger wrote:
On Thu, 30 Jan 2025 21:17:30 +0200
"Lifshits, Vitaly" wrote:
On 1/30/2025 7:11 PM, Stephen Hemminger wrote:
I am using:
5a:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-LM (rev
04)
Subsystem: Intel C
On 2/2/2025 7:08 PM, Piotr Wejman wrote:
Update the driver to the new hw timestamping API. >
Signed-off-by: Piotr Wejman
---
drivers/net/ethernet/intel/e1000e/e1000.h | 2 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 52 --
2 files changed, 20 insertions(+), 34 de
On 1/30/2025 7:11 PM, Stephen Hemminger wrote:
I am using:
5a:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-LM (rev
04)
Subsystem: Intel Corporation Device
Flags: bus master, fast devsel, latency 0, IRQ 19, IOMMU group 20
Memory at 6c50
On 1/22/2025 4:57 PM, ValdikSS wrote:
On 09.12.2024 12:21 PM, ValdikSS wrote:
After (presumably) latest UEFI v0033 update for the NUC, my network
is limited to ~250 Mbit/s download unless I disable PCIE ASPM option
in UEFI settings.
56:00.0 Ethernet controller [0200]: Intel Corporation Ether
On 1/5/2025 1:38 PM, Dmitrii Ermakov wrote:
Replaces watchdog timer with delayed_work as advised
in the driver's TODO comment.
Signed-off-by: Dmitrii Ermakov
---
V1 -> V2: Removed redundant line wraps, renamed e1000_watchdog to
e1000_watchdog_work
drivers/net/ethernet/intel/e1000e/e1000.
On 1/2/2025 7:41 PM, li...@treblig.org wrote:
From: "Dr. David Alan Gilbert"
igc_read_pci_cfg() and igc_write_pci_cfg were added in 2018 as part of
commit 146740f9abc4 ("igc: Add support for PF")
but have remained unused.
Remove them.
Signed-off-by: Dr. David Alan Gilbert
Reviewed-by: V
On 1/2/2025 7:41 PM, li...@treblig.org wrote:
From: "Dr. David Alan Gilbert"
The last uses of igc_read_pcie_cap_reg() and igc_write_pcie_cap_reg()
were removed in 2019 by
commit 16ecd8d9af26 ("igc: Remove the obsolete workaround")
Remove them.
Signed-off-by: Dr. David Alan Gilbert
Revie
On 1/2/2025 7:41 PM, li...@treblig.org wrote:
From: "Dr. David Alan Gilbert"
igc_acquire_nvm() and igc_release_nvm() were added in 2018 as part of
commit ab4056126813 ("igc: Add NVM support")
but never used.
Remove them.
The igc_1225.c has it's own specific implementations.
Signed-off-by
On 12/18/2024 4:37 AM, En-Wei Wu wrote:
When booting with a dock connected, the igc driver may get stuck for ~40
seconds if PCIe link is lost during initialization.
This happens because the driver access device after EECD register reads
return all F's, indicating failed reads. Consequently, h
On 12/19/2024 9:27 PM, Gerhard Engleder wrote:
From: Gerhard Engleder
Link down and up triggers update of MTA table. This update executes many
PCIe writes and a final flush. Thus, PCIe will be blocked until all
writes are flushed. As a result, DMA transfers of other targets suffer
from delay
On 12/17/2024 3:23 AM, Chia-Lin Kao (AceLan) wrote:
On Mon, Dec 16, 2024 at 06:53:10AM +0100, Przemek Kitszel wrote:
On 12/16/24 06:14, Chia-Lin Kao (AceLan) wrote:
When booting with a dock connected, the igc driver can get stuck for ~40
seconds if PCIe link is lost during initialization.
T
On 12/14/2024 9:16 PM, Gerhard Engleder wrote:
From: Gerhard Engleder
Link down and up triggers update of MTA table. This update executes many
PCIe writes and a final flush. Thus, PCIe will be blocked until all
writes are flushed. As a result, DMA transfers of other targets suffer
from delay
On 12/6/2024 6:06 PM, ValdikSS wrote:
Hello Intel team,
I have Intel NUC13ANKI5 machine, with I226-V network card, and gigabit
Internet connection.
After (presumably) latest UEFI v0033 update for the NUC, my network is
limited to ~250 Mbit/s download unless I disable PCIE ASPM option in
On 10/29/2024 10:12 PM, Joe Damato wrote:
Link IRQs to NAPI instances via netdev-genl API so that users can query
this information with netlink.
Compare the output of /proc/interrupts (noting that IRQ 128 is the
"other" IRQ which does not appear to have a NAPI instance):
$ cat /proc/interrup
On 10/29/2024 10:12 PM, Joe Damato wrote:
Link queues to NAPI instances via netdev-genl API so that users can
query this information with netlink. Handle a few cases in the driver:
1. Link/unlink the NAPIs when XDP is enabled/disabled
2. Handle IGC_FLAG_QUEUE_PAIRS enabled and disabled
On 10/28/2024 9:52 PM, Joe Damato wrote:
Link queues to NAPI instances via netdev-genl API so that users can
query this information with netlink. Handle a few cases in the driver:
1. Link/unlink the NAPIs when XDP is enabled/disabled
2. Handle IGC_FLAG_QUEUE_PAIRS enabled and disabled
E
On 10/23/2024 12:52 AM, Joe Damato wrote:
Link queues to NAPI instances via netdev-genl API so that users can
query this information with netlink. Handle a few cases in the driver:
1. Link/unlink the NAPIs when XDP is enabled/disabled
2. Handle IGC_FLAG_QUEUE_PAIRS enabled and disabled
E
On 10/21/2024 8:48 PM, Vinicius Costa Gomes wrote:
Joe Damato writes:
Link queues to NAPI instances via netdev-genl API so that users can
query this information with netlink. Handle a few cases in the driver:
1. Link/unlink the NAPIs when XDP is enabled/disabled
2. Handle IGC_FLAG_QUE
On 10/21/2024 8:48 PM, Vinicius Costa Gomes wrote:
Joe Damato writes:
Link IRQs to NAPI instances via netdev-genl API so that users can query
this information with netlink.
Compare the output of /proc/interrupts (noting that IRQ 144 is the
"other" IRQ which does not appear to have a NAPI i
On 10/14/2024 8:59 PM, Gerhard Engleder wrote:
On 12.10.24 20:42, Andrew Lunn wrote:
On Fri, Oct 11, 2024 at 09:54:12PM +0200, Gerhard Engleder wrote:
From: Gerhard Engleder
Link down and up triggers update of MTA table. This update executes
many
PCIe writes and a final flush. Thus, PCIe w
On 10/4/2024 1:31 PM, Yonatan Avhar wrote:
[1.] One line summary of the problem:
When suspending my Lenovo ThinkPad P14s Gen 5 (Intel) with the latest
Fedora 40 kernel, the system fails to suspend, then begins to
hang/stutter every few seconds.
[2.] Full description of the problem/report:
On 10/2/2024 7:59 PM, Dmitrii Ermakov wrote:
Replaces watchdog timer with delayed_work as advised
in the driver's TODO comment.
Signed-off-by: Dmitrii Ermakov
---
V1 -> V2: Removed redundant line wraps, renamed e1000_watchdog to
e1000_watchdog_work
drivers/net/ethernet/intel/e1000e/e1000
On 10/1/2024 1:50 PM, Simon Horman wrote:
On Mon, Sep 30, 2024 at 05:12:31PM +, Joe Damato wrote:
Add support for netdev-genl, allowing users to query IRQ, NAPI, and queue
information.
After this patch is applied, note the IRQs assigned to my NIC:
$ cat /proc/interrupts | grep ens | cut
On 9/14/2024 12:52 AM, Jesper Juhl wrote:
On Fri, 13 Sept 2024 at 09:02, Lifshits, Vitaly
wrote:
On 9/12/2024 10:45 PM, Jesper Juhl wrote:
Would you be able to decode the stack trace? It may be helpful
to figure out which line of code this is:
igc_update_stats+0x8a/0x6d0 [igc
On 9/12/2024 10:45 PM, Jesper Juhl wrote:
Would you be able to decode the stack trace? It may be helpful
to figure out which line of code this is:
igc_update_stats+0x8a/0x6d0 [igc
22e0a697bfd5a86bd5c20d279bfffd
131de6bb32]
Of course. Just tell me what to do.
- Jesper
On Thu, 12 Sept 202
On 9/4/2024 3:36 PM, Vitaly Lifshits wrote:
On 9/4/2024 3:13 PM, Andrew Lunn wrote:
On Wed, Sep 04, 2024 at 02:56:46PM +0900, Takamitsu Iwai wrote:
So you have confirmed with the datsheet that the write is not needed?
As i said, this is a hardware register, not memory. Writes are not
always
Dear Paul,
On 8/15/2024 5:16 PM, Paul Menzel wrote:
Dear Vitaly,
Thank you for the patch.
Am 15.08.24 um 15:11 schrieb Vitaly Lifshits:
Change the MAC and board types of I219 (19) devices from MTP to ADP.
These devices have hardware more closely related to ADP than MTP.
According to what
of your device is 80 and not 0 as usual, do you use
virtualization features? If so, can you please disable them and retest?
-Original Message-
From: Lifshits, Vitaly
Sent: Wednesday, June 19, 2024 11:37 PM
To: intel-wired-lan@osuosl.org
Cc: hui.w...@canonical.com; Lifshits, Vitaly ; Bra
On 6/20/2024 9:47 AM, Paul Menzel wrote:
Dear Vitaly,
Thank you for your patch. For the summary, it’d be great if you could be
more specific by saying it’s about limiting the scope.
Am 20.06.24 um 08:36 schrieb Vitaly Lifshits:
Commit 861e8086029e ("e1000e: move force SMBUS from enable u
Hi Hui,
On 6/14/2024 4:53 AM, Hui Wang wrote:
Hi Vitaly
I tested the patch on a laptop with the ethernet card [8086:550A], the
system suspend and resume worked well with the cable plugged or unplugged.
But I still think that reverting 2 regression commits is a better solution.
Reverting th
On 5/28/2024 1:43 PM, Paul Menzel wrote:
Dear Vitaly,
Thank you for the patch.
Am 28.05.24 um 12:33 schrieb Vitaly Lifshits:
From: Dima Ruinskiy
On vPro systems,the configuration of the I219-LM to achieve power
s/,the /, the /
Thank you for noticing it.
I will fix it in a v2.
gat
On 4/13/2024 12:27 PM, Hui Wang wrote:
The commit 861e8086029e ("e1000e: move force SMBUS from enable ulp
function to avoid PHY loss issue") introduces a regression on
CH_MTP_I219_LM18 (PCIID: 0x8086550A). Without this commit, the
ethernet works well after suspend and resume, but after applyin
On 4/13/2024 12:27 PM, Hui Wang wrote:
The commit 861e8086029e ("e1000e: move force SMBUS from enable ulp
function to avoid PHY loss issue") introduces a regression on
CH_MTP_I219_LM18 (PCIID: 0x8086550A). Without this commit, the
ethernet works well after suspend and resume, but after applyin
On 2/29/2024 4:31 PM, Paul Menzel wrote:
Dear Vitaly,
Thank you for your reply.
Am 29.02.24 um 11:34 schrieb Lifshits, Vitaly:
On 2/12/2024 11:00 AM, Paul Menzel wrote:
Am 11.02.24 um 16:12 schrieb Vitaly Lifshits:
Forcing SMBUS inside the ULP enabling flow leads to sporadic PHY
On 2/12/2024 11:00 AM, Paul Menzel wrote:
Dear Vitaly,
Thank you for your patch.
Am 11.02.24 um 16:12 schrieb Vitaly Lifshits:
Forcing SMBUS inside the ULP enabling flow leads to sporadic PHY loss on
some systems.
Please list the systems you know of.
On some Meteor-lake systems, we also
Dear Paul,
Thank you for your comments.
On 1/3/2024 5:27 PM, Paul Menzel wrote:
Dear Vitaly,
Thank you for the patch.
In the commit message summary, it’d be great if you used a statement by
adding a verb in imperative mood. Maybe:
Correct flow in e1000_shutdown()
Am 03.01.24 um 09:50 sch
74 matches
Mail list logo
