Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Lan Tianyu <tianyu.lan@intel.com>]

On 2012年12月13日 23:35, Frank Schäfer wrote:
> Am 13.12.2012 09:45, schrieb Lan Tianyu:
> 
> [snip]
>>>> I am curious about whether disabling usb device's wakeup rather than usb
>>>> hc's would make suspend work. Can you do a test?
>>>>
>>>> Go to /sys/bus/usb/devices/ and enter the usb 1,1 device
>>>> directory(normally it will be something like"1-1.1".)
>>>> run "echo disabled > power/wakeup".
>>> Are you sure the file is called 'wakeup' for the devices ? I have no
>>> such file in the power directory...
>> Oh. That means the device doesn't support wakeup function.
>> Non-wakeupable devices also will cause the issue. Now Confirm this is
>> hcd problem.
>>
>> I write a quirk patch. Can you test?
> 
> Yes, that makes it work !
> 
>> I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy
>> hcd id via "lspci -nnvvv"?
>> Thanks.
> 
> I have the MCP61 (rev. A2) with id 10de:03f1.
> 
> Further NVIDIA OHCI HCD IDs can be found at
> http://openbenchmarking.org/linux/PCI/0c03.
> But I'm not sure that we should blacklist them all. Maybe this bug has
> been fixed in newer chipset revisions / generations ?
> Where did you get the ID for the MCP79 from ? Is it confirmed that this
> device still suffers from the same bug ?
Yeah. From other reporter.
> 
> I also wonder if this could be an BIOS / ACPI issue.
Just from my opinion, this cause's by OHCI/UHCI. Because if there is no
attached device, suspend can work. This shows BIOS/ACPI work correctly.
> So far, all boards I've seen were form ASUSTeK (Octavio: A8N-VM, me:
> M2N-VM DH, and I remember having seen the same bug on another M2N board
> with MCP55 a while ago).
> 
> Regards,
> Frank
> 


-- 
Best regards
Tianyu Lan