* Wake on connect / wake on disconnect
@ 2025-04-03 18:12 Mario Limonciello
2025-04-04 6:02 ` Mika Westerberg
0 siblings, 1 reply; 14+ messages in thread
From: Mario Limonciello @ 2025-04-03 18:12 UTC (permalink / raw)
To: Mika Westerberg; +Cc: open list:USB XHCI DRIVER, Gong, Richard
Mika,
Recently there are some conversations about wake-up from
connect/disconnect happening and I wanted to get some background from
you about the current policy set in tb_switch_suspend().
Wake on connect and disconnect are only used for runtime, not for system
suspend. Would you be open to adding wake on connect as well for system
suspend? This should help enable use cases like plugging in a closed
laptop to a dock (which works on Windows).
Something like this:
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 6a2116cbb06f..f2f6a085a742 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -3599,6 +3599,7 @@ void tb_switch_suspend(struct tb_switch *sw, bool
runtime)
flags |= TB_WAKE_ON_USB4;
flags |= TB_WAKE_ON_USB3 | TB_WAKE_ON_PCIE | TB_WAKE_ON_DP;
} else if (device_may_wakeup(&sw->dev)) {
+ flags |= TB_WAKE_ON_CONNECT;
flags |= TB_WAKE_ON_USB4 | TB_WAKE_ON_USB3 | TB_WAKE_ON_PCIE;
}
Thanks!
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: Wake on connect / wake on disconnect
2025-04-03 18:12 Wake on connect / wake on disconnect Mario Limonciello
@ 2025-04-04 6:02 ` Mika Westerberg
2025-04-04 11:47 ` Mario Limonciello
0 siblings, 1 reply; 14+ messages in thread
From: Mika Westerberg @ 2025-04-04 6:02 UTC (permalink / raw)
To: Mario Limonciello; +Cc: open list:USB XHCI DRIVER, Gong, Richard
Hi Mario,
On Thu, Apr 03, 2025 at 01:12:07PM -0500, Mario Limonciello wrote:
> Mika,
>
> Recently there are some conversations about wake-up from connect/disconnect
> happening and I wanted to get some background from you about the current
> policy set in tb_switch_suspend().
>
> Wake on connect and disconnect are only used for runtime, not for system
> suspend. Would you be open to adding wake on connect as well for system
> suspend? This should help enable use cases like plugging in a closed laptop
> to a dock (which works on Windows).
Don't we already have a similar for all usb4_portX devices? That does not
work for you?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Wake on connect / wake on disconnect
2025-04-04 6:02 ` Mika Westerberg
@ 2025-04-04 11:47 ` Mario Limonciello
2025-04-04 11:53 ` Mika Westerberg
0 siblings, 1 reply; 14+ messages in thread
From: Mario Limonciello @ 2025-04-04 11:47 UTC (permalink / raw)
To: Mika Westerberg, Mario Limonciello
Cc: open list:USB XHCI DRIVER, Gong, Richard
[-- Attachment #1.1.1: Type: text/plain, Size: 942 bytes --]
On 4/4/25 01:02, Mika Westerberg wrote:
> Hi Mario,
>
> On Thu, Apr 03, 2025 at 01:12:07PM -0500, Mario Limonciello wrote:
>> Mika,
>>
>> Recently there are some conversations about wake-up from connect/disconnect
>> happening and I wanted to get some background from you about the current
>> policy set in tb_switch_suspend().
>>
>> Wake on connect and disconnect are only used for runtime, not for system
>> suspend. Would you be open to adding wake on connect as well for system
>> suspend? This should help enable use cases like plugging in a closed laptop
>> to a dock (which works on Windows).
>
> Don't we already have a similar for all usb4_portX devices? That does not
> work for you?
>
I think that will functionally work - but I'll double check.
However usb_portX power/wakeup defaults are 'disabled' so this would
need a udev rule. Could we set the kernel default for those to
'enabled' instead?
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6617 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Wake on connect / wake on disconnect
2025-04-04 11:47 ` Mario Limonciello
@ 2025-04-04 11:53 ` Mika Westerberg
2025-04-04 15:03 ` Mario Limonciello
0 siblings, 1 reply; 14+ messages in thread
From: Mika Westerberg @ 2025-04-04 11:53 UTC (permalink / raw)
To: Mario Limonciello
Cc: Mario Limonciello, open list:USB XHCI DRIVER, Gong, Richard
On Fri, Apr 04, 2025 at 06:47:31AM -0500, Mario Limonciello wrote:
> On 4/4/25 01:02, Mika Westerberg wrote:
> > Hi Mario,
> >
> > On Thu, Apr 03, 2025 at 01:12:07PM -0500, Mario Limonciello wrote:
> > > Mika,
> > >
> > > Recently there are some conversations about wake-up from connect/disconnect
> > > happening and I wanted to get some background from you about the current
> > > policy set in tb_switch_suspend().
> > >
> > > Wake on connect and disconnect are only used for runtime, not for system
> > > suspend. Would you be open to adding wake on connect as well for system
> > > suspend? This should help enable use cases like plugging in a closed laptop
> > > to a dock (which works on Windows).
> >
> > Don't we already have a similar for all usb4_portX devices? That does not
> > work for you?
> >
>
> I think that will functionally work - but I'll double check.
>
> However usb_portX power/wakeup defaults are 'disabled' so this would need a
> udev rule. Could we set the kernel default for those to 'enabled' instead?
No because that would trigger wakeup each time you unplug/plug and this is
certainly not good if you close the lid, unplug from dock and throw the
laptop to your backpack. Chrome uses this with "dark resume" so if this is
supported by the userspace then it can also enable these.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Wake on connect / wake on disconnect
2025-04-04 11:53 ` Mika Westerberg
@ 2025-04-04 15:03 ` Mario Limonciello
2025-04-04 16:10 ` Mika Westerberg
0 siblings, 1 reply; 14+ messages in thread
From: Mario Limonciello @ 2025-04-04 15:03 UTC (permalink / raw)
To: Mika Westerberg, Mario Limonciello
Cc: open list:USB XHCI DRIVER, Gong, Richard
On 4/4/2025 6:53 AM, Mika Westerberg wrote:
> On Fri, Apr 04, 2025 at 06:47:31AM -0500, Mario Limonciello wrote:
>> On 4/4/25 01:02, Mika Westerberg wrote:
>>> Hi Mario,
>>>
>>> On Thu, Apr 03, 2025 at 01:12:07PM -0500, Mario Limonciello wrote:
>>>> Mika,
>>>>
>>>> Recently there are some conversations about wake-up from connect/disconnect
>>>> happening and I wanted to get some background from you about the current
>>>> policy set in tb_switch_suspend().
>>>>
>>>> Wake on connect and disconnect are only used for runtime, not for system
>>>> suspend. Would you be open to adding wake on connect as well for system
>>>> suspend? This should help enable use cases like plugging in a closed laptop
>>>> to a dock (which works on Windows).
>>>
>>> Don't we already have a similar for all usb4_portX devices? That does not
>>> work for you?
>>>
>>
>> I think that will functionally work - but I'll double check.
>>
>> However usb_portX power/wakeup defaults are 'disabled' so this would need a
>> udev rule. Could we set the kernel default for those to 'enabled' instead?
>
> No because that would trigger wakeup each time you unplug/plug and this is
> certainly not good if you close the lid, unplug from dock and throw the
> laptop to your backpack. Chrome uses this with "dark resume" so if this is
> supported by the userspace then it can also enable these.
Ahhh. I was thinking specifically with wake on connect that's not a
problem, but the sysfs knob for the port changes both wake on connect
and wake on disconnect.
Is there actually a use case for chrome with wake on disconnect? IE if
we didn't turn on wake on disconnect but defaulted to wake on connect
would things be OK? Or made the sysfs knob control only wake on disconnect?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Wake on connect / wake on disconnect
2025-04-04 15:03 ` Mario Limonciello
@ 2025-04-04 16:10 ` Mika Westerberg
2025-04-04 16:16 ` Mario Limonciello
0 siblings, 1 reply; 14+ messages in thread
From: Mika Westerberg @ 2025-04-04 16:10 UTC (permalink / raw)
To: Mario Limonciello
Cc: Mario Limonciello, open list:USB XHCI DRIVER, Gong, Richard
On Fri, Apr 04, 2025 at 10:03:18AM -0500, Mario Limonciello wrote:
> On 4/4/2025 6:53 AM, Mika Westerberg wrote:
> > On Fri, Apr 04, 2025 at 06:47:31AM -0500, Mario Limonciello wrote:
> > > On 4/4/25 01:02, Mika Westerberg wrote:
> > > > Hi Mario,
> > > >
> > > > On Thu, Apr 03, 2025 at 01:12:07PM -0500, Mario Limonciello wrote:
> > > > > Mika,
> > > > >
> > > > > Recently there are some conversations about wake-up from connect/disconnect
> > > > > happening and I wanted to get some background from you about the current
> > > > > policy set in tb_switch_suspend().
> > > > >
> > > > > Wake on connect and disconnect are only used for runtime, not for system
> > > > > suspend. Would you be open to adding wake on connect as well for system
> > > > > suspend? This should help enable use cases like plugging in a closed laptop
> > > > > to a dock (which works on Windows).
> > > >
> > > > Don't we already have a similar for all usb4_portX devices? That does not
> > > > work for you?
> > > >
> > >
> > > I think that will functionally work - but I'll double check.
> > >
> > > However usb_portX power/wakeup defaults are 'disabled' so this would need a
> > > udev rule. Could we set the kernel default for those to 'enabled' instead?
> >
> > No because that would trigger wakeup each time you unplug/plug and this is
> > certainly not good if you close the lid, unplug from dock and throw the
> > laptop to your backpack. Chrome uses this with "dark resume" so if this is
> > supported by the userspace then it can also enable these.
>
> Ahhh. I was thinking specifically with wake on connect that's not a
> problem, but the sysfs knob for the port changes both wake on connect and
> wake on disconnect.
>
> Is there actually a use case for chrome with wake on disconnect? IE if we
> didn't turn on wake on disconnect but defaulted to wake on connect would
> things be OK? Or made the sysfs knob control only wake on disconnect?
Good guestion - I don't know ;-) The Chrome folks wanted this so I suppose
their usecase is specifically that dark resume and I think that's when you
unplug a device so disconnect. Not so sure about wake on connect.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Wake on connect / wake on disconnect
2025-04-04 16:10 ` Mika Westerberg
@ 2025-04-04 16:16 ` Mario Limonciello
2025-04-04 16:20 ` Mario Limonciello
0 siblings, 1 reply; 14+ messages in thread
From: Mario Limonciello @ 2025-04-04 16:16 UTC (permalink / raw)
To: Mika Westerberg, Mario Limonciello, rajat.khandelwal
Cc: open list:USB XHCI DRIVER, Gong, Richard
[-- Attachment #1.1.1: Type: text/plain, Size: 2591 bytes --]
On 4/4/25 11:10, Mika Westerberg wrote:
> On Fri, Apr 04, 2025 at 10:03:18AM -0500, Mario Limonciello wrote:
>> On 4/4/2025 6:53 AM, Mika Westerberg wrote:
>>> On Fri, Apr 04, 2025 at 06:47:31AM -0500, Mario Limonciello wrote:
>>>> On 4/4/25 01:02, Mika Westerberg wrote:
>>>>> Hi Mario,
>>>>>
>>>>> On Thu, Apr 03, 2025 at 01:12:07PM -0500, Mario Limonciello wrote:
>>>>>> Mika,
>>>>>>
>>>>>> Recently there are some conversations about wake-up from connect/disconnect
>>>>>> happening and I wanted to get some background from you about the current
>>>>>> policy set in tb_switch_suspend().
>>>>>>
>>>>>> Wake on connect and disconnect are only used for runtime, not for system
>>>>>> suspend. Would you be open to adding wake on connect as well for system
>>>>>> suspend? This should help enable use cases like plugging in a closed laptop
>>>>>> to a dock (which works on Windows).
>>>>>
>>>>> Don't we already have a similar for all usb4_portX devices? That does not
>>>>> work for you?
>>>>>
>>>>
>>>> I think that will functionally work - but I'll double check.
>>>>
>>>> However usb_portX power/wakeup defaults are 'disabled' so this would need a
>>>> udev rule. Could we set the kernel default for those to 'enabled' instead?
>>>
>>> No because that would trigger wakeup each time you unplug/plug and this is
>>> certainly not good if you close the lid, unplug from dock and throw the
>>> laptop to your backpack. Chrome uses this with "dark resume" so if this is
>>> supported by the userspace then it can also enable these.
>>
>> Ahhh. I was thinking specifically with wake on connect that's not a
>> problem, but the sysfs knob for the port changes both wake on connect and
>> wake on disconnect.
>>
>> Is there actually a use case for chrome with wake on disconnect? IE if we
>> didn't turn on wake on disconnect but defaulted to wake on connect would
>> things be OK? Or made the sysfs knob control only wake on disconnect?
>
> Good guestion - I don't know ;-) The Chrome folks wanted this so I suppose
> their usecase is specifically that dark resume and I think that's when you
> unplug a device so disconnect. Not so sure about wake on connect.
I found the original patch from Rajat [1].
Rajat, any comments? Could you loop in the right people from the Chrome
side to ask? I think my "preference" would be that we make "wake on
connect" always enabled and then let the sysfs knob control "wake on
disconnect".
[1]
https://lore.kernel.org/linux-usb/20221101115042.248187-1-rajat.khandelwal@intel.com/
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6617 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Wake on connect / wake on disconnect
2025-04-04 16:16 ` Mario Limonciello
@ 2025-04-04 16:20 ` Mario Limonciello
2025-04-04 16:55 ` Raul Rangel
0 siblings, 1 reply; 14+ messages in thread
From: Mario Limonciello @ 2025-04-04 16:20 UTC (permalink / raw)
To: Mika Westerberg, rrangel; +Cc: open list:USB XHCI DRIVER, Gong, Richard
On 4/4/25 11:16, Mario Limonciello wrote:
>
>
> On 4/4/25 11:10, Mika Westerberg wrote:
>> On Fri, Apr 04, 2025 at 10:03:18AM -0500, Mario Limonciello wrote:
>>> On 4/4/2025 6:53 AM, Mika Westerberg wrote:
>>>> On Fri, Apr 04, 2025 at 06:47:31AM -0500, Mario Limonciello wrote:
>>>>> On 4/4/25 01:02, Mika Westerberg wrote:
>>>>>> Hi Mario,
>>>>>>
>>>>>> On Thu, Apr 03, 2025 at 01:12:07PM -0500, Mario Limonciello wrote:
>>>>>>> Mika,
>>>>>>>
>>>>>>> Recently there are some conversations about wake-up from connect/
>>>>>>> disconnect
>>>>>>> happening and I wanted to get some background from you about the
>>>>>>> current
>>>>>>> policy set in tb_switch_suspend().
>>>>>>>
>>>>>>> Wake on connect and disconnect are only used for runtime, not for
>>>>>>> system
>>>>>>> suspend. Would you be open to adding wake on connect as well for
>>>>>>> system
>>>>>>> suspend? This should help enable use cases like plugging in a
>>>>>>> closed laptop
>>>>>>> to a dock (which works on Windows).
>>>>>>
>>>>>> Don't we already have a similar for all usb4_portX devices? That
>>>>>> does not
>>>>>> work for you?
>>>>>>
>>>>>
>>>>> I think that will functionally work - but I'll double check.
>>>>>
>>>>> However usb_portX power/wakeup defaults are 'disabled' so this
>>>>> would need a
>>>>> udev rule. Could we set the kernel default for those to 'enabled'
>>>>> instead?
>>>>
>>>> No because that would trigger wakeup each time you unplug/plug and
>>>> this is
>>>> certainly not good if you close the lid, unplug from dock and throw the
>>>> laptop to your backpack. Chrome uses this with "dark resume" so if
>>>> this is
>>>> supported by the userspace then it can also enable these.
>>>
>>> Ahhh. I was thinking specifically with wake on connect that's not a
>>> problem, but the sysfs knob for the port changes both wake on connect
>>> and
>>> wake on disconnect.
>>>
>>> Is there actually a use case for chrome with wake on disconnect? IE
>>> if we
>>> didn't turn on wake on disconnect but defaulted to wake on connect would
>>> things be OK? Or made the sysfs knob control only wake on disconnect?
>>
>> Good guestion - I don't know ;-) The Chrome folks wanted this so I
>> suppose
>> their usecase is specifically that dark resume and I think that's when
>> you
>> unplug a device so disconnect. Not so sure about wake on connect.
>
> I found the original patch from Rajat [1].
>
> Rajat, any comments? Could you loop in the right people from the Chrome
> side to ask? I think my "preference" would be that we make "wake on
> connect" always enabled and then let the sysfs knob control "wake on
> disconnect".
>
> [1] https://lore.kernel.org/linux-usb/20221101115042.248187-1-
> rajat.khandelwal@intel.com/
Oh Rajat's email bounced. The only person I know that I've worked on
wakeup related stuff is Raul. I'll add him.
Mika, Raul,
Could you pull in current Chrome people from Intel and Google that could
comment here?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Wake on connect / wake on disconnect
2025-04-04 16:20 ` Mario Limonciello
@ 2025-04-04 16:55 ` Raul Rangel
2025-04-07 5:55 ` Mika Westerberg
0 siblings, 1 reply; 14+ messages in thread
From: Raul Rangel @ 2025-04-04 16:55 UTC (permalink / raw)
To: Mario Limonciello, Opal Voravootivat
Cc: Mika Westerberg, open list:USB XHCI DRIVER, Gong, Richard
On Fri, Apr 4, 2025 at 10:20 AM Mario Limonciello <superm1@kernel.org> wrote:
>
>
>
> On 4/4/25 11:16, Mario Limonciello wrote:
> >
> >
> > On 4/4/25 11:10, Mika Westerberg wrote:
> >> On Fri, Apr 04, 2025 at 10:03:18AM -0500, Mario Limonciello wrote:
> >>> On 4/4/2025 6:53 AM, Mika Westerberg wrote:
> >>>> On Fri, Apr 04, 2025 at 06:47:31AM -0500, Mario Limonciello wrote:
> >>>>> On 4/4/25 01:02, Mika Westerberg wrote:
> >>>>>> Hi Mario,
> >>>>>>
> >>>>>> On Thu, Apr 03, 2025 at 01:12:07PM -0500, Mario Limonciello wrote:
> >>>>>>> Mika,
> >>>>>>>
> >>>>>>> Recently there are some conversations about wake-up from connect/
> >>>>>>> disconnect
> >>>>>>> happening and I wanted to get some background from you about the
> >>>>>>> current
> >>>>>>> policy set in tb_switch_suspend().
> >>>>>>>
> >>>>>>> Wake on connect and disconnect are only used for runtime, not for
> >>>>>>> system
> >>>>>>> suspend. Would you be open to adding wake on connect as well for
> >>>>>>> system
> >>>>>>> suspend? This should help enable use cases like plugging in a
> >>>>>>> closed laptop
> >>>>>>> to a dock (which works on Windows).
> >>>>>>
> >>>>>> Don't we already have a similar for all usb4_portX devices? That
> >>>>>> does not
> >>>>>> work for you?
> >>>>>>
> >>>>>
> >>>>> I think that will functionally work - but I'll double check.
> >>>>>
> >>>>> However usb_portX power/wakeup defaults are 'disabled' so this
> >>>>> would need a
> >>>>> udev rule. Could we set the kernel default for those to 'enabled'
> >>>>> instead?
> >>>>
> >>>> No because that would trigger wakeup each time you unplug/plug and
> >>>> this is
> >>>> certainly not good if you close the lid, unplug from dock and throw the
> >>>> laptop to your backpack. Chrome uses this with "dark resume" so if
> >>>> this is
> >>>> supported by the userspace then it can also enable these.
> >>>
> >>> Ahhh. I was thinking specifically with wake on connect that's not a
> >>> problem, but the sysfs knob for the port changes both wake on connect
> >>> and
> >>> wake on disconnect.
> >>>
> >>> Is there actually a use case for chrome with wake on disconnect? IE
> >>> if we
> >>> didn't turn on wake on disconnect but defaulted to wake on connect would
> >>> things be OK? Or made the sysfs knob control only wake on disconnect?
> >>
> >> Good guestion - I don't know ;-) The Chrome folks wanted this so I
> >> suppose
> >> their usecase is specifically that dark resume and I think that's when
> >> you
> >> unplug a device so disconnect. Not so sure about wake on connect.
> >
> > I found the original patch from Rajat [1].
> >
> > Rajat, any comments? Could you loop in the right people from the Chrome
> > side to ask? I think my "preference" would be that we make "wake on
> > connect" always enabled and then let the sysfs knob control "wake on
> > disconnect".
> >
> > [1] https://lore.kernel.org/linux-usb/20221101115042.248187-1-
> > rajat.khandelwal@intel.com/
>
> Oh Rajat's email bounced. The only person I know that I've worked on
> wakeup related stuff is Raul. I'll add him.
>
> Mika, Raul,
>
> Could you pull in current Chrome people from Intel and Google that could
> comment here?
+ Opal who should be able to answer the question regarding wake on
connect/disconnect.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Wake on connect / wake on disconnect
2025-04-04 16:55 ` Raul Rangel
@ 2025-04-07 5:55 ` Mika Westerberg
2025-04-09 17:03 ` Mario Limonciello
0 siblings, 1 reply; 14+ messages in thread
From: Mika Westerberg @ 2025-04-07 5:55 UTC (permalink / raw)
To: Raul Rangel
Cc: Mario Limonciello, Opal Voravootivat, open list:USB XHCI DRIVER,
Gong, Richard, Utkarsh Patel
On Fri, Apr 04, 2025 at 10:55:35AM -0600, Raul Rangel wrote:
> On Fri, Apr 4, 2025 at 10:20 AM Mario Limonciello <superm1@kernel.org> wrote:
> >
> >
> >
> > On 4/4/25 11:16, Mario Limonciello wrote:
> > >
> > >
> > > On 4/4/25 11:10, Mika Westerberg wrote:
> > >> On Fri, Apr 04, 2025 at 10:03:18AM -0500, Mario Limonciello wrote:
> > >>> On 4/4/2025 6:53 AM, Mika Westerberg wrote:
> > >>>> On Fri, Apr 04, 2025 at 06:47:31AM -0500, Mario Limonciello wrote:
> > >>>>> On 4/4/25 01:02, Mika Westerberg wrote:
> > >>>>>> Hi Mario,
> > >>>>>>
> > >>>>>> On Thu, Apr 03, 2025 at 01:12:07PM -0500, Mario Limonciello wrote:
> > >>>>>>> Mika,
> > >>>>>>>
> > >>>>>>> Recently there are some conversations about wake-up from connect/
> > >>>>>>> disconnect
> > >>>>>>> happening and I wanted to get some background from you about the
> > >>>>>>> current
> > >>>>>>> policy set in tb_switch_suspend().
> > >>>>>>>
> > >>>>>>> Wake on connect and disconnect are only used for runtime, not for
> > >>>>>>> system
> > >>>>>>> suspend. Would you be open to adding wake on connect as well for
> > >>>>>>> system
> > >>>>>>> suspend? This should help enable use cases like plugging in a
> > >>>>>>> closed laptop
> > >>>>>>> to a dock (which works on Windows).
> > >>>>>>
> > >>>>>> Don't we already have a similar for all usb4_portX devices? That
> > >>>>>> does not
> > >>>>>> work for you?
> > >>>>>>
> > >>>>>
> > >>>>> I think that will functionally work - but I'll double check.
> > >>>>>
> > >>>>> However usb_portX power/wakeup defaults are 'disabled' so this
> > >>>>> would need a
> > >>>>> udev rule. Could we set the kernel default for those to 'enabled'
> > >>>>> instead?
> > >>>>
> > >>>> No because that would trigger wakeup each time you unplug/plug and
> > >>>> this is
> > >>>> certainly not good if you close the lid, unplug from dock and throw the
> > >>>> laptop to your backpack. Chrome uses this with "dark resume" so if
> > >>>> this is
> > >>>> supported by the userspace then it can also enable these.
> > >>>
> > >>> Ahhh. I was thinking specifically with wake on connect that's not a
> > >>> problem, but the sysfs knob for the port changes both wake on connect
> > >>> and
> > >>> wake on disconnect.
> > >>>
> > >>> Is there actually a use case for chrome with wake on disconnect? IE
> > >>> if we
> > >>> didn't turn on wake on disconnect but defaulted to wake on connect would
> > >>> things be OK? Or made the sysfs knob control only wake on disconnect?
> > >>
> > >> Good guestion - I don't know ;-) The Chrome folks wanted this so I
> > >> suppose
> > >> their usecase is specifically that dark resume and I think that's when
> > >> you
> > >> unplug a device so disconnect. Not so sure about wake on connect.
> > >
> > > I found the original patch from Rajat [1].
> > >
> > > Rajat, any comments? Could you loop in the right people from the Chrome
> > > side to ask? I think my "preference" would be that we make "wake on
> > > connect" always enabled and then let the sysfs knob control "wake on
> > > disconnect".
> > >
> > > [1] https://lore.kernel.org/linux-usb/20221101115042.248187-1-
> > > rajat.khandelwal@intel.com/
> >
> > Oh Rajat's email bounced. The only person I know that I've worked on
> > wakeup related stuff is Raul. I'll add him.
> >
> > Mika, Raul,
> >
> > Could you pull in current Chrome people from Intel and Google that could
> > comment here?
>
> + Opal who should be able to answer the question regarding wake on
> connect/disconnect.
Added Utkarsh from Intel side.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Wake on connect / wake on disconnect
2025-04-07 5:55 ` Mika Westerberg
@ 2025-04-09 17:03 ` Mario Limonciello
2025-04-09 17:24 ` Raul Rangel
2025-04-10 4:27 ` Mika Westerberg
0 siblings, 2 replies; 14+ messages in thread
From: Mario Limonciello @ 2025-04-09 17:03 UTC (permalink / raw)
To: Mika Westerberg, Raul Rangel
Cc: Opal Voravootivat, open list:USB XHCI DRIVER, Gong, Richard,
Utkarsh Patel
On 4/7/2025 12:55 AM, Mika Westerberg wrote:
> On Fri, Apr 04, 2025 at 10:55:35AM -0600, Raul Rangel wrote:
>> On Fri, Apr 4, 2025 at 10:20 AM Mario Limonciello <superm1@kernel.org> wrote:
>>>
>>>
>>>
>>> On 4/4/25 11:16, Mario Limonciello wrote:
>>>>
>>>>
>>>> On 4/4/25 11:10, Mika Westerberg wrote:
>>>>> On Fri, Apr 04, 2025 at 10:03:18AM -0500, Mario Limonciello wrote:
>>>>>> On 4/4/2025 6:53 AM, Mika Westerberg wrote:
>>>>>>> On Fri, Apr 04, 2025 at 06:47:31AM -0500, Mario Limonciello wrote:
>>>>>>>> On 4/4/25 01:02, Mika Westerberg wrote:
>>>>>>>>> Hi Mario,
>>>>>>>>>
>>>>>>>>> On Thu, Apr 03, 2025 at 01:12:07PM -0500, Mario Limonciello wrote:
>>>>>>>>>> Mika,
>>>>>>>>>>
>>>>>>>>>> Recently there are some conversations about wake-up from connect/
>>>>>>>>>> disconnect
>>>>>>>>>> happening and I wanted to get some background from you about the
>>>>>>>>>> current
>>>>>>>>>> policy set in tb_switch_suspend().
>>>>>>>>>>
>>>>>>>>>> Wake on connect and disconnect are only used for runtime, not for
>>>>>>>>>> system
>>>>>>>>>> suspend. Would you be open to adding wake on connect as well for
>>>>>>>>>> system
>>>>>>>>>> suspend? This should help enable use cases like plugging in a
>>>>>>>>>> closed laptop
>>>>>>>>>> to a dock (which works on Windows).
>>>>>>>>>
>>>>>>>>> Don't we already have a similar for all usb4_portX devices? That
>>>>>>>>> does not
>>>>>>>>> work for you?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I think that will functionally work - but I'll double check.
>>>>>>>>
>>>>>>>> However usb_portX power/wakeup defaults are 'disabled' so this
>>>>>>>> would need a
>>>>>>>> udev rule. Could we set the kernel default for those to 'enabled'
>>>>>>>> instead?
>>>>>>>
>>>>>>> No because that would trigger wakeup each time you unplug/plug and
>>>>>>> this is
>>>>>>> certainly not good if you close the lid, unplug from dock and throw the
>>>>>>> laptop to your backpack. Chrome uses this with "dark resume" so if
>>>>>>> this is
>>>>>>> supported by the userspace then it can also enable these.
>>>>>>
>>>>>> Ahhh. I was thinking specifically with wake on connect that's not a
>>>>>> problem, but the sysfs knob for the port changes both wake on connect
>>>>>> and
>>>>>> wake on disconnect.
>>>>>>
>>>>>> Is there actually a use case for chrome with wake on disconnect? IE
>>>>>> if we
>>>>>> didn't turn on wake on disconnect but defaulted to wake on connect would
>>>>>> things be OK? Or made the sysfs knob control only wake on disconnect?
>>>>>
>>>>> Good guestion - I don't know ;-) The Chrome folks wanted this so I
>>>>> suppose
>>>>> their usecase is specifically that dark resume and I think that's when
>>>>> you
>>>>> unplug a device so disconnect. Not so sure about wake on connect.
>>>>
>>>> I found the original patch from Rajat [1].
>>>>
>>>> Rajat, any comments? Could you loop in the right people from the Chrome
>>>> side to ask? I think my "preference" would be that we make "wake on
>>>> connect" always enabled and then let the sysfs knob control "wake on
>>>> disconnect".
>>>>
>>>> [1] https://lore.kernel.org/linux-usb/20221101115042.248187-1-
>>>> rajat.khandelwal@intel.com/
>>>
>>> Oh Rajat's email bounced. The only person I know that I've worked on
>>> wakeup related stuff is Raul. I'll add him.
>>>
>>> Mika, Raul,
>>>
>>> Could you pull in current Chrome people from Intel and Google that could
>>> comment here?
>>
>> + Opal who should be able to answer the question regarding wake on
>> connect/disconnect.
>
> Added Utkarsh from Intel side.
I had another look at usb4_port.c the flows used. This is the call path:
tb_switch_suspend()
->tb_switch_set_wake()
->->usb4_switch_set_wake()
The flags for wakeup policy are set in tb_switch_suspend() and then
passed as arguments down to usb4_switch_set_wake(). This enumerates
whether wake is set for any usb4_port device and applies the flags to
that device.
So AFAICT that means that even on ChromeOS there won't be a wake on
connect or wake on disconnect event for suspend/resume no matter what
the sysfs files for each port are set to.
In summary; my ask is whether we can do this:
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 6a2116cbb06f9..f2f6a085a742b 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -3599,6 +3599,7 @@ void tb_switch_suspend(struct tb_switch *sw, bool
runtime)
flags |= TB_WAKE_ON_USB4;
flags |= TB_WAKE_ON_USB3 | TB_WAKE_ON_PCIE | TB_WAKE_ON_DP;
} else if (device_may_wakeup(&sw->dev)) {
+ flags |= TB_WAKE_ON_CONNECT;
flags |= TB_WAKE_ON_USB4 | TB_WAKE_ON_USB3 |
TB_WAKE_ON_PCIE;
}
That would allow the use case of "plug in a closed laptop to a dock" and
it wakes up.
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: Wake on connect / wake on disconnect
2025-04-09 17:03 ` Mario Limonciello
@ 2025-04-09 17:24 ` Raul Rangel
2025-04-10 4:27 ` Mika Westerberg
1 sibling, 0 replies; 14+ messages in thread
From: Raul Rangel @ 2025-04-09 17:24 UTC (permalink / raw)
To: Mario Limonciello, Subrata Banik
Cc: Mika Westerberg, Opal Voravootivat, open list:USB XHCI DRIVER,
Gong, Richard, Utkarsh Patel
On Wed, Apr 9, 2025 at 11:03 AM Mario Limonciello <superm1@kernel.org> wrote:
>
> On 4/7/2025 12:55 AM, Mika Westerberg wrote:
> > On Fri, Apr 04, 2025 at 10:55:35AM -0600, Raul Rangel wrote:
> >> On Fri, Apr 4, 2025 at 10:20 AM Mario Limonciello <superm1@kernel.org> wrote:
> >>>
> >>>
> >>>
> >>> On 4/4/25 11:16, Mario Limonciello wrote:
> >>>>
> >>>>
> >>>> On 4/4/25 11:10, Mika Westerberg wrote:
> >>>>> On Fri, Apr 04, 2025 at 10:03:18AM -0500, Mario Limonciello wrote:
> >>>>>> On 4/4/2025 6:53 AM, Mika Westerberg wrote:
> >>>>>>> On Fri, Apr 04, 2025 at 06:47:31AM -0500, Mario Limonciello wrote:
> >>>>>>>> On 4/4/25 01:02, Mika Westerberg wrote:
> >>>>>>>>> Hi Mario,
> >>>>>>>>>
> >>>>>>>>> On Thu, Apr 03, 2025 at 01:12:07PM -0500, Mario Limonciello wrote:
> >>>>>>>>>> Mika,
> >>>>>>>>>>
> >>>>>>>>>> Recently there are some conversations about wake-up from connect/
> >>>>>>>>>> disconnect
> >>>>>>>>>> happening and I wanted to get some background from you about the
> >>>>>>>>>> current
> >>>>>>>>>> policy set in tb_switch_suspend().
> >>>>>>>>>>
> >>>>>>>>>> Wake on connect and disconnect are only used for runtime, not for
> >>>>>>>>>> system
> >>>>>>>>>> suspend. Would you be open to adding wake on connect as well for
> >>>>>>>>>> system
> >>>>>>>>>> suspend? This should help enable use cases like plugging in a
> >>>>>>>>>> closed laptop
> >>>>>>>>>> to a dock (which works on Windows).
> >>>>>>>>>
> >>>>>>>>> Don't we already have a similar for all usb4_portX devices? That
> >>>>>>>>> does not
> >>>>>>>>> work for you?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I think that will functionally work - but I'll double check.
> >>>>>>>>
> >>>>>>>> However usb_portX power/wakeup defaults are 'disabled' so this
> >>>>>>>> would need a
> >>>>>>>> udev rule. Could we set the kernel default for those to 'enabled'
> >>>>>>>> instead?
> >>>>>>>
> >>>>>>> No because that would trigger wakeup each time you unplug/plug and
> >>>>>>> this is
> >>>>>>> certainly not good if you close the lid, unplug from dock and throw the
> >>>>>>> laptop to your backpack. Chrome uses this with "dark resume" so if
> >>>>>>> this is
> >>>>>>> supported by the userspace then it can also enable these.
> >>>>>>
> >>>>>> Ahhh. I was thinking specifically with wake on connect that's not a
> >>>>>> problem, but the sysfs knob for the port changes both wake on connect
> >>>>>> and
> >>>>>> wake on disconnect.
> >>>>>>
> >>>>>> Is there actually a use case for chrome with wake on disconnect? IE
> >>>>>> if we
> >>>>>> didn't turn on wake on disconnect but defaulted to wake on connect would
> >>>>>> things be OK? Or made the sysfs knob control only wake on disconnect?
> >>>>>
> >>>>> Good guestion - I don't know ;-) The Chrome folks wanted this so I
> >>>>> suppose
> >>>>> their usecase is specifically that dark resume and I think that's when
> >>>>> you
> >>>>> unplug a device so disconnect. Not so sure about wake on connect.
> >>>>
> >>>> I found the original patch from Rajat [1].
> >>>>
> >>>> Rajat, any comments? Could you loop in the right people from the Chrome
> >>>> side to ask? I think my "preference" would be that we make "wake on
> >>>> connect" always enabled and then let the sysfs knob control "wake on
> >>>> disconnect".
> >>>>
> >>>> [1] https://lore.kernel.org/linux-usb/20221101115042.248187-1-
> >>>> rajat.khandelwal@intel.com/
> >>>
> >>> Oh Rajat's email bounced. The only person I know that I've worked on
> >>> wakeup related stuff is Raul. I'll add him.
> >>>
> >>> Mika, Raul,
> >>>
> >>> Could you pull in current Chrome people from Intel and Google that could
> >>> comment here?
> >>
> >> + Opal who should be able to answer the question regarding wake on
> >> connect/disconnect.
> >
> > Added Utkarsh from Intel side.
>
> I had another look at usb4_port.c the flows used. This is the call path:
>
> tb_switch_suspend()
> ->tb_switch_set_wake()
> ->->usb4_switch_set_wake()
>
> The flags for wakeup policy are set in tb_switch_suspend() and then
> passed as arguments down to usb4_switch_set_wake(). This enumerates
> whether wake is set for any usb4_port device and applies the flags to
> that device.
>
> So AFAICT that means that even on ChromeOS there won't be a wake on
> connect or wake on disconnect event for suspend/resume no matter what
> the sysfs files for each port are set to.
>
> In summary; my ask is whether we can do this:
>
> diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
> index 6a2116cbb06f9..f2f6a085a742b 100644
> --- a/drivers/thunderbolt/switch.c
> +++ b/drivers/thunderbolt/switch.c
> @@ -3599,6 +3599,7 @@ void tb_switch_suspend(struct tb_switch *sw, bool
> runtime)
> flags |= TB_WAKE_ON_USB4;
> flags |= TB_WAKE_ON_USB3 | TB_WAKE_ON_PCIE | TB_WAKE_ON_DP;
> } else if (device_may_wakeup(&sw->dev)) {
> + flags |= TB_WAKE_ON_CONNECT;
> flags |= TB_WAKE_ON_USB4 | TB_WAKE_ON_USB3 |
> TB_WAKE_ON_PCIE;
> }
>
> That would allow the use case of "plug in a closed laptop to a dock" and
> it wakes up.
+ Subrata since they might have more context on the TB stack.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Wake on connect / wake on disconnect
2025-04-09 17:03 ` Mario Limonciello
2025-04-09 17:24 ` Raul Rangel
@ 2025-04-10 4:27 ` Mika Westerberg
1 sibling, 0 replies; 14+ messages in thread
From: Mika Westerberg @ 2025-04-10 4:27 UTC (permalink / raw)
To: Mario Limonciello
Cc: Raul Rangel, Opal Voravootivat, open list:USB XHCI DRIVER,
Gong, Richard, Utkarsh Patel
On Wed, Apr 09, 2025 at 12:03:52PM -0500, Mario Limonciello wrote:
> On 4/7/2025 12:55 AM, Mika Westerberg wrote:
> > On Fri, Apr 04, 2025 at 10:55:35AM -0600, Raul Rangel wrote:
> > > On Fri, Apr 4, 2025 at 10:20 AM Mario Limonciello <superm1@kernel.org> wrote:
> > > >
> > > >
> > > >
> > > > On 4/4/25 11:16, Mario Limonciello wrote:
> > > > >
> > > > >
> > > > > On 4/4/25 11:10, Mika Westerberg wrote:
> > > > > > On Fri, Apr 04, 2025 at 10:03:18AM -0500, Mario Limonciello wrote:
> > > > > > > On 4/4/2025 6:53 AM, Mika Westerberg wrote:
> > > > > > > > On Fri, Apr 04, 2025 at 06:47:31AM -0500, Mario Limonciello wrote:
> > > > > > > > > On 4/4/25 01:02, Mika Westerberg wrote:
> > > > > > > > > > Hi Mario,
> > > > > > > > > >
> > > > > > > > > > On Thu, Apr 03, 2025 at 01:12:07PM -0500, Mario Limonciello wrote:
> > > > > > > > > > > Mika,
> > > > > > > > > > >
> > > > > > > > > > > Recently there are some conversations about wake-up from connect/
> > > > > > > > > > > disconnect
> > > > > > > > > > > happening and I wanted to get some background from you about the
> > > > > > > > > > > current
> > > > > > > > > > > policy set in tb_switch_suspend().
> > > > > > > > > > >
> > > > > > > > > > > Wake on connect and disconnect are only used for runtime, not for
> > > > > > > > > > > system
> > > > > > > > > > > suspend. Would you be open to adding wake on connect as well for
> > > > > > > > > > > system
> > > > > > > > > > > suspend? This should help enable use cases like plugging in a
> > > > > > > > > > > closed laptop
> > > > > > > > > > > to a dock (which works on Windows).
> > > > > > > > > >
> > > > > > > > > > Don't we already have a similar for all usb4_portX devices? That
> > > > > > > > > > does not
> > > > > > > > > > work for you?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I think that will functionally work - but I'll double check.
> > > > > > > > >
> > > > > > > > > However usb_portX power/wakeup defaults are 'disabled' so this
> > > > > > > > > would need a
> > > > > > > > > udev rule. Could we set the kernel default for those to 'enabled'
> > > > > > > > > instead?
> > > > > > > >
> > > > > > > > No because that would trigger wakeup each time you unplug/plug and
> > > > > > > > this is
> > > > > > > > certainly not good if you close the lid, unplug from dock and throw the
> > > > > > > > laptop to your backpack. Chrome uses this with "dark resume" so if
> > > > > > > > this is
> > > > > > > > supported by the userspace then it can also enable these.
> > > > > > >
> > > > > > > Ahhh. I was thinking specifically with wake on connect that's not a
> > > > > > > problem, but the sysfs knob for the port changes both wake on connect
> > > > > > > and
> > > > > > > wake on disconnect.
> > > > > > >
> > > > > > > Is there actually a use case for chrome with wake on disconnect? IE
> > > > > > > if we
> > > > > > > didn't turn on wake on disconnect but defaulted to wake on connect would
> > > > > > > things be OK? Or made the sysfs knob control only wake on disconnect?
> > > > > >
> > > > > > Good guestion - I don't know ;-) The Chrome folks wanted this so I
> > > > > > suppose
> > > > > > their usecase is specifically that dark resume and I think that's when
> > > > > > you
> > > > > > unplug a device so disconnect. Not so sure about wake on connect.
> > > > >
> > > > > I found the original patch from Rajat [1].
> > > > >
> > > > > Rajat, any comments? Could you loop in the right people from the Chrome
> > > > > side to ask? I think my "preference" would be that we make "wake on
> > > > > connect" always enabled and then let the sysfs knob control "wake on
> > > > > disconnect".
> > > > >
> > > > > [1] https://lore.kernel.org/linux-usb/20221101115042.248187-1-
> > > > > rajat.khandelwal@intel.com/
> > > >
> > > > Oh Rajat's email bounced. The only person I know that I've worked on
> > > > wakeup related stuff is Raul. I'll add him.
> > > >
> > > > Mika, Raul,
> > > >
> > > > Could you pull in current Chrome people from Intel and Google that could
> > > > comment here?
> > >
> > > + Opal who should be able to answer the question regarding wake on
> > > connect/disconnect.
> >
> > Added Utkarsh from Intel side.
>
> I had another look at usb4_port.c the flows used. This is the call path:
>
> tb_switch_suspend()
> ->tb_switch_set_wake()
> ->->usb4_switch_set_wake()
>
> The flags for wakeup policy are set in tb_switch_suspend() and then passed
> as arguments down to usb4_switch_set_wake(). This enumerates whether wake
> is set for any usb4_port device and applies the flags to that device.
Indeed. So this actually never worked.
> So AFAICT that means that even on ChromeOS there won't be a wake on connect
> or wake on disconnect event for suspend/resume no matter what the sysfs
> files for each port are set to.
>
> In summary; my ask is whether we can do this:
>
> diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
> index 6a2116cbb06f9..f2f6a085a742b 100644
> --- a/drivers/thunderbolt/switch.c
> +++ b/drivers/thunderbolt/switch.c
> @@ -3599,6 +3599,7 @@ void tb_switch_suspend(struct tb_switch *sw, bool
> runtime)
> flags |= TB_WAKE_ON_USB4;
> flags |= TB_WAKE_ON_USB3 | TB_WAKE_ON_PCIE | TB_WAKE_ON_DP;
> } else if (device_may_wakeup(&sw->dev)) {
> + flags |= TB_WAKE_ON_CONNECT;
> flags |= TB_WAKE_ON_USB4 | TB_WAKE_ON_USB3 |
> TB_WAKE_ON_PCIE;
> }
>
> That would allow the use case of "plug in a closed laptop to a dock" and it
> wakes up.
I think we should set both here. Someone will want the unplug to behave the
same and at that point it is hard to change anymore to avoid breaking
things. Then it is up to the userspace to enable per USB4 port, and deal
with (e.g dark resume).
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Wake on connect / wake on disconnect
[not found] <35b9b1e658eb233b0bde45e0f30ba4646e1de858.camel@ieee.org>
@ 2025-06-23 15:46 ` Mario Limonciello
0 siblings, 0 replies; 14+ messages in thread
From: Mario Limonciello @ 2025-06-23 15:46 UTC (permalink / raw)
To: Cristian Cocos, mika.westerberg
Cc: Richard.Gong, linux-usb, puthik, rrangel, utkarsh.h.patel
On 6/23/25 10:45 AM, Cristian Cocos wrote:
> Any chance this patch will find its way in kernel 6.16? I recall having
> no problems rebooting my laptop with the lid closed with older kernels;
> current troubles started with kernels 6.12 or 6.13 (or thereabouts).
>
> Thank you!
Hello,
The wake on connect/disconnect patches landed in 6.16-rc1. There was a
regression identified however the fix is in the -fixes branch and should
land before 6.16 final.
That being said; I don't expect WoC/WoD patches are going to affect lid
behavior. You might have a different problem?
Thanks,
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2025-06-23 15:46 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-03 18:12 Wake on connect / wake on disconnect Mario Limonciello
2025-04-04 6:02 ` Mika Westerberg
2025-04-04 11:47 ` Mario Limonciello
2025-04-04 11:53 ` Mika Westerberg
2025-04-04 15:03 ` Mario Limonciello
2025-04-04 16:10 ` Mika Westerberg
2025-04-04 16:16 ` Mario Limonciello
2025-04-04 16:20 ` Mario Limonciello
2025-04-04 16:55 ` Raul Rangel
2025-04-07 5:55 ` Mika Westerberg
2025-04-09 17:03 ` Mario Limonciello
2025-04-09 17:24 ` Raul Rangel
2025-04-10 4:27 ` Mika Westerberg
[not found] <35b9b1e658eb233b0bde45e0f30ba4646e1de858.camel@ieee.org>
2025-06-23 15:46 ` Mario Limonciello
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).