ACK/Cmnt: [PATCH 0/1][SRU][J][OEM-5.17] e1000e report hardware changed

[AceLan Kao]

Tim Gardner <tim.gardner at canonical.com> 於 2022年5月12日 週四 下午8:26寫道：
>
> Acked-by: Tim Gardner <tim.gardner at canonical.com>
>
> Shouldn't this also go into unstable just so we make sure it doesn't get
> lost ? If it really gets upstream then it'll fall out during a rebase.
>
We'll check all the patches applied on oem kernel later and make sure
all of them have been applied to ubuntu kernel.
I presume this patch will land on v5.18-rc, so this should go into our
next ubuntu kernel directly, and don't want to bother the maintenance
of the unstable kernel.
This patch is not accepted/merged into upstream yet, so there might be
v3 or v4, anyway we'll check this later.

> On 5/11/22 20:39, AceLan Kao wrote:
> > From: "Chia-Lin Kao (AceLan)" <acelan.kao at canonical.com>
> >
> > BugLink: https://bugs.launchpad.net/bugs/1973104
> >
> > [Impact]
> > e1000e hardware unit hang after s2idle
> > May 06 15:34:49 ubuntu kernel: e1000e 0000:00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
> >                                   TDH <1>
> >                                   TDT <5>
> >                                   next_to_use <5>
> >                                   next_to_clean <1>
> >                                 buffer_info[next_to_clean]:
> >                                   time_stamp <1000587f0>
> >                                   next_to_watch <1>
> >                                   jiffies <1000589c0>
> >                                   next_to_watch.status <0>
> >                                 MAC Status <40080283>
> >                                 PHY Status <796d>
> >                                 PHY 1000BASE-T Status <3800>
> >                                 PHY Extended Status <3000>
> >                                 PCI Status <10>
> >
> > [Fix]
> > Below commit fixes this issue
> > https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20220508070905.1878172-1-sasha.neftin@intel.com/
> >
> > [Test]
> > Verified on the target machine, and confirmed the issue is gone.
> >
> > [Where problems could occur]
> > The impact is low, it keeps the GPT clock enabled for CSME when
> > e1000e_pm_resume() is called. I can't see this may introduce any regression.
> >
> > Sasha Neftin (1):
> >    UBUNTU: SAUCE: e1000e: Enable GPT clock before sending message to CSME
> >
> >   drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++++
> >   1 file changed, 4 insertions(+)
> >
>
> --
> -----------
> Tim Gardner
> Canonical, Inc