RE: Possible nvme regression in 6.4.11

[Ricky WU <ricky_wu@realtek.com>]

>On 8/24/23 05:48, Genes Lists wrote:
>> On 8/23/23 22:44, Ricky WU wrote:
>>> Hi Gene,
>>>
>>> I can't reproduce this issue on my side...
>>>
>>> So if you only revert this patch
>>> (69304c8d285b77c9a56d68f5ddb2558f27abf406) can work fine?
>>> This patch only do is pull our clock request to HIGH if HOST need also
>>> can pull to LOW, and this only do on our device
>>> I don’t think this will affect other ports...
>>>
>>> BR,
>>> Ricky
>>
>> Thanks Ricky - I will test revering just that commit and report back.  I
>> wont be able to get to it till later today (sometime after 2pm EDT) but
>> I will do it today.
>>
>> FYI, i see one mpre report of someone experiencing same problem [1]
>>
>> gene
>>
>  > [1] https://bugs.archlinux.org/task/79439
>>
>>
>
>That commit was what was reverted in the last step of the git bisect -
>and indeed reverting that commit makes the problem go away and machine
>then boots fine.
>
>thanks
>
>gene

I think maybe it is a system power saving issue....
In the past if the BIOS(config space) not set L1-substate, our driver will keep drive low CLKREQ# when HOST want to enter power saving state that make whole system not enter the power saving state.
But this patch we release the CLKREQ# to HOST, make whole system can enter power saving state success when the HOST want to enter the power saving state, but I don't  know why your system can not wake out success from power saving stat on the platform

Ricky