On Wed, 28 Mar 2012, Lan Tianyu wrote:
> Move child's pointer to the struct usb_hub_port since the child device
> is directly associated with the port. Provide usb_get_hub_child_device()
> to get child's pointer.
> --- a/drivers/usb/core/devices.c
> +++ b/drivers/usb/core/devices.c
> @@ -590,7 +590,9 @@ static ssize_t usb_device_dump(char __user **buffer, size_t *nbytes,
>
> /* Now look at all of this device's children. */
> for (chix = 0; chix < usbdev->maxchild; chix++) {
> - struct usb_device *childdev = usbdev->children[chix];
> + struct usb_device *childdev;
> + if (usb_get_hub_child_device(usbdev, chix + 1, &childdev) < 0)
> + continue;
>
Whitespace issue: The blank line should come before the new executable
statement, not after it.
> @@ -1475,11 +1477,12 @@ bool usb_device_is_owned(struct usb_device *udev)
>
> static void recursively_mark_NOTATTACHED(struct usb_device *udev)
> {
> + struct usb_hub *hub = hdev_to_hub(udev);
I'm not sure this is good. You are calling hdev_to_hub without knowing
beforehand that udev really is a hub -- in fact, most of the time udev
won't be a hub. The routine wasn't meant to be used that way. Have
you checked that hdev_to_hub won't crash when the argument isn't a hub?
What happens if the active configuration has no interfaces?
> @@ -4147,3 +4151,15 @@ void usb_queue_reset_device(struct usb_interface *iface)
> schedule_work(&iface->reset_ws);
> }
> EXPORT_SYMBOL_GPL(usb_queue_reset_device);
> +
> +int usb_get_hub_child_device(struct usb_device *hdev, int port1,
> + struct usb_device **child)
> +{
> + struct usb_hub *hub = hdev_to_hub(hdev);
> +
> + if (port1 > hdev->maxchild || port1 < 1)
> + return -EINVAL;
> + *child = hub->port_data[port1 - 1].child;
> + return 0;
> +}
This new routine is more complicated that it needs to be. You don't
have to return an error code; none of the callers make use of it.
Just return the child pointer, and return NULL if there's an error.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
