From: Paul Bolle <pebolle@tiscali.nl>
To: Yijing Wang <wangyijing@huawei.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Rafael <rjw@sisk.pl>, Hanjun Guo <guohanjun@huawei.com>,
jiang.liu@huawei.com, Oliver Neukum <oneukum@suse.de>,
Gu Zheng <guz.fnst@cn.fujitsu.com>
Subject: Re: [PATCH 2/2] PCI,pciehp: avoid add a device already exist during pciehp_resume
Date: Tue, 09 Jul 2013 10:07:41 +0200 [thread overview]
Message-ID: <1373357261.1633.4.camel@x61.thuisdomein> (raw)
In-Reply-To: <1373356564-21668-1-git-send-email-wangyijing@huawei.com>
On Tue, 2013-07-09 at 15:56 +0800, Yijing Wang wrote:
> Currently, pciehp_resume will call pciehp_enable_slot() to add
> device if there is a device in the slot. But if the device was
> present before suspend, it's no necessary to add again. Now in
> such case, there is some uncomfortable message like
>
> pciehp 0000:00:1c.1:pcie04: Device 0000:03:00.0 already exists at 0000:03:00, cannot hot-add
> pciehp 0000:00:1c.1:pcie04: Cannot add device at 0000:03:00
>
> This problem was reported by Paul Bolle <pebolle@tiscali.nl>
> The discussion link: http://comments.gmane.org/gmane.linux.kernel.pci/19876
>
> We can use PCIe Device Serial Number to identify the device if
> device support DSN.
>
> currently:
> 1. slot is empty before suspend, insert card during suspend.
> In this case, is safe, pciehp will add device by check adapter
> status register in pciehp_resume.
>
> 2. slot is non empty before suspend, remove card during suspend.
> Also be safe, pciehp will remove device by check adapter
> status register in pciehp_resume.
>
> 3. slot is non empty before suspend, remove card during suspend
> and insert a new card.
> Now pciehp just call pciehp_enable_slot() roughly. We should
> remove the old card firstly, then add the new card.
>
> 4. slot is non empty before suspend, no action during suspend.
> We should do nothing in pciehp_resume, but we call
> pciehp_enable_slot(), so some uncomfortable messages show like above.
> In this case, we can improve it a little by add a guard
> if (!list_empty(bus->devices)).
Great!
I'm currently trying to bisect another problem, but hope to test this
patch (and the preceding patch it apparently needs) in a few days.
Please feel free to prod me if you think testing is needed but I'm
taking to long to report back.
Thanks!
Paul Bolle
next prev parent reply other threads:[~2013-07-09 8:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-09 7:56 Yijing Wang
2013-07-09 8:07 ` Paul Bolle [this message]
2013-07-09 8:18 ` Yijing Wang
2013-07-11 3:55 ` Yijing Wang
2013-07-11 10:19 ` Paul Bolle
2013-07-12 1:49 ` Yijing Wang
2013-07-09 22:27 ` Bjorn Helgaas
2013-07-10 3:00 ` Yijing Wang
2013-07-10 20:27 ` Bjorn Helgaas
2013-07-11 2:33 ` Yijing Wang
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=1373357261.1633.4.camel@x61.thuisdomein \
--to=pebolle@tiscali.nl \
--cc=bhelgaas@google.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=rjw@sisk.pl \
--cc=wangyijing@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
all inboxes | Powered by JetHome®