Linux那些事儿之我是Hub(29)梦醒时分

爱情就像拔河比赛,如果一方先放手,另一方就会受伤.

只可惜说出这句话的梁咏琪,最终还是放开了与郑伊健相牵的手.

suspend和resume也是这样,如果你不调用suspend,那么你永远也不需要调用resume,它们就这样青梅竹马的存在于这个世界上,过着世外桃源般的日子.但是如果你不小心调用了suspend让设备睡眠,那么你就必然需要在将来某个时刻调用resume来唤醒设备.

看完了suspend我们来看resume,变量usb_bus_type中的成员resume被赋值为usb_resume,和usb_suspend对应.来自drivers/usb/core/driver.c:

   1504 static int usb_resume(struct device *dev)

   1505 {

   1506         struct usb_device       *udev;

   1507

   1508         if (!is_usb_device(dev))        /* Ignore PM for interfaces */

   1509                 return 0;

   1510         udev = to_usb_device(dev);

   1511         if (udev->autoresume_disabled)

   1512                 return -EPERM;

   1513         return usb_external_resume_device(udev);

   1514 }

看过了usb_suspend再来看这个usb_resume就显得很简单了,两个函数基本能体现一种对称美.autoresume_disabled是struct usb_device中的一个成员,即,我们提供给用户一种选择,让用户可以自己来disable掉设备的autoresume,一旦disable掉了,就意味着设备是不会唤醒了,所以这里直接返回错误码.

接着,usb_external_resume_device,

   1469 /**

   1470  * usb_external_resume_device - external resume of a USB device and its interfaces

   1471  * @udev: the usb_device to resume

   1472  *

   1473  * This routine handles external resume requests: ones not generated

   1474  * internally by a USB driver (autoresume) but rather coming from the user

   1475  * (via sysfs), the PM core (system resume), or the device itself (remote

   1476  * wakeup).  @udev's usage counter is unaffected.

   1477  *

   1478  * The caller must hold @udev's device lock.

   1479  */

   1480 int usb_external_resume_device(struct usb_device *udev)

   1481 {

   1482         int     status;

   1483

   1484         usb_pm_lock(udev);

   1485         udev->auto_pm = 0;

   1486         status = usb_resume_both(udev);

   1487         udev->last_busy = jiffies;

   1488         usb_pm_unlock(udev);

   1489

   1490         /* Now that the device is awake, we can start trying to autosuspend

   1491          * it again. */

   1492         if (status == 0)

   1493                 usb_try_autosuspend_device(udev);

   1494         return status;

   1495 }

也不干别的,设置好udev->auto_pm为0,然后调用usb_resume_both.再然后调用usb_try_autosuspend_device,关于autosuspend/autoresume的部分我们稍候会单独讲.现在先来看usb_resume_both.

   1083 /**

   1084  * usb_resume_both - resume a USB device and its interfaces

   1085  * @udev: the usb_device to resume

   1086  *

   1087  * This is the central routine for resuming USB devices.  It calls the

   1088  * the resume method for @udev and then calls the resume methods for all

   1089  * the interface drivers in @udev.

   1090  *

   1091  * Before starting the resume, the routine calls itself recursively for

   1092  * the parent device of @udev, thereby propagating the change up the device

   1093  * tree and assuring that @udev will be able to resume.  If the parent is

   1094  * unable to resume successfully, the routine fails.

   1095  *

   1096  * The resume method calls are subject to mutual exclusion under control

   1097  * of @udev's pm_mutex.  Many of these calls are also under the protection

   1098  * of @udev's device lock (including all requests originating outside the

   1099  * USB subsystem), but autoresume requests generated by a child device or

   1100  * interface driver may not be.  Usbcore will insure that the method calls

   1101  * do not arrive during bind, unbind, or reset operations.  However, drivers

   1102  * must be prepared to handle resume calls arriving at unpredictable times.

   1103  * The only way to block such calls is to do an autoresume (preventing

   1104  * other autoresumes) while holding @udev's device lock (preventing outside

   1105  * resumes).

   1106  *

   1107  * The caller must hold @udev->pm_mutex.

   1108  *

   1109  * This routine can run only in process context.

   1110  */

   1111 static int usb_resume_both(struct usb_device *udev)

   1112 {

   1113         int                     status = 0;

   1114         int                     i;

   1115         struct usb_interface    *intf;

   1116         struct usb_device       *parent = udev->parent;

   1117

   1118         cancel_delayed_work(&udev->autosuspend);

   1119         if (udev->state == USB_STATE_NOTATTACHED) {

   1120                 status = -ENODEV;

   1121                 goto done;

   1122         }

   1123

   1124         /* Propagate the resume up the tree, if necessary */

   1125         if (udev->state == USB_STATE_SUSPENDED) {

   1126                 if (udev->auto_pm && udev->autoresume_disabled) {

   1127                         status = -EPERM;

   1128                         goto done;

   1129                 }

   1130                 if (parent) {

   1131                         status = usb_autoresume_device(parent);

   1132                         if (status == 0) {

   1133                                 status = usb_resume_device(udev);

   1134                                 if (status) {

   1135                                         usb_autosuspend_device(parent);

   1136

   1137                                         /* It's possible usb_resume_device()

   1138                                          * failed after the port was

   1139                                          * unsuspended, causing udev to be

   1140                                          * logically disconnected.  We don't

   1141                                          * want usb_disconnect() to autosuspend

   1142                                          * the parent again, so tell it that

   1143                                          * udev disconnected while still

   1144                                          * suspended. */

   1145                                         if (udev->state ==

   1146                                                         USB_STATE_NOTATTACHED)

   1147                                                 udev->discon_suspended = 1;

   1148                                 }

   1149                         }

   1150                 } else {

   1151

   1152                         /* We can't progagate beyond the USB subsystem,

   1153                          * so if a root hub's controller is suspended

   1154                          * then we're stuck. */

   1155                         if (udev->dev.parent->power.power_state.event !=

   1156                                         PM_EVENT_ON)

   1157                                 status = -EHOSTUNREACH;

   1158                         else

   1159                                 status = usb_resume_device(udev);

   1160                 }

   1161         } else {

   1162

   1163                 /* Needed only for setting udev->dev.power.power_state.event

   1164                  * and for possible debugging message. */

   1165                 status = usb_resume_device(udev);

   1166         }

   1167

   1168         if (status == 0 && udev->actconfig) {

   1169                 for (i = 0; i < udev->actconfig->desc.bNumInterfaces; i++) {

   1170                         intf = udev->actconfig->interface[i];

   1171                         usb_resume_interface(intf);

   1172                 }

   1173         }

   1174

   1175  done:

   1176         // dev_dbg(&udev->dev, "%s: status %d/n", __FUNCTION__, status);

   1177         return status;

   1178 }

