Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Feedback-ID: ifd894703:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1048-g9229b632c5-fm-20231019.001-g9229b632
MIME-Version: 1.0
Message-Id: <52ec45eb-6633-4d51-96ff-d29d1743e1aa@app.fastmail.com>
In-Reply-To: <c9a99e29-1a16-4b46-8e3a-afd0aae5b76e@leemhuis.info>
References: <20230725061008.1504292-1-jiaxun.yang@flygoat.com>
 <e9c103dc-98ac-9a51-7291-f5da1467b2ff@flygoat.com>
 <CAAhV-H7_OjTaU_wn6mUW0-JSrXS+=A2rXCiBc8cyce5ob49BLg@mail.gmail.com>
 <861a809d-3df1-327e-e033-87506f6d89e5@flygoat.com>
 <20230907011828.GA2865@thinkpad>
 <6e1bdebf-f335-23a5-c79f-d603c5d0150c@flygoat.com>
 <20230907050805.GA3218@thinkpad>
 <91336c97-0831-3ce3-5ff0-54344f18e065@leemhuis.info>
 <c9a99e29-1a16-4b46-8e3a-afd0aae5b76e@leemhuis.info>
Date:   Sun, 22 Oct 2023 14:36:13 +0100
From:   "Jiaxun Yang" <jiaxun.yang@flygoat.com>
To:     "Linux regressions mailing list" <regressions@lists.linux.dev>,
        "Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>
Cc:     "Huacai Chen" <chenhuacai@kernel.org>,
        linux-pci <linux-pci@vger.kernel.org>,
        "Bjorn Helgaas" <bhelgaas@google.com>,
        linux-kernel@vger.kernel.org,
        =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= <kw@linux.com>,
        "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH v2] pci: loongson: Workaround MIPS firmware MRRS settings
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


=E5=9C=A82023=E5=B9=B410=E6=9C=8820=E6=97=A5=E5=8D=81=E6=9C=88 =E4=B8=8B=
=E5=8D=8812:04=EF=BC=8CThorsten Leemhuis=E5=86=99=E9=81=93=EF=BC=9A
> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> for once, to make this easily accessible to everyone.
>
> Just wondering what's up here. The patch this thread is about afaics w=
as
> supposed to fix a regression reported in July
> (https://bugzilla.kernel.org/show_bug.cgi?id=3D217680 ), but has made =
not
> steps closer to get mainlined during the past few weeks. Is there a
> reason, or did it maybe fell through the cracks?
>
> Jiaxun Yang, from it quick look it seems like you wanted to post a v3,
> but never did so; but I might be mistaken there.

I just figure out the problem of this implementation.
Will resend and explain.

Thanks
- Jiaxun

>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' ha=
t)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
> #regzbot poke
>
> On 20.09.23 14:33, Linux regression tracking (Thorsten Leemhuis) wrote:
>> [CCing the regression list, as it should be in the loop for regressio=
ns:
>> https://docs.kernel.org/admin-guide/reporting-regressions.html]
>>=20
>> On 07.09.23 07:08, Manivannan Sadhasivam wrote:
>>> On Thu, Sep 07, 2023 at 11:13:00AM +0800, Jiaxun Yang wrote:
>>>> =E5=9C=A8 2023/9/7 9:18, Manivannan Sadhasivam =E5=86=99=E9=81=93:
>>>> [...]
>>>>> Why do you need to walk through every single device instead of jus=
t bridges?
>>>>> I'm not the maintainer, but my suggestion is to go for Huacai Chen=
's solution.
>>>>
>>>> Thanks for your reply, unfortunately Huacai's solution is impractic=
al in
>>>> this case.
>>>>
>>>> The problem we have, is firmware (or BIOS) setting improper MRRS fo=
r devices
>>>> attached under those bridges. So we have to fix up MRRS for every s=
ingle
>>>> device.
>>>> We can't iterate child device in bridge quirk because there is no g=
uarantee
>>>> that
>>>> bridge will be probed before=C2=A0 it's child device, partly due to=
 hotplug.
>>>
>>> Okay, this clarifies and also warrants improvement in commit message.
>>>
>>> You could also use pci_walk_bus() after pci_host_probe() to iterate =
over the
>>> child devices under root bridge and set MRRS. IMO that would look ne=
at.
>>=20
>> Hi, Thorsten here, the Linux kernel's regression tracker. What's the
>> status here? The regression that was supposed to be fixed by the patc=
hed
>> that started this thread was reported 9 weeks ago[1] and the culprit
>> made it to many stable kernels as well. Would be really good to final=
ly
>> fix this, as a regression like this should ideally be fixed within 2 =
to
>> 3 weeks (in both mainline and stable). With a revert if necessary -- =
is
>> this maybe still a option, or would that cause more trouble then it
>> solved (I guess that's the case).
>>=20
>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=3D217680
>>=20
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' h=
at)
>> --
>> Everything you wanna know about Linux kernel regression tracking:
>> https://linux-regtracking.leemhuis.info/about/#tldr
>> If I did something stupid, please tell me, as explained on that page.
>>=20
>>>> This quirk has been in tree for a while, until Huacai refactored it=
 and
>>>> broke some
>>>> systems in 8b3517f88ff2 ("PCI: loongson: Prevent LS7A MRRS increase=
s").
>>>>
>>>> Also to note that ks_pcie_quirk in drivers/pci/controller/dwc/pci-k=
eystone.c
>>>> uses similar approach.
>>>>> This avoids iterating over bridges/devices two times.
>>>>>
>>>>> Also, please rename firmware to BIOS, as firmware commonly represe=
nts the
>>>>> software running on PCIe endpoint devices.
>>>> Ack, will fix in next reversion.
>>>>
>>>> Thanks
>>>> - Jiaxun
>>>>>
>>>>> - Mani
>>>> [...]
>>>

--=20
- Jiaxun