NACK/Cmnt: [SRU][N/O/unstable][PATCH 0/2] Enable ASPM for nvme controller when working in RAID on mode

[Hui Wang]

On 8/15/24 20:38, Stefan Bader wrote:
> On 15.08.24 05:22, Hui Wang wrote:
>> BugLink: https://bugs.launchpad.net/bugs/2072679
>>
>> [Impact]
>> The NVME controller works in RAID on mode by default on some Dell
>> machines, and in this case, the PCIE ASPM couldn't be enabled, and
>> as a result the system idle can't enter deep idle states. This issue
>> not only impacts ubuntu users but also impacts our Dell OEM projects.
>>
>>
>> [Fix]
>> pick 2 commits from linux-pci mailist
>>
>> [Test]
>> After running the patched kernel, we could run 'sudo lspci -nnvv'
>> and check "Non-Volatile memory controller":
>>                 LnkCtl: ASPM L1 Enabled;
>>
>> And check idle states, we could see the system could enter deep idle:
>> $ sudo cat /sys/kernel/debug/pmc_core/package_cstate_show
>> Package C2 : 55740989
>> Package C3 : 4656373
>> Package C6 : 43325041
>> Package C7 : 6687655
>> Package C8 : 44948950
>> Package C9 : 1693
>> Package C10 : 92865596
>>
>> [Where problems could occur]
>> Because the patchset is not accepted by upstream yet, it is a bit
>> risky to merge the patchset to ubuntu kernel. And the patch only
>> impacts vmd driver, hence if there is regression, it could only be
>> in the nvme driver with RAID on mode. The regression possibility is
>> very low because we already tested the patch on many Dell, lenovo
>> machines, there is no regression so far.
>>
>>
>> Kai-Heng Feng (2):
>>    UBUNTU: SAUCE: PCI: ASPM: Allow OS to configure ASPM where BIOS is
>>      incapable of
>>    UBUNTU: SAUCE: PCI: vmd: Let OS control ASPM for devices under VMD
>>      domain
>>
>>   drivers/pci/controller/vmd.c | 2 ++
>>   drivers/pci/pcie/aspm.c      | 8 ++++++--
>>   include/linux/pci.h          | 1 +
>>   3 files changed, 9 insertions(+), 2 deletions(-)
>>
>
> Rejected for the following reasons:
> - Patches which are not at least in linux-next are not material for SRU
>
> -Stefan

Hi Stefan,

Understand, that is the general rule for SRU.

In this case, it impacts our Dell oem project. This issue is a 
regression of hwe-6.8 kernel,  we don't have this issue with the oem-6.5 
kernel, but oem-6.5 is EOL. Hence we need to merge this patchset to 
-generic kernel ASAP.

Kai-Heng will continue working on this patchset and make sure it will be 
accepted by PCI maintainers. So could we get an exception in this case?

Thanks,

Hui.