和usb_suspend_both的结构比较类似,不过这里是先针对device,再针对interface,而usb_suspend_both那儿是先针对interface,再针对device.我们先来看一下udev->autosuspend.我们刚刚才看到过cancel_delayed_work,这里又出现了一次.

struct usb_device结构体有一个成员,struct delayed_work autosuspend,要明白它,必须先明白另一个家伙,ksuspend_usb_wq.在drivers/usb/core/usb.c中:

     51 /* Workqueue for autosuspend and for remote wakeup of root hubs */

     52 struct workqueue_struct *ksuspend_usb_wq;

之前咱们在讲hub->leds的时候提到过struct workqueue_struct代表一个工作队列,不过作为hub->leds,咱们没有单独建立一个工作队列,而是使用默认的公共队列,但是这里咱们需要单独建立自己的队列.很显然,hub->leds代表着与指示灯相关的代码,其地位是很低下的,不可能受到足够的重视,而这里这个工作队列代表着整个usb子系统里与电源管理非常相关的一部分代码的利益,当然会被受到重视.

不信的话,咱们可以再一次看一下usb子系统初始化的代码,即usb_init函数,其第一个重要的函数就是ksuspend_usb_init(),drivers/usb/core/usb.c中:

    200 #ifdef  CONFIG_PM

    201

    202 static int ksuspend_usb_init(void)

    203 {

    204         /* This workqueue is supposed to be both freezable and

    205          * singlethreaded.  Its job doesn't justify running on more

    206          * than one CPU.

    207          */

    208         ksuspend_usb_wq = create_freezeable_workqueue("ksuspend_usbd");

    209         if (!ksuspend_usb_wq)

    210                 return -ENOMEM;

    211         return 0;

    212 }

    213

    214 static void ksuspend_usb_cleanup(void)

    215 {

    216         destroy_workqueue(ksuspend_usb_wq);

    217 }

    218

    219 #else

    220

    221 #define ksuspend_usb_init()     0

    222 #define ksuspend_usb_cleanup()  do {} while (0)

    223

224 #endif  /* CONFIG_PM */

如果你没有打开CONFIG_PM这个编译开关,当然就什么也不会发生,这俩函数也就是空函数,如果打开了,那么ksuspend_usb_init在usb_init中被调用,而ksuspend_usb_cleanup反其道而行之,在usb_exit中被调用.

我们看到,这两个函数都非常短,但这并不要紧.生命的长短并不是最重要的,而是精彩与否. 　　利群广告词:人生就像是一场旅行,不在乎目的地,在乎的是沿途的风景和看风景的心情.怎样理解这段广告词?一个吸烟的同学说,可不可以这样认为,吸烟就像是男人的春药,不在乎浓缩生命的长河,在乎的是吸烟时的沉醉和沉醉时的快乐.

