[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5b1aa8ef91a4c71982ad77234932349@intel.com>
Date: Thu, 18 Feb 2021 03:00:20 +0000
From: "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>
To: 'Krzysztof Wilczyński' <kw@...ux.com>
CC: Bjorn Helgaas <bhelgaas@...gle.com>,
"Kelley, Sean V" <sean.v.kelley@...el.com>,
"Luck, Tony" <tony.luck@...el.com>, "Jin, Wen" <wen.jin@...el.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/1] PCI/RCEC: Fix failure to inject errors to some RCiEP
devices
Hi Krzysztof,
Sorry, just back from Chinese New Year holiday.
> From: Krzysztof Wilczyński <kw@...ux.com>
> ...
> ...
> Would this only affect error injection or would this be also a generic problem
> with the driver itself causing issues regardless of whether it was an error
> injection or not for this particular device? I am asking, as there is a lot going on
> in the commit message.
This is also a generic problem.
> I wonder if simplifying this commit message so that it clearly explains what was
> broken, why, and how this patch is fixing it, would perhaps be an option? The
> backstory of how you found the issue while doing some testing and error
> injection is nice, but not sure if needed.
>
> What do you think?
Agree to simplify the commit message. How about the following subject and commit message?
Subject:
Use device number to check RCiEPBitmap of RCEC
Commit message:
rcec_assoc_rciep() used the combination of device number and function number 'devfn' to check whether the corresponding bit in the RCiEPBimap of RCEC was set. According to [1], it only needs to use the device number to check the corresponding bit in the RCiEPBitmap was set. So fix it by using PCI_SLOT() to convert 'devfn' to device number for rcec_assoc_rciep().
[1] PCIe r5.0, sec "7.9.10.2 Association Bitmap for RCiEPs"
Thanks!
-Qiuxu
Powered by blists - more mailing lists