From 1ab40abcdbb2c409372223060078cc2347df2721 Mon Sep 17 00:00:00 2001 From: "Ricardo B. Marliere" Date: Sun, 18 Feb 2024 16:18:12 -0300 Subject: usb: core: constify the struct device_type usage Since commit aed65af1cc2f ("drivers: make device_type const"), the driver core can properly handle constant struct device_type. Move the usb_device_type, usb_if_device_type, usb_ep_device_type and usb_port_device_type variables to be constant structures as well, placing it into read-only memory which can not be modified at runtime. Signed-off-by: Ricardo B. Marliere Link: https://lore.kernel.org/r/20240218-device_cleanup-usb-v1-4-77423c4da262@marliere.net Signed-off-by: Greg Kroah-Hartman --- drivers/usb/core/message.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/usb/core/message.c') diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c index 077dfe48d01c..67316d271596 100644 --- a/drivers/usb/core/message.c +++ b/drivers/usb/core/message.c @@ -1849,7 +1849,7 @@ static int usb_if_uevent(const struct device *dev, struct kobj_uevent_env *env) return 0; } -struct device_type usb_if_device_type = { +const struct device_type usb_if_device_type = { .name = "usb_interface", .release = usb_release_interface, .uevent = usb_if_uevent, -- cgit v1.2.3 From 9f2a3933beeaeead53829d3a7be53770e41e7869 Mon Sep 17 00:00:00 2001 From: Michal Pecio Date: Sun, 18 Feb 2024 09:25:15 +0100 Subject: 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 Link: https://lore.kernel.org/r/20240218092515.7635ff8c@foxbook Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/usb/callbacks.rst | 6 ++++-- drivers/usb/core/message.c | 5 ++++- 2 files changed, 8 insertions(+), 3 deletions(-) (limited to 'drivers/usb/core/message.c') diff --git a/Documentation/driver-api/usb/callbacks.rst b/Documentation/driver-api/usb/callbacks.rst index 2b80cf54bcc3..927da49b8f00 100644 --- a/Documentation/driver-api/usb/callbacks.rst +++ b/Documentation/driver-api/usb/callbacks.rst @@ -99,8 +99,10 @@ The disconnect() callback This callback is a signal to break any connection with an interface. You are not allowed any IO to a device after returning from this callback. You also may not do any other operation that may interfere -with another driver bound the interface, eg. a power management -operation. +with another driver bound to the interface, eg. a power management +operation. Outstanding operations on the device must be completed or +aborted before this callback may return. + If you are called due to a physical disconnection, all your URBs will be killed by usbcore. Note that in this case disconnect will be called some time after the physical disconnection. Thus your driver must be prepared 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. -- cgit v1.2.3