[PATCH v2 0/2][SRU]{OEM-B]SATA device is not going to DEVSLP

[Anthony Wong]

On Wed, Jul 18, 2018 at 09:26:30AM +0800, AceLan Kao wrote:
> BugLink: https://bugs.launchpad.net/bugs/1781533
> 
> [Impact]
> Any of the platforms we’ve been seeing SATA problems not going to deepest
> state leading to other devices not getting there during long idle or
> s2idle. And it also prevents the system from entering deeper PC state
> other than PC3.
> 
> [Test]
> Verified the power consumption on some new platforms, it doesn't do too
> much difference to the numbers, but it improves.
> 
> [Fix]
> Suggested from Intel and Dell to contains the 2 commits
> https://patchwork.kernel.org/patch/10502285/
> https://patchwork.kernel.org/patch/10502287/
> 
> [Regression Potential]
> Low, the production machines with suspend-to-idle enabled should have the
> DEVSLP function been validated.
> 
> [Misc]
> Those commits do not show up in any public git tree yet, so let's verify
> them in oem kernel first, and then will submit to bionic kernel later.
> 
> Srinivas Pandruvada (2):
>   UBUNTU: SAUCE: ata: libahci: Correct setting of DEVSLP register
>   UBUNTU: SAUCE: ata: libahci: Allow reconfigure of DEVSLP register
> 
>  drivers/ata/libahci.c | 20 ++++++++++++--------
>  1 file changed, 12 insertions(+), 8 deletions(-)

I am not totally against these patches but given upstream has not
acked the patches makes me feel uneasy to even accept them in
linux-oem.

On verification, do we have any machines that show the problem that SATA
devices fail to enter DEVSLP?

Thanks,
Anthony