linux usb gadget驱动详解（三）
本文将对linux4.4.19版本usb gadget源码进行简单分析。鉴于前文反复测试U盘设备驱动，现从linux-4.4.19/drivers/usb/gadget/legacy/mass_storage.c开始分析。
目的是了解U盘设备驱动的工作原理，为啥它能让PC识别成“可移动磁盘”，以及它可以像市面上的U盘一样能读写文件。最后介绍内核gadget框架提供的api，助力实现自定义的USB设备驱动。
#mass_storage.c line:242
/****************************** Some noise ******************************/
static struct usb_composite_driver msg_driver = {
.name = "g_mass_storage",
.dev = &msg_device_desc,
.max_speed = USB_SPEED_SUPER,
.needs_serial = 1,
.strings = dev_strings,
.bind = msg_bind,
.unbind = msg_unbind,
};
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_AUTHOR("Michal Nazarewicz");
MODULE_LICENSE("GPL");
static int __init msg_init(void)
{
return usb_composite_probe(&msg_driver);
}
module_init(msg_init);
static void msg_cleanup(void)
{
if (test_and_clear_bit(0, &msg_registered))
usb_composite_unregister(&msg_driver);
}
module_exit(msg_cleanup);
从上面代码的module_init(msg_init);我们知道，驱动入口在static int __init msg_init(void);其中__init修饰表明这个函数仅在初始化期间使用，在模块被装载之后，它占用的资源就会释放掉。msg_init函数只是糖衣炮弹，真正干活的是usb_composite_probe，这个函数有大来头，在composite.c中实现：
#composite.c line:2198
int usb_composite_probe(struct usb_composite_driver *driver)
{
struct usb_gadget_driver *gadget_driver;
if (!driver || !driver->dev || !driver->bind)
return -EINVAL;
if (!driver->name)
driver->name = "composite";
driver->gadget_driver = composite_driver_template;
gadget_driver = &driver->gadget_driver;
gadget_driver->function = (char *) driver->name;
gadget_driver->driver.name = driver->name;
gadget_driver->max_speed = driver->max_speed;
return usb_gadget_probe_driver(gadget_driver);
}
EXPORT_SYMBOL_GPL(usb_composite_probe);我们先看回来msg_init()函数，它用到了struct usb_composite_driver结构体对象的一个实例——msg_driver：
struct usb_composite_driver {
const char *name;
const struct usb_device_descriptor *dev;
struct usb_gadget_strings **strings;
enum usb_device_speed max_speed;
unsigned needs_serial:1;
int (*bind)(struct usb_composite_dev *cdev);
int (*unbind)(struct usb_composite_dev *);
void (*disconnect)(struct usb_composite_dev *);
/* global suspend hooks */
void (*suspend)(struct usb_composite_dev *);
void (*resume)(struct usb_composite_dev *);
struct usb_gadget_driver gadget_driver;
};
static struct usb_composite_driver msg_driver = {
.name = "g_mass_storage",
.dev = &msg_device_desc,
.max_speed = USB_SPEED_SUPER,
.needs_serial = 1,
.strings = dev_strings,
.bind = msg_bind,
.unbind = msg_unbind,
};这里我们定义了U盘驱动的“名称name”、“设备描述符dev”、“设备的速度”、“字符串描述符”、以及注册bind和unbind回调函数，这些参数和回调函数，最终会在libcomposite.ko驱动（composite.c）中回调。
其中每一个USB设备均有一个设备描述符，设备描述符的字段及其意义参考USB2.0规范的第九章(linux内核定义了ch9.h头文件专门来描述规范里描述的结构体和宏定义)：
static struct usb_device_descriptor msg_device_desc = {
.bLength = sizeof msg_device_desc,
.bDescriptorType = USB_DT_DEVICE,
.bcdUSB = cpu_to_le16(0x0200),
.bDeviceClass = USB_CLASS_PER_INTERFACE,
/* Vendor and product id can be overridden by module parameters. */
.idVendor = cpu_to_le16(FSG_VENDOR_ID),
.idProduct = cpu_to_le16(FSG_PRODUCT_ID),
.bNumConfigurations = 1,
};上述的bNumConfigurations字段值为1，代表该U盘设备驱动只有一个配置（描述符）。
现在回到刚刚的usb_composite_probe()函数，我们先来分析这个函数内部究竟做了什么内容。
我们发现usb_composite_probe主要是填充好struct usb_composite_driver结构体里面的成员gadget_driver：
struct usb_gadget_driver gadget_driver;
值得注意的是，它在这里被赋值为composite_driver_template实例了，这个函数最后把重要的工作交给了return usb_gadget_probe_driver(gadget_driver);
#linux-4.4.19/drivers/usb/gadget/udc/udc-core.c
int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
{
struct usb_udc *udc = NULL;
int ret;
if (!driver || !driver->bind || !driver->setup)
return -EINVAL;
mutex_lock(&udc_lock);
list_for_each_entry(udc, &udc_list, list) {
/* For now we take the first one */
if (!udc->driver)
goto found;
}
pr_debug("couldn't find an available UDC\n");
mutex_unlock(&udc_lock);
return -ENODEV;
found:
ret = udc_bind_to_driver(udc, driver);
mutex_unlock(&udc_lock);
return ret;
}
EXPORT_SYMBOL_GPL(usb_gadget_probe_driver);
从上面usb_gadget_probe_driver()函数的代码片段可知，它在遍历udc_list链表，找到一个udc（usb设备控制器驱动描述结构体）没有对应驱动的实例，然后通过udc_bind_to_driver()将udc驱动与上述的composite_driver_template模板实例绑定在一起，即能通过udc找回composite_driver_template实例，也能通过composite_driver_template实例找到绑定它的udc驱动。内核很喜欢使用container_of()宏找来找去，container_of()作用是根据某对象成员的指针返回该对象的指针，有点父类找派生类的意思，作为内核面向对象编程的工具，container_of宏用得很频繁！！既然有udc队列的遍历取出，必然有udc队列的添加，每注册一个udc驱动（usb_add_gadget_udc()）就会把udc结构体添加到udc队列的尾部。
我们再来看udc_bind_to_driver做了什么：
#linux-4.4.19/drivers/usb/gadget/udc/udc-core.c
/* udc_lock must be held */
static int udc_bind_to_driver(struct usb_udc *udc, struct usb_gadget_driver *driver)
{
int ret;
dev_dbg(&udc->dev, "registering UDC driver [%s]\n",
driver->function);
udc->driver = driver;
udc->dev.driver = &driver->driver;
udc->gadget->dev.driver = &driver->driver;
ret = driver->bind(udc->gadget, driver);
if (ret)
goto err1;
/* If OTG, the otg core starts the UDC when needed */
mutex_unlock(&udc_lock);
udc->is_otg = !usb_otg_register_gadget(udc->gadget, &otg_gadget_intf);
mutex_lock(&udc_lock);
if (!udc->is_otg) {
ret = usb_gadget_udc_start(udc);
if (ret) {
driver->unbind(udc->gadget);
goto err1;
}
usb_udc_connect_control(udc);
}
kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE);
return 0;
err1:
if (ret != -EISNAM)
dev_err(&udc->dev, "failed to start %s: %d\n",
udc->driver->function, ret);
udc->driver = NULL;
udc->dev.driver = NULL;
udc->gadget->dev.driver = NULL;
return ret;
}上述代码片段说明udc与driver绑定其实就是一个“它们的结构体成员互相赋值”的过程：
udc->driver = driver;
udc->dev.driver = &driver->driver;
udc->gadget->dev.driver = &driver->driver;
这样我包含你你包含我。最后回调了driver的bind函数，这个bind回调函数在composite_driver_template实例中赋值。最后，调用usb_otg_register_gadget()将gadget注册到otg core去，然后开启udc功能(usb_gadget_udc_start(udc))。对应BBB板用到的TI芯片am3358来说otg 用到了Mentor Graphics公司的musb ip核。usb_gadget_udc_start(udc)事实上是回调了drivers/usb/musb/musb_gadget.c（对应musb_hdrc.ko驱动）的musb_gadget_start()函数进行操控otg硬件寄存器。udc驱动我们这里不作讨论！
当然了，如果USB控制器不支持otg，kernel也没有加入CONFIG_USB_OTG的话，usb_otg_register_gadget()其实是空函数，返回不支持（return -ENOTSUPP;）。
下面看下composite_bind()
static int composite_bind(struct usb_gadget *gadget,
struct usb_gadget_driver *gdriver)
{
struct usb_composite_dev *cdev;
struct usb_composite_driver *composite = to_cdriver(gdriver);
int status = -ENOMEM;
cdev = kzalloc(sizeof *cdev, GFP_KERNEL);
if (!cdev)
return status;
spin_lock_init(&cdev->lock);
cdev->gadget = gadget;
set_gadget_data(gadget, cdev);
INIT_LIST_HEAD(&cdev->configs);
INIT_LIST_HEAD(&cdev->gstrings);
status = composite_dev_prepare(composite, cdev);
if (status)
goto fail;
/* composite gadget needs to assign strings for whole device (like
* serial number), register function drivers, potentially update
* power state and consumption, etc
*/
status = composite->bind(cdev);
if (status < 0)
goto fail;
if (cdev->use_os_string) {
status = composite_os_desc_req_prepare(cdev, gadget->ep0);
if (status)
goto fail;
}
update_unchanged_dev_desc(&cdev->desc, composite->dev);
/* has userspace failed to provide a serial number? */
if (composite->needs_serial && !cdev->desc.iSerialNumber)
WARNING(cdev, "userspace failed to provide iSerialNumber\n");
INFO(cdev, "%s ready\n", composite->name);
return 0;
fail:
__composite_unbind(gadget, false);
return status;
}其中，composite_dev_prepare()主要是初始化ep0端，申请了ep0的请求队列（struct usb_request *req）、创建sysfs文件系统的属性文件、最后填充struct usb_request *req的complete完成函数。我们知道ep0是设备控制传输用到的端点，尤其在设备枚举、属性配置上起关键作用，所以我们要首先初始化。
int composite_dev_prepare(struct usb_composite_driver *composite,
struct usb_composite_dev *cdev)
{
struct usb_gadget *gadget = cdev->gadget;
int ret = -ENOMEM;
/* preallocate control response and buffer */
cdev->req = usb_ep_alloc_request(gadget->ep0, GFP_KERNEL);
if (!cdev->req)
return -ENOMEM;
cdev->req->buf = kmalloc(USB_COMP_EP0_BUFSIZ, GFP_KERNEL);
if (!cdev->req->buf)
goto fail;
ret = device_create_file(&gadget->dev, &dev_attr_suspended);
if (ret)
goto fail_dev;
cdev->req->complete = composite_setup_complete;
cdev->req->context = cdev;
gadget->ep0->driver_data = cdev;
cdev->driver = composite;
/*
* As per USB compliance update, a device that is actively drawing
* more than 100mA from USB must report itself as bus-powered in
* the GetStatus(DEVICE) call.
*/
if (CONFIG_USB_GADGET_VBUS_DRAW <= USB_SELF_POWER_VBUS_MAX_DRAW)
usb_gadget_set_selfpowered(gadget);
/* interface and string IDs start at zero via kzalloc.
* we force endpoints to start unassigned; few controller
* drivers will zero ep->driver_data.
*/
usb_ep_autoconfig_reset(gadget);
return 0;
fail_dev:
kfree(cdev->req->buf);
fail:
usb_ep_free_request(gadget->ep0, cdev->req);
cdev->req = NULL;
return ret;
}紧跟着，status = composite->bind(cdev);实际上是回调mass_storage.c的int msg_bind(struct usb_composite_dev *cdev)，而cdev在composite_bind()函数开头通过kzalloc创建，并把gadget驱动等填充好struct usb_composite_dev结构体对象。msg_bind(这个函数下一节再讲，这个函数比较复杂 。而update_unchanged_dev_desc()主要用于填充新的设备描述符信息，因为调用了msg_bind()后信息可能会有改变。
这就完成了U盘设备驱动的初始化（注册）了，但U盘为什么能工作起来，这里貌似没有体现出来，下篇文章将从msg_bind()说起。
说个题外话，除了可以使用int usb_gadget_probe_driver(struct usb_gadget_driver *driver)来注册外，还可以使用int usb_udc_attach_driver(const char *name, struct usb_gadget_driver *driver);该函数有个额外参数name，可以指定用哪个usb口来初始化gadget驱动，譬如am3358含有两个usb控制器USB0和USB1，我们可以使用ret = usb_udc_attach_driver("musb-hdrc.0.auto", gadget_driver);来指定将gadget驱动挂到USB0上，这样该U盘 gadget设备就可以固定在USB0这个usb口上模拟出一个u盘了，USB1口则可以作它用。"musb-hdrc.0.auto"这个名字似曾相识吧？对，在上篇文章中使用configfs来启动U盘时，通过echo "musb-hdrc.1.auto" > UDC，底层就是调用了这个usb_udc_attach_driver()函数，来指定使用USB0。