没错,ksuspend_usb_init虽然超级短,但是它却做了一件相当有意义的事情,那就是调用create_freezeable_workqueue(),这其实就是创建一个工作队列,函数的参数就是这个工作队列的名字,即ksuspend_usbd,而函数的返回值就是工作队列结构体指针,即struct workqueue_struct指针,然后赋值给了ksuspend_usb_wq.所以我们接下来就需要和ksuspend_usb_wq打交道了.我们所要知道的是,如果我们要把一个任务加入到工作队列中来,我们可以调用queue_work或者queue_delayed_work.在2.6.22.1的内核中,往这个工作队列中加工作的地方只有两处,一个是drivers/usb/core/driver.c中的autosuspend_check()函数内部,调用的是queue_delayed_work,一个是drivers/usb/core/hcd.c中,调用的是queue_work.autosuspend_check我们后面会讲,现在把与ksuspend_usb_wq相关的两行贴出来,先睹为快.

    976                         queue_delayed_work(ksuspend_usb_wq, &udev->autosuspend,

    977                                         suspend_time - jiffies);

这里第三个参数suspend_time-jiffies,表明一个延时的时间,即至少经过这么多时间之后,这个任务才可以真正执行.这就和我们前面见过的那个schedule_delayed_work()函数类似.

而正是这里让我们看到了udev->autosuspend和ksuspend_usb_wq之间的关系,即后者代表一个工作队列,而前者代表一个工作,这里的做法就是把autosuspend给加入到了ksuspend_usb_wq这个队列里,并且在经过一段延时之后执行这个工作.工作队列中的任务由相关的工作线程执行,可能是在一个无法预期的时间(取决于负载,中断等等),或者是在一段延迟之后.

于是你该问了,udev->autosuspend是一个struct delayed_work结构体,那么它所对应的那个函数是谁?其实我们见过,不过也许你已经忘记了,还记得八大函数的第一个么,usb_alloc_dev,当时就有这么一行,INIT_DELAYED_WORK(&dev->autosuspend,usb_autosuspend_work),所以说,每一个usb设备在它刚问世的时候就已经和一个叫做usb_autosuspend_work给捆绑了起来,即它还少不更事的时候就已经和usb_autosuspend_work()函数签了这么一个卖身契,因此,不管你是usb鼠标还是usb键盘,或者是usb mass storage,总之你都和usb_autosuspend_work得发生关系.

至此,我们就很好理解usb_resume_both函数中cancel_delayed_work那行的意思了.我们且不管autosuspend和一般的suspend有什么区别,一个很简单的道理,既然要resume,那当然就不要suspend了.cancel了一个设备的autosuspend的work,自然它就不会再自动挂起,而如果你以后要让它能够自动挂起,你可以再次调用queue_delayed_work,正如在autosuspend_check中做的那样.具体代码我们后面讲autosuspend了再看.

继续在usb_resume_both中往下看,刚才我们设置了auto_pm为0,所以这里1126这个if内部不会执行.

1130行,如果不是Root Hub,那么调用针对父设备调用usb_autoresume_device,还是我们一直强调的那个道理,挂起的时候要从下至上,而唤醒的时候要自上而下.一个自来水管系统,如果上面没水,下面开关全打开也没有任何意义.

上面醒来了,才调用usb_resume_device唤醒下面的当前这个device.如果当前设备的唤醒失败了,那么调用usb_autosuspend_device()来把刚才做的事情取消掉,道理很简单,本来咱们的目的就是为了唤醒当前设备,为此我们先唤醒了上层的设备,结果上层的设备唤醒了,但是咱们自己却没有唤醒,那咱们所作的就是无用功了,所以还是把刚刚唤醒的上层设备给催眠吧.

虽然我们还没有讲autosuspend/autoresume,但是凭一个男人的直觉,我们基本上能够感觉出,usb_autosuspend_device和usb_autoresume_device这两个函数可以很好的处理usb设备树,即他们不会仅仅对付一个设备,而是会很自然的沿着usb设备树去往上走或者往下走,从而保证咱们刚才说的那个挂起时从下至上,唤醒时从上而下.其实,在usb_suspend_both中我们还剩下一个函数没有提,它正是usb_autosuspend_device(),而且是针对父设备的,如果你有耐心,你会发现usb_autosuspend_device会调用usb_autopm_do_device(),而后者又会调用usb_suspend_both,这样一层一层往上走,其效果就像一只蜗牛,一步一步往上爬,在最高点乘着叶片往前飞,任风吹干流过的泪和汗.而这里的usb_autoresume_device的原理恰好相反,它也会调用usb_autopm_do_device(),而后者这时候又会调用usb_resume_both,于是就会一层一层往下走,效果就相当于我们以前往的那个游戏—“是男人就下一百层”.也正是因为这种你调用我我调用你的复杂关系,我们才决定先不去深入看autosuspend相关的函数,等我们看完了非autosuspend的函数再去看就会很容易理解.

