Make driver init() function optional#3565
Conversation
Handle init() like deinit()
There was a problem hiding this comment.
Pull request overview
This PR makes the host class-driver init() callback optional (similar to how deinit() is already treated), allowing application-provided host drivers to omit an init routine when it isn’t needed.
Changes:
- Guard host driver initialization so
driver->init()is called only when non-NULL. - Update architecture documentation to list
init()as an optional class driver function.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
src/host/usbh.c |
Skips calling class driver init() when the callback pointer is NULL. |
docs/reference/architecture.rst |
Moves init() from “Required” to “Optional” in the class driver interface description. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (driver != NULL) { | ||
| if (driver != NULL && driver->init) { | ||
| TU_LOG_USBH("%s init\r\n", driver->name); | ||
| driver->init(); |
There was a problem hiding this comment.
driver->init() returns bool (see usbh_class_driver_t), but its return value is ignored. Several built-in class init functions can return false on internal TU_ASSERT failures, so tuh_rhport_init() may still succeed even though a class driver failed to initialize. Consider asserting/propagating the init result (e.g., fail tuh_rhport_init() if any present init() returns false).
| driver->init(); | |
| bool inited = driver->init(); | |
| TU_ASSERT(inited); | |
| if (!inited) { | |
| return false; | |
| } |
|
|
||
| **Optional Functions**: | ||
| - ``init()``: Initialize class driver |
There was a problem hiding this comment.
This section still references device-side behavior ("See usbd.c"), where init() is required (the stack asserts driver->init). Moving init() to Optional Functions here makes the documentation inaccurate unless the device-side requirement is also relaxed, or the doc is clarified/split for host vs device class driver interfaces.
| **Optional Functions**: | |
| - ``init()``: Initialize class driver | |
| - ``init()``: Initialize class driver | |
| **Optional Functions**: |
There was a problem hiding this comment.
Let's see if I'm a good copilot...
Size Difference ReportBecause TinyUSB code size varies by port and configuration, the metrics below represent the averaged totals across all example builds. Note: If there is no change, only one value is shown. Changes >1% in sizeNo entries. Changes <1% in size
No changes
|
|
Thank you |
|
late response, deinit() is optional (since it may be never called) but init() is mandatory. just have an do nothing init() if you don't use them. |
I got that part, my patch was just a small proposal to change that and make it non-mandatory, to simplify people's life.
Yes |
|
I would not mind merging this, but it increases the code size (extra compare statement) for the default (no-app driver), which is 90% the case of usage. |
|
Ok, not a problem, it was just a suggestion. I've no problem if you don't like it. That said, I do not really understand how the communication works in this project :) |
Make init() class driver optional, like deinit()
In my driver, I don't need any of them.