From: Wenchao Hao <haowenchao@huawei.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Keith Busch <kbusch@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>, <linux-pci@vger.kernel.org>,
Wu Bo <wubo40@huawei.com>,
Zhiqiang Liu <liuzhiqiang26@huawei.com>, <linfeilong@huawei.com>,
<lijinlin3@huawei.com>, Matthew Wilcox <willy@infradead.org>
Subject: Re: [question]: Query regarding the PCI addresses
Date: Tue, 20 Jul 2021 10:05:40 +0800 [thread overview]
Message-ID: <3ad42d27-f7a8-56d7-778d-5e26511e4e24@huawei.com> (raw)
In-Reply-To: <20210716142527.GA2097477@bjorn-Precision-5520>
On 2021/7/16 22:25, Bjorn Helgaas wrote:
> On Fri, Jul 16, 2021 at 10:04:51PM +0800, Wenchao Hao wrote:
>> On 2021/7/15 1:26, Keith Busch wrote:
>>> On Wed, Jul 14, 2021 at 11:54:27AM -0500, Bjorn Helgaas wrote:
>>>> On Wed, Jul 14, 2021 at 02:33:37PM +0800, Wenchao Hao wrote:
>>>>
>>>>> If they are not fixed, then is there anyway I can get a fixed ID
>>>>> which can indicate physical connection.
>>>> You can look at the "lspci -P" option. I'm not really familiar with
>>>> this, but I think Matthew (cc'd) implemented it.
>>> That option shows the parent devices for each listed device, but that
>>> may not produce the same output if BDf doesn't always enumerate the
>>> same.
>>>
>>> I think Wenchao was seeking some invariant device identification that
>>> can be used to look up its BDf. There's no PCI level requirement for
>>> uniquely identifying a specific device across changing topologies, so I
>>> don't think this is generically possible.
>> Yes, I want a way to access device which can keep unchanged, a
>> direction is according to hardware. If we have anyway which makes
>> it possible for software can describe hardware connection would
>> satisfy our demand.
> I don't know whether this would be useful, but PCI does define an
> optional "Device Serial Number" extended capability. It has issues
> like the fact that many devices don't support it at all, and even on
> devices that do support it, the serial number may not actually be
> unique. There is minimal support for this in Linux (pci_get_dsn()),
> but it is currently not exposed to userspace via sysfs.
>
> Bjorn
> .
This "Device Serial Number" seems can not satisfy our demand because it
is looks
not a general ID. According to BIOS conclusion, if we can the hardware keeps
unchanged, the BUS number would not change. We would put some
restrictions as
workaround temporarily.
Thanks a lot for your suggestions.
next prev parent reply other threads:[~2021-07-20 2:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-14 6:33 [question]: Query regarding the PCI addresses Wenchao Hao
2021-07-14 16:54 ` Bjorn Helgaas
2021-07-14 17:26 ` Keith Busch
2021-07-16 14:04 ` Wenchao Hao
2021-07-16 14:25 ` Bjorn Helgaas
2021-07-20 2:05 ` Wenchao Hao [this message]
2021-07-16 13:59 ` Wenchao Hao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ad42d27-f7a8-56d7-778d-5e26511e4e24@huawei.com \
--to=haowenchao@huawei.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=kbusch@kernel.org \
--cc=lijinlin3@huawei.com \
--cc=linfeilong@huawei.com \
--cc=linux-pci@vger.kernel.org \
--cc=liuzhiqiang26@huawei.com \
--cc=willy@infradead.org \
--cc=wubo40@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).