public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


      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