ACK/Cmnt: [PATCH 0/9][SRU][G/H/U/OEM-5.10] re-enable s0ix of e1000e

[Stefan Bader]

On 11.01.21 09:01, Aaron Ma wrote:
> BugLink: https://bugs.launchpad.net/bugs/1910541
> 
> [Impact]
> Due to s2idle failure on e1000e driver in ME enabled system, it disabled
> s0ix.
> Finally latest kernel accepted the bump up timeout value to fixed the
> issue.
> s0ix can be supported again.
> 
> [Fix]
> Rebase the sauce patch to upstream patch, then support s0ix of e1000e.
> 
> [Test Case]
> s2idle can work normally on ME enabled platform.
> 
> [Where problems could occur]
> s2idle may fail to suspend on 2nd times.
> 
> These patches are trying to revert the disabled s0ix patch in 5.8+,
> no need for 5.7- kernels.
> 
> Aaron Ma (5):
>   Revert "UBUNTU: SAUCE: e1000e: bump up timeout to wait when ME
>     un-configure ULP mode"
>   Revert "UBUNTU: SAUCE: e1000e: Add more Dell AIO systems into s0ix
>     heuristics"
>   Revert "UBUNTU: SAUCE: e1000e: Add more Dell CML systems into s0ix
>     heuristics"
>   Revert "UBUNTU: SAUCE: e1000e: Add Dell's Comet Lake systems into s0ix
>     heuristics"
>   Revert "UBUNTU: SAUCE: e1000e: allow turning s0ix flows on for systems
>     with ME"
> 
> Mario Limonciello (4):
>   e1000e: Only run S0ix flows if shutdown succeeded
>   e1000e: bump up timeout to wait when ME un-configures ULP mode
>   Revert "e1000e: disable s0ix entry and exit flows for ME systems"
>   e1000e: Export S0ix flags to ethtool
> 
>  .../device_drivers/ethernet/intel/e1000e.rst  |  23 --
>  drivers/net/ethernet/intel/Kconfig            |   1 -
>  drivers/net/ethernet/intel/e1000e/e1000.h     |   6 -
>  drivers/net/ethernet/intel/e1000e/ethtool.c   |  46 ++++
>  drivers/net/ethernet/intel/e1000e/ich8lan.c   |  15 +-
>  drivers/net/ethernet/intel/e1000e/netdev.c    |  47 +---
>  drivers/net/ethernet/intel/e1000e/param.c     | 237 ------------------
>  7 files changed, 69 insertions(+), 306 deletions(-)
> 
Concentrating on the Groovy changes from my side. So this looks to replace a
special solution by upstream changes which is always good. Question on testing:
Did we double check that this did not re-introduce the power consumption issues
on at least one of the previously affected platforms?
Other question: Is the groovy version of user-space ethtool able to handle the
additional flag?


If both is looking good: Acked-by: Stefan Bader <stefan.bader at canonical.com>
-Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20210119/f50c9222/attachment-0001.sig>