usb: device_next: hid: add a suspend callback

[fabiobaltieri]

Add an optional suspend callback to let a downstream hid driver be notified of HID suspend and resume events.

[fabiobaltieri]

@jfischer-no using this on an hid device to detect when the host goes into suspend, is this the right thing? Can't quite tell it from the controller apis apparently.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tmon-nordic]

I like this approach better than relying on USB notifications in the application, because here the call is synchronous and therefore the state never gets out-of-sync.

[fabiobaltieri]

I like this approach better than relying on USB notifications in the application, because here the call is synchronous and therefore the state never gets out-of-sync.

Ok... what notifications are you referring to though?

[tmon-nordic]

I like this approach better than relying on USB notifications in the application, because here the call is synchronous and therefore the state never gets out-of-sync.

Ok... what notifications are you referring to though?

zephyr/subsys/usb/device_next/usbd_core.c

Line 154 in df8b43d

usbd_msg_pub_simple(uds_ctx, USBD_MSG_SUSPEND, 0);

and

zephyr/subsys/usb/device_next/usbd_core.c

Line 160 in df8b43d

usbd_msg_pub_simple(uds_ctx, USBD_MSG_RESUME, 0);

[fabiobaltieri]

@tmon-nordic ok but I think USBD_MSG_RESUME and USBD_MSG_SUSPEND are a different thing, that's the first thing I tried to use but it seems like they refer to the whole usb device controller, the ones in this PR and the ones I needed seemingly gets called when the host goes into suspend and stops polling the HID endpoint. I'm using them downstream to control a keyboard underglow and these two works fine. :-)

[tmon-nordic]

@tmon-nordic ok but I think USBD_MSG_RESUME and USBD_MSG_SUSPEND are a different thing

No, they are the same. The difference is that USBD_MSG_RESUME and USBD_MSG_SUSPEND are subject to getting lost due to the IMHO bad design choice of

zephyr/subsys/usb/device_next/usbd_msg.c

Line 38 in df8b43d

if (k_mem_slab_alloc(&usbd_msg_slab, (void **)&m_pkt, K_NO_WAIT)) {

when CONFIG_USBD_MSG_DEFERRED_MODE is not enabled.

[fabiobaltieri]

No, they are the same. The difference is that USBD_MSG_RESUME and USBD_MSG_SUSPEND are subject to getting lost due to the IMHO bad design choice of

Ok very interesting, well, this is cheap enough and works reliably then... Thanks for the pointers.