Ok,让我们来看usb_resume_device(),

    822 /* Caller has locked udev's pm_mutex */

    823 static int usb_resume_device(struct usb_device *udev)

    824 {

    825         struct usb_device_driver        *udriver;

    826         int                             status = 0;

    827

    828         if (udev->state == USB_STATE_NOTATTACHED ||

    829                         udev->state != USB_STATE_SUSPENDED)

    830                 goto done;

    831

    832         /* Can't resume it if it doesn't have a driver. */

    833         if (udev->dev.driver == NULL) {

    834                 status = -ENOTCONN;

    835                 goto done;

    836         }

    837

    838         udriver = to_usb_device_driver(udev->dev.driver);

    839         status = udriver->resume(udev);

    840

    841 done:

    842         // dev_dbg(&udev->dev, "%s: status %d/n", __FUNCTION__, status);

    843         if (status == 0) {

    844                 udev->autoresume_disabled = 0;

    845                 udev->dev.power.power_state.event = PM_EVENT_ON;

    846         }

    847         return status;

    848 }

这种似曾相识的感觉是不言而喻的,和usb_suspend_device那是相当的对称啊!最重要的当然是839行,调用属于设备驱动的resume函数.不过,至少到2.6.22.1的内核为止,这个世界上总共只有一个struct usb_device_driver的结构体变量,它就是struct usb_device_driver usb_generic_driver,而实际上你会发现你的每个设备默认情况下都会和这个usb_generic_driver相绑定,除非你自己定义了自己的struct usb_device_driver结构体,不过至少在标准内核中,暂时还没有人这么干,当然以后也许会有.否则struct usb_device_driver这个结构体就太浪费了点.关于usb_generic_driver,你可以在sysfs下看到效果,比如:

localhost:/usr/src/linux-2.6.22.1/drivers/usb/core # ls /sys/bus/usb/drivers

hub  usb  usb-storage  usbfs

所有的usb驱动程序都会在这里有一个对应的目录,其中与usb_generic_driver对应的就是那个usb目录.这是因为:

    210 struct usb_device_driver usb_generic_driver = {

    211         .name = "usb",

    212         .probe = generic_probe,

    213         .disconnect = generic_disconnect,

    214 #ifdef  CONFIG_PM

    215         .suspend = generic_suspend,

    216         .resume = generic_resume,

    217 #endif

    218         .supports_autosuspend = 1,

    219 };

这里的name就对应了在/sys/bus/usb/drivers/下面的那个子目录名称.现在的内核的处理方式是,凡是有一个新的设备被探测到,就先把它的struct usb_device和这个generic driver相绑定,即首先被调用的generic_probe,然后才会根据每一个具体的interface去绑定属于具体interface的驱动程序,去调用具体的那个interface对应的driver的probe函数,比如storage_probe.因此你会发现,不管你插入任何usb设备,你都会在/sys/bus/usb/drivers/usb/目录下面发现多出一个文件来,比如:

localhost:/usr/src/linux-2.6.22.1/drivers/usb/core # ls /sys/bus/usb/drivers/usb

1-1  bind  module  unbind  usb1  usb2  usb3  usb4  usb5

而如果你插入的是usb-storage,那么接下来在/sys/bus/usb/drivers/usb-storage/下面也将多出一个对应的文件来,

localhost:/usr/src/linux-2.6.22.1/drivers/usb/core # ls /sys/bus/usb/drivers/usb-storage/

1-1:1.0  bind  module  new_id  unbind

而在/sys/bus/usb/devices/目录下面你能看到所有的usb设备,

localhost:/usr/src/linux-2.6.22.1/drivers/usb/core # ls /sys/bus/usb/devices/

1-0:1.0  1-1  1-1:1.0  2-0:1.0  3-0:1.0  4-0:1.0  5-0:1.0  usb1  usb2  usb3  usb4  usb5

贴出这些只是为了给你有一个直观的印象,而我们需要知道的是对于当前的设备来说,其默认情况下所对应的设备驱动级的suspend函数就是generic_suspend,resume函数就是generic_resume,所以我们来看一下这两个函数,

    192 #ifdef  CONFIG_PM

    193

    194 static int generic_suspend(struct usb_device *udev, pm_message_t msg)

    195 {

    196         /* USB devices enter SUSPEND state through their hubs, but can be

    197          * marked for FREEZE as soon as their children are already idled.

    198          * But those semantics are useless, so we equate the two (sigh).

    199          */

    200         return usb_port_suspend(udev);

    201 }

    202

    203 static int generic_resume(struct usb_device *udev)

    204 {

    205         return usb_port_resume(udev);

    206 }

    207

    208 #endif  /* CONFIG_PM */

