Linux那些事儿 之 戏说USB(27)设备的生命线(十)

跟着设备的生命线走到现在,我算是明白了,什么东西的发展都是越往后越高级越复杂。再给张小表,看看现在和上次那张表出现的时候有什么变化。

state        USB_STATE_ADDRESS
speed     taken
ep0         ep0.urb_list,描述符长度/类型,wMaxPacketSize

接下来设备的目标当然就是Configured了。
要进入Configured状态,你得去配置设备,当然不能是盲目的去配置,要知道设备是可能有多个配置的,所以你要有选择有目的有步骤有计划的去配置,要做这样一个四有新人,就要先去获得设备的设备描述符,message.c中的usb_get_device_descriptor()就是core里专门干这个的。
int usb_get_device_descriptor(struct usb_device *dev, unsigned int size)
{
	struct usb_device_descriptor *desc;
	int ret;

	if (size > sizeof(*desc))
		return -EINVAL;
	desc = kmalloc(sizeof(*desc), GFP_NOIO);
	if (!desc)
		return -ENOMEM;

	ret = usb_get_descriptor(dev, USB_DT_DEVICE, 0, desc, size);
	if (ret >= 0)
		memcpy(&dev->descriptor, desc, size);
	kfree(desc);
	return ret;
}

这个函数比较的精悍,先是准备了一个struct usb_device_descriptor结构体,然后就用它去调用message.c里的usb_get_descriptor()获得设备描述符,获得之后再把得到的描述符复制到设备struct usb_device结构体的descriptor成员里。因此,这个函数成功与否的关键就在usb_get_descriptor()。其实对于写驱动的来说,眼里是只有usb_get_descriptor()没有usb_get_device_descriptor()的,不管你想获得哪种描述符都是要通过usb_get_descriptor(),而usb_get_device_descriptor()是专属内核用的接口。

int usb_get_descriptor(struct usb_device *dev, unsigned char type,
		       unsigned char index, void *buf, int size)
{
	int i;
	int result;

	memset(buf, 0, size);	/* Make sure we parse really received data */

	for (i = 0; i < 3; ++i) {
		/* retry on length 0 or error; some devices are flakey */
		result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
				USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
				(type << 8) + index, 0, buf, size,
				USB_CTRL_GET_TIMEOUT);
		if (result <= 0 && result != -ETIMEDOUT)
			continue;
		if (result > 1 && ((u8 *)buf)[1] != type) {
			result = -ENODATA;
			continue;
		}
		break;
	}
	return result;
}
参数type就是用来区分不同的描述符的,协议里说了,GET_DESCRIPTOR请求主要就是适用于三种描述符,设备描述符,配置描述符和字符串描述符。参数index是要获得的描述符的序号,如果希望得到的这种描述符设备里可以有多个,你需要指定获得其中的哪个,比如配置描述符就可以有多个,不过对于设备描述符来说,是只有一个的,所以这里的index应该为0。参数buf和size就是描述你用来放置获得的描述符的缓冲区的。


这个函数的内容挺单调的,主要就是调用了一个usb_control_msg(),你如果到现在还觉得usb_control_msg()只是个熟悉的陌生人,那俺也就太失败了。这里要说的第一个问题是它的一堆参数,这就需要认真了解一下spec 9.4.3里的这张表

GET_DESCRIPTOR请求的数据传输方向很明显是device-to-host的,而且还是协议里规定所有设备都要支持的标准请求,也不是针对端点或者接口什么的,而是针对设备的,所以bRequestType只能为0x80,就是上面表里的10000000B,也等于12行的USB_DIR_IN。wValue的高位字节表示描述符的类型,低位字节表示描述符的序号,所以就有13行的(type << 8) + index。wIndex对于字符串描述符应该设置为使用语言的ID,对于其它的描述符应该设置为0,所以也有了13行中间的那个0。至于wLength,就是描述符的长度,对于设备描述符,一般来说你都会指定为USB_DT_DEVICE_SIZE吧。

