lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 06 Dec 2021 11:08:42 +1100 From: Benjamin Herrenschmidt <benh@...nel.crashing.org> To: Neal Liu <neal_liu@...eedtech.com>, Felipe Balbi <balbi@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Joel Stanley <joel@....id.au>, Andrew Jeffery <andrew@...id.au>, Cai Huoqing <caihuoqing@...du.com>, Tao Ren <rentao.bupt@...il.com>, Julia Lawall <julia.lawall@...ia.fr>, kernel test robot <lkp@...el.com>, Sasha Levin <sashal@...nel.org>, "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org> Cc: BMC-SW <BMC-SW@...eedtech.com> Subject: Re: [PATCH 2/3] usb: aspeed-vhub: support remote wakeup feature On Thu, 2021-12-02 at 03:03 +0000, Neal Liu wrote: > > > 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.
Powered by blists - more mailing lists