linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.


  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).