On Thu, 17 May 2012, Lan Tianyu wrote:
> > Also, you should check to see whether the usb_lock_device() call is
> > really needed. If the caller already owns the lock for the parent hub
> > then you don't need to lock the child -- you don't even need the
> > usb_{get,put}_dev() calls.
> How about this?
> #define usb_get_hub_each_child(hdev, port1, child) \
> for (port1 = 1, child = usb_get_hub_child(hdev, port1); \
> port1 <= hdev->maxchild; child = \
> usb_get_hub_child(hdev, ++port1))
>
> usb_get_hub_child(hdev, port1)
> {
> struct usb_hub *hub = hdev_to_hub(hdev);
> return usb_get_dev(hub->port_data[port1 - 1].child);
> }
>
> For more general, usb_get_hub_child() increases child refcount
> to prevent child from being removed during processing and the caller
> should invoke usb_put_dev() when child will never be used.
Have you looked through the callers to see whether the child's refcount
really needs to be incremented? I think it probably doesn't. (Hint:
If the current code doesn't increment the refcount, that's a good sign
that the new code doesn't need to increment it either.)
Alan Stern
--
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
