diff options
| author | Michal Pecio <michal.pecio@gmail.com> | 2024-02-18 11:25:15 +0300 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2024-03-02 22:37:14 +0300 |
| commit | 9f2a3933beeaeead53829d3a7be53770e41e7869 (patch) | |
| tree | 67300379e0ad61ff90e711a73f234c056420a185 /drivers/usb/core | |
| parent | be95cc6d71dfd0cba66e3621c65413321b398052 (diff) | |
| download | linux-9f2a3933beeaeead53829d3a7be53770e41e7869.tar.xz | |
USB: document some API requirements on disconnection
A call to usb_set_interface() crashes if the device is deallocated
concurrently, such as due to physical removal or a serious IO error.
It could also interfere with other drivers using the device if the
current driver is unbound before the call is finished.
Document the need to delay driver unbinding until this call returns,
which solves both issues.
Document the same regarding usb_clear_halt(), which is equally known
to be routinely called by drivers.
Explicitly mention finishing pending operations in the documentation
of the driver disconnect callback.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Link: https://lore.kernel.org/r/20240218092515.7635ff8c@foxbook
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/usb/core')
| -rw-r--r-- | drivers/usb/core/message.c | 5 |
1 files changed, 4 insertions, 1 deletions
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c index 67316d271596..d2b2787be409 100644 --- a/drivers/usb/core/message.c +++ b/drivers/usb/core/message.c @@ -1198,6 +1198,8 @@ EXPORT_SYMBOL_GPL(usb_get_status); * same status code used to report a true stall. * * This call is synchronous, and may not be used in an interrupt context. + * If a thread in your driver uses this call, make sure your disconnect() + * method can wait for it to complete. * * Return: Zero on success, or else the status code returned by the * underlying usb_control_msg() call. @@ -1516,7 +1518,8 @@ void usb_enable_interface(struct usb_device *dev, * This call is synchronous, and may not be used in an interrupt context. * Also, drivers must not change altsettings while urbs are scheduled for * endpoints in that interface; all such urbs must first be completed - * (perhaps forced by unlinking). + * (perhaps forced by unlinking). If a thread in your driver uses this call, + * make sure your disconnect() method can wait for it to complete. * * Return: Zero on success, or else the status code returned by the * underlying usb_control_msg() call. |