RE: Regression since 6.1.46 (commit 8ee39ec): rtsx_pci from drivers/misc/cardreader breaks NVME power state, preventing system boot

[Ricky WU <ricky_wu@realtek.com>]

Hi Jade，

I think you have some misunderstand, our set clkreg register is not go directly to control CLKREQ# after setting....
Our device keep CLKREQ# low until enter ASPM, so the system let our device to ASPM mode then we release this CLKREQ# pin

> 
> > 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 this system can not wake out success from
> power saving state"
> 
> >
> 
> > This is a PCIE CLKREQ# design problem on those platform, the pcie spec
> allow device release the CLKREQ# to HOST, this patch only do this....
> 
> 
> 
> I spent some time debugging today but I am not a PCIe expert. I think
> 
> that the card reader is actually violating the PCIe spec by not forcing
> 
> CLKREQ# low on systems that don't support ASPM, as appears to be done
> 
> (accidentally?) by the regressing driver change.
> 
> 
> 
> The kernel logs on the affected system states the following:
> 
> [    0.142326] ACPI FADT declares the system doesn't support PCIe ASPM, so
> disable it
> 
> 
> 
> The PCIe 3.0 spec states (in the description of the Link Control
> 
> Register), regarding enabling clock power management:
> 
> > Enable Clock Power Management – Applicable only for Upstream Ports and
> with form factors that support a “Clock Request” (CLKREQ#) mechanism, this
> bit operates as follows:
> 
> > 0b Clock power management is disabled and device must hold CLKREQ#
> signal low.
> 
> > 1b When this bit is Set, the device is permitted to use CLKREQ# signal to
> power manage Link clock
> 
> > according to protocol defined in appropriate form factor specification.
> 
> 
> 
> My reading of this is that on this system which does not support ASPM
> 
> and therefore also does not support clock PM, the driver must have the
> 
> device hold the line low, but I may be wrong.
> 
> 
> 
> It's still unclear to me based on studying the schematic of the laptop
> 
> and the PCH datasheet why the one PCIe port is able to break the other
> 
> one like it does. The CLKREQ# lines are simply connected directly to the
> 
> SRCCLKREQ# lines of the PCH, plus a 10k pull-up to 3v3, which seems
> 
> entirely reasonable; any breakage surely would be some software/firmware
> level
> 
> misconfiguration.
> 
> 
> 
> Jade