呵呵,原来也就是调用usb_port_suspend和usb_port_resume而已.前面我们已经看过usb_port_suspend函数,现在我们来看usb_port_resume,

   1838 /*

   1839  * usb_port_resume - re-activate a suspended usb device's upstream port

   1840  * @udev: device to re-activate

   1841  * Context: must be able to sleep; device not locked; pm locks held

   1842  *

   1843  * This will re-activate the suspended device, increasing power usage

   1844  * while letting drivers communicate again with its endpoints.

   1845  * USB resume explicitly guarantees that the power session between

   1846  * the host and the device is the same as it was when the device

   1847  * suspended.

   1848  *

   1849  * Returns 0 on success, else negative errno.

   1850  */

   1851 int usb_port_resume(struct usb_device *udev)

   1852 {

   1853         int     status;

   1854

   1855         /* we change the device's upstream USB link,

   1856          * but root hubs have no upstream USB link.

   1857          */

   1858         if (udev->parent) {

   1859                 // NOTE this fails if parent is also suspended...

   1860                 status = hub_port_resume(hdev_to_hub(udev->parent),

   1861                                 udev->portnum, udev);

   1862         } else {

   1863                 dev_dbg(&udev->dev, "usb %sresume/n",

   1864                                 udev->auto_pm ? "auto-" : "");

   1865                 status = finish_port_resume(udev);

   1866         }

   1867         if (status < 0)

   1868                 dev_dbg(&udev->dev, "can't resume, status %d/n", status);

   1869         return status;

   1870 }

结构很清晰,对于非Root Hub,调用hub_port_resume,对于Root Hub,调用finish_port_resume,先看前者再看后者.

   1770 static int

   1771 hub_port_resume(struct usb_hub *hub, int port1, struct usb_device *udev)

   1772 {

   1773         int     status;

   1774         u16     portchange, portstatus;

   1775

   1776         /* Skip the initial Clear-Suspend step for a remote wakeup */

   1777         status = hub_port_status(hub, port1, &portstatus, &portchange);

   1778         if (status == 0 && !(portstatus & USB_PORT_STAT_SUSPEND))

   1779                 goto SuspendCleared;

   1780

   1781         // dev_dbg(hub->intfdev, "resume port %d/n", port1);

   1782

   1783         set_bit(port1, hub->busy_bits);

   1784

   1785         /* see 7.1.7.7; affects power usage, but not budgeting */

   1786         status = clear_port_feature(hub->hdev,

   1787                         port1, USB_PORT_FEAT_SUSPEND);

   1788         if (status) {

   1789                 dev_dbg(hub->intfdev,

   1790                         "can't resume port %d, status %d/n",

   1791                         port1, status);

   1792         } else {

   1793                 /* drive resume for at least 20 msec */

   1794                 if (udev)

   1795                         dev_dbg(&udev->dev, "usb %sresume/n",

   1796                                         udev->auto_pm ? "auto-" : "");

   1797                 msleep(25);

   1798

   1799 #define LIVE_FLAGS      ( USB_PORT_STAT_POWER /

   1800                         | USB_PORT_STAT_ENABLE /

   1801                         | USB_PORT_STAT_CONNECTION)

   1802

   1803                 /* Virtual root hubs can trigger on GET_PORT_STATUS to

   1804                  * stop resume signaling.  Then finish the resume

   1805                  * sequence.

   1806                  */

   1807                 status = hub_port_status(hub, port1, &portstatus, &portchange);

   1808 SuspendCleared:

   1809                 if (status < 0

   1810                                 || (portstatus & LIVE_FLAGS) != LIVE_FLAGS

   1811                                 || (portstatus & USB_PORT_STAT_SUSPEND) != 0

   1812                                 ) {

   1813                         dev_dbg(hub->intfdev,

   1814                                 "port %d status %04x.%04x after resume, %d/n",

   1815                                 port1, portchange, portstatus, status);

   1816                         if (status >= 0)

   1817                                 status = -ENODEV;

   1818                 } else {

   1819                         if (portchange & USB_PORT_STAT_C_SUSPEND)

   1820                                 clear_port_feature(hub->hdev, port1,

   1821                                                 USB_PORT_FEAT_C_SUSPEND);

   1822                         /* TRSMRCY = 10 msec */

   1823                         msleep(10);

   1824                         if (udev)

   1825                                 status = finish_port_resume(udev);

   1826                 }

   1827         }

   1828         if (status < 0)

   1829                 hub_port_logical_disconnect(hub, port1);

   1830

   1831         clear_bit(port1, hub->busy_bits);

   1832         if (!hub->hdev->parent && !hub->busy_bits[0])

   1833                 usb_enable_root_hub_irq(hub->hdev->bus);

   1834

   1835         return status;

   1836 }

