From: Yijing Wang <wangyijing@huawei.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Don Dutile <ddutile@redhat.com>, Paul Bolle <pebolle@tiscali.nl>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Rafael <rjw@sisk.pl>, Hanjun Guo <guohanjun@huawei.com>,
Jiang Liu <jiang.liu@huawei.com>, Oliver Neukum <oneukum@suse.de>,
Gu Zheng <guz.fnst@cn.fujitsu.com>
Subject: Re: [PATCH -v3 3/3] PCI,pciehp: use PCIe DSN to identify device change during suspend
Date: Tue, 30 Jul 2013 12:06:16 +0800 [thread overview]
Message-ID: <51F73BB8.6090908@huawei.com> (raw)
In-Reply-To: <CAErSpo6Zw3Q=bzw6tAR70TCcXs1+UB9BNW3y7w8qNusT2c79tg@mail.gmail.com>
>>
>> Hi Bjorn,
>> I'm reworking this patch, but found some strange info about vpd serial number.
>> I have two x86 machines, they almost have the same hardware topology. But by lspci,
>> I found two different Broadcom BCM5709 NIC in different machine have the same vpd serial
>> number. If this is normal, vpd serial number seems to be useless for identify device change.
>
> I wouldn't say it's completely useless. If the VPD serial number
> changes, we can be pretty confident that the card has changed. It's
> just that if the VPD serial number is unchanged, we might incorrectly
> assume it's the same device.
>
> But we currently *always* assume it's the same device, since we don't
> look at serial numbers at all. If we can detect some changes, that
> should be an improvement over what we have today even though it's not
> perfect.
Hmmm, Yes, different VPD serial number must comes from different device.
Although the same serial number maybe not the same device.
I will send out the new version patchset soon.
Thanks!
Yijing.
>
>> The first machine:
>> linux:/home/yijing # lspci -vvv -s 0000:01:00.0
>> 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)
>> Subsystem: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Latency: 0, Cache Line Size: 256 bytes
>> Interrupt: pin A routed to IRQ 28
>> Region 0: Memory at c0000000 (64-bit, non-prefetchable) [size=32M]
>> Capabilities: [48] Power Management version 3
>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
>> Capabilities: [50] Vital Product Data
>> Product Name: Broadcom NetXtreme II Ethernet Controller
>> Read-only fields:
>> [PN] Part number: BCM95706A0
>> [EC] Engineering changes: 220197-2
>> [SN] Serial number: 0123456789
>> [MN] Manufacture ID: 31 34 65 34
>> [RV] Reserved: checksum good, 31 byte(s) reserved
>> End
>> Capabilities: [58] MSI: Enable- Count=1/16 Maskable- 64bit+
>> Address: 0000000000000000 Data: 0000
>> ..............[snip]...................
>>
>> The second machine:
>> linux-suse-vmdq:~/pciutils-3.2.0 # ./lspci -vvv -s 01:00.0
>> 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)
>> Subsystem: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Latency: 0, Cache Line Size: 256 bytes
>> Interrupt: pin A routed to IRQ 28
>> Region 0: Memory at f6000000 (64-bit, non-prefetchable) [size=32M]
>> Capabilities: [48] Power Management version 3
>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
>> Capabilities: [50] Vital Product Data
>> Product Name: Broadcom NetXtreme II Ethernet Controller
>> Read-only fields:
>> [PN] Part number: BCM95706A0
>> [EC] Engineering changes: 220197-2
>> [SN] Serial number: 0123456789
>> [MN] Manufacture ID: 31 34 65 34
>> [RV] Reserved: checksum good, 31 byte(s) reserved
>> End
>> .......[snip]........
>>
>>
>>>
>>> Also, I think it's possible to use acpiphp for ExpressCard slots, and
>>> this patch doesn't help acpiphp detect card swaps. I don't see any
>>> mention of suspend/resume in acpiphp, so I don't know if it does
>>> anything at all to detect card changes while suspended. Maybe Rafael
>>> can shed some light?
>>>
>>> I put the first two patches on a pci/yijing-dsn-v3 branch while we
>>> work out the details of this one.
>>>
>>> Bjorn
>>>
>>>> } else if (!list_empty(&pbus->devices)) {
>>>> pciehp_disable_slot(slot);
>>>> }
>>>> --
>>>> 1.7.1
>>>>
>>>>
>>>
>>> .
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
>
> .
>
--
Thanks!
Yijing
prev parent reply other threads:[~2013-07-30 4:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-12 9:32 [PATCH -v3 0/3] Use PCIe DSN to improve pciehp_resume Yijing Wang
2013-07-12 9:32 ` [PATCH -v3 1/3] PCI: introduce PCIe Device Serial Number Capability support Yijing Wang
2013-07-12 9:32 ` [PATCH -v3 2/3] PCI,pciehp: avoid add a device already exist before suspend during resume Yijing Wang
2013-07-12 9:32 ` [PATCH -v3 3/3] PCI,pciehp: use PCIe DSN to identify device change during suspend Yijing Wang
2013-07-26 0:17 ` Bjorn Helgaas
2013-07-26 8:25 ` Yijing Wang
2013-07-30 3:46 ` Yijing Wang
2013-07-30 3:58 ` Bjorn Helgaas
2013-07-30 4:06 ` Yijing Wang [this message]
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=51F73BB8.6090908@huawei.com \
--to=wangyijing@huawei.com \
--cc=bhelgaas@google.com \
--cc=ddutile@redhat.com \
--cc=guohanjun@huawei.com \
--cc=guz.fnst@cn.fujitsu.com \
--cc=jiang.liu@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=oneukum@suse.de \
--cc=pebolle@tiscali.nl \
--cc=rjw@sisk.pl \
/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