[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tencent_DBC0851ABE9B45D70B4BA098F876F5F10609@qq.com>
Date: Mon, 20 Jan 2025 22:19:01 +0800
From: Jiwei <jiwei.sun.bj@...com>
To: "Maciej W. Rozycki" <macro@...am.me.uk>, Jiwei Sun <sjiwei@....com>
Cc: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>, helgaas@...nel.org,
Lukas Wunner <lukas@...ner.de>, ahuang12@...ovo.com, sunjw10@...ovo.com,
sunjw10@...look.com
Subject: Re: [PATCH v2 2/2] PCI: reread the Link Control 2 Register before
using
On 1/18/25 09:03, Maciej W. Rozycki wrote:
> On Fri, 17 Jan 2025, Jiwei Sun wrote:
>
>> However, within this section of code, lnkctl2 is not modified (after
>> reading from register on line 111) at all and remains 0x5. This results
>> in the condition on line 130 evaluating to 0 (false), which in turn
>> prevents the code from line 132 onward from being executed. The removing
>> 2.5GT/s downstream link speed restriction work can not be done.
>
> It seems like a regression from my original code indeed.
Sorry, I am confused by this sentence.
IIUC, there is no regression regarding the lifting 2.5GT/s restriction in
the commit a89c82249c37 ("PCI: Work around PCIe link training failures").
However, since commit de9a6c8d5dbf ("PCI/bwctrl: Add
pcie_set_target_speed() to set PCIe Link Speed"), the code to lift the
restriction is no longer executed. Therefore, commit de9a6c8d5dbf
("PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed") can be
considered a regression of commit a a89c82249c37 ("PCI: Work around PCIe
link training failures").
So, this fix patch(PCI: reread the Link Control 2 Register before using)
is required, right?
Thanks,
Regards,
Jiwei
>
> Maciej
Powered by blists - more mailing lists