看起来还挺复杂.但目的很明确,唤醒这个hub端口.首先是察看该port是否已经是resume了.然后最直观最实在的代码就是1786行那个clear_port_feature,这行代码很显然是和hub_port_suspend中那行set_port_feature遥相呼应的.你给hub port设置了USB_PORT_FEAT_SUSPEND,我就给你清掉,偏要跟你对着干.

如果成功了,status为0,进入1792行这个else,睡眠25ms,usb spec 2.0规定,resume信号应该维持至少20毫秒才能有效,这个时间被称为T_DRSMDN.这个道理很显然,我们说技术是无国界的,今天早上在城铁上看见一个女的用小刀割伤了一个男的手,说那哥们对人家性骚扰,那么这道理是一样的,只有性骚扰持续了一段时间,那女的才能感觉到,否则你比如说那个男的技术足够好,那手从人家某部位像闪电一样过去,那估计双方都没有任何感觉.

1807至1826行这里是一种特殊情况,你这里想得很周到,睡眠25ms,可是Root Hub可能会把你的resume信号给stop掉,只要它在这期间发送了GET_PORT_STATUS请求.所以这里就再次读取端口的状态,如果这个端口对应的USB_PORT_STAT_POWER/USB_PORT_STAT_ENABLE/USB_PORT_STAT_CONNECTION中有一位为0,那么说明出错了,也就不用继续折腾了.而如果USB_PORT_STAT_SUSPEND这一位又被设置了,那么咱的猜测也就对了.这种情况咱们这里先把status设置为-ENODEV.

如果不是以上情况,那么1818行进去.如果SUSPEND位确实有变化,说明resume操作基本上达到了目的,那么先清掉这一位.睡眠10ms,这个10毫秒被称为T_RSMRCY,或称为resume恢复时间(resume recovery time),这个道理也很简单,通常我睡一觉醒来之后必然不是马上很清醒,肯定还需要一段时间恢复一下,特别是前一天晚上玩游戏玩到半夜,第二天又有喜欢点名的变态老师的课,那么我基本上是匆匆从南区赶到本部教室,但意识却还未清醒,不过我和设备不同的是,设备恢复了之后就可以工作了,而我赶到教室之后就是接着睡.

   1709 /*

   1710  * If the USB "suspend" state is in use (rather than "global suspend"),

   1711  * many devices will be individually taken out of suspend state using

   1712  * special" resume" signaling.  These routines kick in shortly after

   1713  * hardware resume signaling is finished, either because of selective

   1714  * resume (by host) or remote wakeup (by device) ... now see what changed

   1715  * in the tree that's rooted at this device.

   1716  */

   1717 static int finish_port_resume(struct usb_device *udev)

   1718 {

   1719         int     status;

   1720         u16     devstatus;

   1721

   1722         /* caller owns the udev device lock */

   1723         dev_dbg(&udev->dev, "finish resume/n");

   1724

   1725         /* usb ch9 identifies four variants of SUSPENDED, based on what

   1726          * state the device resumes to.  Linux currently won't see the

   1727          * first two on the host side; they'd be inside hub_port_init()

   1728          * during many timeouts, but khubd can't suspend until later.

   1729          */

   1730         usb_set_device_state(udev, udev->actconfig

   1731                         ? USB_STATE_CONFIGURED

   1732                         : USB_STATE_ADDRESS);

   1733

   1734         /* 10.5.4.5 says be sure devices in the tree are still there.

   1735          * For now let's assume the device didn't go crazy on resume,

   1736          * and device drivers will know about any resume quirks.

   1737          */

   1738         status = usb_get_status(udev, USB_RECIP_DEVICE, 0, &devstatus);

   1739         if (status >= 0)

   1740                 status = (status == 2 ? 0 : -ENODEV);

   1741

   1742         if (status)

   1743                 dev_dbg(&udev->dev,

   1744                         "gone after usb resume? status %d/n",

   1745                         status);

   1746         else if (udev->actconfig) {

   1747                 le16_to_cpus(&devstatus);

   1748                 if ((devstatus & (1 << USB_DEVICE_REMOTE_WAKEUP))

   1749                                 && udev->parent) {

   1750                         status = usb_control_msg(udev,

   1751                                         usb_sndctrlpipe(udev, 0),

   1752                                         USB_REQ_CLEAR_FEATURE,

   1753                                                 USB_RECIP_DEVICE,

   1754                                         USB_DEVICE_REMOTE_WAKEUP, 0,

   1755                                         NULL, 0,

   1756                                         USB_CTRL_SET_TIMEOUT);

   1757                         if (status)

   1758                                 dev_dbg(&udev->dev, "disable remote "

   1759                                         "wakeup, status %d/n", status);

   1760                 }

   1761                 status = 0;

   1762

   1763         } else if (udev->devnum <= 0) {

   1764                 dev_dbg(&udev->dev, "bogus resume!/n");

   1765                 status = -EINVAL;

   1766         }

   1767         return status;

   1768 }

