1. 02 11月, 2017 1 次提交
  2. 16 3月, 2017 1 次提交
  3. 28 2月, 2017 1 次提交
  4. 05 10月, 2016 1 次提交
  5. 09 8月, 2016 1 次提交
  6. 08 6月, 2016 1 次提交
    • S
      usb: echi-hcd: Add ehci_setup check before echi_shutdown · 11c011a5
      Srinivas Kandagatla 提交于
      This patch protects system from crashing at shutdown in
      cases where usb host is not added yet from OTG controller driver.
      As ehci_setup() not done yet, so stop accessing registers or
      variables initialized as part of ehci_setup().
      
      The use case is simple, for boards like DB410c where the usb host
      or device functionality is decided based on the micro-usb cable
      presence. If the board boots up with micro-usb connected, the
      OTG driver like echi-msm would not add the usb host by default.
      However a system shutdown would go and access registers and
      uninitialized variables, resulting in below crash.
      
      Unable to handle kernel NULL pointer dereference at virtual address
       00000008
      pgd = ffffffc034581000
      [00000008] *pgd=0000000000000000, *pud=0000000000000000
      CPU: 2 PID: 1957 Comm: reboot Not tainted 4.6.0+ #99
      task: ffffffc034bc0000 ti: ffffffc0345cc000 task.ti: ffffffc0345cc000
      PC is at ehci_halt+0x54/0x108
      LR is at ehci_halt+0x38/0x108
      pc : [<ffffff800869837c>] lr : [<ffffff8008698360>] pstate: a00001c5
      sp : ffffffc0345cfc60
      x29: ffffffc0345cfc60 x28: ffffffc0345cc000
      x27: ffffff8008a4d000 x26: 000000000000008e
      x25: ffffff8008d86cb0 x24: ffffff800908b040
      x23: ffffffc036068870 x22: ffffff8009d0a000
      x21: ffffffc03512a410 x20: ffffffc03512a410
      x19: ffffffc03512a338 x18: 00000000000065ba
      x17: ffffff8009b16b80 x16: 0000000000000003
      x15: 00000000000065b9 x14: 00000000000065b6
      x13: 0000000000000000 x12: 0000000000000000
      x11: 000000000000003d x10: ffffffc0345cf9e0
      x9 : 0000000000000001 x8 : ffffffc0345cc000
      x7 : ffffff8008698360 x6 : 0000000000000000
      x5 : 0000000000000080 x4 : 0000000000000001
      x3 : 0000000000000000 x2 : 0000000000000000
      x1 : 0000000000000008 x0 : ffffffc034bc0000
      
      Process reboot (pid: 1957, stack limit = 0xffffffc0345cc020)
      Stack: (0xffffffc0345cfc60 to 0xffffffc0345d0000)
      fc60: ffffffc0345cfc90 ffffff8008698448 ffffffc03512a338 ffffffc03512a338
      fc80: ffffffc03512a410 ffffff8008a3bbfc ffffffc0345cfcc0 ffffff8008698548
      fca0: ffffffc03512a338 ffffffc03512a000 ffffffc03512a410 ffffff8009d0a000
      fcc0: ffffffc0345cfcf0 ffffff800865d2bc ffffffc036068828 ffffffc036068810
      fce0: ffffffc036003810 ffffff800853f43c ffffffc0345cfd00 ffffff800854338c
      fd00: ffffffc0345cfd10 ffffff800853f45c ffffffc0345cfd60 ffffff80080e0f48
      fd20: 0000000000000000 0000000001234567 ffffff8008f8c000 ffffff8008f8c060
      fd40: 0000000000000000 0000000000000015 0000000000000120 ffffff80080e0f30
      fd60: ffffffc0345cfd70 ffffff80080e1020 ffffffc0345cfd90 ffffff80080e12fc
      fd80: 0000000000000000 0000000001234567 0000000000000000 ffffff8008085e70
      fda0: 0000000000000000 0000005592905000 ffffffffffffffff 0000007f79daf1cc
      fdc0: 0000000000000000 0000000000000000 0000007ffcbb1198 000000000000000a
      fde0: 00000055928d3f58 0000000000000001 ffffffc034900000 00000000fffffffe
      fe00: ffffffc034900000 0000007f79da902c ffffffc0345cfe40 ffffff800820af38
      fe20: 0000000000000000 0000007ffcbb1078 ffffffffffffffff ffffff80081e9b38
      fe40: ffffffc0345cfe60 ffffff80081eb410 ffffffc0345cfe60 ffffff80081eb444
      fe60: ffffffc0345cfec0 ffffff80081ec4f4 0000000000000000 0000007ffcbb1078
      fe80: ffffffffffffffff 0000000000000015 ffffffc0345cfec0 0000007ffcbb1078
      fea0: 0000000000000002 000000000000000a ffffffffffffffff 0000000000000000
      fec0: 0000000000000000 ffffff8008085e70 fffffffffee1dead 0000000028121969
      fee0: 0000000001234567 0000000000000000 ffffffffffffffff 8080800000800000
      ff00: 0000800000808080 0000007ffcbb10f0 000000000000008e fefeff54918cb8c7
      ff20: 7f7f7f7fffffffff 0101010101010101 0000000000000010 0000000000000000
      ff40: 0000000000000000 0000007f79e33588 0000005592905eb8 0000007f79daf1b0
      ff60: 0000007ffcbb1340 0000005592906000 0000005592905000 0000005592906000
      ff80: 0000005592907000 0000000000000002 0000007ffcbb1d98 0000005592906000
      ffa0: 00000055928d2000 0000000000000000 0000000000000000 0000007ffcbb1aa0
      ffc0: 00000055928b819c 0000007ffcbb1aa0 0000007f79daf1cc 0000000000000000
      ffe0: fffffffffee1dead 000000000000008e 05ef555057155555 d555544d55d775d3
      Call trace:
      Exception stack(0xffffffc0345cfaa0 to 0xffffffc0345cfbc0)
      Set corner to 6
      faa0: ffffffc03512a338 ffffffc03512a410 ffffffc0345cfc60 ffffff800869837c
      fac0: ffffff8008114210 0000000100000001 ffffff8009ce1b20 ffffff8009ce5f20
      fae0: ffffffc0345cfb80 ffffff80081145a8 ffffffc0345cfc10 ffffff800810b924
      fb00: ffffffc0345cc000 00000000000001c0 ffffffc03512a410 ffffff8009d0a000
      fb20: ffffffc036068870 ffffff800908b040 ffffff8008d86cb0 000000000000008e
      fb40: ffffffc034bc0000 0000000000000008 0000000000000000 0000000000000000
      fb60: 0000000000000001 0000000000000080 0000000000000000 ffffff8008698360
      fb80: ffffffc0345cc000 0000000000000001 ffffffc0345cf9e0 000000000000003d
      fba0: 0000000000000000 0000000000000000 00000000000065b6 00000000000065b9
      [<ffffff800869837c>] ehci_halt+0x54/0x108
      [<ffffff8008698448>] ehci_silence_controller+0x18/0xcc
      [<ffffff8008698548>] ehci_shutdown+0x4c/0x64
      [<ffffff800865d2bc>] usb_hcd_platform_shutdown+0x1c/0x24
      [<ffffff800854338c>] platform_drv_shutdown+0x20/0x28
      [<ffffff800853f45c>] device_shutdown+0xf4/0x1b0
      [<ffffff80080e0f48>] kernel_restart_prepare+0x34/0x3c
      [<ffffff80080e1020>] kernel_restart+0x14/0x74
      [<ffffff80080e12fc>] SyS_reboot+0x110/0x21c
      [<ffffff8008085e70>] el0_svc_naked+0x24/0x28
      Code: 53001c42 350000a2 d5033e9f 91002021 (b9000022)
      
      Fixes 4bb3cad7 ("usb: host: ehci-msm: Register usb shutdown function")
      Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Tested-by: NPramod Gurav <pramod.gurav@linaro.org>
      Tested-by: NAndy Gross <andy.gross@linaro.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      11c011a5
  7. 05 2月, 2016 1 次提交
  8. 04 2月, 2016 3 次提交
    • A
      USB: EHCI: add a delay when unlinking an active QH · 87d61912
      Alan Stern 提交于
      Michael Reutman reports that an AMD/ATI EHCI host controller on one of
      his computers does not stop transferring data when an active bulk QH
      is unlinked from the async schedule.  Apparently that host controller
      fails to implement the IAA mechanism correctly when an active QH is
      unlinked.  This leads to data corruption, because the controller
      continues to update the QH in memory when the driver doesn't expect
      it.  As a result, the next URB submitted for that QH can hang, because
      the link pointers for the TD queue have been messed up.  This
      misbehavior is observed quite regularly.
      
      To be fair, the EHCI spec (section 4.8.2) says that active QHs should
      not be unlinked.  It goes on to recommend a procedure that involves
      waiting for the QH to go inactive before unlinking it.  In the real
      world this is impractical, not least because the QH may _never_ go
      inactive.  (What were they thinking?)  Sometimes we have no choice but
      to unlink an active QH.
      
      In an attempt to avoid the problems that can ensue, this patch changes
      how the driver decides when the unlink is complete.  In addition to
      waiting through two IAA cycles, in cases where the QH was not known to
      be inactive beforehand we now wait until a 2-ms period has elapsed
      with the host controller making no change to the QH data structure
      (the hw_current and hw_token fields in particular).  The intuition
      here is that after such a long period, the endpoint must be NAKing and
      hopefully the QH has been dropped from the host controller's internal
      cache.  There's no way to know if this reasoning is really valid --
      the spec is no help in this regard -- but at least this approach fixes
      Michael's problem.
      
      The test for whether the QH is already known to be inactive involves
      the reason for unlinking the QH originally.  If it was unlinked
      because it had halted, or it stopped in response to a short read, or
      it overlaid a dummy TD (a silicon bug), then it certainly is inactive.
      If it was unlinked because the TD queue was empty and no TDs have been
      added to the queue in the meantime, then it must be inactive.  Or if
      the hardware status indicates that the QH is currently halted (even if
      that wasn't the reason for unlinking it), then it is inactive.
      Otherwise, if none of those checks apply, we go through the 2-ms
      delay.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NMichael Reutman <mreutman@epiqsolutions.com>
      Tested-by: NMichael Reutman <mreutman@epiqsolutions.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      87d61912
    • A
      USB: EHCI: improve handling of the ehci->iaa_in_progress flag · f96fba0d
      Alan Stern 提交于
      This patch improves the way ehci-hcd handles the iaa_in_progress flag.
      The current code is somewhat careless in this regard:
      
      	The flag is meaningless when the root hub isn't running, most
      	particularly after the root hub has been suspended.  But in
      	start_iaa_cycle(), the driver checks the flag before checking
      	the root hub's state.  They should be checked in the opposite
      	order.
      
      	That routine also sets the flag too early, before it has
      	definitely committed to starting an IAA cycle.
      
      	The flag is turned off in end_unlink_async().  Upcoming
      	changes will call that routine at other times, not just at the
      	end of an IAA cycle.  The two actions are logically separate
      	(although related), so we separate out a new routine to be
      	called in place of end_unlink_async() whenever an IAA cycle
      	ends: end_iaa_cycle().
      
      	iaa_in_progress should be turned off when the root hub is
      	suspended -- we certainly don't want it still to be set when
      	the root hub resumes.  Therefore the call to
      	end_unlink_async() in ehci_bus_suspend() should also be
      	replaced with a call to end_iaa_cycle().
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f96fba0d
    • A
      USB: EHCI: store reason for unlinking a QH · fcc5184e
      Alan Stern 提交于
      This patch replaces the "exception" bitflag in the ehci_qh structure
      with a more explicit "unlink_reason" bitmask.  This is for use in the
      following patch, where we will need to have a good idea of the
      reason for unlinking a QH, not just "something exceptional happened".
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NMichael Reutman <mreutman@epiqsolutions.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fcc5184e
  9. 25 1月, 2016 1 次提交
  10. 05 12月, 2015 1 次提交
  11. 10 11月, 2015 1 次提交
  12. 31 5月, 2015 1 次提交
  13. 25 5月, 2015 1 次提交
  14. 08 4月, 2015 1 次提交
  15. 10 1月, 2015 1 次提交
  16. 26 11月, 2014 1 次提交
  17. 04 11月, 2014 1 次提交
  18. 24 9月, 2014 1 次提交
  19. 20 9月, 2014 1 次提交
  20. 27 2月, 2014 1 次提交
  21. 04 12月, 2013 3 次提交
  22. 20 10月, 2013 1 次提交
  23. 15 10月, 2013 1 次提交
    • A
      USB: EHCI: create per-TT bandwidth tables · b35c5009
      Alan Stern 提交于
      This patch continues the scheduling changes in ehci-hcd by adding a
      table to store the bandwidth allocation below each TT.  This will
      speed up the scheduling code, as it will no longer need to read
      through the entire schedule to compute the bandwidth currently in use.
      
      Properly speaking, the FS/LS budget calculations should be done in
      terms of full-speed bytes per microframe, as described in the USB-2
      spec.  However the driver currently uses microseconds per microframe,
      and the scheduling code isn't robust enough at this point to change
      over.  For the time being, we leave the calculations as they are.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b35c5009
  24. 12 10月, 2013 3 次提交
    • A
      USB: EHCI: use a bandwidth-allocation table · d0ce5c6b
      Alan Stern 提交于
      This patch significantly changes the scheduling code in ehci-hcd.
      Instead of calculating the current bandwidth utilization by trudging
      through the schedule and adding up the times used by the existing
      transfers, we will now maintain a table holding the time used for each
      of 64 microframes.  This will drastically speed up the bandwidth
      computations.
      
      In addition, it eliminates a theoretical bug.  An isochronous endpoint
      may have bandwidth reserved even at times when it has no transfers
      listed in the schedule.  The table will keep track of the reserved
      bandwidth, whereas adding up entries in the schedule would miss it.
      
      As a corollary, we can keep bandwidth reserved for endpoints even
      when they aren't in active use.  Eventually the bandwidth will be
      reserved when a new alternate setting is installed; for now the
      endpoint's reservation takes place when its first URB is submitted.
      
      A drawback of this approach is that transfers with an interval larger
      than 64 microframes will have to be charged for bandwidth as though
      the interval was 64.  In practice this shouldn't matter much;
      transfers with longer intervals tend to be rather short anyway (things
      like hubs or HID devices).
      
      Another minor drawback is that we will keep track of two different
      period and phase values: the actual ones and the ones used for
      bandwidth allocation (which are limited to 64).  This adds only a
      small amount of overhead: 3 bytes for each endpoint.
      
      The patch also adds a new debugfs file named "bandwidth" to display
      the information stored in the new table.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d0ce5c6b
    • A
      USB: EHCI: create a "periodic schedule info" struct · ffa0248e
      Alan Stern 提交于
      This patch begins the process of unifying the scheduling parameters
      that ehci-hcd uses for interrupt and isochronous transfers.  It
      creates an ehci_per_sched structure, which will be stored in both
      ehci_qh and ehci_iso_stream structures, and will contain the common
      scheduling information needed for both.
      
      Initially we merely create the new structure and move some existing
      fields into it.  Later patches will add more fields and utilize these
      structures in improved scheduling algorithms.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ffa0248e
    • A
      USB: EHCI: change toggle only upon successful reset · 27c4a31d
      Alan Stern 提交于
      ehci-hcd uses a value of 0 in an endpoint's toggle flag to indicate
      that the endpoint has been reset (and therefore the Data Toggle bit
      needs to be cleared in the endpoint's QH overlay region).
      
      The toggle flag should be set to 0 only when ehci_endpoint_reset()
      succeeds.  This patch moves the usb_settoggle() call into the
      appropriate branch of the "if" statement.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      27c4a31d
  25. 27 9月, 2013 1 次提交
  26. 24 9月, 2013 1 次提交
  27. 18 9月, 2013 1 次提交
  28. 31 8月, 2013 2 次提交
  29. 13 8月, 2013 3 次提交
    • M
      USB: EHCI: support running URB giveback in tasklet context · 428aac8a
      Ming Lei 提交于
      All 4 transfer types can work well on EHCI HCD after switching to run
      URB giveback in tasklet context, so mark all HCD drivers to support
      it.
      
      Also we don't need to release ehci->lock during URB giveback any more.
      
      >From below test results on 3 machines(2 ARM and one x86), time
      consumed by EHCI interrupt handler droped much without performance
      loss.
      
      1 test description
      1.1 mass storage performance test:
      - run below command 10 times and compute the average performance
      
          dd if=/dev/sdN iflag=direct of=/dev/null bs=200M count=1
      
      - two usb mass storage device:
      A: sandisk extreme USB 3.0 16G(used in test case 1 & case 2)
      B: kingston DataTraveler G2 4GB(only used in test case 2)
      
      1.2 uvc function test:
      - run one simple capture program in the below link
      
         http://kernel.ubuntu.com/~ming/up/capture.c
      
      - capture format 640*480 and results in High Bandwidth mode on the
      uvc device: Z-Star 0x0ac8/0x3450
      
      - on T410(x86) laptop, also use guvcview to watch video capture/playback
      
      1.3 about test2 and test4
      - both two devices involved are tested concurrently by above test items
      
      1.4 how to compute irq time(the time consumed by ehci_irq)
      - use trace points of irq:irq_handler_entry and irq:irq_handler_exit
      
      1.5 kernel
      3.10.0-rc3-next-20130528
      
      1.6 test machines
      Pandaboard A1: ARM CortexA9 dural core
      Arndale board: ARM CortexA15 dural core
      T410: i5 CPU 2.67GHz quad core
      
      2 test result
      2.1 test case1: single mass storage device performance test
      --------------------------------------------------------------------
      		upstream 		| patched
      		perf(MB/s)+irq time(us)	| perf(MB/s)+irq time(us)
      --------------------------------------------------------------------
      Pandaboard A1:  25.280(avg:145,max:772)	| 25.540(avg:14, max:75)
      Arndale board:  29.700(avg:33, max:129)	| 29.700(avg:10,  max:50)
      T410: 		34.430(avg:17, max:154*)| 34.660(avg:12, max:155)
      ---------------------------------------------------------------------
      
      2.2 test case2: two mass storage devices' performance test
      --------------------------------------------------------------------
      		upstream 			| patched
      		perf(MB/s)+irq time(us)		| perf(MB/s)+irq time(us)
      --------------------------------------------------------------------
      Pandaboard A1:  15.840/15.580(avg:158,max:1216)	| 16.500/16.160(avg:15,max:139)
      Arndale board:  17.370/16.220(avg:33 max:234)	| 17.480/16.200(avg:11, max:91)
      T410: 		21.180/19.820(avg:18 max:160)	| 21.220/19.880(avg:11, max:149)
      ---------------------------------------------------------------------
      
      2.3 test case3: one uvc streaming test
      - uvc device works well(on x86, luvcview can be used too and has
      same result with uvc capture)
      --------------------------------------------------------------------
      		upstream 		| patched
      		irq time(us)		| irq time(us)
      --------------------------------------------------------------------
      Pandaboard A1:  (avg:445, max:873)	| (avg:33, max:44)
      Arndale board:  (avg:316, max:630)	| (avg:20, max:27)
      T410: 		(avg:39,  max:107)	| (avg:10, max:65)
      ---------------------------------------------------------------------
      
      2.4 test case4: one uvc streaming plus one mass storage device test
      --------------------------------------------------------------------
      		upstream 		| patched
      		perf(MB/s)+irq time(us)	| perf(MB/s)+irq time(us)
      --------------------------------------------------------------------
      Pandaboard A1:  20.340(avg:259,max:1704)| 20.390(avg:24, max:101)
      Arndale board:  23.460(avg:124,max:726)	| 23.370(avg:15, max:52)
      T410: 		28.520(avg:27, max:169)	| 28.630(avg:13, max:160)
      ---------------------------------------------------------------------
      
      2.5 test case5: read single mass storage device with small transfer
      - run below command 10 times and compute the average speed
      
       dd if=/dev/sdN iflag=direct of=/dev/null bs=4K count=4000
      
      1), test device A:
      --------------------------------------------------------------------
      		upstream 		| patched
      		perf(MB/s)+irq time(us)	| perf(MB/s)+irq time(us)
      --------------------------------------------------------------------
      Pandaboard A1:  6.5(avg:21, max:64)	| 6.5(avg:10, max:24)
      Arndale board:  8.13(avg:12, max:23)	| 8.06(avg:7,  max:17)
      T410: 		6.66(avg:13, max:131)   | 6.84(avg:11, max:149)
      ---------------------------------------------------------------------
      
      2), test device B:
      --------------------------------------------------------------------
      		upstream 		| patched
      		perf(MB/s)+irq time(us)	| perf(MB/s)+irq time(us)
      --------------------------------------------------------------------
      Pandaboard A1:  5.5(avg:21,max:43)	| 5.49(avg:10, max:24)
      Arndale board:  5.9(avg:12, max:22)	| 5.9(avg:7, max:17)
      T410: 		5.48(avg:13, max:155)	| 5.48(avg:7, max:140)
      ---------------------------------------------------------------------
      
      * On T410, sometimes read ehci status register in ehci_irq takes more
      than 100us, and the problem has been reported on the link:
      
      	http://marc.info/?t=137065867300001&r=1&w=2Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      428aac8a
    • M
      USB: EHCI: improve interrupt qh unlink · 9118f9eb
      Ming Lei 提交于
      ehci-hcd currently unlinks an interrupt QH when it becomes empty, that
      is, after its last URB completes.  This works well because in almost
      all cases, the completion handler for an interrupt URB resubmits the
      URB; therefore the QH doesn't become empty and doesn't get unlinked.
      
      When we start using tasklets for URB completion, this scheme won't work
      as well.  The resubmission won't occur until the tasklet runs, which
      will be some time after the completion is queued with the tasklet.
      During that delay, the QH will be empty and so will be unlinked
      unnecessarily.
      
      To prevent this problem, this patch adds a 5-ms time delay before empty
      interrupt QHs are unlinked.  Most often, during that time the interrupt
      URB will be resubmitted and thus we can avoid unlinking the QH.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9118f9eb
    • M
      USB: EHCI: improve ehci_endpoint_disable · 35371e4f
      Ming Lei 提交于
      The patch does the below improvement:
      
      - think QH_STATE_COMPLETING as unlinking state since all URBs on the
      endpoint should be in unlinking or unlinked when doing endpoint_disable()
      
      - add "WARN_ON(!list_empty(&qh->qtd_list));" if qh->qh_state is
      QH_STATE_LINKED because there shouldn't be any active transfer in qh
      
      - when qh->qh_state is QH_STATE_LINKED, the QH(async or periodic)
      should be in its corresponding list, so the search through the async
      list isn't necessary.
      
      - unlink periodic QH to speed up unlinking if the QH is in linked
      state
      
      Basically, only the last one is related with this patchset because
      the assumption of "periodic qh self-unlinks on empty" isn't true
      any more when we introduce unlink-wait for periodic qh.
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      35371e4f
  30. 18 6月, 2013 2 次提交