Peter Chen <peter.chen@xxxxxxxxxxxxx> writes:
> During this API, the deactivation count will be update, and it
> will try to connect or disconnect gadget. It can be used to
> enable functions for gadget.
It's up to Felipe, but I'd like to see answers to the following
questions in this commit message:
* what is a deactivation, when does happen and why?
* what is the problem that it solves?
* who is the intended user of this api?
* what are the constraints of using this api?
It'd also be nice to mention some of these in the code.
> /**
> + * usb_udc_activation_handler - updates udc's deactivation count and
> + * try to connect or disconnect
> + *
> + * @gadget: The gadget which the function is at
> + * @active: the function needs to be active or not
> + *
> + * The composite core calls it when it wants to activate or deactivate
> + * function.
> + */
> +void usb_udc_activation_handler(struct usb_gadget *gadget, bool active)
> +{
> + struct usb_udc *udc = usb_gadget_find_udc(gadget);
> +
> + if (udc) {
> + if (active)
> + udc->deactivations--;
> + else
> + udc->deactivations++;
> + usb_udc_connect_control(udc);
> + }
> +}
> +EXPORT_SYMBOL_GPL(usb_udc_activation_handler);
Since this is exported to the drivers, does it make sense to guard
against deactivations going negative and/or print a warning?
Regards,
--
Alex
--
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