这个函数其实就是做一些收尾的工作.我们刚才在usb_port_resume中看到,对于Root Hub就是直接调用这个函数,因为Root Hub不存在说接在别的Hub口上的说法.

1730行调用usb_set_device_state设置状态, USB_STATE_CONFIGURED或者是USB_STATE_ADDRESS,如果配置好了,就记录为前者,如果没有配置好,就记录为后者.

1738行,如注释所言,spec 10.5.4.5节建议这么做.以确认设备还在,而不是说在suspend/resume的过程中被拔走了.于是调用usb_get_status,获取设备的状态,返回值是设备返回的数据的长度.按spec规定,返回的数据应该是16位,即2个bytes,所以1740行判断是否为2.如果为2,就将status置为0,并开始新的判断.即1742行的判断,

1746行,如果设备配置好了,然后设备又不是Root Hub,然后设备的Wakeup功能是enabled的,那么就发送ClearFeature请求把这个功能给关掉,因为很显然,当一个设备在醒来的时候就没有必要打开这个功能,只有在将要睡去的时候才有必要打开,就好比我们起床以后就会把闹钟关掉,只有在我们将要睡觉的时候才有必要定闹钟.

然后如果一切正常就返回0.看完finish_port_resume函数,我们回到hub_port_resume中来,接下来,如果status小于0,说明出了问题, 于是调用hub_port_logical_disconnect,

   1560 /*

   1561  * Disable a port and mark a logical connnect-change event, so that some

   1562  * time later khubd will disconnect() any existing usb_device on the port

   1563  * and will re-enumerate if there actually is a device attached.

   1564  */

   1565 static void hub_port_logical_disconnect(struct usb_hub *hub, int port1)

   1566 {

   1567         dev_dbg(hub->intfdev, "logical disconnect on port %d/n", port1);

   1568         hub_port_disable(hub, port1, 1);

   1569

   1570         /* FIXME let caller ask to power down the port:

   1571          *  - some devices won't enumerate without a VBUS power cycle

   1572          *  - SRP saves power that way

   1573          *  - ... new call, TBD ...

   1574          * That's easy if this hub can switch power per-port, and

   1575          * khubd reactivates the port later (timer, SRP, etc).

   1576          * Powerdown must be optional, because of reset/DFU.

   1577          */

   1578

   1579         set_bit(port1, hub->change_bits);

   1580         kick_khubd(hub);

   1581 }

很简单,这个函数其实就是先把该端口关了,然后重新枚举该设备.因为刚才的返回值为负值说明出了某种问题,但并不确定究竟是何种问题,所以最省事的办法就是重新初始化该端口.而1579行这个set_bit设置了hub->change_bits,于是我们在hub_events()中就会根据这个来处理这个端口.(kick_khubd会触发hub_events,这我们早就知道.)

这时候我们注意到,在hub_port_resume的一开始我们调用set_bit设置了该端口对应的busy_bits,而在hub_port_resume快结束的时候我们调用clear_bit清掉了这个busy_bits.唯一受此影响的函数是hub_events(),当初我们其实提过,但我们在对一个端口进行resume或者reset的时候,hub_events是不会对该端口进行任何操作的.

而1832行, busy_bits[0]为0就意味着所有的端口都没有处于resume或者reset阶段,hub->hdev->parent为NULL则意味着当前Hub是Root Hub,于是还是调用usb_enable_root_hub_irq,当初我们在hub_events()的结尾阶段也调用了这个函数.这就是调用host controller driver的一个函数hub_irq_enable,某些主机控制器的端口连接是使用以电平触发的中断,这类主机控制器的驱动会提供这样一个函数,这个和具体的硬件有关,各家的产品不一样,咱们就不多说了.

至此,hub_port_resume函数就返回了.回到usb_port_resume,我们发现其实这个函数我们也已经看完了,因为finish_port_resume不小心也被我们讲完了.于是我们回到了usb_resume_device,如果一切Ok,那么dev.power.power_state.event也就设置为PM_EVENT_ON.

然后我们经过跋山涉水翻山越岭之后再次回到了usb_resume_both.1150行,如果是Root Hub,进入else,我们一直说Root Hub没有parent,其实这是不严谨的.我们注意到struct usb_device结构体有一个成员struct usb_device *parent,同时我们还注意到struct device结构体本身也有一个成员struct device *parent,其实对于Root Hub来说,是没有前者的那个parent,但是却有后者这个parent,后者的这个parent就是相应的Host Controller所对应的struct device结构体指针.所以这里的意思就很明白了,如果主机控制器没醒的话,Root Hub以及其它的子设备再怎么玩也白搭.

