>> @@ -5529,8 +5528,7 @@ static int usb_reset_and_verify_device(struct >> usb_device *udev) >> dev_err(&udev->dev, >> "can't restore configuration #%d (error=%d)\n", >> udev->actconfig->desc.bConfigurationValue, ret); >> - mutex_unlock(hcd->bandwidth_mutex); >> - goto re_enumerate; >> + goto unlock; >> } >> mutex_unlock(hcd->bandwidth_mutex); >> usb_set_device_state(udev, USB_STATE_CONFIGURED); >> @@ -5583,6 +5581,8 @@ static int usb_reset_and_verify_device(struct >> usb_device *udev) >> udev->bos = bos; >> return 0; >> >> +unlock: >> + mutex_unlock(hcd->bandwidth_mutex); > > This makes it harder for the reader,
I am curious if the view on the preferred code readability can be clarified further. > as the mutex_unlock() is now far below the block > of code that's protected by the lock. I got an other software development opinion for this aspect. Can the label be clear enough about the shown purpose already? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
