On Thu, Oct 27, 2016 at 03:02:30PM -0700, Brian Norris wrote:
> In reading through a USB interface driver, I noticed that it called
> usb_{get,put}_dev() in its probe() and disconnect() methods. This seemed
> unnecessary, but a look at the comments here matched the usage.
>
> USB interface devices seem to be well covered by the parent/child
> relationship of the device model, and so it should be unnecessary for a
> child device to grab a refcount on its parent device.
>
> Signed-off-by: Brian Norris <computersforpeace@xxxxxxxxx>
Yes, usb_device is parent of usb_interface and device core does "parent
= get_device(dev->parent);" as part of device_add() when registering new
interfaces.
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
> ---
> This reflects my understanding (and testing), as well as the majority of usage
> -- there are *very* few interface drivers that actually call usb_get_dev(). If
> I'm wrong, please feel free to tell me so! But I thought patching the
> documentation would be the best way to solicit a response :)
>
> drivers/usb/core/usb.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> index 592151461017..0ba7e070f04e 100644
> --- a/drivers/usb/core/usb.c
> +++ b/drivers/usb/core/usb.c
> @@ -539,9 +539,9 @@ EXPORT_SYMBOL_GPL(usb_alloc_dev);
> *
> * Each live reference to a device should be refcounted.
> *
> - * Drivers for USB interfaces should normally record such references in
> - * their probe() methods, when they bind to an interface, and release
> - * them by calling usb_put_dev(), in their disconnect() methods.
> + * The device driver core automatically handles this refcounting for USB
> + * interface drivers, but this API can be used for non-parent/child
> + * relationships.
> *
> * Return: A pointer to the device with the incremented reference counter.
> */
> --
> 2.8.0.rc3.226.g39d4020
>
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