如果Host Controller醒来了,那么1159行,对Root Hub来说,也调用usb_resume_device去唤醒它.

1161行这个else的意思更直接,如果设备根本就没睡眠,那就没有什么唤醒它的意义了,调用usb_resume_device也不会做什么实事,无非就是设置dev.power_power_state.event为PM_EVENT_ON,仅此而已.

1168行,满足了集体的,再来满足个人的,社会主义制度优越性再次被体现.usb_resume_interface按照interface的个数来循环调用,

    887 /* Caller has locked intf's usb_device's pm_mutex */

    888 static int usb_resume_interface(struct usb_interface *intf)

    889 {

    890         struct usb_driver       *driver;

    891         int                     status = 0;

    892

    893         if (interface_to_usbdev(intf)->state == USB_STATE_NOTATTACHED ||

    894                         is_active(intf))

    895                 goto done;

    896

    897         /* Don't let autoresume interfere with unbinding */

    898         if (intf->condition == USB_INTERFACE_UNBINDING)

    899                 goto done;

    900

    901         /* Can't resume it if it doesn't have a driver. */

    902         if (intf->condition == USB_INTERFACE_UNBOUND) {

    903                 status = -ENOTCONN;

    904                 goto done;

    905         }

    906         driver = to_usb_driver(intf->dev.driver);

    907

    908         if (driver->resume) {

    909                 status = driver->resume(intf);

    910                 if (status)

    911                         dev_err(&intf->dev, "%s error %d/n",

    912                                         "resume", status);

    913                 else

    914                         mark_active(intf);

    915         } else {

    916                 dev_warn(&intf->dev, "no resume for driver %s?/n",

    917                                 driver->name);

    918                 mark_active(intf);

    919         }

    920

    921 done:

    922         // dev_dbg(&intf->dev, "%s: status %d/n", __FUNCTION__, status);

    923         if (status == 0)

    924                 intf->dev.power.power_state.event = PM_EVENT_ON;

    925         return status;

    926 }

898行,关于struct usb_interface结构体的成员condition我们当初在usb_reset_composite_device中已经讲过,一共有四种状况,其含义正如其字面意义那样,无需多说.

908行至919行这一段不用解释你也该明白吧,看过了当初那个usb_suspend_interface()函数之后,我相信即便是西直门城铁站外面每天晚上等着招呼大家坐他的黑车的司机朋友也该知道现在这段代码的含义了.这里的mark_active和当初的那个mark_quiesced相对应,一个唱红脸一个唱白脸.而909行那个driver->resume()就是调用属于该interface的驱动程序的resume函数,对于hub driver,调用的自然就是hub_resume,和前面那个hub_suspend相对应.

   1962 static int hub_resume(struct usb_interface *intf)

   1963 {

   1964         struct usb_hub          *hub = usb_get_intfdata (intf);

   1965         struct usb_device       *hdev = hub->hdev;

   1966         int                     status;

   1967

   1968         dev_dbg(&intf->dev, "%s/n", __FUNCTION__);

   1969

   1970         /* "global resume" of the downstream HC-to-USB interface */

   1971         if (!hdev->parent) {

   1972                 struct usb_bus  *bus = hdev->bus;

   1973                 if (bus) {

   1974                         status = hcd_bus_resume (bus);

   1975                         if (status) {

   1976                                 dev_dbg(&intf->dev, "'global' resume %d/n",

   1977                                         status);

   1978                                 return status;

   1979                         }

   1980                 } else

   1981                         return -EOPNOTSUPP;

   1982                 if (status == 0) {

   1983                         /* TRSMRCY = 10 msec */

   1984                         msleep(10);

   1985                 }

   1986         }

   1987

   1988         /* tell khubd to look for changes on this hub */

   1989         hub_activate(hub);

   1990         return 0;

   1991 }

一路走来的兄弟们现在看着个函数是不是觉得有点小儿科,相当于一个游戏机高手去玩魂斗罗,菜鸟调出30条命来还未必能通关,可是高手也许一条命就能玩过八关(魂斗罗一代).这个函数我想就没有必要讲了,我们完全可以一目十行,它和hub_suspend实在是太他妈的对称了.对于Roob Hub,需要调用hcd_bus_resume,这个host controller driver那边的resume函数.最后调用hub_activate()彻底激活hub.

至此 , 我们算是把 usb_resume_both 看完了 , 看完了 usb_resume_both, 也看完了 usb_suspend_both, 我们就算是基本上知道了整个 usb 子系统是如何支持电源管理的 , 或者说如何支持 PM core 的 .