Hi Marcel,
The issue is the system automatically wakes up from S3.
We tried to figure out the issue and found that BT is suspicious
that's how the workaround comes from.
Also, we found that if we connect the BT antenna, the system will be
waken up more quickly.
I know the quirk will disable the ability to wake up the system from
remote, but I have no idea how to debug it further.
Is there any way I could try to check if we really got a wake up
packet or we keep receiving random packets and trigger the wake up
process?
Thanks.
Best regards,
AceLan Kao.
2018-01-05 22:59 GMT+08:00 Marcel Holtmann <marcel@xxxxxxxxxxxx>:
> Hi AceLan,
>
>> We found an issue that when system enters S3, it stays in S3 for a few
>> seconds, and somehow it resumes automatically.
>> And we try below quirk which can prevent it from waking up.
>>
>> drivers/usb/core/quirks.c
>> @@ -208,11 +208,11 @@ static const struct usb_device_id usb_quirk_list[] = {
>> USB_QUIRK_DISCONNECT_SUSPEND },
>> { USB_DEVICE(0x12d1, 0x15c3), .driver_info =
>> USB_QUIRK_DISCONNECT_SUSPEND },
>> + { USB_DEVICE(0x8087, 0x0025), .driver_info =
>> + USB_QUIRK_DISCONNECT_SUSPEND },
>>
>> Here are some findings from the system.
>>
>> $ lsusb
>> Bus 001 Device 004: ID 8087:0025 Intel Corp.
>
> can we be a bit more specific here on what is going on and triage this a bit more. I have not heard of our hardware needing such a broad quirk. Also disconnecting on suspend means that we loose the support for remote wakeup and I am pretty sure that we do not want that.
>
> Regards
>
> Marcel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
