1. 17 9月, 2020 1 次提交
    • Q
      ehci-hcd: Move include to keep CRC stable · 29231826
      Quentin Perret 提交于
      The CRC calculation done by genksyms is triggered when the parser hits
      EXPORT_SYMBOL*() macros. At this point, genksyms recursively expands the
      types of the function parameters, and uses that as the input for the CRC
      calculation. In the case of forward-declared structs, the type expands
      to 'UNKNOWN'. Following this, it appears that the result of the
      expansion of each type is cached somewhere, and seems to be re-used
      when/if the same type is seen again for another exported symbol in the
      same C file.
      
      Unfortunately, this can cause CRC 'stability' issues when a struct
      definition becomes visible in the middle of a C file. For example, let's
      assume code with the following pattern:
      
          struct foo;
      
          int bar(struct foo *arg)
          {
      	/* Do work ... */
          }
          EXPORT_SYMBOL_GPL(bar);
      
          /* This contains struct foo's definition */
          #include "foo.h"
      
          int baz(struct foo *arg)
          {
      	/* Do more work ... */
          }
          EXPORT_SYMBOL_GPL(baz);
      
      Here, baz's CRC will be computed using the expansion of struct foo that
      was cached after bar's CRC calculation ('UNKOWN' here). But if
      EXPORT_SYMBOL_GPL(bar) is removed from the file (because of e.g. symbol
      trimming using CONFIG_TRIM_UNUSED_KSYMS), struct foo will be expanded
      late, during baz's CRC calculation, which now has visibility over the
      full struct definition, hence resulting in a different CRC for baz.
      
      The proper fix for this certainly is in genksyms, but that will take me
      some time to get right. In the meantime, we have seen one occurrence of
      this in the ehci-hcd code which hits this problem because of the way it
      includes C files halfway through the code together with an unlucky mix
      of symbol trimming.
      
      In order to workaround this, move the include done in ehci-hub.c early
      in ehci-hcd.c, hence making sure the struct definitions are visible to
      the entire file. This improves CRC stability of the ehci-hcd exports
      even when symbol trimming is enabled.
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NQuentin Perret <qperret@google.com>
      Link: https://lore.kernel.org/r/20200916171825.3228122-1-qperret@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29231826
  2. 10 7月, 2020 1 次提交
  3. 22 8月, 2019 1 次提交
  4. 03 6月, 2019 1 次提交
  5. 28 9月, 2018 1 次提交
  6. 20 9月, 2018 1 次提交
  7. 25 6月, 2018 1 次提交
  8. 31 5月, 2018 1 次提交
  9. 26 3月, 2018 1 次提交
  10. 07 11月, 2017 1 次提交
  11. 04 11月, 2017 1 次提交
  12. 02 11月, 2017 1 次提交
  13. 16 3月, 2017 1 次提交
  14. 28 2月, 2017 1 次提交
  15. 05 10月, 2016 1 次提交
  16. 09 8月, 2016 1 次提交
  17. 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
  18. 05 2月, 2016 1 次提交
  19. 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
  20. 25 1月, 2016 1 次提交
  21. 05 12月, 2015 1 次提交
  22. 10 11月, 2015 1 次提交
  23. 31 5月, 2015 1 次提交
  24. 25 5月, 2015 1 次提交
  25. 08 4月, 2015 1 次提交
  26. 10 1月, 2015 1 次提交
  27. 26 11月, 2014 1 次提交
  28. 04 11月, 2014 1 次提交
  29. 24 9月, 2014 1 次提交
  30. 20 9月, 2014 1 次提交
  31. 27 2月, 2014 1 次提交
  32. 04 12月, 2013 3 次提交
  33. 20 10月, 2013 1 次提交
  34. 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
  35. 12 10月, 2013 2 次提交
    • 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
新手
引导
客服 返回
顶部