1. 09 Mar, 2016 1 commit
  2. 05 Mar, 2016 4 commits
    • Greg Kroah-Hartman's avatar
      Merge tag 'phy-for-4.6' of... · a5675005
      Greg Kroah-Hartman authored
      Merge tag 'phy-for-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-testing
      
      Kishon writes:
      
      phy: for 4.6
      
      *) Add driver for rockchip Display Port PHY
      *) Add driver for the Rockchip SoC internal eMMC PHY
      *) Add usb-uart functionality in rockchip-usb
      *) cleanup rcar usb2 PHY driver
      *) Fix for randconfig error
      Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      a5675005
    • Peter Chen's avatar
      USB: core: let USB device know device node · 69bec725
      Peter Chen authored
      Although most of USB devices are hot-plug's, there are still some devices
      are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
      If these kinds of USB devices are multiple functions, and they can supply
      other interfaces like i2c, gpios for other devices, we may need to
      describe these at device tree.
      
      In this commit, it uses "reg" in dts as physical port number to match
      the phyiscal port number decided by USB core, if they are the same,
      then the device node is for the device we are creating for USB core.
      Signed-off-by: default avatarPeter Chen <peter.chen@freescale.com>
      Acked-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      69bec725
    • Reilly Grant's avatar
      usb: devio: Add ioctl to disallow detaching kernel USB drivers. · d883f52e
      Reilly Grant authored
      The new USBDEVFS_DROP_PRIVILEGES ioctl allows a process to voluntarily
      relinquish the ability to issue other ioctls that may interfere with
      other processes and drivers that have claimed an interface on the
      device.
      
      This commit also includes a simple utility to be able to test the
      ioctl, located at Documentation/usb/usbdevfs-drop-permissions.c
      
      Example (with qemu-kvm's input device):
      
          $ lsusb
          ...
          Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd
      
          $ usb-devices
          ...
          C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
          I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=02 Driver=usbhid
      
          $ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
          OK: privileges dropped!
          Available options:
          [0] Exit now
          [1] Reset device. Should fail if device is in use
          [2] Claim 4 interfaces. Should succeed where not in use
          [3] Narrow interface permission mask
          Which option shall I run?: 1
          ERROR: USBDEVFS_RESET failed! (1 - Operation not permitted)
          Which test shall I run next?: 2
          ERROR claiming if 0 (1 - Operation not permitted)
          ERROR claiming if 1 (1 - Operation not permitted)
          ERROR claiming if 2 (1 - Operation not permitted)
          ERROR claiming if 3 (1 - Operation not permitted)
          Which test shall I run next?: 0
      
      After unbinding usbhid:
      
          $ usb-devices
          ...
          I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=02 Driver=(none)
      
          $ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
          ...
          Which option shall I run?: 2
          OK: claimed if 0
          ERROR claiming if 1 (1 - Operation not permitted)
          ERROR claiming if 2 (1 - Operation not permitted)
          ERROR claiming if 3 (1 - Operation not permitted)
          Which test shall I run next?: 1
          OK: USBDEVFS_RESET succeeded
          Which test shall I run next?: 0
      
      After unbinding usbhid and restricting the mask:
      
          $ sudo ./usbdevfs-drop-permissions /dev/bus/usb/001/002
          ...
          Which option shall I run?: 3
          Insert new mask: 0
          OK: privileges dropped!
          Which test shall I run next?: 2
          ERROR claiming if 0 (1 - Operation not permitted)
          ERROR claiming if 1 (1 - Operation not permitted)
          ERROR claiming if 2 (1 - Operation not permitted)
          ERROR claiming if 3 (1 - Operation not permitted)
      Signed-off-by: default avatarReilly Grant <reillyg@chromium.org>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarEmilio López <emilio.lopez@collabora.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d883f52e
    • Greg Kroah-Hartman's avatar
      Merge tag 'usb-for-v4.6' of http://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next · 3d0712de
      Greg Kroah-Hartman authored
      Felipe writes:
      
      usb changes for v4.6 merge window
      
      This is almost all under drivers/usb/dwc2/. Many
      changes to the host side implementation of dwc2 have
      been done by Douglas Anderson.
      
      We also have USB 3.1 support added to the Gadget
      Framework and, because of that work, dwc3 got
      support to Synopsys new DWC_usb31 IP core.
      
      Other than these 2 important series, we also have
      the usual collection of non-critical fixes,
      Documentation updates, and minor changes all over
      the place.
      3d0712de
  3. 04 Mar, 2016 35 commits
    • Krzysztof Opasiak's avatar
      usb: gadget: f_acm: Fix configfs attr name · 0561f77e
      Krzysztof Opasiak authored
      Correct attribute name is port_num not num.
      
      Fixes: ea6bd6b1 ("usb-gadget/f_acm: use per-attribute show and store methods")
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarKrzysztof Opasiak <k.opasiak@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      0561f77e
    • Vladimir Zapolskiy's avatar
      usb: udc: lpc32xx: remove USB PLL and USB OTG clock management · 59e05272
      Vladimir Zapolskiy authored
      LPC32xx common clock framework driver correctly manages parent clocks
      of USB device clock, so there is no need to manually enable and
      disable them from the driver, which now depends only on a single USB
      device clock.
      Signed-off-by: default avatarVladimir Zapolskiy <vz@mleia.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      59e05272
    • Vladimir Zapolskiy's avatar
      usb: udc: lpc32xx: remove direct access to clock controller registers · c9083dd3
      Vladimir Zapolskiy authored
      Direct access to clock control registers can be safely removed, the
      task of clock management is done by platform clock driver based on
      common clock framework.
      Signed-off-by: default avatarVladimir Zapolskiy <vz@mleia.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      c9083dd3
    • Vladimir Zapolskiy's avatar
      usb: udc: lpc32xx: switch to clock prepare/unprepare model · 68726e77
      Vladimir Zapolskiy authored
      The driver requires to prepare/unprepare clocks to work properly on a
      platform with enabled common clock framework, otherwise unprepared
      clocks are not enabled:
      
          WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:728 clk_core_enable+0x2c/0xf0()
          Modules linked in:
          CPU: 0 PID: 1 Comm: swapper Not tainted 4.3.0-rc2+ #284
          Hardware name: LPC32XX SoC (Flattened Device Tree)
          Backtrace:
          [<>] (dump_backtrace) from [<>] (show_stack+0x18/0x1c)
          [<>] (show_stack) from [<>] (dump_stack+0x20/0x28)
          [<>] (dump_stack) from [<>] (warn_slowpath_common+0x90/0xb8)
          [<>] (warn_slowpath_common) from [<>] (warn_slowpath_null+0x24/0x2c)
          [<>] (warn_slowpath_null) from [<>] (clk_core_enable+0x2c/0xf0)
          [<>] (clk_core_enable) from [<>] (clk_enable+0x24/0x38)
          [<>] (clk_enable) from [<>] (lpc32xx_udc_probe+0x284/0x924)
          [<>] (lpc32xx_udc_probe) from [<>] (platform_drv_probe+0x50/0xa0)
          [<>] (platform_drv_probe) from [<>] (driver_probe_device+0x18c/0x408)
          [<>] (driver_probe_device) from [<>] (__driver_attach+0x70/0x94)
          [<>] (__driver_attach) from [<>] (bus_for_each_dev+0x74/0x98)
          [<>] (bus_for_each_dev) from [<>] (driver_attach+0x20/0x28)
          [<>] (driver_attach) from [<>] (bus_add_driver+0x11c/0x248)
          [<>] (bus_add_driver) from [<>] (driver_register+0xa4/0xe8)
          [<>] (driver_register) from [<>] (__platform_driver_register+0x50/0x64)
          [<>] (__platform_driver_register) from [<>] (__platform_driver_probe+0x54/0x100)
          [<>] (__platform_driver_probe) from [<>] (lpc32xx_udc_driver_init+0x1c/0x28)
          [<>] (lpc32xx_udc_driver_init) from [<>] (do_one_initcall+0x11c/0x1dc)
          [<>] (do_one_initcall) from [<>] (kernel_init_freeable+0x10c/0x1d4)
          [<>] (kernel_init_freeable) from [<>] (kernel_init+0x10/0xec)
          [<>] (kernel_init) from [<>] (ret_from_fork+0x14/0x24)
      Signed-off-by: default avatarVladimir Zapolskiy <vz@mleia.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      68726e77
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: gadget: fix giveback status code in usbhsg_pipe_disable() · 11ebf3ad
      Yoshihiro Shimoda authored
      A udc driver should set the giveback status to -ESHUTDOWN in
      usb_ep_disable(). Otherwise, a gadget driver (e.g. g_serial) might
      request next data wrongly and it is possible to cause kernel panic.
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      11ebf3ad
    • Simon Horman's avatar
      usb: gadget: renesas_usb3: Use ARCH_RENESAS · dd9fee67
      Simon Horman authored
      Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
      
      This is part of an ongoing process to migrate from ARCH_SHMOBILE to
      ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
      appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
      Acked-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      dd9fee67
    • John Youn's avatar
      usb: dwc2: Fix issues in dwc2_complete_non_isoc_xfer_ddma() · 1fc65989
      John Youn authored
      Fixes a static analysis issue in dwc2_complete_non_isoc_xfer_ddma(). The
      qtd was being passed to a function after being freed. It was not being
      used in the function so this doesn't fix any bugs. But it fixes up the
      warning and makes the code safer by setting qtd to NULL and not using it
      at all.
      Reported-by: default avatarFelipe Balbi <balbi@kernel.org>
      Signed-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      1fc65989
    • Antti Seppälä's avatar
      usb: dwc2: Add support for Lantiq ARX and XRX SoCs · 6c0c0951
      Antti Seppälä authored
      Add support for Lantiq ARX and XRX SoC families to the dwc2 driver.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarAntti Seppälä <a.seppala@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      6c0c0951
    • Maarten ter Huurne's avatar
      usb: phy: generic: Handle late registration of gadget · 2eafe93b
      Maarten ter Huurne authored
      It is possible for the VBUS detect GPIO interrupt to occur before
      nop_set_peripheral() is called, in which case otg->gadget is NULL.
      Signed-off-by: default avatarMaarten ter Huurne <maarten@treewalker.org>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      2eafe93b
    • Alexey Khoroshilov's avatar
      usb: gadget: bdc_udc: fix race condition in bdc_udc_exit() · cff5638e
      Alexey Khoroshilov authored
      bdc_ep_disable() expects to be called with bdc->lock held.
      The assumption is met in all the cases except for call from bdc_udc_exit(),
      that is called from bdc_remove(). As a result a race can happen or unheld
      bdc->lock can be unlocked in bdc_req_complete().
      
      The patch proposes to acquire-release bdc->lock around bdc_ep_disable()
      in bdc_udc_exit().
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      cff5638e
    • Petr Kulhavy's avatar
      usb: musb: core: added missing const qualifier to musb_hdrc_platform_data::config · ead22caf
      Petr Kulhavy authored
      The musb_hdrc_platform_data::config was defined as a non-const pointer.
      However some drivers (e.g. the ux500) set up this pointer to point to a
      static structure, which is potentially dangerous. Since the musb core
      uses the pointer in a read-only manner the const qualifier was added to
      protect the content of the config.
      Signed-off-by: default avatarPetr Kulhavy <petr@barix.com>
      Acked-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      ead22caf
    • John Youn's avatar
      usb: dwc2: Move host-specific core functions into hcd.c · b02038fa
      John Youn authored
      Move host core initialization and host channel routines into hcd.c. This
      allows these functions to only be compiled in host-enabled driver
      configurations (DRD or host-only).
      Tested-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      b02038fa
    • John Youn's avatar
      usb: dwc2: Move register save and restore functions · 58e52ff6
      John Youn authored
      Move the register save and restore functions into the host and gadget
      specific files.
      Tested-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      58e52ff6
    • Amitoj Kaur Chawla's avatar
      usb: dwc2: Use kmem_cache_free() · 9bbe91a1
      Amitoj Kaur Chawla authored
      Here, free memory is allocated using kmem_cache_zalloc.  So, use
      kmem_cache_free instead of kfree.
      
      This is done using Coccinelle and semantic patch used
      is as follows:
      
      //<smpl>
      @@
      expression x,E,c;
      @@
       x =
      \(kmem_cache_alloc\|kmem_cache_zalloc\|kmem_cache_alloc_node\)(c,...)
       ... when != x = E
           when != &x
      ?-kfree(x)
      +kmem_cache_free(c,x)
      //</smpl>
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarAmitoj Kaur Chawla <amitoj1606@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      9bbe91a1
    • Douglas Anderson's avatar
      usb: dwc2: host: If using uframe scheduler, end splits better · 1479cb69
      Douglas Anderson authored
      The microframe scheduler figured out exactly how many transfers we need
      for a split transaction.  Let's use this knowledge to know when to end
      things.
      
      Without this I found that certain devices would just keep responding
      with tons of NYET resonses on their INT_IN endpoint.  These would just
      keep going and going and eventually we'd decide to terminate the
      transfer (because the whole frame changed), but by that time the
      scheduler would decide that we "missed" the start of the next transfer.
      I can also imagine that if we blow past the end of our scheduled time we
      may mess up other things that were scheduled to happen.
      
      No known test cases are improved by this patch except that the scheduler
      code doesn't yell about MISSES constantly anymore.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      1479cb69
    • Douglas Anderson's avatar
      usb: dwc2: host: Totally redo the microframe scheduler · 9f9f09b0
      Douglas Anderson authored
      This totally reimplements the microframe scheduler in dwc2 to attempt to
      handle periodic splits properly.  The old code didn't even try, so this
      was a significant effort since periodic splits are one of the most
      complicated things in USB.
      
      I've attempted to keep the old "don't use the microframe" schduler
      around for now, but not sure it's needed.  It has also only been lightly
      tested.
      
      I think it's pretty certain that this scheduler isn't perfect and might
      have some bugs, but it seems much better than what was there before.
      With this change my stressful USB test (USB webcam + USB audio + some
      keyboards) crackles less.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      9f9f09b0
    • Douglas Anderson's avatar
      usb: dwc2: host: Properly set even/odd frame · 9cf1a601
      Douglas Anderson authored
      When setting up ISO and INT transfers dwc2 needs to specify whether the
      transfer is for an even or an odd frame (or microframe if the controller
      is running in high speed mode).
      
      The controller appears to use this as a simple way to figure out if a
      transfer should happen right away (in the current microframe) or should
      happen at the start of the next microframe.  Said another way:
      
      - If you set "odd" and the current frame number is odd it appears that
        the controller will try to transfer right away.  Same thing if you set
        "even" and the current frame number is even.
      - If the oddness you set and the oddness of the frame number are
        _different_, the transfer will be delayed until the frame number
        changes.
      
      As I understand it, the above technique allows you to plan ahead of time
      where possible by always working on the next frame.  ...but it still
      allows you to properly respond immediately to things that happened in
      the previous frame.
      
      The old dwc2_hc_set_even_odd_frame() didn't really handle this concept.
      It always looked at the frame number and setup the transfer to happen in
      the next frame.  In some cases that meant that certain transactions
      would be transferred in the wrong frame.
      
      We'll try our best to set the even / odd to do the transfer in the
      scheduled frame.  If that fails then we'll do an ugly "schedule ASAP".
      We'll also modify the scheduler code to handle this and not try to
      schedule a second transfer for the same frame.
      
      Note that this change relies on the work to redo the microframe
      scheduler.  It can work atop ("usb: dwc2: host: Manage frame nums better
      in scheduler") but it works even better after ("usb: dwc2: host: Totally
      redo the microframe scheduler").
      
      With this change my stressful USB test (USB webcam + USB audio +
      keyboards) has less audio crackling than before.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      9cf1a601
    • Douglas Anderson's avatar
      usb: dwc2: host: Add dwc2_hcd_get_future_frame_number() call · fae4e826
      Douglas Anderson authored
      As we start getting more exact about our scheduling it's becoming more
      and more important to know exactly how far through the current frame we
      are.  This lets us make decisions about whether there's still time left
      to start a new transaction in the current frame.
      
      We'll add dwc2_hcd_get_future_frame_number() which will tell you what
      the frame number will be a certain number of microseconds (us) from
      now.  We can use this information to help decide if there's enough time
      left in the frame for a transaction that will take a certain duration.
      
      This is expected to be used by a future change ("usb: dwc2: host:
      Properly set even/odd frame").
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      fae4e826
    • Douglas Anderson's avatar
      usb: dwc2: host: Manage frame nums better in scheduler · fb616e3f
      Douglas Anderson authored
      The dwc2 scheduler (contained in hcd_queue.c) was a bit confusing in the
      way it initted / kept track of which frames a QH was going to be active
      in.  Let's clean things up a little bit in preparation for a rewrite of
      the microframe scheduler.
      
      Specifically:
      * Old code would pick a frame number in dwc2_qh_init() and would try to
        pick it "in a slightly future (micro)frame".  As far as I can tell the
        reason for this was that there was a delay between dwc2_qh_init() and
        when we actually wanted to dwc2_hcd_qh_add().  ...but apparently this
        attempt to be slightly in the future wasn't enough because
        dwc2_hcd_qh_add() then had code to reset things if the frame _wasn't_
        in the future.  There's no reason not to just pick the frame later.
        For non-periodic QH we now pick the frame in dwc2_hcd_qh_add().  For
        periodic QH we pick the frame at dwc2_schedule_periodic() time.
      * The old "dwc2_qh_init() actually assigned to "hsotg->frame_number".
        This doesn't seem like a great idea since that variable is supposed to
        be used to keep track of which SOF the interrupt handler has seen.
        Let's be clean: anyone who wants the current frame number (instead of
        the one as of the last interrupt) should ask for it.
      * The old code wasn't terribly consistent about trying to use the frame
        that the microframe scheduler assigned to it.  In
        dwc2_sched_periodic_split() when it was scheduling the first frame it
        always "ORed" in 0x7 (!).  Since the frame goes on the wire 1 uFrame
        after next_active_frame it meant that the SSPLIT would always try for
        uFrame 0 and the transaction would happen on the low speed bus during
        uFrame 1.  This is irregardless of what the microframe scheduler
        said.
      * The old code assumed it would get called to schedule the next in a
        periodic split very quickly.  That is if next_active_frame was
        0 (transfer on wire in uFrame 1) it assumed it was getting called to
        schedule the next uFrame during uFrame 1 too (so it could queue
        something up for uFrame 2).  It should be possible to actually queue
        something up for uFrame 2 while in uFrame 2 (AKA queue up ASAP).  To
        do this, code needs to look at the previously scheduled frame when
        deciding when to next be active, not look at the current frame number.
      * If there was no microframe scheduler, the old code would check for
        whether we should be active using "qh->next_active_frame ==
        frame_number".  This seemed like a race waiting to happen.  ...plus
        there's no way that you wouldn't want to schedule if next_active_frame
        was actually less than frame number.
      
      Note that this change doesn't make 100% sense on its own since it's
      expecting some sanity in the frame numbers assigned by the microframe
      scheduler and (as per the future patch which rewries it) I think that
      the current microframe scheduler is quite insane.  However, it seems
      like splitting this up from the microframe scheduler patch makes things
      into smaller chunks and hopefully adds to clarity rather than reduces
      it.  The two patches could certainly be squashed.  Not that in the very
      least, I don't see any obvious bad behavior introduced with just this
      patch.
      
      I've attempted to keep the config parameter to disable the microframe
      scheduler in tact in this change, though I'm not sure it's worth it.
      Obviously the code is touched a lot so it's possible I regressed
      something when the microframe scheduler is disabled, though I did some
      basic testing and it seemed to work OK.  I'm still not 100% sure why you
      wouldn't want the microframe scheduler (presuming it works), so maybe a
      future patch (or a future version of this patch?) could remove that
      parameter.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      fb616e3f
    • Douglas Anderson's avatar
      usb: dwc2: host: Add scheduler logging for missed SOFs · 483bb254
      Douglas Anderson authored
      We'll use the new "scheduler verbose debugging" macro to log missed
      SOFs.  This is fast enough (assuming you configure it to use the ftrace
      buffer) that we can do it without worrying about the speed hit.  The
      overhead hit if the scheduler tracing is set to "no_printk" should be
      near zero.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      483bb254
    • Douglas Anderson's avatar
      usb: dwc2: host: Split code out to make dwc2_do_reserve() · 2d3f1398
      Douglas Anderson authored
      This no-op change splits code out of dwc2_schedule_periodic() into a
      dwc2_do_reserve() function.  This makes it a little easier to follow the
      logic.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      2d3f1398
    • Douglas Anderson's avatar
      usb: dwc2: host: Reorder things in hcd_queue.c · b951c6c7
      Douglas Anderson authored
      This no-op change just reorders a few functions in hcd_queue.c in order
      to prepare for future changes.  Motivations here:
      
      The functions dwc2_hcd_qh_free() and dwc2_hcd_qh_create() are exported
      functions.  They are not called within the file.  That means that they
      should be near the bottom so that they can easily call static helpers.
      
      The function dwc2_qh_init() is only called by dwc2_hcd_qh_create() and
      should move near the bottom with it.
      
      The only reason that the dwc2_unreserve_timer_fn() timer function (and
      its subroutine dwc2_do_unreserve()) were so high in the file was that
      they needed to be above dwc2_qh_init().  Now that dwc2_qh_init() has
      been moved down it can be moved down a bit.  A later patch will split
      the reserve code out of dwc2_schedule_periodic() and the reserve
      function should be near the unreserve function.  The reserve function
      needs to be below dwc2_find_uframe() since it calls that.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      b951c6c7
    • Douglas Anderson's avatar
      usb: dwc2: host: Rename some fields in struct dwc2_qh · ced9eee1
      Douglas Anderson authored
      This no-op change just does some renames to simplify a future patch.
      
      1. The "interval" field is renamed to "host_interval" to make it more
         obvious that this interval may be 8 times the interval that the
         device sees (if we're doing split transactions).  A future patch will
         also add the "device_interval" field.
      2. The "usecs" field is renamed to "host_us" again to make it more
         obvious that this is the time for the transaction as seen by the
         host.  For split transactions the device may see a much longer
         transaction time.  A future patch will also add "device_us".
      3. The "sched_frame" field is renamed to "next_active_frame".  The name
         "sched_frame" kept confusing me because it felt like something more
         permament (the QH's reservation or something).  The name
         "next_active_frame" makes it more obvious that this field is
         constantly changing.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      ced9eee1
    • Douglas Anderson's avatar
      usb: dwc2: host: Use periodic interrupt even with DMA · 4e50e011
      Douglas Anderson authored
      The old code in dwc2_process_periodic_channels() would only enable the
      "periodic empty" interrupt if we weren't using DMA.  That wasn't right
      since we can still get into cases where we have small FIFOs even on
      systems that have DMA (the rk3288 is a prime example).
      
      Let's always enable/disable the "periodic empty" when appropriate.  As
      part of this:
      
      * Always call dwc2_process_periodic_channels() even if there's nothing
        in periodic_sched_assigned (we move the queue empty check so we still
        avoid the extra work).  That will make extra certain that we will
        properly disable the "periodic empty" interrupt even if there's
        nothing queued up.
      
      * Move the enable of "periodic empty" due to non-empty
        periodic_sched_assigned to be for slave mode (non-DMA mode) only.
        Presumably this was the original intention of the check for DMA since
        it seems to match the comments above where in slave mode we leave
        things on the assigned queue.
      
      Note that even before this change slave mode didn't work for me, so I
      can't say for sure that my understanding of slave mode is correct.
      However, this shouldn't change anything for slave mode so if slave mode
      worked for someone in the past it ought to still work.
      
      With this change, I no longer get constant misses reported by my other
      debugging code (and with future patches) when I've got:
      * Rockchip rk3288 Chromebook, using port ff540000
        -> Pluggable 7-port Hub with Charging (powered)
           -> Microsoft Wireless Keyboard 2000 in port 1.
           -> Das Keyboard in port 2.
           -> Jabra Speaker in port 3
           -> Logitech, Inc. Webcam C600 in port 4
           -> Microsoft Sidewinder X6 Keyboard in port 5
      
      ...and I'm playing music on the USB speaker and capturing video from the
      webcam.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      4e50e011
    • Douglas Anderson's avatar
      usb: dwc2: host: There's not really a TT for the root hub · d82a810e
      Douglas Anderson authored
      I find that when I plug a full speed (NOT high speed) hub into a dwc2
      port and then I plug a bunch of devices into that full speed hub that
      dwc2 goes bat guano crazy.  Specifically, it just spews errors like this
      in the console:
        usb usb1: clear tt 1 (9043) error -22
      
      The specific test case I used looks like this:
      /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
          |__ Port 1: Dev 17, If 0, Class=Hub, Driver=hub/4p, 12M
              |__ Port 2: Dev 19, If 0, ..., Driver=usbhid, 1.5M
              |__ Port 4: Dev 20, If 0, ..., Driver=usbhid, 12M
              |__ Port 4: Dev 20, If 1, ..., Driver=usbhid, 12M
              |__ Port 4: Dev 20, If 2, ..., Driver=usbhid, 12M
      
      Showing VID/PID:
       Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
       Bus 001 Device 017: ID 03eb:3301 Atmel Corp. at43301 4-Port Hub
       Bus 001 Device 020: ID 045e:0745 Microsoft Corp. Nano Transceiver ...
       Bus 001 Device 019: ID 046d:c404 Logitech, Inc. TrackMan Wheel
      
      I spent a bunch of time trying to figure out why there are errors to
      begin with.  I believe that the issue may be a hardware issue where the
      transceiver sometimes accidentally sends a PREAMBLE packet if you send a
      packet to a full speed device right after one to a low speed device.
      Luckily the USB driver retries and the second time things work OK.
      
      In any case, things kinda seem work despite the errors, except for the
      "clear tt" spew mucking up my console.  Chalk it up for a win for
      retries and robust protocols.
      
      So getting back to the "clear tt" problem, it appears that we get those
      because there's not actually a TT here to clear.  It's my understanding
      that when dwc2 operates in low speed or full speed mode that there's no
      real TT out there.  That makes all these attempts to "clear the TT"
      somewhat meaningless and also causes the spew in the log.
      
      Let's just skip all the useless TT clears.  Eventually we should root
      cause the errors, but even if we do this is still a proper fix and is
      likely to avoid the "clear tt" error in the future.
      
      Note that hooking up a Full Speed USB Audio Device (Jabra 510) to this
      same hub with the keyboard / trackball shows that even audio works over
      this janky connection.  As a point to note, this particular change (skip
      bogus TT clears) compared to just commenting out the dev_err() in
      hub_tt_work() actually produces better audio.
      
      Note: don't ask me where I got a full speed USB hub or whether the
      massive amount of dust that accumulated on it while it was in my junk
      box affected its funtionality.  Just smile and nod.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Reviewed-by: default avatarKever Yang <kever.yang@rock-chips.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      d82a810e
    • Douglas Anderson's avatar
      usb: dwc2: host: Properly set the HFIR · 9ed04d97
      Douglas Anderson authored
      According to the most up to date version of the dwc2 databook, the FRINT
      field of the HFIR register should be programmed to:
      * 125 us * (PHY clock freq for HS) - 1
      * 1000 us * (PHY clock freq for FS/LS) - 1
      
      This is opposed to older versions of the doc that claimed it should be:
      * 125 us * (PHY clock freq for HS)
      * 1000 us * (PHY clock freq for FS/LS)
      
      In case you didn't spot it, the difference is the "- 1".
      
      Let's add the "- 1" to match the newest user manual.  It's presumed that
      the "- 1" should have always been there and that this was always a
      documentation error.  If some hardware needs the "- 1" and other
      hardware doesn't, we'll have to add a configuration parameter for it in
      the future.
      
      I checked things before and after this patch on rk3288 using a Total
      Phase Beagle 5000 analyzer.
      
      Before this patch, a low speed mouse shows constant Frame Timing Jitter
      errors.  After this patch errors have gone away.
      
      Before this patch SOF packets move forward about 1 us per 4 ms.  After
      this patch the SOF packets move backward about 1 us per 255 ms.  Some
      specific SOF timestamps from the analyzer are below.
      
      Before:
        6.603.790
        6.603.916
        6.604.041
        6.604.166
        ...
        6.607.541
        6.607.667
        6.607.792
        6.607.917
        ...
        6.611.417
        6.611.543
        6.611.668
        6.611.793
      
      After:
        6.215.159
        6.215.284
        6.215.408
        6.215.533
        6.215.658
        ...
        6.470.658
        6.470.783
        6.470.907
        ...
        6.726.032
        6.726.157
        6.725.281
        6.725.406
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      9ed04d97
    • Douglas Anderson's avatar
      usb: dwc2: host: Giveback URB in tasklet context · 8add17cf
      Douglas Anderson authored
      In commit 94dfd7ed ("USB: HCD: support giveback of URB in tasklet
      context") support was added to give back the URB in tasklet context.
      Let's take advantage of this in dwc2.
      
      This speeds up the dwc2 interrupt handler considerably.
      
      Note that this requires the change ("usb: dwc2: host: Add a delay before
      releasing periodic bandwidth") to come first.
      
      Note that, as per Alan Stern in
      <https://patchwork.kernel.org/patch/7555771/>, we also need to make sure
      that the extra delay before the device drivers submit more data doesn't
      break the scheduler.  At the moment the scheduler is pretty broken (see
      future patches) so it's hard to be 100% certain, but I have yet to see
      any new breakage introduced by this delay.  ...and speeding up interrupt
      processing for dwc2 is a huge deal because it means we've got a better
      chance of not missing SOF interrupts.  That means we've got an overall
      win here.
      
      Note that when playing USB audio and using a USB webcam and having
      several USB keyboards plugged in, the crackling on the USB audio device
      is noticably reduced with this patch.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      8add17cf
    • Douglas Anderson's avatar
      usb: dwc2: host: Add a delay before releasing periodic bandwidth · 17dd5b64
      Douglas Anderson authored
      We'd like to be able to use HCD_BH in order to speed up the dwc2 host
      interrupt handler quite a bit.  However, according to the kernel doc for
      usb_submit_urb() (specifically the part about "Reserved Bandwidth
      Transfers"), we need to keep a reservation active as long as a device
      driver keeps submitting.  That was easy to do when we gave back the URB
      in the interrupt context: we just looked at when our queue was empty and
      released the reserved bandwidth then.  ...but now we need a little more
      complexity.
      
      We'll follow EHCI's lead in commit 9118f9eb ("USB: EHCI: improve
      interrupt qh unlink") and add a 5ms delay.  Since we don't have a whole
      timer infrastructure in dwc2, we'll just add a timer per QH.  The
      overhead for this is very small.
      
      Note that the dwc2 scheduler is pretty broken (see future patches to fix
      it).  This patch attempts to replicate all old behavior and just add the
      proper delay.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      17dd5b64
    • Douglas Anderson's avatar
      usb: dwc2: host: Add scheduler tracing · 74fc4a75
      Douglas Anderson authored
      In preparation for future changes to the scheduler let's add some
      tracing that makes it easy for us to see what's happening.  By default
      this tracing will be off.
      
      By changing "core.h" you can easily trace to ftrace, the console, or
      nowhere.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarKever Yang <kever.yang@rock-chips.com>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      74fc4a75
    • Douglas Anderson's avatar
      usb: dwc2: host: fix split transfer schedule sequence · c9c8ac01
      Douglas Anderson authored
      We're supposed to keep outstanding splits in order.  Keep track of a
      list of the order of splits and process channel interrupts in that
      order.
      
      Without this change and the following setup:
      * Rockchip rk3288 Chromebook, using port ff540000
        -> Pluggable 7-port Hub with Charging (powered)
           -> Microsoft Wireless Keyboard 2000 in port 1.
           -> Das Keyboard in port 2.
      
      ...I find that I get dropped keys on the Microsoft keyboard (I'm sure
      there are other combinations that fail, but this documents my test).
      Specifically I've been typing "hahahahahahaha" on the keyboard and often
      see keys dropped or repeated.
      
      After this change the above setup works properly.  This patch is based
      on a previous patch proposed by Yunzhi Li ("usb: dwc2: hcd: fix periodic
      transfer schedule sequence")
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarYunzhi Li <lyz@rock-chips.com>
      Reviewed-by: default avatarKever Yang <kever.yang@rock-chips.com>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarKever Yang <kever.yang@rock-chips.com>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      c9c8ac01
    • Douglas Anderson's avatar
      usb: dwc2: host: Always add to the tail of queues · 94ef7aee
      Douglas Anderson authored
      The queues the the dwc2 host controller used are truly queues.  That
      means FIFO or first in first out.
      
      Unfortunately though the code was iterating through these queues
      starting from the head, some places in the code was adding things to the
      queue by adding at the head instead of the tail.  That means last in
      first out.  Doh.
      
      Go through and just always add to the tail.
      
      Doing this makes things much happier when I've got:
      * 7-port USB 2.0 Single-TT hub
      * - Microsoft 2.4 GHz Transceiver v7.0 dongle
      * - Jabra speakerphone playing music
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarKever Yang <kever.yang@rock-chips.com>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      94ef7aee
    • Douglas Anderson's avatar
      usb: dwc2: host: Avoid use of chan->qh after qh freed · 16e80218
      Douglas Anderson authored
      When poking around with USB devices with slub_debug enabled, I found
      another obvious use after free.  Turns out that in dwc2_hc_n_intr() I
      was in a state when the contents of chan->qh was filled with 0x6b,
      indicating that chan->qh was freed but chan still had a reference to
      it.
      
      Let's make sure that whenever we free qh we also make sure we remove a
      reference from its channel.
      
      The bug fixed here doesn't appear to be new--I believe I just got lucky
      and happened to see it while stress testing.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarKever Yang <kever.yang@rock-chips.com>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      16e80218
    • Douglas Anderson's avatar
      usb: dwc2: host: Set host_rx_fifo_size to 525 for rk3066 · 098c1ef8
      Douglas Anderson authored
      As documented in dwc2_calculate_dynamic_fifo(), host_rx_fifo_size should
      really be:
       2 * ((Largest Packet size / 4) + 1 + 1) + n
       with n = number of host channel.
      
      We have 9 host channels, so
       2 * ((1024/4) + 2) + 9 = 516 + 9 = 525
      
      We've got 960 / 972 total_fifo_size on rk3288 (and presumably on
      rk3066) and 525 + 128 + 256 = 909 so we're still under on both ports
      even when we increment by 5.
      
      In the future, it would be nice if dwc2_calculate_dynamic_fifo() could
      handle the "too small" FIFO case and come up with something more
      dynamically.  When we do that we can figure out how to allocate the
      extra 48 / 60 bytes of FIFO that we're currently wasting.
      
      NOTE: no known bugs are fixed by this patch, but it seems like a simple
      fix and ought to fix someone.
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarKever Yang <kever.yang@rock-chips.com>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      098c1ef8
    • Douglas Anderson's avatar
      usb: dwc2: host: Get aligned DMA in a more supported way · 3bc04e28
      Douglas Anderson authored
      All other host controllers who want aligned buffers for DMA do it a
      certain way.  Let's do that too instead of working behind the USB core's
      back.  This makes our interrupt handler not take forever and also rips
      out a lot of code, simplifying things a bunch.
      
      This also has the side effect of removing the 65535 max transfer size
      limit.
      
      NOTE: The actual code to allocate the aligned buffers is ripped almost
      completely from the tegra EHCI driver.  At some point in the future we
      may want to add this functionality to the USB core to share more code
      everywhere.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      3bc04e28
    • Douglas Anderson's avatar
      usb: dwc2: rockchip: Make the max_transfer_size automatic · 40eed7d7
      Douglas Anderson authored
      Previously we needed to set the max_transfer_size to explicitly be 65535
      because the old driver would detect that our hardware could support much
      bigger transfers and then would try to do them.  This wouldn't work
      since the DMA alignment code couldn't support it.
      
      Later in commit e8f8c14d ("usb: dwc2: clip max_transfer_size to
      65535") upstream added support for clipping this automatically.  Since
      that commit it has been OK to just use "-1" (default), but nobody
      bothered to change it.
      
      Let's change it to default now for two reasons:
      - It's nice to use autodetected params.
      - If we can remove the 65535 limit, we can transfer more!
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarFelipe Balbi <balbi@kernel.org>
      40eed7d7