USB_CTRL_GET_TIMEOUT是定义在include/linux/usb.h里的一个宏,值为5000,表示有5s的超时时间。
#define USB_CTRL_GET_TIMEOUT	5000
#define USB_CTRL_SET_TIMEOUT	5000
第二个问题就是为什么会有3次循环。这个又要归咎于一些不守规矩的厂商了,搞出的设备古里古怪的,比如一些usb读卡器,一次请求还不定能成功,但是设备描述符拿不到接下来就没法子走了,所以这里多试几次,再不成功,就成鬼了。至于15到17行之间的代码都是判断是不是成功得到请求的描述符的,这个版本的内核这里的判断还比较混乱,就不多说了,你只要知道((u8 *)buf)[1] != type是用来判断获得描述符是不是请求的类型就可以了。

现在设备描述符已经有了,但是只有设备描述符是远远不够的,你从设备描述符里只能知道它一共支持几个配置,具体每个配置是何方神圣,是公的还是母的都不知道,你要配置一个设备总得知道这些吧。所以接下来就要获得各个配置的配置描述符,并且拿结果去充实struct usb_device的config、rawdescriptors等相关元素。core内部并不直接调用上面的usb_get_descriptor()去完成这个任务,而是调用config.c里的usb_get_configuration(),为什么?core总是需要做更多的事情,不然就不叫core了。

drivers/usb/core/config.c

int usb_get_configuration(struct usb_device *dev)
{
	struct device *ddev = &dev->dev;
	int ncfg = dev->descriptor.bNumConfigurations;
	int result = 0;
	unsigned int cfgno, length;
	unsigned char *bigbuffer;
	struct usb_config_descriptor *desc;

	cfgno = 0;
	result = -ENOMEM;
	if (ncfg > USB_MAXCONFIG) {
		dev_warn(ddev, "too many configurations: %d, "
		    "using maximum allowed: %d\n", ncfg, USB_MAXCONFIG);
		dev->descriptor.bNumConfigurations = ncfg = USB_MAXCONFIG;
	}

	if (ncfg < 1) {
		dev_err(ddev, "no configurations\n");
		return -EINVAL;
	}

	length = ncfg * sizeof(struct usb_host_config);
	dev->config = kzalloc(length, GFP_KERNEL);
	if (!dev->config)
		goto err2;

	length = ncfg * sizeof(char *);
	dev->rawdescriptors = kzalloc(length, GFP_KERNEL);
	if (!dev->rawdescriptors)
		goto err2;

	desc = kmalloc(USB_DT_CONFIG_SIZE, GFP_KERNEL);
	if (!desc)
		goto err2;

	result = 0;
	for (; cfgno < ncfg; cfgno++) {
		/* We grab just the first descriptor so we know how long
		 * the whole configuration is */
		result = usb_get_descriptor(dev, USB_DT_CONFIG, cfgno,
		    desc, USB_DT_CONFIG_SIZE);
		if (result < 0) {
			dev_err(ddev, "unable to read config index %d "
			    "descriptor/%s: %d\n", cfgno, "start", result);
			if (result != -EPIPE)
				goto err;
			dev_err(ddev, "chopping to %d config(s)\n", cfgno);
			dev->descriptor.bNumConfigurations = cfgno;
			break;
		} else if (result < 4) {
			dev_err(ddev, "config index %d descriptor too short "
			    "(expected %i, got %i)\n", cfgno,
			    USB_DT_CONFIG_SIZE, result);
			result = -EINVAL;
			goto err;
		}
		length = max((int) le16_to_cpu(desc->wTotalLength),
		    USB_DT_CONFIG_SIZE);

		/* Now that we know the length, get the whole thing */
		bigbuffer = kmalloc(length, GFP_KERNEL);
		if (!bigbuffer) {
			result = -ENOMEM;
			goto err;
		}

		if (dev->quirks & USB_QUIRK_DELAY_INIT)
			msleep(100);

		result = usb_get_descriptor(dev, USB_DT_CONFIG, cfgno,
		    bigbuffer, length);
		if (result < 0) {
			dev_err(ddev, "unable to read config index %d "
			    "descriptor/%s\n", cfgno, "all");
			kfree(bigbuffer);
			goto err;
		}
		if (result < length) {
			dev_warn(ddev, "config index %d descriptor too short "
			    "(expected %i, got %i)\n", cfgno, length, result);
			length = result;
		}

		dev->rawdescriptors[cfgno] = bigbuffer;

		result = usb_parse_configuration(dev, cfgno,
		    &dev->config[cfgno], bigbuffer, length);
		if (result < 0) {
			++cfgno;
			goto err;
		}
	}
	result = 0;

err:
	kfree(desc);
	dev->descriptor.bNumConfigurations = cfgno;
err2:
	if (result == -ENOMEM)
		dev_err(ddev, "out of memory\n");
	return result;
}
说代码前先说点理论,不然要被这么生猛的代码给吓倒了。不管过多少河拐几道弯,要想得到配置描述符,最终都不可避免的要向设备发送GET_DESCRIPTOR请求,这就需要以USB_DT_CONFIG为参数调用usb_get_descriptor函数,也就需要知道该为获得的描述符准备多大的一个缓冲区,本来这个长度应该很明确的为USB_DT_CONFIG_SIZE,它表示的就是配置描述符的大小,但是实际上不是这么回事儿,USB_DT_CONFIG_SIZE只表示配置描述符本身的大小,并不表示GET_DESCRIPTOR请求返回结果的大小。因为向设备发送GET_DESCRIPTOR请求时,设备并不单单返回一个配置描述符了事,而是一股脑儿的将这个配置下面的所有接口描述符,端点描述,还有class-或vendor-specific描述符都返回了给你。那么这个总长度如何得到那?在神秘的配置描述符里有这样一个神秘的字段wTotalLength,它里面记录的就是这个总长度,那么问题就简单了,可以首先发送USB_DT_CONFIG_SIZE个字节的请求过去,获得这个配置描述符的内容,从而获得那个总长度,然后以这个长度再请求一次,这样就可以获得一个配置下面所有的描述符内容了。上面的usb_get_configuration()采用的就是这个处理方法。

