[PATCH] PCI: imx6: Keep Root Port MSI capability also for i.MX6Q

Thorsten Leemhuis regressions at leemhuis.info
Fri Sep 18 23:57:02 PDT 2026


On 9/19/26 01:00, Bjorn Helgaas wrote:
> [+cc Thorsten, possible regzbot confusion?]
> 
> On Mon, Apr 27, 2026 at 01:58:04PM +0200, Soeren Moch wrote:
>> Also on the NXP i.MX6Q chipset MSIs from the endpoints won't be received by
>> the iMSI-RX MSI controller if the Root Port MSI capability is disabled.
>>
>> Even though the Root Port MSIs won't be received by the iMSI-RX controller
>> due to design, this chipset has some weird hardware bug that prevents
>> the endpoint MSIs from reaching when the Root Port MSI capability is
>> disabled.
>>
>> Hence, always keep the Root Port MSI capability for this chipset.
>>
>> Note that by keeping Root Port MSI capability, Root Port MSIs such as AER,
>> PME and others won't be received by default. So users need to use
>> workarounds such as passing 'pcie_pme=nomsi' cmdline param.
>>
>> Fixes: 3a4e8302e72f ("PCI: imx6: Keep Root Port MSI capability with iMSI-RX to work around hardware bug")
>> Cc: <stable at vger.kernel.org> # 7.0.x
>> Signed-off-by: Soeren Moch <smoch at web.de>
> 
> This thread is still listed as a regression:
> https://linux-regtracking.leemhuis.info/regzbot/regression/lore/20260427115804.134231-1-smoch@web.de/

My fault, afaics; sorry.

> But I *think* it's been resolved by:
> 
>   b4bee12ebecc ("PCI: imx6: Keep i.MX6 Root Port MSI/MSI-X Capabilities with iMSI-RX to work around hardware bug")> 
> Can you confirm?
>
> Maybe regzbot is confused by the fact that the regression was first
> attributed to 3a4e8302e72f, and then later attributed to
> f5cd8a929c825?

The main problem is something different: Sometimes one commit causes
multiple issues that in rare cases might even be reported by the same
person -- and regzbot needs to keep them and fixes for them apart. Which
is why it is cautions and will only auto-close a tracked regressions
when a Link:/Closes: tags points to what regzbot considers the report,
as Linus demands those anyway. And b4bee12ebeccfc didn't to that. No
problem, happens all the time, normally I notice these things and tell
regzbot manually. And I kinda did when I noticed that a fix was in the
works, but then the subject of the fix changed later -- and I missed that.

These things happen and in a ideal world regzbot should be little more
gentle and likely auto-close tracked regressions when a Fixes: tag
combined with a Reported-by: or Tested-by: matches. That is kinda on the
todo list, but not near the top (wait for by LPC talk). Anyway, thx for
mentioning it and let me update regzbot:

#regzbot fix: b4bee12ebecc

Ciao, Thorsten
>> ---
>> Cc: Manivannan Sadhasivam <mani at kernel.org>
>> Cc: Richard Zhu <hongxing.zhu at nxp.com>
>> Cc: Lucas Stach <l.stach at pengutronix.de>
>> Cc: Bjorn Helgaas <bhelgaas at google.com>
>> Cc: Frank Li <Frank.Li at nxp.com>
>> Cc: Fabio Estevam <festevam at gmail.com>
>> Cc: linux-pci at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: imx at lists.linux.dev
>> Cc: linux-kernel at vger.kernel.org
>>
>> Tested on a tbs2910 board [1]
>> [1] arch/arm/boot/dts/nxp/imx/imx6q-tbs2910.dts
>> ---
>>  drivers/pci/controller/dwc/pci-imx6.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
>> index 6d6a1688e7eb..3d461bdef967 100644
>> --- a/drivers/pci/controller/dwc/pci-imx6.c
>> +++ b/drivers/pci/controller/dwc/pci-imx6.c
>> @@ -1865,7 +1865,8 @@ static const struct imx_pcie_drvdata drvdata[] = {
>>  		.flags = IMX_PCIE_FLAG_IMX_PHY |
>>  			 IMX_PCIE_FLAG_SPEED_CHANGE_WORKAROUND |
>>  			 IMX_PCIE_FLAG_BROKEN_SUSPEND |
>> -			 IMX_PCIE_FLAG_SUPPORTS_SUSPEND,
>> +			 IMX_PCIE_FLAG_SUPPORTS_SUSPEND |
>> +			 IMX_PCIE_FLAG_KEEP_MSI_CAP,
>>  		.dbi_length = 0x200,
>>  		.gpr = "fsl,imx6q-iomuxc-gpr",
>>  		.ltssm_off = IOMUXC_GPR12,
>> -- 
>> 2.43.0
>>




More information about the linux-arm-kernel mailing list