On 2013/7/11 18:19, Paul Bolle wrote:
> Yijing,
>
> On Thu, 2013-07-11 at 11:55 +0800, Yijing Wang wrote:
>> Can you provide the lspci -vvv and lspci - info messages ?
>> I want to confirm your hardware information which cause your resume error.
>> You can get these messages in any kernel vers
Yijing,
On Thu, 2013-07-11 at 11:55 +0800, Yijing Wang wrote:
> Can you provide the lspci -vvv and lspci - info messages ?
> I want to confirm your hardware information which cause your resume error.
> You can get these messages in any kernel version, that's ok.
Would it be sufficient to send
>> 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
>> If the slot support surprise hot remove, this action maybe safe. right?
>
> If there's no device, config space accesses performed by .remove()
> will fail (reads will return -1 data or error; writes will be
> dropped). MMIO or I/O port accesses may fail with machine checks or
> similar bad thi
On Tue, Jul 9, 2013 at 9:00 PM, Yijing Wang wrote:
> Hi Bjorn,
>Thanks for your review and comments!
>
>>> We can use PCIe Device Serial Number to identify the device if
>>> device support DSN.
>>
>> I think I like the idea of this, especially because the Microsoft PCI
>> Hardware Compliance T
Hi Bjorn,
Thanks for your review and comments!
>> We can use PCIe Device Serial Number to identify the device if
>> device support DSN.
>
> I think I like the idea of this, especially because the Microsoft PCI
> Hardware Compliance Test apparently requires DSN for hot-pluggable
> PCIe devices
On Tue, Jul 9, 2013 at 1:56 AM, 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 lik
>> 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 testin
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 l
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 :00:1c.1:pcie04: Device :03:00.0 alrea
10 matches
Mail list logo