4行,获得设备配置描述符的数目。

12行,这些检验又来了,在光天化日之下莫明其妙的受到戴大盖帽的盘问很不爽是吧,但这就是他们的规矩他们的工作,不然你让他们做什么。USB_MAXCONFIG是config.c理定义的
#define USB_MAXCONFIG			8	/* Arbitrary limit */
限制了一个设备最多只能支持8种配置拥有8个配置描述符,如果超出了这个限制,15行就强制它为这个最大值,你一个设备要想在linux里混就得守这里的规矩,自由民主只是相对的。不过如果设备里没有任何一个配置描述符,什么配置都没有,就想裸身蒙混过关,那是不可能的,18行这关就过不去。

24行,struct usb_device里的config表示的是设备拥有的所有配置,你设备有多少个配置就为它准备多大的空间。

29行,rawdescriptors还认识吧,这是个字符指针数组里的每一项都指向一个使用GET_DESCRIPTOR请求去获取配置描述符时所得到的结果。

33行,准备一个大小为USB_DT_CONFIG_SIZE的缓冲区,第一次发送GET_DESCRIPTOR请求要用的。

38行,剩下的主要就是这个for循环了,获取每一个配置的那些描述符。

41行,诚如上面所说的,首先发送USB_DT_CONFIG_SIZE个字节请求,获得配置描述符的内容。然后对返回的结果进行检验,知道为什么51行会判断结果是不是小于4么?答案尽在配置描述符中,里面的3,4字节就是wTotalLength,只要得到前4个字节,就已经完成任务能够获得总长度了。

62行,既然总长度已经有了,那么这里就为接下来的GET_DESCRIPTOR请求准备一个大点的缓冲区。

71行,现在可以获得这个配置相关的所有描述符了。然后是对返回结果的检验,再然后就是将得到的那一堆数据的地址赋给rawdescriptors数组里的指针。

87行,你将会遇到另一个超级变态的函数,它将对前面GET_DESCRIPTOR请求获得的那堆数据做处理。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值