Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Feedback-ID: ifd894703:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1048-g9229b632c5-fm-20231019.001-g9229b632
MIME-Version: 1.0
Message-Id: <30afffac-b470-43ce-95cd-7bc72bf1752f@app.fastmail.com>
In-Reply-To: <20230907050805.GA3218@thinkpad>
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>
Date:   Sun, 22 Oct 2023 14:38:30 +0100
From:   "Jiaxun Yang" <jiaxun.yang@flygoat.com>
To:     "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=B49=E6=9C=887=E6=97=A5=E4=B9=9D=E6=9C=88 =E4=B8=8A=E5=
=8D=886:08=EF=BC=8CManivannan Sadhasivam=E5=86=99=E9=81=93=EF=BC=9A
> On Thu, Sep 07, 2023 at 11:13:00AM +0800, Jiaxun Yang wrote:
>>=20
>>=20
>> =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 just=
 bridges?
>> > I'm not the maintainer, but my suggestion is to go for Huacai Chen'=
s solution.
>> Hi Mani,
>>=20
>> Thanks for your reply, unfortunately Huacai's solution is impractical=
 in
>> this case.
>>=20
>> The problem we have, is firmware (or BIOS) setting improper MRRS for =
devices
>> attached under those bridges. So we have to fix up MRRS for every sin=
gle
>> device.
>> We can't iterate child device in bridge quirk because there is no gua=
rantee
>> that
>> bridge will be probed before=C2=A0 it's child device, partly due to h=
otplug.
>>=20
>
> Okay, this clarifies and also warrants improvement in commit message.
>
> You could also use pci_walk_bus() after pci_host_probe() to iterate ov=
er the
> child devices under root bridge and set MRRS. IMO that would look neat.

This won't work as disabling device will reset MRRS and you have to set
it again, while pci_host_probe will only run at init.

So quirk at device enablement is still the best solution.

Thanks
- Jiaxun

>
> - Mani
>
>> This quirk has been in tree for a while, until Huacai refactored it a=
nd
>> broke some
>> systems in 8b3517f88ff2 ("PCI: loongson: Prevent LS7A MRRS increases"=
).
>>=20
>> Also to note that ks_pcie_quirk in drivers/pci/controller/dwc/pci-key=
stone.c
>> uses similar approach.
>> > This avoids iterating over bridges/devices two times.
>> >=20
>> > Also, please rename firmware to BIOS, as firmware commonly represen=
ts the
>> > software running on PCIe endpoint devices.
>> Ack, will fix in next reversion.
>>=20
>> Thanks
>> - Jiaxun
>> >=20
>> > - Mani
>> [...]
>
> --=20
> =E0=AE=AE=E0=AE=A3=E0=AE=BF=E0=AE=B5=E0=AE=A3=E0=AF=8D=E0=AE=A3=E0=AE=A9=
=E0=AF=8D =E0=AE=9A=E0=AE=A4=E0=AE=BE=E0=AE=9A=E0=AE=BF=E0=AE=B5=E0=AE=AE=
=E0=AF=8D

--=20
- Jiaxun