|
- UID
- 852665
|
Linux那些事儿之我是Hub(24)所谓的热插拔
你问我这世界,最远的地方在哪里,我将答案抛向蓝天之外落在你心底,你问我这世界,最后的真爱在哪里,我把线索指向大海之外直达我怀里.你问我hub_irq()这个函数,最终是被谁调用,我却只能说我既没有答案也没有线索.当然,你要是问我芙蓉姐姐还能红多久,我倒是可以很爽快的告诉你,你知道永远有多远吗?
我们曾经在hub_configure中讲过中断传输,当时调用了usb_fill_int_urb()函数,并且把hub_irq作为一个参数传递了进去,最终把urb->complete赋值为hub_irq.然后,主机控制器会定期询问hub,每当hub端口上有一个设备插入或者拔除时,它就会向主机控制器打小报告.(怎么哪都有人打小报告啊,当初在Intel不知道哪位哥们缺德,跟老板说我做事情只关注结果不管过程,只要问题解决了就好,根本不管问题是怎么被解决的.害得我在Intel差点没过试用期.)具体来说,从硬件的角度看,就是hub会向host controller返回一些信息,或者说data,这个Data被称作”Hub and Port Status Change Bitmap”,而从软件角度来看,host controller的驱动程序接下来会在处理好这个过程的urb之后,调用该urb的complete函数,对于hub来说,这个函数就是hub_irq().
337 /* completion function, fires on port status changes and various faults */
338 static void hub_irq(struct urb *urb)
339 {
340 struct usb_hub *hub = urb->context;
341 int status;
342 int i;
343 unsigned long bits;
344
345 switch (urb->status) {
346 case -ENOENT: /* synchronous unlink */
347 case -ECONNRESET: /* async unlink */
348 case -ESHUTDOWN: /* hardware going away */
349 return;
350
351 default: /* presumably an error */
352 /* Cause a hub reset after 10 consecutive errors */
353 dev_dbg (hub->intfdev, "transfer --> %d/n", urb->status);
354 if ((++hub->nerrors < 10) || hub->error)
355 goto resubmit;
356 hub->error = urb->status;
357 /* FALL THROUGH */
358
359 /* let khubd handle things */
360 case 0: /* we got data: port status changed */
361 bits = 0;
362 for (i = 0; i < urb->actual_length; ++i)
363 bits |= ((unsigned long) ((*hub->buffer)))
364 << (i*8);
365 hub->event_bits[0] = bits;
366 break;
367 }
368
369 hub->nerrors = 0;
370
371 /* Something happened, let khubd figure it out */
372 kick_khubd(hub);
373
374 resubmit:
375 if (hub->quiescing)
376 return;
377
378 if ((status = usb_submit_urb (hub->urb, GFP_ATOMIC)) != 0
379 && status != -ENODEV && status != -EPERM)
380 dev_err (hub->intfdev, "resubmit --> %d/n", status);
381 }
你问这个参数urb是哪个urb?告诉你,中断传输就是只有一个urb,不是说像bulk传输那样每次开启一次传输都要有申请一个urb,提交urb,对于中断传输,一个urb就可以了,反复利用,所以我们只有一次调用usb_fill_int_urb()函数.这正体现了中断交互的周期性.
340行,当初我们填充urb的时候,urb->context就是赋的hub,所以现在这句话就可以获得我们的那个hub.
345行开始判断urb的状态,前三种都是出错了,直接返回.
351的default和case 0.这段代码是我认为最有技术含量的一段代码.我不知道我是该恨谭浩强该是该恨我自己,我记得我在谭浩强的书上看到的default总是在各个case之后,结果我以为这里default不管case等于0与否都会执行,结果半天没看懂,后来我明白了,其实当urb->status为0的时候,default那一段是不会执行的.
所以这段代码就很好理解了.一开始hub->error为0,hub->nerrors也为0,所以default这一段很明显,goto resubmit,即,我们允许年轻人犯错误,并且可以允许犯十次,错了没有关系,只要不在同一条阴沟里翻船翻十次就可以了,我相信这对大多数人来说都足够了,唯一例外的大概是中国男足了.每次阴沟里翻船,爬起来一看,咦,怎么还是上次那条阴沟啊?resubmit那一段就是重新调用了一次usb_submit_urb()而已.当然,还判断了hub->quisecing.这个变量初始值为1,但是我们前面在hub_activate里把它设置为了0,有一个函数会把它设置为1,这个函数就是hub_quiesce(),而调用后者的只有两个函数,一个是hub_suspend,一个是hub_pre_reset().于是,这里的意思就很明确了,如果hub被挂起了,或者要被reset了,那么就不用重新提交urb了,hub_irq()函数直接返回吧.
再看case 0,urb->status为0,说明这个urb被顺利的处理了,即host controller获得了他想要的数据,即那个”Hub and Port Status Change Bitmap”,因为我们当初调用usb_fill_int_urb的时候,把*hub->buffer传递给了urb->transfer_buffer,所以这个数据现在就在hub->buffer中,我们来看这个bitmap是什么样子,usb spec中给出了这样一幅图:
首先这幅图为我们解答了一个很大的疑惑.当时在hub_events()中您大概还有一些地方不是很清楚.现在我们可以来弄清楚它们了.
我们回过头来看,struct usb_hub中,unsigned long event_bits[1],首先这是一个数组,其次这个数组只有一个元素,而这一个元素恰恰就是对应这里的这个Bitmap,即所谓的位图,每一位都有其作用.一个unsigned long至少4个字节,即32个bits.所以够用了,而我们看到这张图里,bit0和其它的bit是不一样的,bit 0表示Hub有变化,而其它bit则具体表示某一个端口有没有变化,即bit 1表示端口1有变化,bit 2表示端口2有变化,如果一个端口没有变化,对应的那一位就是0.
所以我们可以回到hub_events()函数中来,看看当时我们是如何判断hub->event_bits的,当时我们有这么一小段,
2685 /* deal with port status changes */
2686 for (i = 1; i <= hub->descriptor->bNbrPorts; i++) {
2687 if (test_bit(i, hub->busy_bits))
2688 continue;
2689 connect_change = test_bit(i, hub->change_bits);
2690 if (!test_and_clear_bit(i, hub->event_bits) &&
2691 !connect_change && !hub->activating)
2692 continue;
看到了吗?循环指数i从1开始,有多少端口就循环多少次,而对event_bits的测试,即2690判断的是bitmap中bit 1,bit 2,…,bit N,而不需要判断bit 0.
反过来,如果具体每个端口没有变化,而变化的是hub的整体,比如,Local Power有变化,比如Overcurrent有变化,我们则需要判断的是bit 0.即当时我们在hub_events()中看到的下面这段代码.
2776 /* deal with hub status changes */
2777 if (test_and_clear_bit(0, hub->event_bits) == 0)
2778 ; /* do nothing */
2779 else if (hub_hub_status(hub, &hubstatus, &hubchange) < 0)
2780 dev_err (hub_dev, "get_hub_status failed/n");
2781 else {
2782 if (hubchange & HUB_CHANGE_LOCAL_POWER) {
2783 dev_dbg (hub_dev, "power change/n");
2784 clear_hub_feature(hdev, C_HUB_LOCAL_POWER);
2785 if (hubstatus & HUB_STATUS_LOCAL_POWER)
2786 /* FIXME: Is this always true? */
2787 hub->limited_power = 0;
2788 else
2789 hub->limited_power = 1;
2790 }
2791 if (hubchange & HUB_CHANGE_OVERCURRENT) {
2792 dev_dbg (hub_dev, "overcurrent change/n");
2793 msleep(500); /* Cool down */
2794 clear_hub_feature(hdev, C_HUB_OVER_CURRENT);
2795 hub_power_on(hub);
2796 }
2797 }
而这样我们就很清楚hub_events()的整体思路了,判断每个端口是否有变化,如果有变化就去处理它,没有变化也没有关系,接下来判断是否hub整体上有变化,如果有有变化,那么也去处理它.满足了个人利益,满足了集体利益,这不正体现了我们社会主义制度的优越性么?
关于这个actual_length,其实你不傻的话这个根本就不用我啰嗦了.因为每一个hub的port是不一样的,所以这张bitmap的长度就不一样,比如说你是16个port,那么这个bitmap最多就只要16+1个bit就足够了.而actual_length就是3,即3个bytes.因为3个bytes等于24个bits,足以容纳16+1个bits了.而struct usb_hub中,buffer是这样一个成员,char (*buffer)[8],所以3个bytes就意味着这个buffer的前三个元素里承载着我们的希望.这样我们就不难理解这里这个hub->event_bits是如何变成为这张bitmap的了.
369行,把nerrors清零吧,过去的事情就让它过去吧,让我们忘记过去,展望未来.其实这道理不用我说,小刚那首<<忘记>>就说的很清楚了:有太多往事就别喝下太少酒精,太珍惜生命就别随便掏心,舍不得看破就别张开眼睛,想开心就要舍得伤心;有太多行李就别单独旅行,不能够离开就不要接近,舍不得结束就别开始一段感情,想忘记就要一切归零.谢谢林夕,用这么好的歌词为我们诠释了Linux内核代码.
最关键的当然还是372行,再次调用kick_khubd()函数,于是会再一次触发hub_events().
而hub_irq()函数也就到这里了.这个函数不长,可是很重要,其中最重要的正是最后这句kick_khubd().而这也就是所谓的热插拔的实现路径,要知道我们上次分析kick_khubd的时候是在hub初始化的时候,即那次针对的情况是设备一开始就插在了hub上,而这里再次调用kick_khubd才是真正的在使用过程中,突然间hub有了变化的情况,应该说这个后者才是真正有技术含量的冬冬. |
|
