Thread (14 messages) 14 messages, 2 authors, 2021-12-06

[PATCH 2/3] usb: aspeed-vhub: support remote wakeup feature

flat view

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2021-12-06 00:14:46
Also in: linux-arm-kernel, linux-usb, lkml

On Thu, 2021-12-02 at 03:03 +0000, Neal Liu wrote:
quoted
Let's me describe more details for our hardware behavior and hope you
understand.

HUB00[3]: MANUAL_REMOTE_WAKEUP
HUB00[4]: AUTO_REMOTE_WAKEUP

Set HUB00[3] implies USB device will do remote wakeup if any write
command to vhub register.
Set HUB00[4] implies USB device will do remote wakeup. It can only be
set in suspend state.

For current design, d->wakeup_en only controls whether HUB00[4] can
be set through usb_gadget_ops.wakeup().
If some applications (take KVM as example) want to wakeup host by
sending a packet, it won't go through sb_gadget_ops.wakeup().
We enable HUB00[3] to fix this problem. It won't override above
mentioned behavior.
If host has enabled the USB_DEVICE_REMOTE_WAKEUP feature, it has 2
ways to wakeup host.
1. set srp 1 (/sys/device/platform/xxxxxxxxx/udc/xxxxxx/srp)
2. emulated device has activity
If host has disabled the USB_DEVICE_REMOTE_WAKEUP feature, these 2
ways still cannot wakeup host even if USB bus is in resume state.
Thanks
So what you are saying is that currently, the various gadgets aren't
calling usb_gadget_wakeup() ?

Ie. it should be a gadget policy to decide when to wake-up I suppose,
but it's true that nothing in the core nor the existing gadgets seem to
handle that.

I think what you propose is a band-aid. The real problem is that the
gadget drivers should trigger wakeups (or the core should do so on
activity).

That said, for now, I don't object to adding that "auto" bit, but I
would prefer if that behaviour was use configurable.

Cheers,
Ben.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help