Re: [PATCH v3] PCI: rcar-gen4: Limit Max_Read_Request_Size and Max_Payload_Size to 256 Bytes

[Rong Zhang]

Hi Marek,

On Wed, 2026-09-09 at 04:34 +0200, Marek Vasut wrote:
> On 9/6/26 7:07 PM, Rong Zhang wrote:
> 
> Hello Rong,
> 
> I apologize for my delayed reply.
> 
> > > > If you need more information I can do some more experiments with the PCIe
> > > > switch card.
> > > 
> > > Please look at the commit message [1] , that lists the exact test and
> > > the PCIe NVMe SSD which triggers the data corruption (let me know if
> > > something is unclear). I think any PCIe NVMe SSD which is non-HMB with
> > > MRRS on the SSD size that is > MRRS on the controller side will trigger
> > > this issue too.
> > > 
> > 
> > Unfortunately I don't have any non-HMB NVMe SSD, and it's unlikely I'll
> > get one anytime soon due to the crazy price. Before the AI supply chain
> > crisis, I bought several NVMe SSDs, but I chose HMB ones as they generate
> > less heat and consume less electricity.
> 
> Maybe this could be reproduced even with another PCIe device with 
> MRRS=512 or more, which posts MRd to the PCIe controller with MRRS=128 
> or 256. The AHCI controller might be capable of that. I only have the 
> SSD as a reproducer, but there could easily be more.
> 
> > > If you could reproduce it on the Loongson, then yes, it
> > > is affected. You might have to disable the current MRRS workaround in
> > > the Loongson PCIe driver though as it might hide the issue.
> > 
> > Due to the lack of non-HMB NVMe SSDs, I can't reproduce the exact same
> > issue. Theoretically I may try to mess around with the AHCI controller
> > (see the mentioned commit below) by manually overriding MRRS, as my
> > device's firmware already clamps it. We will see...
> 
> Does the AHCI controller have MRRS higher than the PCIe controller ?

Oh, I meant "a" controller, not "the" controller. Sorry for the typo.

I don't have the exact same controller as the report, but I do have a
quite modern one. It's from an AMD Promontory 21 chipset add-in card, see
https://oshwhub.com/wesd/b650

I haven't done any MRRS experiment yet. I will find some time this week
or the next. As I've said, you don't need to wait for my result :-)

> 
> > The firmware of many Loongson devices (except for some MIPS-based ones,
> > see the commit message of commit ef61a0405742 ("PCI: loongson: Limit MRRS
> > to 256")) already clamps MRRS for most PCIe devices, which has proven
> > that the 7A1000/7A2000 chipset does need the MRRS quirk.
> 
> This still only applies the MRRS limit to the PCIe controller, not to 
> all devices on the bus, correct ?

This applies to all devices that are the downstream (direct or behind
another bridge) of any root ports (i.e., internal bridges). In detail,
pci_match_id(loongson_internal_bridge_devids, *bridge*) matches the root
port but pcie_set_readrq(*pdev*, 256) sets the downstream PCIe device.

This essentially sets all PCIe devices on the bus (unless firmware has
selected a smaller MRRS), since any other internal endpoints of the
chipset have no PCIe capability (i.e., they are legacy PCI or HT
devices). IOW, only the root ports (i.e.,
loongson_internal_bridge_devids) and their downstream PCIe devices have
MRRS, and they are covered by loongson_set_min_mrrs_quirk().

> 
> I would like to find out whether all the devices (not only the 
> controller) on the PCIe bus on Loongson must have MRRS limited or not.
> -> If yes, then I should start preparing core patches
> -> If no, then this quirk might specific to this controller

My answer is yes.

> 
> > Therefore, you
> > can just go ahead with preparing the core patches without the need of
> > waiting for my test result. It seems that your approach is not going to
> > change the current fixup effects in a significant way, so it should be
> > fine.
> 
> [...]
> 
> Thank you for your help !

Thanks,
Rong