Scsi - Index of

Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 002: ID 0624:0294 Avocent Corp.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
看这个第二行, Cypress Semiconductor Corp., 这么一长串的东西,你说哪来的?是不是应该从设备里
来?
设备的那几个标准描述符,整个描述符的大小也不一定放得下这么一长串,所以,一些设备专门准备了一些字
符串描述符(string descriptor).就用来记这些长串的东西,我们结合刚才的518 行开始讲,如果设备描述
符里边iManufacturer 不为0,那么调用usb_string,这句话具体做了什么?就是根据iManufactuer 的值
得到公司名字,而iManufactuer 的第一个字母i,就表示index,它记录的是真正的公司名字保存在哪一个字
符串描述符中,因为字符串描述符可以有多个,那么必然就有个号码来区分,接下来几行,iProduct 记录了产
品名在第几个字符串描述符中,iSerialNumber 记录了产品序列号在第几个字符串描述中,然后调用
usb_string 这个函数,就把真正的字符串描述符里的冬冬给记录了下来.我们看到,我们三次调用的时候分
别传递了us->vendor,us->product,us->serial.这样函数调用结束之后,这三个里面就记录了必要的信
息,于是以后我们就可以用了.
得到了us->vendor,us->product,us->serial,那么下面528 直到547 行就不需要多讲了,就是说如果
得到的东西是空的,(得到的是空可以有两种可能,一个是设备根本就没提供这些字符串描述符,另一种情况
是usb_string 函数没能成功,但是这个函数不成功也无所谓,没影响.)那也没关系,毕竟这些信息我们可有
可无,无非是打印出来给客户看看.如果unusual_dev 里边有的话,那就拷贝过来,如果也没有,那没办法,设
为Unknown.而序列号这个就索性置为None 好了,最后US_DEBUGP 把这些信息给打印出来,如果你打
开了debug 开关,那么你会在日志文件里看到这么一句话,在/var/log/messages 里边.
47
至此,get_device_info 这个函数就结束了他的使命.在usb storage 这部戏里,他将不再出场.但我想说,
对于usb storage 这整个模块来说,主角配角不重要,每个函数都是画布上的一抹色彩.就像我们每一个人,
不也是别人人生中的配角,但总是自己人生的主角吗?
冬天来了,春天还会远吗(四)
结束了get_device_info,我们继续沿着storage_probe 一步一步走下去.为了保持原汁原味,我们贴代码
的原则是一个函数的每一行都贴出来.get_device_info 是962 行,我们已经贴过,所以下面从963 行开
始
了.
963
964 #ifdef CONFIG_USB_STORAGE_SDDR09
965 if (us->protocol == US_PR_EUSB_SDDR09 ||
966 us->protocol == US_PR_DPCM_USB) {
967 /* set the configuration -- STALL is an acceptable response here */
968 if (us->pusb_dev->actconfig->desc.bConfigurationValue != 1) {
969 US_DEBUGP("active config #%d != 1 ??\n", us->pusb_dev
970 ->actconfig->desc.bConfigurationValue);
971 goto BadDevice;
972 }
973 result = usb_reset_configuration(us->pusb_dev);