RE: Possible nvme regression in 6.4.11

[Ricky WU <ricky_wu@realtek.com>]

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

> -----Original Message-----
> From: Genes Lists <lists@sapience.com>
> Sent: Thursday, August 24, 2023 4:25 AM
> To: Keith Busch <kbusch@kernel.org>
> Cc: linux-kernel@vger.kernel.org; axboe@kernel.dk; sagi@grimberg.me;
> linux-nvme@lists.infradead.org; hch@lst.de; arnd@arndb.de; Ricky WU
> <ricky_wu@realtek.com>; gregkh@linuxfoundation.org
> Subject: Re: Possible nvme regression in 6.4.11
> 
> 
> External mail.
> 
> 
> 
> On 8/23/23 13:41, Keith Busch wrote:
> > On Thu, Aug 17, 2023 at 05:16:01AM -0400, Genes Lists wrote:
> >>> ----------------------------------------------------------------
> >>> 69304c8d285b77c9a56d68f5ddb2558f27abf406 is the first bad commit
> >>> commit 69304c8d285b77c9a56d68f5ddb2558f27abf406
> >>> Author: Ricky WU <ricky_wu@realtek.com>
> >>> Date:   Tue Jul 25 09:10:54 2023 +0000
> >>>
> >>>       misc: rtsx: judge ASPM Mode to set PETXCFG Reg
> >>>
> >>>       commit 101bd907b4244a726980ee67f95ed9cafab6ff7a upstream.
> >>>
> >>>       ASPM Mode is ASPM_MODE_CFG need to judge the value of
> clkreq_0
> >>>       to set HIGH or LOW, if the ASPM Mode is ASPM_MODE_REG
> >>>       always set to HIGH during the initialization.
> >>>
> >>>       Cc: stable@vger.kernel.org
> >>>       Signed-off-by: Ricky Wu <ricky_wu@realtek.com>
> >>>       Link:
> >>>
> https://lore.kernel.org/r/52906c6836374c8cb068225954c5543a@realtek.com
> >>>       Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>>
> >>>    drivers/misc/cardreader/rts5227.c  |  2 +-
> >>>    drivers/misc/cardreader/rts5228.c  | 18 ------------------
> >>>    drivers/misc/cardreader/rts5249.c  |  3 +--
> >>>    drivers/misc/cardreader/rts5260.c  | 18 ------------------
> >>>    drivers/misc/cardreader/rts5261.c  | 18 ------------------
> >>>    drivers/misc/cardreader/rtsx_pcr.c |  5 ++++-
> >>>    6 files changed, 6 insertions(+), 58 deletions(-)
> >>>
> >>> ------------------------------------------------------
> >>>
> >>> And the machine does have this hardware:
> >>>
> >>> 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd.
> >>> RTS525A PCI Express Card Reader (rev 01)
> >>>           Subsystem: Dell RTS525A PCI Express Card Reader
> >>>           Physical Slot: 1
> >>>           Flags: bus master, fast devsel, latency 0, IRQ 141
> >>>           Memory at ed100000 (32-bit, non-prefetchable) [size=4K]
> >>>           Capabilities: [80] Power Management version 3
> >>>           Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit+
> >>>           Capabilities: [b0] Express Endpoint, MSI 00
> >>>           Kernel driver in use: rtsx_pci
> >>>           Kernel modules: rtsx_pci
> >>>
> >>>
> >>>
> >>
> >>
> >> Adding to CC list since bisect landed on
> >>
> >>     drivers/misc/cardreader/rtsx_pcr.c
> >>
> >> Thread starts here: https://lkml.org/lkml/2023/8/16/1154
> >
> > I realize you can work around this by blacklisting the rtsx_pci, but
> > that's not a pleasant solution. With only a few days left in 6.5,
> > should the commit just be reverted?
> 
> Keith - thanks for reminder.
> 
> The card reader device itself is non-critical and very low priority.
> 
> What perhaps is a little more worrisome is the change in rtsx somehow
> prevented nvme from functioning normally and the machine then not booting
> (at least for some combination(s) of hardware).
> 
> If there is a simple fix to prevent nvme from being impacted by the rtsx driver
> that would be more than sufficient?
> 
> On the other hand 6.4.11 is out, and I'm guessing there isn't a lot of noise on
> this either. From what I've seen, 1 other user with same problem [1] and 1 with
> same card reader not having a problema [2].
> And no 'me-too's in the kernel bugzilla [3] either.
> 
> 
> Gene
> 
> 
> [1] https://bbs.archlinux.org/viewtopic.php?id=288095
> [2] https://bugs.archlinux.org/task/79439
> [3] https://bugzilla.kernel.org/show_bug.cgi?id=217802
> 
> 
> 
> 
> ------Please consider the environment before printing this e-mail.